Software development has an interesting problem right now. We’ve spent years trying to make developers write code faster, and AI coding agents are finally delivering something close to that promise.
Tools like Claude Code, Codex, and GitHub Copilot can explore repositories, implement features, write tests, and fix bugs. Sometimes, they can complete tasks that would otherwise take a developer hours.
But there’s a question that doesn’t receive nearly enough attention.
What happens six months later, when someone needs to change that code?
Generating code and maintaining software are not the same thing. And the faster we become at producing code, the more important that distinction becomes.
Writing Code Is Only Half the Job
Developers don’t spend their entire careers creating new applications from scratch.
Much of the work involves understanding existing systems, fixing bugs, updating dependencies, changing business rules, and figuring out why something that worked yesterday suddenly stopped working.
That’s where maintainability matters.
A maintainable codebase is one that developers can understand, modify, and test without unnecessary difficulty. It doesn’t need to be perfect, and it certainly doesn’t need to follow every fashionable architectural pattern.
It just needs to make future changes reasonably straightforward.
AI coding agents complicate this picture because they can produce large amounts of code without requiring the developer to understand every implementation detail before it’s generated.
That’s useful when the output is correct, simple, and consistent with the existing architecture.
It’s less useful when the agent creates an abstraction nobody needed, duplicates functionality that already exists, or introduces dependencies that make future changes harder.
The code might work perfectly today.
Tomorrow’s developer still has to live with it.
What the Research Says About AI-Generated Technical Debt
A study titled Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild, last revised on October 13, 2026, provides an interesting perspective.
The researchers analyzed approximately 302,600 verified AI-authored commits across 6,299 GitHub repositories, covering five AI coding assistants.
They identified 484,366 distinct issues using static analysis. Code smells accounted for 89.3% of them.
Code smells aren’t necessarily bugs. They’re patterns that may indicate maintainability problems, such as excessive complexity or questionable design decisions.
The study also found that between 7.5% and 14.8% of each assistant’s commits introduced at least one detected issue. More notably, 22.7% of the tracked AI-introduced issues were still present in the latest repository revisions.
That’s worth paying attention to.
However, these findings don’t establish that AI-generated code is universally worse than human-written code. Static analysis can identify suspicious patterns, but it cannot determine whether every warning represents a meaningful problem in production.
The study also doesn’t establish how much developer time those surviving issues will eventually cost.
What it does show is that AI-authored changes can introduce quality concerns that remain in real repositories rather than disappearing immediately after the next commit.
And those concerns matter when the software needs to evolve.
But AI Doesn’t Automatically Make Code Harder to Maintain
Before we blame coding agents for the next generation of technical debt, there’s another study worth discussing.
Researchers writing in Empirical Software Engineering published a controlled experiment in June 2026 involving 151 participants, most of whom were professional developers.
In the first phase, developers implemented features in a Java application, either with or without AI assistance.
In the second phase, different developers were asked to extend those implementations without using AI.
The researchers found no statistically significant difference in subsequent task completion time or code quality between the AI-assisted and non-AI-assisted implementations.
Interestingly, AI assistance was associated with a 30.7% median reduction in implementation time during the first phase.
So, in this setting, developers completed the initial work faster without producing code that was demonstrably harder for another developer to maintain.
That sounds pretty encouraging.
There are limitations, though. The study’s development tasks were relatively constrained, and its underlying experiment predates the widespread adoption of today’s more autonomous coding agents.
A controlled Java task cannot tell us everything about maintaining a complicated production system over several years.
Still, the findings challenge the simplistic argument that AI-generated code is inherently bad.
The problem isn’t necessarily who wrote the code. It’s whether anyone understands it well enough to take responsibility for it.
When Nobody Understands the Code Anymore
There’s a reason this question interests me.
During my time at Kooora, our team inherited a Go library from a developer who had left the company.
Nobody else on the team was particularly comfortable with Go.
We attempted to maintain the library with AI assistance, using it to help fix bugs and implement relatively minor features.
The problem wasn’t simply getting AI to produce code.
It was understanding and reviewing what it produced.
When a team doesn’t know the language or the existing implementation well enough, evaluating AI-generated changes becomes difficult. You can check whether the tests pass, but that doesn’t necessarily tell you whether the approach is appropriate or whether you’ve introduced another problem elsewhere.
We eventually rewrote the library rather than continuing to struggle with it.
That experience wasn’t a scientific experiment, and I wouldn’t claim it proves anything about the general reliability of AI coding assistants.
But it illustrates a problem that AI can make easier to overlook.
If a team cannot confidently maintain a piece of software, generating more code for it doesn’t necessarily solve the underlying issue.
Sometimes, it simply postpones the difficult decisions.
The Productivity Numbers Don’t Tell the Whole Story
Productivity is another area where the evidence deserves careful interpretation.
GitHub’s controlled Copilot study involving 202 experienced developers found improvements in functionality and several code-quality measures when participants used AI assistance.
That’s evidence that AI can improve code quality in certain development tasks, not merely produce code faster.
Yet productivity gains aren’t universal.
In July 2025, METR published a randomized controlled trial involving experienced open-source developers working in repositories they already knew.
The developers took 19% longer to complete their tasks when AI assistance was allowed.
This doesn’t mean AI tools always slow developers down. The study measured a particular group of developers, tasks, and generation of AI systems.
What makes the finding interesting is the gap between perceived and measured productivity.
An assistant can make individual coding steps feel easier while still adding time for prompting, inspecting generated changes, correcting mistakes, and reviewing the final result.
And even when an agent genuinely makes today’s task faster, that doesn’t automatically establish a long-term productivity gain.
To understand that, we would also need to consider what happens after the code is merged.
The Hidden Cost of Understanding Someone Else’s Code
Imagine asking an AI agent to implement a new API endpoint.
It examines the codebase, creates the endpoint, adds validation, writes tests, and produces a pull request.
Everything passes.
You review the changes, merge the pull request, and move on.
Two months later, a different developer needs to modify that endpoint.
They discover that the generated implementation uses an unfamiliar abstraction, duplicates part of an existing service, and handles an edge case differently from the rest of the application.
None of those decisions necessarily caused a bug during the original implementation.
But understanding them takes time.
Now imagine this happening repeatedly across dozens of features.
The original productivity gains may be real, while some of the resulting maintenance costs are pushed into the future.
This is what makes technical debt difficult to measure.
We can count completed tasks, pull requests, and generated lines of code. Measuring the cost of future comprehension, debugging, and architectural inconsistency is much harder.
It would be premature to conclude that AI agents necessarily increase those costs. The available research is mixed, and long-term evidence remains limited.
But ignoring the possibility because today’s tests pass would be equally premature.
Human Code Reviews Still Matter
Another interesting development comes from a 2026 study involving more than 10,000 Meta developers and 400,000 code changes.
The researchers examined AI-assisted code, review time, and production outages.
They observed shorter review times and lower outage rates for changes containing AI-generated code. However, those relationships were influenced by context: AI-generated contributions appeared more frequently in less-central parts of the codebase.
In other words, we shouldn’t automatically credit AI for better outcomes when developers may be using it on different kinds of tasks.
The same principle applies to code reviews.
A pull request that looks clean and passes its tests isn’t necessarily well designed.
Reviewers still need to ask whether the implementation fits the existing architecture, whether its complexity is justified, and whether future developers can reasonably modify it.
This becomes especially important when agents generate changes faster than developers can meaningfully inspect them.
A review process that becomes little more than approving successful test runs is missing much of its purpose.
How I’d Approach AI-Assisted Development
I don’t think the answer is to stop using coding agents.
That would be an overreaction, especially when there’s credible evidence that AI assistance can improve development speed and code quality in appropriate settings.
The better approach is to treat AI-generated code like any other contribution, while recognizing that its volume and generation speed can create additional review challenges.
A few practices seem particularly important:
- Keep changes focused. Smaller pull requests are generally easier to understand, review, and correct.
- Review architectural decisions, not just syntax. Verify that new abstractions, dependencies, and patterns belong in the project.
- Don’t confuse passing tests with maintainability. Tests help establish behavior, but they cannot fully assess design quality.
- Use existing project conventions. Giving agents clear architectural guidance reduces unnecessary inconsistency.
- Make someone responsible for the result. An AI agent cannot replace the team’s responsibility for code that reaches production.
- Measure outcomes beyond completed tasks. Defects, rework, review effort, and the difficulty of future changes deserve attention alongside delivery speed.
There’s also a practical rule worth following.
If you cannot explain what a generated change does and why it was implemented that way, you probably shouldn’t merge it yet.
That doesn’t mean understanding every line must require manually writing it yourself.
It means understanding enough to evaluate the design, identify important risks, and maintain the implementation when circumstances change.
The Real Question Isn’t How Much Code AI Can Write
AI coding agents will almost certainly continue improving, and developers will continue finding ways to use them effectively.
The research already shows that some assisted workflows can produce faster implementations and code that performs well in reviews.
It also shows that AI-generated changes can introduce persistent quality issues, and that the relationship between AI usage and actual developer productivity is more complicated than impressive demos suggest.
Those findings aren’t contradictory. They’re evidence that software engineering involves more than code generation.
I think the biggest mistake developers can make is treating the completion of an AI-generated task as the end of their responsibility.
Shipping a feature is one achievement. Keeping it understandable and adaptable is another.
The best AI-assisted code isn’t necessarily the code an agent writes the fastest. It’s code the team can confidently maintain long after the original prompt has been forgotten.
