According to a McKinsey survey, 32% of organisations surveyed have abandoned buying at least one software product or feature because they could build it in-house with agentic coding tools. Another figure: the share of large enterprises deploying agents at scale has risen from 27% to 40%, while smaller organisations remain stuck at 22%.
We reported on Tuesday that half of the Fortune 500 would favour open models over APIs. Here is the same trend applied to software itself, and it is hitting an entire sector.
What has changed in the calculation
The build-versus-buy decision rested on a stable asymmetry: developing an internal tool was costly in developer time, buying it cost a subscription. For anything that was not your core business, buying almost always won.
Agentic coding tools shift that balance point. A simple internal tool — a dashboard, a connector, a business form — that used to take three weeks can now be prototyped in a few days.
And crucially, the decisive argument is often not cost but fit. Purchased software imposes its own concepts and fields; a built tool conforms to how you work. That gap rarely justified the development cost before. It does more often now.
Software is not finished when it works. It needs maintaining, fixing vulnerabilities, adapting to API changes, training new hires, managing the departure of whoever wrote it. It is this burden that made buying rational, and agentic tools do not remove it — they speed up building, not maintenance. The risk is therefore real: accumulating dozens of internal tools that no one maintains and no one understands. That is called technical debt, and it always comes due.
The widening gap
The second figure may be more important than the first. Large enterprises are moving from 27% to 40% on deploying agents at scale; smaller ones remain at 22%.
This is a gap that is accelerating, and it contradicts a widespread idea: that AI would favour small, agile organisations over large, heavy ones.
The reason is simple and we have encountered it several times. Deploying agents at scale requires what we described as traceability and verifiable permissions, a security team, data governance, integration budgets. The model is free; the infrastructure around it is not.
This is consistent with what we noted about the absence of measured productivity gains: what is missing is not technical capability, it is the reorganisation needed to extract value from it. And that reorganisation is expensive.
What this means for software vendors
An entire sector is affected: that of software whose value rested mainly on the fact that building it was tedious.
What holds up are products whose value does not come from code: those that bring data you do not have, a network of users, certified compliance, or contractual liability if something goes wrong. This is exactly the logic of Thomson Reuters building its own model: the value is in the corpus, not in the software.
What to take away
The practical rule that emerges is fairly clear.
Build what is specific to your organisation, small in scope, and that you will be able to maintain. Buy what engages your liability, what must be certified, and what derives its value from data or a network you do not have.
And be wary of the moment when building becomes easy: that is precisely when you accumulate what you will not be able to maintain. The question was never "can I do it", but "who will look after it in two years".