AI Coding Tools Changed Build vs Buy. Here's How Much.
Nearly a third of organisations have now declined to buy a software product because they could build the functionality in-house using AI coding tools. That is a real, measured shift — and it changes less about the decision than the headline suggests.
The claim that AI coding tools have "changed everything" about whether to build or buy software is overstated. The claim that they have changed nothing is wrong too. The actual shift is specific, measured, and smaller than the more dramatic framing suggests. This is a companion piece to our build vs buy framework.
The actual number
McKinsey's The State of AI in 2026 survey of 1,719 respondents across 97 nations found that 32% of organisations had decided against purchasing at least one software product or feature because they could build the functionality in-house using agentic coding tools. Among AI high performers, the figure rose to nearly half; among everyone else, it sat closer to 31%. (McKinsey — note McKinsey reuses this URL for each annual edition, so verify the figure matches the 2026 report when checking)
That is a genuine, measurable shift in purchasing behaviour. It is not evidence that building has become the default choice, or that buying has become obsolete — it describes roughly a third of organisations declining to buy at least one thing, not a third of all software decisions flipping from buy to build.
What AI coding tools actually change, mechanically
They lower the cost of producing code. A capability that would have taken a developer several days to build might now take considerably less time with AI assistance handling much of the boilerplate and routine implementation work.
What they do not change
They do not lower the cost of owning code. As we cover in the main build vs buy framework, the ongoing burden — maintenance, security patching, dependency updates, the institutional knowledge required to safely change the system — is the larger and more persistent cost in almost every software decision, and AI coding tools address none of it directly. Generated code still needs review, testing, and someone who understands it well enough to safely modify it at 2am when something breaks.
DORA's research found that even elite-performing engineering teams report spending only about 50% of their time on new work, the rest going to unplanned work, rework, defects and support. (DORA) Faster initial production of code does not reduce this ratio — if anything, a larger volume of AI-generated code without proportionally more review capacity could increase the share of time spent on defects and rework, not decrease it.
Where the shift is real and specific
Small, well-bounded internal tools that previously weren't worth a developer's time now clear the bar. This is the most genuine expansion the AI coding shift has produced: functionality that was always technically simple to build, but not economically justified when weighed against a developer's fully loaded cost, can now be produced fast enough to be worth building even for narrow, internal use cases.
The build estimate for genuinely new capability has become less certain in a specific direction — usually shorter, not longer, but the tail risk described in the peer-reviewed literature on project overruns has not disappeared. The largest study of IT project costs found no statistically significant relationship between project size and overrun risk (p = 0.863), and AI-assisted development speed does not address the underlying causes of that tail risk — ambiguous requirements, integration complexity, and undiscovered edge cases remain exactly where they were.
What this means practically
Apply the AI coding shift specifically to the smaller, more bounded end of your build vs buy decisions, where it genuinely changes the calculus, and resist applying it as a blanket justification for larger, differentiating builds where the ownership burden — not the initial build cost — was always the dominant factor. The main framework's five questions still apply unchanged; question four, about what the AI shift actually changes, is where this fits in the broader decision.
A caution about the number itself
32% is a self-reported figure from a single annual survey, describing what organisations say they decided, not an independently verified measurement of actual cost outcomes from those decisions. Treat it as a genuine and useful data point about a real behavioural shift, not as proof that the underlying economics of ownership have changed to the same degree.
What we do
We factor AI-assisted development speed into build estimates for genuinely bounded, internal-facing tools, while continuing to weigh the full ownership cost — not just the build speed — for anything more consequential. If you are weighing build vs buy and want the AI coding shift factored in honestly rather than used as a blanket argument for building, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.