A skipped purchase is not a deployment

Thirty-two per cent of organisations told McKinsey they declined at least one software purchase because agentic coding tools could build it internally — and the same survey found AI's contribution to EBIT essentially unchanged from 2025. Both facts are true because the first one measures a decision, not a system. A purchase declined is recorded at the cheapest moment that will ever exist for it: after the build cost collapsed, and before a single hour of run cost has been incurred.

What the survey actually says

McKinsey's State of AI ran from 4 May to 8 June 2026 and covers 1,719 respondents across 97 nations, weighted by each nation's contribution to global GDP. It is a serious instrument and the finding is a real one. It is worth reading the whole page it sits on rather than the sentence that travelled.

Finding	Figure	What it measures
Declined a software purchase, could build it with agentic coding tools	32%	A procurement decision, self-reported, at least once
Same, among "AI high performers"	Nearly half, vs 31% of peers	A correlation in a cross-sectional survey, direction unstated
AI contributed positively to EBIT	37%, essentially unchanged from 2025	Perceived financial impact at the enterprise level
At least experimenting with AI agents	62%	Any agent activity, from pilot to production
Have not begun scaling AI across the enterprise	Nearly two-thirds	Self-assessed scaling maturity

Nine points separate the most and least affected industries. This is not a technology-sector story.

The flatness of the industry spread is the first thing worth noticing. If this were hype concentrated among software firms, technology would be twenty points clear. Instead financial institutions sit at 36% and pharmaceutical and medical products at 33% — sectors with procurement processes designed specifically to prevent this kind of decision being made quickly. Something real is happening in the long tail of enterprise software purchasing.

The number is a decision, and decisions are cheap

The survey caught the first column. The bill arrives in the third.

Respondents were asked whether they decided against buying. They were not asked whether the replacement shipped, whether it passed a security review, whether the users it was meant to serve actually moved onto it, or whether it is still running twelve months later. Every one of those is a place where a build-instead-of-buy decision quietly reverses, and none of them is in the 32%.

This is not a criticism of the survey, which asked a well-formed question and got a clean answer. It is a criticism of how the number is being read. "A third of enterprises are replacing SaaS with agent-built software" is a claim about deployments. The data supports a claim about intentions, taken at the exact moment when building looks cheapest it ever will — because generating the first working version is now genuinely fast, and nothing else has happened yet.

Notice, too, what the same survey says a few paragraphs over. Roughly two-thirds of organisations have not begun scaling AI across the enterprise, and the share reporting a positive EBIT contribution from AI sat at 37%, essentially unchanged from 2025. The year in which a third of enterprises decided to build rather than buy is the year the aggregate financial return did not move. Those numbers are compatible — but only under the reading where the decisions are mostly still decisions.

What the licence was buying was never the code

One line item got an order of magnitude cheaper. The other seven changed owner.

Here is the part the arithmetic keeps dropping. A software licence is a bundle, and the code is the cheapest thing in it. The rest of the bundle is maintenance in perpetuity, security patching and vulnerability response, the audit reports and data processing agreements your compliance team relies on, integration testing against every other vendor's upgrade cycle, a support contract with somebody else's on-call rota, a roadmap paid for by other customers' problems, and contractual liability that sits on someone else's balance sheet.

An agent writing the software in an afternoon makes exactly one of those cheaper. The other seven transfer to you the moment the change merges, priced at zero in the decision and at engineering headcount forever after. That is not an argument against building — it is an argument for costing the thing you are actually acquiring, which is an obligation rather than an artefact. The wiki's build vs buy page makes the same case in slower detail, and it did not need agents to be true.

The asymmetry matters more than the totals. A licence you declined is easy to buy next year if the build disappoints — the vendor will be delighted to hear from you. A system three teams now depend on is not easy to unwind, and by the time the maintenance cost is legible, the reversal has a migration attached to it. Cheap to enter, expensive to exit, and the survey question captures only the entry.

The high-performer correlation almost certainly runs backwards

The finding most likely to be quoted in a strategy deck is that among "AI high performers" — the roughly 6% of respondents attributing more than 5% of EBIT to AI — close to half declined a purchase, against 31% of everyone else. The implied lesson writes itself: skip more purchases, become a high performer.

Read it the other way, which fits the mechanism much better. Owning software is a capability, and it is expensive to have. It requires a platform team, a deployment pipeline, an on-call rota, an evaluation harness for anything with a model in it, and a culture that treats internal tools as products rather than as someone's side project. Organisations that already have all of that can afford to own more of their stack, and they are also — for entirely separate reasons — the organisations getting measurable EBIT from AI. The survey is cross-sectional. It cannot distinguish "skipping purchases made them high performers" from "being high performers is what made skipping purchases survivable", and the second story requires no new assumptions.

The practical version of this test is one question, and it is not about the agent. Who is on the pager for this system in eighteen months, and have they been hired? If the answer is "the team that requested it", you have not replaced a vendor, you have moved a cost into a budget line that nobody is watching.

Where building instead is genuinely the right call

None of this means the 32% are wrong. There is a large, real category of enterprise software that was always overpriced for what it did, and agentic coding tools have made that visible in a way procurement could not argue with before.

The long tail of small tools. Forty thousand a year for a form, a table and an approval step was a market failure held up by the cost of building the alternative. That cost has genuinely collapsed, and this is the honest core of the finding.
Internal glue. Anything that exists because two systems you own do not talk to each other. There is no compliance surface, no external user, and no vendor was ever going to model your data properly anyway.
Where the vendor's data model fought yours. Teams have paid for years of workarounds to fit a product's assumptions. Building removes the mismatch rather than papering over it.
Things with a natural end date. A migration tool, a one-off reconciliation, a reporting job for a regulatory cycle that ends. Maintenance cost is bounded because the system is.

The failure mode is generalising from that list to systems of record — anything holding customer data, touching money, or carrying an audit obligation. Those are exactly the systems where the seven non-code line items dominate the licence price, and where "the agent wrote it" answers none of the questions your auditor will ask.

What to measure instead

If you are one of the 32%, the number that tells you whether it worked does not exist yet, and it will not arrive on its own. Instrument for it now, while the decisions are fresh enough to attribute.

Keep a register of skipped purchases. What it was, the quoted licence cost, who owns the replacement, and the date. Without this you cannot compute anything in a year, and nobody reconstructs it afterwards.
Measure at month 13, not month 1. Engineering hours spent on the replacement since launch, incidents attributable to it, and the compliance work that the vendor used to do. Compare that total to the licence you did not renew, honestly.
Count the ones that quietly died. The denominator matters more than the wins. A build programme where a third of the replacements were abandoned is still possibly a good trade — but you cannot know that if abandonments are never counted.
Watch the ownership signal. A system whose original author has left and whose next maintainer has not been named is a system you are about to re-buy. That is a leading indicator, and it is free to collect.
Separate the pilot from the estate. The other trap in this survey's territory is measuring agent adoption instead of agent outcomes — the pattern the agent pullback turned out to be made of.

The honest summary of the 32% is that enterprises have discovered they can build the long tail, and have not yet discovered what the long tail costs to keep. Both halves of that sentence will be measurable next year. Only the first one is measurable today, and it is the one everybody quoted.

FAQ

Is the 32% figure wrong?

No. It is a well-collected answer to the question that was asked: has your organisation decided against buying at least one software product or feature because agentic coding tools could build it internally. The problem is entirely in the retelling, where a decision becomes a deployment and "at least one" becomes a strategy.

Doesn't a positive EBIT number stuck at 37% just mean AI is overhyped?

It is more likely to mean the effects are still in flight. Two-thirds of organisations in the same survey say they have not begun scaling AI across the enterprise, and enterprise-level EBIT is a slow, heavily-mediated measure. The interesting reading is not "AI does not pay" but that the build-instead-of-buy decisions are being taken well ahead of any measurable return, which is normal and also worth knowing.

How do I cost an internal replacement properly before committing?

Price the seven non-code line items directly: maintenance hours per year, patching and dependency upgrades, the compliance artefacts you now have to produce yourself, on-call load, integration testing, the roadmap work nobody else will do for you, and the liability that no longer sits with a vendor. Then compare against the licence. If the replacement still wins on that basis, it is a genuinely good trade.

Does this mean my team should not build with coding agents?

It means build where the run cost is small and bounded — internal glue, small tools, anything with an end date — and be much more careful where it is not. The distinction is not how hard the software is to write, which is the axis the agent changed. It is how expensive the software is to keep, which the agent did not change at all.

What is the single earliest signal that a replacement is going wrong?

Nobody is named as its owner. Not "the team uses it" — a named person or rota accountable for its patching, its incidents and its next dependency upgrade. In practice, the replacements that get quietly re-purchased eighteen months later are almost always the ones that never had that name filled in.