Some organizations get large gains from coding agents. Others get more defects and no more throughput. It is tempting to blame the tools. The evidence points somewhere else: the codebase the agent is working in.
Adam Tornhill, founder and CTO of CodeScene and author of Your Code as a Crime Scene, has spent 15 years measuring technical debt. His team’s recent research asks whether code quality can predict whether an agent will help or amplify defects. This post walks through what they found and what to do with it.
The finding: agents need near-perfect code
The hypothesis was simple. The patterns that make code hard for humans to understand should also hurt coding agents. Agents are trained on human-written code, so they inherit human sensitivities.
The result was more dramatic than expected. To keep defect rates in check, code quality needs to be close to a perfect 10 on CodeScene’s code health scale. As health declines, defect rates rise, and the relationship is nonlinear. It gets bad fast.
On unhealthy legacy code, Tornhill’s measurements show a typical increase of 40 to 50 percent in defects, with no gain in throughput. In the worst cases, hallucination and error rates can reach 80 to 90 percent. You get worse software, and you do not even get it faster.
What code quality actually means
No single metric captures code quality. Tornhill’s code health metric samples multiple properties, each one correlated with a factor that makes code hard to understand:
- Missing abstractions, such as long chains of complicated boolean logic.
- Low cohesion, where one module carries too many business responsibilities.
- Duplicated code.
- Very long methods, sometimes running to hundreds or thousands of lines.
An algorithm converts the samples into a range from 10 (healthy) to 1 (the worst technical debt imaginable).
Language is not the problem. A legacy Java codebase is not unhealthy because it is Java. It is unhealthy because the implementation is low-level and brute-force: nested conditionals, loops, and nothing in the code that states what problem it solves. Without good functions, well-named classes, and clear modules, an agent cannot build context. Neither can a new hire.
Why agents fail on legacy code
An agent works from a prompt describing a problem and a codebase that should reflect it. In healthy code, there is a natural mapping between the two. In legacy code, there is not. Even the agent’s search is hard. When it is then asked to change the code, the result is hit or miss.
Tests can partly compensate. But missing tests are usually a hallmark of the same legacy code.
The management mistake Tornhill sees most is treating all code as equal. Vendor claims like “55 percent faster” are not universal. Your existing code is the most important part of any agent’s context, and most organizations do not know how bad theirs is.
Finding the AI-ready parts of a large codebase
Most legacy codebases contain parts that are in good shape. The missing capability is situational awareness: which parts are AI-ready today, and which are not.
Tornhill’s approach for a 5 to 10 million line system:
- Analyze code health across the whole codebase. Find the problems and the parts that are already agent-friendly.
- Overlay business relevance. Around 90 percent of a large codebase is stable and rarely touched. Lower quality there may be acceptable. The hotspot technique identifies the parts that change often and carry business risk.
- Make the business-critical hotspots AI-ready first. That is where the return on investment is.
The threshold for agentic uplift
There is a second threshold below 10. Code with serious quality issues can still be lifted by an agent if its health is roughly 6.5 to 7 or above. CodeScene provides code health to the agent through an MCP server, so the agent has a direction and a goal, and refactorings that used to take weeks complete in a day.
Below that threshold, in truly unhealthy code, a human has to guide the agent closely. The transformations can still be automated, but in small iterative steps, validated at each one.
Fully autonomous feature development needs code health of about 9.5 or higher.
Discipline matters more, not less
Tornhill’s experience after a year of hands-on agentic work is that succeeding with agents takes more engineering discipline than coding by hand. The reasons:
- Proofs of concept are one-off tasks. Software is not. Around 95 percent of cost comes after the first release, in maintenance, where agents need the most guidance.
- Safeguards have to run while code is written. Automated quality gates via MCP servers and CLI tools give feedback to the agent in the loop.
- Test coverage has to approach 100 percent. That used to be extreme. It is now the only way to trust agent output.
- Design is still human. Good design is a guardrail in itself. It sets the pattern the agent follows. Tornhill now spends far more time up front on anything novel, and insists on end-to-end tests before any code is produced.
AI accelerates existing trends. Good code gets better faster. Bad code gets worse faster.
What to do with this
If coding agents are underperforming on your codebase, the first step is to find out where you stand. Measure code health. Identify the hotspots. Start agents on the parts that are ready, and plan the uplift for the parts that are not.
That is also the sequence Swimm follows. Deterministic analysis maps dependencies, entry points, data flows, dead code, and cross-repo relationships. The output is a verified picture of the system that agents and people can trust before changes are made.
Swimm is a product-enabled service company. We combine deterministic analysis for accuracy, AI for scale, and SMEs to catch what tools miss. Book a 30-minute scoping call to find the AI-ready parts of your codebase.
FAQ
Does code quality affect how well AI coding agents work?
Yes, strongly. Research from CodeScene shows agents need code health close to a perfect 10 to keep defect rates in check. On unhealthy legacy code, defects rise 40 to 50 percent with no throughput gain.
What makes a codebase AI-ready?
Good abstractions, cohesive modules, little duplication, short methods, and tests. In short, the same properties that make code understandable to humans. Agents are trained on human code and share human limitations.
Can AI agents work on legacy code?
Yes, with conditions. Code with health above roughly 6.5 to 7 on a 10-point scale can be lifted by an agent given direction and a goal. Below that, a human must guide the agent in small, validated steps.
Where should you start applying AI in a large legacy codebase?
In the business-critical hotspots that are already healthy. Most of a large codebase is stable and rarely changed, so start where the code is both important and ready.
Does AI reduce the need for engineering discipline?
No. It increases it. Most software cost comes after first release, where agents need guidance. Automated quality gates, near-total test coverage, fast feedback loops, and strong up-front design are now requirements.