Build versus buy is the oldest capital-allocation decision in software. For four decades it resolved to a single trade-off: pay to own something that fits you exactly, or pay less to rent something that fits you approximately. Agentic generation has detonated one side of that equation. When a coding agent can produce a working integration, a bespoke admin tool or an entire service in an afternoon, the cost of building appears to collapse toward zero. The obvious conclusion, popular in 2025's commentary, was the so-called SaaSocalypse: if building is now cheap, build everything, and watch the SaaS estate wither.
That conclusion is wrong, or at least dangerously incomplete. Cheap generation does not tilt build-versus-buy toward build. It dissolves the premises on which the decision was ever made. David Klotz of the Institute for Applied AI at Media University Stuttgart argues the SaaSocalypse thesis is overstated: agentic AI does not simply favour Make, it transforms both Make and Buy simultaneously, with the right answer depending on application class — commodity, differentiating, regulated or mission-critical — and gated by a threshold variable he calls organisational AI capability. You do not get to choose 'build' just because generation is cheap. You earn the right to choose it by being able to absorb what building now actually costs.
The cost did not disappear; it changed phase
Generation collapses the development line item — the CAPEX of first writing the code. But Klotz points out that operations and maintenance consume 60 to 80 per cent of software lifecycle cost. Cheaper development does not remove that 60 to 80 per cent; it shifts the centre of gravity of cost into OPEX, governance and quality assurance. You have not saved money. You have moved it downstream, into the part of the lifecycle that is hardest to forecast and hardest to staff.
There is a second, sharper shift: liability. When custom-developed software fails in production, Klotz notes, the firm bears the full consequences. AI tool vendors, meanwhile, explicitly disclaim responsibility for the correctness or lawfulness of generated code. Quality-assurance liability stays entirely with the commissioning firm. So the moment you press 'generate', you have not bought a capability with a vendor's indemnity behind it — you have manufactured a liability with your own name on it. This is the hidden term in the new equation, and it is what makes 'generate' a genuinely distinct third path rather than a cheaper flavour of 'build'.
Why generation is its own sourcing path
The evidence that generated code carries a structural ongoing liability is now substantial and converging from independent angles. GitClear's analysis of 211 million changed lines from 2020 to 2024, spanning major repositories, found refactoring fell from 25 per cent of changed lines in 2021 to under 10 per cent in 2024, copy-pasted lines rose from 8.3 to 12.3 per cent, and code churn — lines revised within two weeks — climbed from 3.1 to 5.7 per cent. Abundant generation appears to degrade structural quality rather than improve it. An empirical study of 302,600 verified AI-authored commits across 6,299 repositories reinforces this: more than 15 per cent of commits from every assistant introduced at least one issue, and 22.7 per cent of those AI-introduced issues survived to the latest repository version, accumulating past 100,000 surviving defects by February 2026.
The maintenance burden does not fall evenly. Xu, Medappa, Tunc, Vroegindeweij and Fransoo found that after GitHub Copilot's introduction, experienced core open-source developers saw a 19 per cent drop in their original-code productivity while reviewing 6.5 per cent more code — the rework of meeting repository standards shifted onto senior people. And system-level outcomes can move opposite to individual ones: the 2024 DORA report associated a 25 per cent increase in AI adoption with a 7.2 per cent decrease in delivery stability and a 1.5 per cent decrease in throughput, even as code quality and review speed nudged up. Generation is fast at the keyboard and slow in production.
The question is no longer which capabilities you can afford to build. It is which capabilities you can afford to own the acceptance, integration and maintenance liability for.
Acceptance is the new sourcing constraint
This is the Acceptance Gap expressed in capital-allocation terms. Once generation is abundant, the binding constraint is no longer the supply of code but your capacity to accept it — to review, integrate, attest to and stand behind it. Sonar's 2025 survey of roughly 20,000 developers found only 24 per cent of AI-generated suggestions were accepted without modification. A METR randomised controlled trial sharpens the warning: experienced developers took 19 per cent longer to complete tasks with early-2025 AI tools, despite predicting a 24 per cent speed-up and believing afterwards they had been 20 per cent faster. The perception of cheap building is itself a cost-allocation hazard, because the people approving the budget are systematically wrong about the saving.
Retool's 2026 Build vs Buy report, surveying 817 builders, shows how mature teams actually behave. Yes, 35 per cent had already replaced at least one SaaS tool with something custom-built, and 78 per cent planned to build more in 2026. But 93 per cent used LLMs to build, 72 per cent used AI for discrete code snippets rather than whole applications, and only 8 per cent shipped AI code immediately without changes. 'Generate' in practice means generation wrapped in heavy human acceptance — not autonomous building. The sourcing strategy that works is one that budgets for that acceptance layer explicitly.
The third path has its own runaway-cost profile
Generation also carries financial liability of a kind build and buy never did. Gartner predicts that by 2027, 40 per cent of enterprises using consumption-priced AI coding tools will face unplanned costs exceeding twice their expected budgets, and that over 40 per cent of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear value and inadequate risk controls. Yet the same firm forecasts that by 2028, 75 per cent of enterprise software engineers will use AI code assistants, up from under 10 per cent in early 2023. Generation is normalising as a default input at the very moment its cost and risk profile is least understood. And provenance is hardening into a formal liability: AI-generated code is increasingly expected to be recorded in the software bill of materials as a dependency, with standards such as CycloneDX evolving to capture machine-authored components. If you cannot say which code an agent wrote, you cannot attest to it — and attestation is becoming a condition of ownership.
Rebuilding the decision around three liability profiles
The reconstructed question runs across three columns, not two. Buy transfers maintenance and much of the liability to a vendor at the cost of fit. Build gives you fit and control at the cost of owning the full lifecycle. Generate gives you speed and fit at the cost of owning a higher-defect, lower-structural-quality asset whose acceptance, attestation and consumption costs you must budget for from day one. Klotz's threshold variable decides eligibility: only organisations with the AI capability to run that acceptance and governance machinery can responsibly choose 'generate' for differentiating or regulated work. For everyone else, generation belongs to commodity, low-blast-radius surfaces.
Treat 'generate' as a first-class sourcing path with its own total-cost-of-ownership model, its own provenance and attestation requirements, and its own consumption-cost guardrails. Decide it the way you decide architecture — not as a procurement reflex but as a durable commitment about which liabilities you can carry. For how that framing turns into delivered outcomes rather than diagrams, see The Architecture Decisions That Determine Product Success.