AI Made Software Easier to Build. Not Easier to Run.
Code is becoming abundant. Differentiation, operational resilience, and accountability remain scarce.
A few months ago, I wrote that Artificial Intelligence will not kill software. It will kill average software. The central argument was that, as AI lowers the cost of building software, value shifts away from producing code and towards understanding what actually needs to be built.
A recent survey adds another dimension to that discussion.
According to McKinsey’s State of AI Global Survey 2026, 32% of respondents said their organization had decided not to purchase at least one software product or feature because it could build it internally with the help of coding agents.
This is a significant finding. But not because it proves that businesses are suddenly becoming software companies or that SaaS is approaching its end.
It shows something more limited — and at the same time more profound:
The barrier to creating software is falling much faster than the barrier to creating good software.
Today, a team can build in a matter of days what might have taken months only a few years ago. It can create an internal tool, a customer portal, a workflow, a reporting layer, or the first functional version of an application without the staffing and cost that would once have been required.
This changes the economics of development. It does not eliminate the economics of operation.
And this is where the next major challenge for businesses begins: they will be able to create more software than they can understand, differentiate, and operate responsibly.
“We can build it” is no longer enough to justify the decision
For many years, the high cost of software development acted as a natural filter. Before an organization decided to build something internally, it had to secure a budget, people, time, and technical support. That difficulty did not prevent only good ideas from moving forward. It also stopped many poorly conceived, unnecessary, or insufficiently examined implementations.
AI is weakening that filter.
When a prototype can appear within hours, the distance between an idea and its first visible interface almost disappears. This creates real opportunities. It allows smaller teams to test assumptions, automate tasks, and build solutions that would not previously have justified the investment.
But it also creates a new illusion: that because something can be built easily, it is worth building.
The right question is no longer whether we have the technical ability. In most cases, we soon will.
The right question is whether the system creates a capability the organization genuinely needs — and whether that capability justifies the responsibility that comes with operating it.
Another dashboard may be easy to produce. That does not mean it creates insight. Another workflow may automate certain steps. That does not mean it fixes the process. An AI assistant may provide quick answers. That does not mean those answers are reliable enough for the decisions they will influence.
Ease of implementation is not evidence of usefulness.
Building something does not mean creating something that makes a difference
As basic functionality becomes easier to produce, functionality itself loses some of its value as a source of differentiation.
If every competitor can create a similar interface, an equivalent workflow, or an AI assistant, those features no longer constitute a competitive advantage on their own. They become the new minimum standard.
The difference moves elsewhere:
- to how well the system understands the specific work it is meant to support;
- to whether it can handle real-world exceptions rather than only the standard flow;
- to the quality and provenance of its data;
- to its ability to integrate with existing operations;
- to the way it supports different people and levels of responsibility;
- and to whether it produces an outcome that cannot easily be replicated.
AI can help two companies build similar products. It does not automatically give them the same understanding of the market, the same domain experience, the same customer relationships, or the same data.
It may lower the cost of execution. It does not create a reason for the product to exist.
The real question, therefore, is not whether a business can now build internally a feature it used to buy. It is whether that feature forms part of a capability that differentiates the business — or is simply another technical obligation it will have to maintain.
Between prototype and production stands an entire organization
Today’s discussion around AI-assisted development focuses mainly on the moment of creation: how quickly the code was written, how many tests were generated, how many working hours were saved, and how much smaller the team needed to be for the first release.
These metrics matter. But they capture only the beginning of a system’s life.
Software is not finished when it starts running. That is when its real test begins.
A production system must be monitored. It must be protected. It must be updated as its dependencies, regulations, data, processes, and user needs change. It requires backups, recovery plans, identity and access management, audit trails, cost controls, and the ability to investigate failures.
Someone must respond when the system goes down at three in the morning. Someone must decide whether an output is reliable enough to affect a customer, a payment, or a business decision. Someone must understand which changes can be made without disrupting the systems that depend on it.
That “someone” is not a line of code.
It is people, roles, processes, knowledge, and accountability.
The gap between an impressive demo and a reliable production system is not merely technical. It is organizational.
When we measure production, but not the system
WiseTech, one of the world’s leading logistics software companies, reported in its 2026 results that more than 75% of its team uses AI tools, over 90% of its code is written or assisted by AI, and engineering productivity has increased by 45%.
These are impressive figures, and they show that the shift is no longer confined to small experiments. But the numbers alone do not tell us whether the software improved to the same degree.
The percentage of AI-assisted code measures how the software was produced. It does not measure how many defects reached production, how maintainable the system is, how quickly an incident can be resolved, whether security improved, or whether customers gained a meaningfully better capability.
Even the “90%” requires interpretation. It may include anything from simple code completions to entire components created by agents. It does not tell us who defined the architecture, who rejected incorrect suggestions, who assessed the consequences of a change, or who approved the final release.
Productivity in construction matters. But it should not be confused with the quality and resilience of the system being constructed.
AI does not remove the human. It relocates human value.
At the technology’s current stage of development, people remain a critical part of the process. Not simply because someone must check whether AI wrote the code correctly, but because people must make decisions that the system itself cannot yet make reliably or responsibly.
Which problem is worth solving?
Which request reflects a genuine need, and which merely reproduces an outdated way of working?
Which exception is important enough to reshape the entire architecture?
When should speed give way to security?
Which decision can be automated, and which requires human confirmation?
Who will accept responsibility when an outcome proves to be wrong?
AI can process requirements, data, code, and technical documentation. People must still understand what is often documented nowhere: the organization’s real priorities and contradictions, its informal processes, the relationships of responsibility, and the consequences of each choice.
The human role does not disappear. It moves away from manual production and towards interpretation, judgment, choice, and accountability.
The easier it becomes to build something, the more important the person becomes who decides what is worth building, how it should operate, and which consequences we are prepared to accept.
This is not a general declaration that human beings will remain irreplaceable forever, regardless of how the technology evolves. It reflects the reality of AI’s current maturity: AI can participate increasingly in execution, but it does not yet possess the broader understanding, institutional standing, or accountability required for critical decisions.
The new risk: build debt
We already know the concept of technical debt: expedient technical choices that allow a project to move forward today but create costs and constraints for tomorrow.
The AI era may create a broader problem: build debt.
Build debt accumulates when an organization creates more systems than it can meaningfully own. Applications with no clear product owner. Tools that depend on APIs and models whose cost or behavior may change. Automations that work, even though no one fully understands all their dependencies. Internal products that began as experiments and gradually became critical infrastructure without acquiring the corresponding governance.
Build debt does not necessarily appear as bad code. It may consist of functional, well-designed applications.
The problem is that the organization lacks the people, knowledge, processes, or commitment required to support them over time.
AI can lower the cost of the first release while simultaneously increasing the total number of systems requiring maintenance, oversight, and control. If operational capacity does not grow at a similar rate, the initial productivity gain may become a future operational burden.
This is neither the end of SaaS nor the triumph of custom development
It would be easy to interpret this trend as a return to custom software and a retreat from SaaS. Reality will probably be more complex.
General-purpose platforms will continue to offer considerable value wherever they provide much more than features: reliable operation, continuous improvement, security, compliance, support, economies of scale, and accumulated domain knowledge.
For many functions, buying a mature service will remain more sensible than assuming responsibility for the entire lifecycle of an internal solution.
At the same time, one-size-fits-all software will come under greater pressure. As customization becomes more affordable, organizations will be less willing to tolerate products that force their real processes into a generic model.
The result will not be an absolute victory for either SaaS or custom development. It will be a new divide between:
- abundant tools and applications that can be built easily;
- and systems worth operating because they embody real knowledge, differentiation, and operational resilience.
The value of a custom software company can no longer rest solely on development hours or its ability to produce code. It must lie in understanding the problem, designing the architecture, connecting the system to the real organization, and supporting it when the impressive first release is no longer new.
Before we decide to build
As the technical answer to “Can we build it?” becomes “yes” more often, organizations need stricter decision criteria — not looser ones.
Before launching a new internal application or AI-enabled capability, they should be able to answer at least the following questions:
- What specific capability will the organization acquire?
- Why should this capability be built internally rather than purchased?
- Which part of the solution creates genuine differentiation?
- Who will be responsible for its operation, security, and evolution?
- What is its total lifecycle cost, not merely the cost of the first release?
- What happens if the model, API, vendor, regulation, or internal team changes?
- What evidence will demonstrate that the system genuinely improved the operation?
If these questions have no answers, the fact that AI can create the application quickly is not a reason to proceed.
It may be a reason to stop and think more carefully.
Software’s next problem
Software is not becoming less important. It is becoming more available.
For precisely that reason, its mere existence will no longer be evidence of value.
The next generation of businesses will have access to more technological capability than any generation before it. They will be able to create tools, automations, and applications at a speed that would recently have been unimaginable.
The challenge will not be to exploit every possibility.
It will be to decide which possibilities are worth turning into systems.
Producing code does not mean you have created a product. Delivering an application does not mean you have created a capability. And putting something into production does not mean you can operate it reliably for years.
AI made software easier to build.
It did not make it easier to decide which software deserves to exist.
It did not make it easier to create something that genuinely makes a difference.
And, at least not yet, it has not relieved people of the responsibility to understand it, judge it, and keep it alive.