There is no shortage of opinion about what AI does to software delivery. There is much less evidence. Most of what gets published is either a vendor with something to sell or a prediction from someone who has not run a team through the change.

I have now taken several development teams onto AI-assisted development, and used two specific projects to measure its impact. In both cases, we had an unusual opportunity to measure it properly because both projects involved rebuilding a substantial part of software that already existed. Same scope, same outcome, built twice with a new team. That meant we could put the new cost against the old cost of the same work rather than counting story points or asking people how they felt.

The second build came in at around a fifth of the first.

Before anyone reaches for that number as proof that AI software development is five times cheaper, let me explain a little more.

The obvious objection

Building something a second time is always cheaper. The requirements are settled, the edge cases are known, the arguments about design were had years ago. A good part of the original cost was discovery rather than typing.

Two things reduce that effect here but do not remove it. The rebuild was like for like, so nobody quietly dropped the awkward features to make the numbers look better. And it was done by a different team, so the second build did not benefit from people who already carried the original in their heads, although they did have a clear view of the final state.

My estimate is that around 20% of the gain came from having better-defined specifications the second time. That is a judgement, not a measurement.

Why does it matter?

In July 2025, METR published a randomised controlled trial that has been widely quoted since. Sixteen experienced open-source developers worked through 246 real tasks on mature repositories, with AI assistance allowed or disallowed at random. They finished 19% slower with AI, while believing they were 20% faster. Link to the article here.

It is a serious piece of work and it deserves to be taken as such rather than explained away. It is also narrower than the headlines suggest. METR itself expects greater productivity benefits in other settings, such as smaller projects, less experienced developers, or different quality standards. One of the suggested explanations is implicit repository context: experienced developers carry undocumented knowledge of their own codebase that the model cannot see. Worth noting too that most participants had not used the tooling before, so some of that slowdown is a learning curve rather than a ceiling. Link here.

That is close to the opposite of what we did. Rebuilding a defined subsystem gives the team a clean run at a known problem, with no decade of undocumented convention and spaghetti code to fight. So I do not read our result as contradicting METR. I read it as evidence that the setting decides the outcome, and that anyone quoting a single number in either direction is selling something.

What has changed

The work has moved from writing code to reviewing it. This is the real shift, and it is uncomfortable. Everyone says they are reviewing the output. Far fewer actually are, in any meaningful sense. The volume is simply too high to read properly, and reading someone else's code carefully is harder work than writing your own.

The code is average, and it has a particular weakness. It compiles, it passes the tests, it looks reasonable. It also has a habit of producing designs that do not scale, because the model optimises for something that works now rather than something that survives a hundred times the load, after having been changed a hundred times.

The developer experience is changing too. One thing I've noticed within teams is that some experienced developers are less enthusiastic about the shift. Many went into engineering roles because they enjoyed writing software. Increasingly, the job is becoming one of reviewing, correcting and directing what AI produces. That doesn't make the role less valuable, but it does make it a different role.

Cheap building encourages endless building. When each change looks cheap, the temptation is to keep going until it is perfect. Perfection costs what it always did. The bill arrives in review time, testing and the slow accumulation of changes nobody asked for.

Requirements are getting worse, not better. If rework is cheap, why think hard upfront? That logic is seductive and wrong. Poorly defined work produces waste and technical debt at a rate that comfortably outruns the saving on the build.

What has not changed

Knowing what to build, when, and in what order. This is still the hard part and AI has not touched it. The clearest evidence is the stream of non-technical people who have built something, cannot fix a bug in it, and are watching their product drift out of control.

Business people still struggle to say what they want. And they are still focused on what they want rather than what their customers want. That gap is precisely what product roles exist to close, which makes those roles more valuable now, not less.

Testing, including manual testing. Automation catches what you thought to check for. A good manual tester brings context, asks why a requirement exists, and challenges it. That is judgement, and it has not been automated.

Design. UI and UX work is what makes a product fit a particular audience. Without it you get something generic, which is exactly what a model trained on everything will produce by default.

What is getting ugly

We are building things nobody will ever use. When the build is cheap, the discipline of deciding what deserves to exist goes first. The cost of that work is not zero; it is just deferred into maintenance. The KISS (Keep It Simple, Stupid) principle and other similar approaches have existed for decades for good reason. But when adding another feature suddenly looks almost free, that discipline is easy to lose. I suspect we've gone backwards in that regard. We're creating complexity now that someone will have to deal with later.

Technical debt is accumulating faster than anyone is measuring. The code is average and there is very little evidence yet about how average AI-generated code behaves after three or five years. Nobody has run that experiment. We are all running it now, in production. AI is really good at saying yes to everything, and this builds in layers of underlying complexity. Where an engineer would usually go "wait, no, there is a simpler way to achieve 99% of what you need", the AI answer is "great, let's do it, do you also want the cherry on the top?".

A growing number of businesses are sitting on code they do not understand. Products built quickly, making real money, with nobody in the building able to explain how they work. Their owners generally know it. The first serious production incident, or the first technical due diligence in a funding round, is when it surfaces. Some are starting to ask for an outside view before that happens, which is the right instinct, and earlier is a great deal cheaper than later.

So what should you take from this?

If you lead a business that builds software, I think there are four things worth taking away from this.

Building software was never the issue. Yes, it was more expensive and timely, but we've always known how to build it. AI took coding away and has made it look like you can remove your whole tech team, but coders were only a small part of it. Elevating coders to define best practices makes sense, but the rest of the team needs to stay put, at least for now.

The gains are real but they depend entirely on the setting. A well-defined rebuild and a messy legacy codebase are different problems, and the published evidence points in opposite directions for good reason. Measure your own.

The savings move upstream, not away. Less money on writing code means more needed on deciding what to write, reviewing what comes back, and testing it properly. A plan that banks the saving without funding the review is a plan to accumulate debt.

And the skills that matter have shifted rather than disappeared. Product thinking, architecture, testing and design were valuable before. They are now the constraint. Knowing when to accept the AI recommendation and when not to is becoming trickier and trickier. If you're building a demo product that will get rewritten once you actually start, then click yes to every suggestion. If you're building a product that needs to support and scale with the business, be a lot more selective.

What this means for founders

For founders, there is a significant opportunity in all of this. It is now possible to get from an idea to working software faster and with less development resource than it was even a few years ago. But removing some of the cost of writing code does not remove the decisions around what to build, how to build it or what should wait.

In many ways, those decisions matter more when building becomes easier. That's part of the thinking behind Aldemis Foundry. We combine AI-assisted development with experienced technology leadership to help founders turn ideas into software, whilst keeping experienced people responsible for the decisions that matter.

Have an idea you're considering? Explore Aldemis Foundry, or click here to contact us.