AI just made software cheap to build. Your build-versus-buy answer may have flipped.

For most of the last decade, the answer to "should we build this ourselves or buy it" leaned one way. Building custom software was slow, expensive and risky, so unless the thing was core to your advantage, you bought a tool and moved on. That default was rational, and it is quietly going out of date. The single factor that made building the wrong answer, the cost of producing and maintaining code, is falling fast, and a build-versus-buy call you settled two years ago may now be pointing you in the wrong direction.

The reason has a name. MIT Technology Review picked generative coding as one of its breakthrough technologies of 2026: AI systems that turn natural-language intent into working software, with coding assistants and agents moving from novelty to normal. Producing a first version of working code is no longer the bottleneck it was for thirty years, and when the cost of a thing collapses, every decision that was made because it used to be expensive is worth revisiting.

How much has the cost of building software actually moved?

Enough to change the arithmetic. On SWE-bench, a benchmark built from real software-engineering tasks, AI performance rose by 67.3 percentage points in a single year, according to Stanford's AI Index, one of the sharpest capability jumps on any serious benchmark. Over the same rough period, the cost of running a model at a given level of capability fell around 280-fold in eighteen months. And it shows up in real output: a 2026 field study of an AI-forward company found engineering throughput reaching 2.09 times its previous baseline once AI tools were adopted in earnest. More capable, far cheaper, and visibly faster: the production cost of software is genuinely shifting, not just in demos but in the numbers.

So should I just build everything now?

No, and this is exactly where the enthusiasm gets expensive. Cheap to build is not free to own. AI slashes the cost of the first draft of code; it does far less for the cost of maintaining it, securing it, integrating it with everything else, and checking that it is actually right. That last one is not a footnote: as output rises, the burden of reviewing AI-written work rises with it, and human oversight becomes the new constraint rather than the typing. Buying still wins whenever the problem is generic, the vendor carries the maintenance, security and compliance load, and the capability is not a source of advantage you would ever want to differentiate on.

How should I decide, now the line has moved?

By re-asking a question most organisations treat as long settled, using today's costs rather than the ones baked into old habits.

1. Re-run build-versus-buy on the new cost of building. Decisions made when custom software was expensive may be stale. Revisit the ones where you chose "buy" mainly because building was too dear.
2. Build the differentiators, buy the plumbing. AI lowers the cost of building the things that make you distinctive. It does not change the logic that generic capabilities are almost always better bought.
3. Price the whole lifecycle, not the first draft. Include maintenance, security, integration and review, the parts AI helps with least, before you commit to building.
4. Budget for oversight and hardening. AI-written code still needs human review and security work. If you skip it, you have not saved money, you have deferred a bill.
5. Watch the lock-in on both sides. Building can free you from a vendor; it can also create a fresh dependency on AI tools and the people who wield them. Choose with your eyes open, not on novelty.

What does this change for me as a leader?

It reopens a decision your organisation almost certainly treats as closed. The build-versus-buy defaults across your business were set under old economics, and AI has changed the inputs underneath them. The winners will not build everything, nor buy everything. They will re-ask the question on purpose, building where tailoring creates real advantage, buying where it does not, and pricing the full lifecycle rather than the seductive cheapness of the first draft.

This is the discipline behind the end of business as usual: when the cost of a core activity collapses, the smart move is not to do more of it blindly but to rethink the decisions that assumed it was expensive. Re-run the calculus with clear eyes, and AI-cheap software becomes a genuine strategic option rather than a temptation to build things you will regret owning. It is precisely the kind of assumption a board should be re-examining, and part of why most organisations struggle to turn AI into advantage: they adopt the tool without revisiting the decisions it should change.

About the author

Thomas Green

British technology futurist, AI keynote speaker and advisor. Thirty years across enterprise technology and AI strategy, helping leaders navigate the future of work. The futurist who died.