Agentic coding tools have crossed from a productivity story into a procurement one. In McKinsey's 2026 State of AI survey, published on 25 August, nearly a third of organisations said they had decided against buying at least one software product or feature because they could build the functionality in-house. The exact figure is 32 per cent, drawn from 1,719 responses across 97 countries collected between 4 May and 8 June.
That is not a forecast about what AI might do to the software market. It is a count of decisions already taken, by people who had a purchase order in front of them and did not sign it.
What the Survey Actually Asked
The wording matters, because the number has been repeated loosely. McKinsey's report says coding agents are "emboldening companies to build their own software rather than purchase it", and that nearly one-third of respondents report their organisations "have decided against purchasing at least one software product or feature because they were able to build the functionality in-house using agentic coding tools".
The unit is one product or feature, at least once. As Digital Applied noted in its analysis, a company that built a single reporting dashboard instead of buying a seat licence counts the same as one that replaced its customer platform. There is no prior-year figure in the report, so there is no trend line yet, only a level.
Nobody was asked the follow-up questions either: whether the replacement shipped, whether it passed an audit, or whether it is still running a year later. That is a real limitation, and it is worth holding on to before treating 32 per cent as a verdict on the software industry.
The Industry Spread Explains Itself
The breakdown by sector is the most useful part of the finding, because it maps almost perfectly onto who carries engineering capacity and who carries regulatory risk. Technology firms lead at 41 per cent. Healthcare payers and providers follow at 39, professional services and energy and materials at 38, financial institutions at 36, media and telecom at 34, pharmaceuticals at 33.
At the other end, insurance sits at 19 per cent and the public and social sector at 17. The gap is not a difference in engineering talent. Those buyers are purchasing audit evidence, vendor liability and someone to sue, and a coding agent supplies none of those. A regulated buyer who builds internally still has to produce the same compliance artefacts, only now without a vendor to produce them.
Scale moves in the same direction. Among organisations with more than $1bn in revenue, 40 per cent are now scaling AI agents across at least one business function, up from 27 per cent a year earlier. About two in ten organisations overall are scaling software coding agents, rising to 31 per cent at larger enterprises.
Building Rose and Profit Did Not
The companion figure is the one that should temper the excitement. The share of organisations attributing any impact on earnings before interest and tax to AI is 37 per cent, which McKinsey describes as essentially unchanged from a year ago. The high performers, defined as organisations crediting at least 5 per cent of EBIT to AI and calling the impact significant, remain flat at about 6 per cent of respondents.
So a third of the market walked away from a purchase and the earnings line did not notice. Two readings fit, and both are probably partly right. A licence avoided in the second quarter shows up in the profit and loss account over years, not weeks. And the licence was often not the expensive part: one in five organisations now say AI operating costs, including token spend, already limit how much technology they use, and high performers report cost constraints on coding agents roughly three times as often as everyone else, because they use them most.
The pattern that separates the 6 per cent from everyone else is not tooling. McKinsey's own account is that high performers pursue growth alongside efficiency, fundamentally redesign workflows around AI rather than inserting AI into existing ones, and are twice as likely to have leaders visibly committed to the work.
A Second Survey Says the Same Thing
McKinsey is not alone in catching this. Retool's 2026 Build vs Buy report, based on 817 customers and builders surveyed in late 2025, found that 35 per cent of teams had already replaced at least one SaaS tool with a custom build, and 78 per cent expected to build more internal tools this year. The exposed categories are the predictable ones: workflow automation led at 35 per cent, internal admin tools at 33 and business intelligence tools at 29.
The detail that matters most for the shape of this shift is who is doing the building. Retool found that 60 per cent of builders had created software outside IT oversight in the past year, and a quarter said they did so frequently. Just over a third of respondents were software engineers; the rest came from operations, product, data, marketing, finance and business analysis. Startup Fortune's write-up put the commercial consequence plainly: the threat to a vendor is not losing a deal to a rival, it is losing the next renewal to the customer's own team.
The Cost That Arrives After the Saving
Whoever builds it, someone maintains it. That is the part the 32 per cent does not capture, and it is where the run cost lands. The Daily Brief made the point that the avoided licence is a one-line saving while the replacement is an ongoing obligation: hosting, monitoring, security patching, the person who understands it, and the token spend of the agent that keeps changing it.
McKinsey senior partner Lieven Van der Veken framed the change as a posture shift rather than a cost play, describing organisations moving fastest as becoming more deliberate about where to buy, where to build and where to develop enough internal capability. That is a more defensible reading of the data than the one likely to be offered at a renewal meeting, which is that the licence costs a lot and an agent can build it in a sprint.
The honest test for any team is not whether the agent can produce a working first version. It nearly always can. The test is whether the team can still support that system in eighteen months, when the person who prompted it into existence has moved on and the requirement has changed twice.
Why This Is Still Good News for Small Teams
From a technology-democratisation perspective, the more interesting number is not 32 per cent but 60. A majority of the people building internal software in Retool's survey were doing it outside IT, and most of them were not engineers. Capability that used to require a budget line and a hiring round now sits with an operations lead who can describe what they need. At MW3.biz we think that is the more durable change in this data, and that wider access to building is the answer to most of the concerns raised about it. A team of three can now serve itself in ways that previously required either money or permission.
The caution is equally real, and it is not about capability. It is that an unmaintained internal tool is a liability wearing the costume of a saving, and that a small team feels that failure harder than a large one. The discipline that makes this work at any size is the same discipline the high performers show: redesign the workflow, decide deliberately what is worth owning, and price the running cost before the licence is cancelled rather than after.
Read alongside our earlier coverage of how an open-weight coding model rose sixfold without new pretraining, the direction is consistent. The capability keeps arriving faster and cheaper than the organisational habits around it. The organisations getting a return are the ones changing the habits, not the ones buying the tools.
