AI makes software faster to build. Cheaper, too.
The problem isn't the claim - it’s what most organisations do (or assume they’ll do) with that.
The prevailing logic goes: AI reduces build time, build time is a cost, therefore AI reduces cost. Pocket the savings, move on. That logic isn't wrong. It's just not the whole story.
AI has dramatically reduced the cost of custom software development, but it hasn't reduced the cost of building the wrong software.
The numbers that don't make it into the headline
Earlier this year, a telemetry dataset from 22,000 developers across more than 4,000 teams put some hard numbers around what's actually happening as AI adoption scales. The headline figures are the ones you've probably seen: epics completed per developer up 66%, task throughput up 34%, more features shipped than at any point previously measured. Real gains. Genuinely useful.
But, the footnotes are less comfortable.
Bugs per developer are up 54%. Production incidents, per code change merged, are up 243%. The time senior engineers spend in code review is up 441%. Pull requests merged with no review at all are up 31%.
The researchers named this pattern “Acceleration Whiplash”. AI floods the development process with output faster than the downstream system was built to absorb. Throughput goes up at the front. Bugs, incidents, and the hidden cost of experienced engineers unpicking plausible-looking code accumulate at the back. The saving arrives on one line of the ledger. Unfortunately, the cost turns up several lines later, less visibly, and often too late to trace back to the original decision.
This is absolutely not an argument against AI. The report is clear that the productivity gains are real. It's an argument for being honest about where the savings actually should go.
Where should AI efficiency savings go?
Most of the conversation about AI and software costs seem to frame it as: things got cheaper, here's the saving.
Founder/ Director, George Wills, has been encouraging us to think about this differently. That efficiency is actually giving you choices. The question becomes what you do with them.
For example, you can put some of that saving back into quality. More tests, more rigorous QA. A codebase that doesn't become unmaintainable in three years because the team was always moving too fast to write it properly. For a long time, that kind of rigour got cut when budgets got squeezed. Not because anyone wanted to cut it but because the economics made the choice for you.
You could also choose to invest back into security. Security work has historically been the first thing to slip when timelines tighten. AI doesn't change that tendency automatically - but finally you can decide to change it.
You can spend more time in discovery and on UX. We've always believed that the most important work happens before a line of code gets written. Understanding the actual problem, not just the stated requirement. AI has made prototyping faster, which means we can get real user feedback earlier and cheaply. But only if you treat that time as an investment rather than a stage to skip now that build is so much faster.
You can use it to build fewer features, better. The Acceleration Whiplash data shows that AI naturally produces more. More output, more PRs, more code in the codebase. More is not always better. In fact, we promise you that it usually isn’t. A smaller, well-considered feature set is often more useful and far cheaper to maintain than a sprawling one built at speed. That choice takes deliberate restraint. It doesn't happen on its own.
The economics of software development genuinely have shifted. What was too expensive to build two years ago may well be viable now. That's real, and it matters. What hasn't shifted is the cost of building the wrong thing, or building the right thing poorly. Those costs are the same. In some respects, given what the data shows about bugs and incidents at scale, they stand to be higher.
If your problem is really worth solving, or the opportunity in front of you is really worth securing. You still need to be prepared to do it well.
What this looks like in practice
We're having more conversations now about off-the-shelf software versus building bespoke. A few years ago, the default answer for most businesses was: buy something off the shelf and adapt to it. The economics made bespoke hard to justify unless you were large enough to absorb the cost - of both the build and the maintenance.
That calculation is changing. Building your own now sits on the table for a wider range of organisations. But the question that follows isn't just "can we afford to build it?" It's "what do we actually want to build, and how do we make sure we get it right?"
Those are the same questions they've always been - they've just become accessible to more people.
We reckon the businesses that get the most out of the AI efficiency shift aren't the ones who use it to just build more, faster. They'll be the ones who use it to build more carefully. To invest (some of) the difference in the quality, security, and rigour that the economics previously made unavailable to them.
That choice was taken away for a long time. The businesses that use it well won't just build more. They'll finally build the way they always wanted to.
FAQs
Is it cheaper to build custom software now?
Yes, meaningfully so. The economics of software development have shifted significantly in the last two years. Projects that weren't viable at previous costs are now worth revisiting.
That said, AI reduces the cost of building, not the cost of building the wrong thing. Discovery and clear problem definition matter as much as they ever did.
What should we do with AI efficiency savings?
The most useful framing is to treat efficiency gains as choices rather than savings. You should consider reinvesting in things like quality (more rigorous testing and QA), in security (which historically gets cut when budgets tighten), in fewer but better features, or in more time spent in discovery or on UX before build starts. Organisations that make that reinvestment deliberately tend to end up with software that holds up better over time.
What is Acceleration Whiplash?
Acceleration Whiplash is a pattern identified in the AI Engineering Report 2026, based on telemetry from 22,000 developers. It describes what happens when AI increases development throughput faster than downstream quality processes can absorb: bugs, production incidents, and senior engineer review time all rise significantly as AI adoption scales.
Should I build bespoke software or buy off the shelf?
This is a calculation that's genuinely changing. Off-the-shelf software made sense when bespoke was priced out of reach for most businesses. As build & maintenance costs fall, bespoke becomes viable for a wider range.
The honest answer depends on how well available tools fit your actual business processes, and whether the workarounds you'd need to do to make off-the-shelf work are worth the licence saving. We're having that conversation with more organisations than we were two years ago, and the answer is shifting.
Does AI make software development safer?
Not automatically. AI can increase development speed, but speed alone does not improve quality or security. Organisations still need testing, code review, governance and security practices to ensure software remains reliable and maintainable over time.
