What the survey found
McKinsey published The State of AI: Global Survey 2026 around 25 August 2026. Most of the coverage went to the adoption curve, which is the least surprising part of it. The number worth stopping on is buried a little further in, and it is a procurement number rather than a technology one.
- 32% of organisations decided against buying at least one off-the-shelf software product or feature because they could build it internally with agentic coding tools.
- The sector split runs higher than you would guess outside tech. Technology 41%, healthcare payers and providers 39%, professional services 38%, energy and materials 38%, financial institutions 36%.
- Large enterprises are scaling agents, not piloting them. 40% of companies with more than $1bn in revenue are scaling AI agents in one or more business functions, up from 27% a year earlier.
- The coding tools themselves are earlier. About two in ten organisations overall are scaling agentic coding tools; 31% among larger enterprises.
- Individual productivity is nearly universal. Financial impact is not. 80% of respondents report individual productivity gains. 37% attribute at least some EBIT impact to AI — flat versus the previous survey.
- The top of the distribution has not moved either. "High performers" — the 6% of respondents attributing at least 5% of EBIT to AI — remain about 6%, flat year on year. Nearly half of that group are skipping software purchases, against 31% of their peers.
- Efficiency is the default objective. 80% of respondents say their companies set efficiency as an objective of AI initiatives; the companies seeing the most value also set growth or innovation objectives.
The sample: 1,719 respondents across 97 countries, fielded 4 May to 8 June 2026, weighted by each country's share of global GDP. The Register covered the release on 25 August 2026 and reached broadly the same conclusion about the gap between reported productivity and reported profit.
This is a self-reported perception survey, not a set of audited accounts, and the GDP weighting means a few large economies carry disproportionate influence over the headline percentages. Treat every figure here as "what senior people believe is true" — genuinely useful, because procurement decisions are made on exactly that basis, but not a measured outcome. Nobody has verified that the 32% who skipped a purchase actually shipped a working replacement.
Why the 32% is the number that matters to you
Most readers will file the 32% under "AI is eating SaaS" and move on. That misses what the number is. It is not a productivity statistic. It is a demand signal, and it points somewhere specific.
Consider what has to be true for that decision to get made. Somebody had a requirement. Somebody found a product that met it. Somebody produced a price. And then somebody senior enough to sign said: we will build it instead, because the tools have got good enough. That is not an engineering opinion but a budget decision, taken by people who are conservative about build-versus-buy for good historical reasons — and it happened at least once in roughly a third of the organisations surveyed.
Note the wording, though: "at least one product or feature". Some of the 32% will be a plugin nobody wanted to pay for; some will be a customer portal. The number tells you the direction and the confidence, not the scale of any individual decision. So when someone quotes it at you as evidence that enterprise software is finished, it is not that. It is evidence that the threshold at which a team believes it can build has moved down — a slower and more interesting story, and one that follows directly from the shift we described in how agentic tooling is restructuring the software business.
Here is the consequence that nobody puts in a slide. Every one of those skipped purchases has become an internal system. Internal systems do not have a vendor. They have an author, and eventually the author leaves.
Building is cheap now. Running is not.
The economics of writing software have genuinely changed. The economics of owning software have not changed at all, and the gap between those two facts is where a large amount of work is about to appear.
When a company buys a SaaS seat, it is not really buying features. It is buying a bundle of obligations that somebody else has agreed to carry: uptime, patching, compliance updates, a support desk, a migration path when the underlying platform changes. The licence fee is the price of not owning those obligations. When agentic coding tools produce the same features internally, the features arrive and the obligations stay exactly where they were — with the buyer, who has usually not costed them and often has not noticed them.
| Responsibility | Covered by a bought SaaS seat | Owned by you after an internal, agent-written build |
|---|---|---|
| Uptime and out-of-hours response | Vendor's operations team, against a contractual target | Your rota, or nobody, depending on how the incident lands |
| Security patching | Shipped in the vendor's release cycle, applied for you | Yours to track, test and deploy, indefinitely |
| Dependency and library upgrades | Invisible — inside the vendor's build | Yours, including the breaking ones nobody planned for |
| Compliance and regulatory updates | Vendor tracks the change and updates the product | Your team must notice the change and act on it |
| Audit evidence and certifications | Vendor's attestations, reusable in your assurance pack | You produce the evidence from scratch, per audit |
| End-user support and training | Vendor helpdesk, documentation, onboarding material | The person who built it, until they move team |
| Upgrade path and roadmap | Vendor's product plan, whether or not you like it | Nothing exists unless you fund it |
| Documentation and handover | Maintained as a product asset | Optional, and therefore usually absent |
| Model and inference costs | Inside the seat price, if the product uses models at all | A live, variable bill that grows with usage |
| Exit and data migration | Contractual, with an export path | Undefined until the day somebody needs it |
Read the right-hand column as a job description rather than a risk register and the shape of the opportunity becomes obvious. None of these responsibilities is glamorous. All of them are now unallocated in a large number of organisations, because the decision that created them was framed as a saving.
The inference line deserves particular attention, because it behaves least like traditional software. A bought seat has a predictable unit price. An agent-backed internal tool has a bill that moves with usage, model choice and prompt design, and a system that looked cheap at pilot scale can become the third-largest line in a platform budget. We went through that arithmetic in our piece on the economics of inference in 2026; the practical version is set out step by step in our guide to forecasting an LLM bill before launch.
If you are the person recommending a build over a purchase, put a three-year run cost next to the build estimate in the same document — patching effort, on-call, dependency upgrades, audit evidence, inference spend — and name the team carrying each one. You will occasionally talk yourself out of the build, which is fine. More often you will win the argument properly and arrive with a maintenance budget attached. That is the difference between a system that survives its second year and one that rots until somebody proposes buying the product after all.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →The gap between 80% and 37%
Four in five respondents report individual productivity gains. Fewer than two in five report any EBIT impact at all, and that share has not moved since the last survey. The share of high performers is stuck at about 6%. Those three facts sitting together are the most useful thing in the report.
The survey does not explain the gap, and I want to be explicit that what follows is interpretation rather than a finding. But there are three explanations that fit the data and match what most of us have seen inside organisations.
Savings that are real but dispersed
If forty people each save three hours a week, that is a lot of recovered time and none of it appears in a management account. It becomes slightly less overtime, slightly more slack, slightly faster turnaround on things nobody measured. Dispersed savings are real, and invisible to finance unless something is consolidated — a role not backfilled, a contract not renewed, a queue short enough to change a service level. Few AI deployments are designed to consolidate anything, because consolidation is politically expensive and speed is not.
No measurement contract agreed in advance
Most internal AI projects are approved on a qualitative case and then measured, if at all, by surveying the people using them. Nobody agreed beforehand what number would move, by how much, by when, or who would report it. When finance later asks what the impact was, the honest answer is that nobody instrumented the baseline. It is the failure mode we kept meeting when we looked at what separates agent pilots that reach production from those that stall, and our template for writing the internal business case exists mainly to force that conversation early.
Nothing was actually removed
The simplest explanation, and probably the most common. The licence was renewed anyway. The headcount stayed. The manual process ran in parallel "just for this quarter", then permanently. Cost only leaves a business when something stops, and stopping things is harder than starting them. That McKinsey found 80% of companies setting efficiency as an objective, while the firms seeing most value also set growth or innovation objectives, fits this reading: efficiency programmes that retire nothing produce capacity, not profit.
None of that makes the 80% dishonest. It makes it early, and it explains why the build-versus-buy shift is running ahead of the financial return: confidence to build has arrived before the discipline to operate and measure. Closing that gap is not a modelling problem. It is an engineering and governance problem, which is to say a hiring problem.
What this looks like in India and the UK
The pressure is the same in both markets. The position in the value chain is not, and it is worth being precise about the difference rather than treating one as a variant of the other.
India: on the build side of the shift
Indian global capability centres and services firms sit on the supply side of that 32%. When a European or American parent decides to build rather than buy, much of the resulting work is specified, written and increasingly operated from Bengaluru, Hyderabad, Pune or Chennai. That is a volume opportunity, already visible in demand for agent-literate engineers, as our reporting on AI engineering demand and pay this year showed. The risk is familiar: if the work is scoped as build-only, the GCC takes the cheap half of a decade-long commitment and the client keeps the expensive half unowned. Centres that price the run alongside the build — support model, patch cadence, evidence for the client's auditors, inference budget — will be doing higher-value work in three years than those competing on delivery velocity alone. This dynamic played out before with custom application development, and the lesson has not changed.
The UK: the same tail, a thinner bench
UK enterprises are more often on the buy side, and their exposure is different. A mid-sized British insurer, retailer or NHS trust that skips a purchase now owns a system maintained by a small internal team — sometimes by one person — with limited depth to absorb an upgrade, an incident or a resignation. Regulated-sector obligations push the run cost higher still, because evidence has to be produced for the FCA, the ICO or an information governance function that will not accept "the model wrote it" as an answer. The upside is that a builder who can credibly own the tail is unusually valuable here, and the market is small enough that a reputation for keeping things alive travels quickly. The downside is that the same shortage leaves these systems one departure away from becoming somebody's inherited problem.
One point applies to both markets. Neither the build nor the run is safe if nobody can tell whether the thing works, and internal builds skip evaluation far more often than purchased products do, precisely because there is no vendor to hold to a standard. The distance between a benchmark result and production behaviour, which we examined in the gap between agent benchmarks and production, only widens when a system was written quickly against a loose specification.
What a builder should actually do
Take the survey at face value for a moment. A large number of organisations have just committed to systems they do not have a plan to maintain, at the same time as scaling agents in production — 40% of billion-dollar companies, up from 27%. The work that follows is not more building. It is operating, evidencing and eventually retiring what has been built. Position for that.
Concretely, five things are worth doing in the next quarter.
Learn to write the run-cost case. Not the technical design — the three-year ownership document a finance director will read. Who patches this, on what cadence, at what cost, against what evidence requirement. Being the person who can produce that changes how you are treated in the room.
Instrument before you ship. Agree with the sponsor, in writing and before the first commit, which number is expected to move and how it will be read. You cannot claim value you did not baseline, and "we felt faster" does not survive a budget review.
Get good at the second year. Dependency upgrades, evaluation harnesses that still run six months later, model migrations when a provider deprecates a version, cost regressions caught before the invoice. Unfashionable work, exactly what the 32% has created a shortage of, and very few people advertise themselves as competent at it.
Say you operated it, not just that you shipped it. "Built an internal claims-triage agent" is a common claim in 2026. "Built it, ran it for fourteen months, cut its inference bill by a third, handed it over with a runbook" is not, and it is the sentence that gets a reply.
Learn to say when buying is right. The most credible builders in this shift will be the ones who occasionally recommend the purchase — a meaningful share of those 32% of decisions will have been wrong, and whoever called it honestly gets asked next time. The counter-example is a build with an operating model attached: Cisco's agent rollout to 90,000 employees is precisely the part most teams skip.
The headline finding is a story about capability. The flat 37% is a story about follow-through. Builders who can only do the first half are about to become very common. Builders who can do both are about to become expensive.