AI coding tools are making software faster and easier to create. That’s an obvious productivity opportunity. But there’s another side to the equation: somebody still has to look after everything we create.
For decades, building software has been expensive.
A developer needed time to understand the problem, work out a solution, write the code, test it and eventually maintain whatever they had built.
Generative AI is changing that process remarkably quickly.
A developer can describe a feature and have AI produce working code within seconds. More advanced coding agents can navigate repositories, modify files, run tests and take on increasingly complicated tasks with less human involvement.
It’s easy to see the appeal.
If something that previously took several hours can now be completed in twenty minutes, that’s a genuine productivity gain.
But there’s something we shouldn’t lose sight of.
Software was never expensive simply because somebody had to type the code.
The real cost continues long after that.
The code needs to work. It needs to be secure. Other developers need to understand it. And six months from now, when something inevitably changes or breaks, somebody needs to work out what happened.
Producing more code doesn’t necessarily mean producing more value
One obvious way to judge an AI coding assistant is by how much faster it helps developers write code.
The problem is that the amount of code produced has never been a particularly useful measure of productivity.
A hundred lines that solve a problem cleanly can be far more valuable than a thousand lines that create three new problems along the way.
AI makes that distinction particularly important because producing more code has suddenly become very easy.
One recent study examined 304,362 verified AI-authored commits across 6,275 public GitHub repositories.
Researchers identified 484,606 issues associated with those commits, including code smells, bugs and security problems. More than 15% of the commits produced by each AI assistant studied introduced at least one issue.
Perhaps more interestingly, 24.2% of the tracked issues were still present in the repositories’ latest revisions.
Researchers call this technical debt.
A business could use a rather less technical definition:
Work we’re going to have to deal with later.
Technical debt isn’t new
To be fair to AI, developers have been creating technical debt for as long as we’ve been creating software.
People take shortcuts. Deadlines arrive. Requirements change. A temporary fix works well enough, everyone moves on and five years later somebody discovers that half the business apparently depends on it.
Anyone who has worked around an established website or software system will recognise the pattern.
Technical debt is simply the future cost of dealing with those decisions.
AI hasn’t invented it.
What AI could change is how quickly we accumulate it.
If a feature once required three days of developer time, there was a natural limit to how much new software a team could produce.
Give that team tools capable of producing considerably more code in the same three days and you’ve increased its output.
But you’ve potentially increased something else too.
There is now more code to review, test, document, secure and eventually maintain.
The work hasn’t necessarily disappeared.
Some of it has moved further down the road.
Measuring productivity is proving harder than expected
This is where the AI coding story gets particularly interesting.
In 2025, research organisation METR asked experienced open-source developers to complete real tasks in repositories they already knew well. Sometimes they could use AI tools. Sometimes they couldn’t.
The developers expected AI to make them about 24% faster.
Instead, using the early-2025 tools included in the study, they took 19% longer.
What I find particularly interesting is that even after the experiment, the developers still believed AI had made them faster.
That doesn’t mean AI coding tools make developers slower.
METR doesn’t make that claim either.
The technology is changing too quickly for such a simple conclusion. By early 2026, METR was already seeing indications that newer AI tools were providing greater productivity benefits. Measuring those gains was also becoming more difficult because developers increasingly didn’t want to work without AI.
But the research does raise an important point.
Feeling more productive and actually becoming more productive aren’t always the same thing.
And neither can be measured simply by watching how quickly code appears on a screen.
Experienced developers may become more valuable, not less
One of the assumptions surrounding AI coding is that better agents will eventually require less developer involvement.
In practice, experienced developers appear to be finding a different way of working with them.
Research into professional use of coding agents suggests developers don’t simply give an agent a task and accept whatever comes back.
They supervise it. They decide what to delegate. They review the output and keep control of important design and implementation decisions.
That gives us an interesting picture of where software development could be heading.
If AI becomes increasingly good at producing the implementation, experienced developers may spend more of their time applying judgement.
Should we build this in the first place?
Does the solution fit the rest of the system?
What happens if it fails?
Is it secure?
Are we creating something unnecessarily complicated?
And will the next developer who opens this code a year from now have any idea what is going on?
AI doesn’t make those questions disappear.
Cheap code may actually make them more important.
What if review becomes the bottleneck?
Imagine a development team currently produces ten meaningful code changes each week.
With AI, it can suddenly produce thirty.
That sounds like a threefold increase in productivity.
But those thirty changes still need to go somewhere.
Someone needs to review them. Tests need to run. Problems need to be identified. Changes need to fit into the existing system.
If the team’s capacity to review code hasn’t increased alongside its capacity to generate it, the bottleneck hasn’t disappeared.
It has simply moved.
And there’s another risk.
When producing code becomes faster, the temptation to ship faster becomes stronger too. If review standards start slipping because the team can’t keep up with the volume, today’s impressive productivity gain can quietly become next year’s maintenance problem.
That creates an important distinction.
Generation speed asks:
How quickly can we create software?
Engineering productivity asks:
How efficiently can we create software that continues to do its job?
Those are very different measures of success.
Cheap software means we’ll probably build more of it
There’s another consequence of AI coding that I think deserves more attention.
When something becomes cheaper and easier to produce, we tend to produce more of it.
And in many ways, that’s one of the most exciting things about AI-assisted development.
An internal tool that was never important enough to justify several days of developer time might now be built in an afternoon.
A small automation suddenly becomes worthwhile.
A team can test an idea before committing substantial time and money to it.
That opens up enormous possibilities.
It can also leave businesses owning considerably more software than they did before.
And small internal tools have an interesting habit of becoming important.
Someone builds a quick solution on Tuesday.
By Friday, three people are using it as part of their daily work.
Six months later, it has quietly become part of a business process. Nobody is entirely sure how it works. The person who created it has moved on and whatever conversation they had with the AI is long gone.
But the software is still there.
And now somebody has to look after it.
AI writing code is no longer the interesting question
Whether AI should write code is probably a debate we’re quickly moving beyond.
It already does.
Developers are already using it, and the tools are going to get better.
The more useful question for businesses is what needs to change around the code we’re now able to produce so easily.
We still need good review processes, proper testing, documentation, security and sensible architecture.
Not despite AI.
Because of the amount of software AI may allow us to create.
When code becomes cheap, deciding what is worth building, what is safe to release and what is worth maintaining becomes increasingly important.
AI may make writing code considerably cheaper.
It hasn’t made owning software free.
And if businesses forget the difference, the bill may simply arrive later.