AI agents made software cheap to write, not cheap to own

The line item that starts the argument now is a SaaS renewal. Someone on the leadership team looks at it and says what a year ago would have been a joke: we could build that in a sprint. They are not wrong about the sprint. A coding agent will produce a working version of most internal tools in an afternoon, and the demo will be good.

I have sat on both sides of this. I have run companies that bought software they should have built, and I run one now that builds software other companies could, in principle, generate for themselves. So the question is not abstract for me, and I think most leadership teams are answering it with the wrong variable.

My claim: coding agents collapsed the cost of writing software and left the cost of owning it almost untouched. What a vendor's price actually bought was three things: the run cost, the data the vendor sees across all its customers, and someone accountable when it breaks. Build where those three are already yours. Buy where they are not. The code was never the moat, on either side.

What the invoice was buying

Start with what a software vendor sells, because "the software" is the least of it.

The code is one layer. Beneath it sits the run cost: hosting, patching, upgrades, security certification, on-call, and the enhancement work that never stops. Robert Glass's survey of the empirical record put maintenance at "about 40 to 80 percent (60 percent average) of software costs," with roughly 60 percent of that maintenance being enhancement rather than bug-fixing.¹ The software engineering standard for maintenance, ISO/IEC/IEEE 14764, splits the work into four kinds: corrective, adaptive (keeping software usable as the environment changes), perfective (enhancement) and preventive.² Only the first is what people picture when they hear "maintenance." The other three are the bulk, and none of them ends.

Beneath the run cost sits data the vendor sees and you do not: the patterns across a thousand customers' usage, documents, edge cases and failures. A vendor's product embodies every mistake its other customers already made. Your build embodies yours.

Beneath that sits accountability. When the system is down at quarter close, or an auditor asks how a number was produced, or a breach has to be disclosed, the vendor's name is on the contract, the SOC 2 report and the incident. Vanta puts the auditor's fee alone for a SOC 2 Type II at "$10,000 to $50,000," and the first-year all-in cost with readiness and tooling at "$10,000 and $80,000 or more."³ That is per system you now own and other people depend on.

Martin Fowler's 2010 test for which software to build has not changed: "it's all about whether the underlying business function is a differentiator or not," and for a utility, "since the definition of utility is that there's no differentiator, the obvious thing is to go with the package."⁴ He also named the failure mode leadership teams are now repeating with agents: "things that are really utility will be given an inflated importance, rather than dispositioned as the utilities they really are."

What agents changed

The top layer got cheap. The evidence on the other layers is less kind than the demos.

On speed, the only randomized trial I know of on experienced engineers found the opposite of the intuition. METR gave 16 developers with an average of five years on their own mature open-source projects 246 real tasks, randomized AI use, and measured completion time. "Allowing AI actually increases completion time by 19%." The developers had forecast a 24 percent speedup and, afterwards, believed they had achieved 20 percent.⁵ The gap between felt and measured productivity is the most important number in the study, because leadership teams are making build decisions on the felt number.

On autonomy, METR's separate work on task horizons measured how long a task a model can complete unsupervised. The 50 percent success horizon has been doubling roughly every seven months, "every 212 days" in their fit, and for the best model they tested stood at about an hour. The same model's 80 percent horizon was "around 15 minutes."⁶ An agent that finishes an hour-long task half the time is a superb assistant and a poor owner. Ownership is the 80 percent number, and it is short.

On what the code is like afterwards, two independent measurements. Veracode's spring 2026 update tested more than 150 models on 80 coding tasks and found a 55 percent security pass rate, unchanged from two years earlier, with "model size has only a very small effect on security performance."⁷ GitClear analyzed 623 million code changes from 2023 to 2026 and found duplicated lines up 81 percent while refactored or moved code fell from 21 percent of changes in 2022 to 3.8 percent.⁸ Copy-paste now outruns consolidation about five to one. That is the maintenance layer getting more expensive at the exact moment the code layer got cheaper.

None of this says agents are not useful. It says what they are useful for: producing the layer that was already the cheapest part of the stack. Fowler's point stands with a new price tag on it.

The loudest build story

The case everyone cites is Klarna. In August 2024 its CEO said "We just shut down Salesforce. Within a few weeks, we will shut down Workday," and the story travelled as "company replaces SaaS with AI." By March 2025 he had corrected it: "we developed an internal tech stack, using Neo4j and other things, to start bringing data/knowledge together," and "no, we did not replace SaaS with an LLM. Storing CRM data in an LLM would have its limitations." The SaaS shutdowns were, in his words, "the side consequence" of consolidating the company's own data into one graph.⁹

Read against the layers, Klarna did the thing the rule predicts. It built where the data was its own and the differentiation real: a unified knowledge layer over its customers, operations and people. It did not build a CRM. The market heard that agents make vendors optional. The company built a data layer it already owned.

The four questions

The decision rule follows from the layers. Run it on every renewal and every proposed build, in order.

Is the function a differentiator? If customers choose you partly because of how you do this, build, and build well. If not, the burden of proof moves to the build.

Who carries the run cost for the next five years, by name? Not "engineering." A person, a budget line for adaptive and perfective maintenance sized against Glass's numbers rather than against zero, an on-call rotation, and a certification plan if anyone outside depends on it. If that line cannot be filled in, the build is a prototype, and prototypes are fine as long as nobody mistakes them for systems.

Does the vendor see data you cannot? Regulatory feeds, supplier document formats across an industry, fraud patterns across a payments network, benchmark data across a thousand tenants. If the value of the product comes from what it learned elsewhere, an agent cannot regenerate it from your inbox.

Who is accountable to an outsider? If an auditor, a regulator or a customer will ask how the system reached a result, the answer has to be reproducible, source-bound and owned. That is the case where the rule bites hardest, and I have written it up separately for compliance systems of record, where a single audit question decides the whole build-or-buy argument.¹⁰

Three answers pointing to build, or one hard answer on questions three or four pointing to buy, settles most cases. The rest are hybrids, which is where most of the value now sits: buy the system of record and generate everything around it.

What we build and what we buy

At Certivo we sell a compliance system that customers could, in the abstract, generate for themselves, so we have to be honest about the same test internally. We build the parts where the four questions come back yes: the deterministic rule engine that turns regulations into determinations, the register that governs what our agents may and may not do, the evidence and approval chain that an auditor will inspect, and the extraction models tuned on the supplier documents we see across customers. We buy identity, payments, monitoring, the foundation models themselves, and the CRM, because none of those differentiates us, each carries a run cost someone else already amortizes across thousands of customers, and none of them holds data we see better than the vendor does. We have generated internal tools with agents, and we treat each one as a prototype until a named owner and a maintenance line exist. Several have been deleted. That is the system working.

The strongest case against

McKinsey's State of AI in 2026, from a survey of 1,719 respondents, reports that "nearly one-third of respondents (32 percent) report that their organizations 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," and that among AI high performers nearly half did.¹¹ If the best-run companies are building more, perhaps the rule is too conservative.

Two answers. First, the survey records a decision, not an outcome; the 19 percent slowdown study and the 3.8 percent refactoring rate describe what happens after the decision. Second, the 32 percent may be correcting a prior error rather than making a new one. Zylo's 2026 index of $75 billion in SaaS spend found organizations leave 36 percent of licenses unused, with median spend of $9,455 per employee.¹² A company that was over-buying utility software and now generates a replacement for the unused third is applying Fowler's rule, not breaking it. The high performers' behaviour is consistent with the layers: cut what was never differentiating and never carried an external obligation, keep what was. What the survey cannot tell you is which of the 32 percent built something that will still be maintained in 2029.

What this means for a leadership team

Set the policy at the top rather than leaving it to each renewal fight. Three parts.

Keep a build register. Every internally generated system gets a named owner, a maintenance budget and a review date, or it is labelled a prototype and excluded from anything customers or auditors touch. Prototypes that acquire dependents get promoted or killed at the review.

Buy for the bottom two layers, never for the top. If a vendor's pitch is features, an agent can match it and you should negotiate hard or leave. If the pitch is cross-customer data, certification, uptime and a name on the contract, that is what you are paying for, and the price should be compared to carrying it yourself, SOC 2 included.

Measure the build decision at eighteen months, not at the demo. The demo is the layer agents made free. Eighteen months is when adaptive and perfective maintenance, the security backlog and the departure of the original author have all arrived. If the register shows the system is still owned, still patched and still reproducible, the build was right. If not, the vendor was cheaper after all.

Agents changed the economics of one layer of software. The other three are where companies have always won or lost, and where they still do.

— Kunal