AI-assisted software development produces more code, but not automatically better quality: statistically, twice as much code means twice as many bugs. According to the available studies, automated code reviews deliver only about 30 percent useful comments. AI can supplement quality assurance, but it can’t replace it.
Key Takeaways
- Producing twice as much code statistically means twice as many bugs: AI-assisted code generation makes the quality problem bigger instead of solving it.
- According to studies, AI code reviews deliver only about 30 percent useful comments; the rest is irrelevant or actively harmful to the system.
- Compared with static analysis, an AI review costs roughly 1,000 times as much, because expensive language models have to run for every check.
- Without deliberate countermeasures, the internal quality of a software system measurably erodes when AI agents generate and change code unsupervised.
- Some developers deliberately write individual features by hand again so they don’t lose their programming skills by only reviewing code.
Twice as Much AI-Generated Code Means Twice as Many Bugs
If you increase the amount of AI-generated code, you statistically increase the number of bugs by the same factor. That’s the blind spot in the current debate about AI-assisted software development. Most discussions revolve around how to produce code even faster. Hardly anyone asks whether the problem in practice was ever too little code.
For long-lived systems, the math is uncomfortable. Benjamin Hummel works with clients whose software doesn’t run to 10,000 or 20,000 lines but into the millions. Systems like that are hard for people to get their heads around, and an AI model struggles with them too.
The success stories you hear so often rarely show the other side. What works on a small scale, say an app that falls out of a single prompt, says little about whether the same approach holds up in a grown, complex system.
Where Companies in German-Speaking Countries Really Stand
The spectrum is wide, and nobody has a fully automated software factory up and running. The impression that everyone else is already further ahead doesn’t survive contact with reality.
Some teams are experimenting with agentic tools on a small scale. Others have rolled out agentic coding tools to every developer. And some are already rolling them back, because they’ve found that running them costs money and needs to be managed in a new way.
That reversal isn’t an isolated case. Agentic work burns tokens, and an agent that goes its own way gets expensive fast.
Why Quality Assurance Becomes the Real Bottleneck
When more code comes out at the front, the bottleneck moves to the back. That’s exactly where quality assurance sits, whether it’s a person or a slow test process.
The tempting answer is to drop quality assurance because it slows things down. That may be fine for a prototype. For a production system that sends out tax assessments or calculates insurance policies, it’s a bad idea.
Instead of saving on quality assurance, the opposite logic applies: quality assurance has to grow with the new volume of code. The question is whether existing practices can simply be scaled up, whether new approaches are needed, or whether it takes a mix of both.
Harness Engineering: The Scaffolding Around the Model
An LLM is a machine that takes in words and puts out words. To turn that into targeted software development, you need control around it. The term harness engineering has caught on for this scaffolding.
The harness feeds the existing code into the model, takes in the changes and gives the model tools: start the compiler, run the tests, react to feedback. This part has little to do with AI itself. The source code of Claude Code, which became public, runs to two to three hundred thousand lines: classic software engineering, just to make the AI usable in the first place.
For quality assurance, the harness is the docking point. If you step in here, you can push the model’s output in a better direction: cleaner structure, less redundancy. Because generating code is cheap, models quickly rebuild functions that have long existed in utility classes, with all the familiar maintenance problems.
Fast Feedback Matters, for the Agent Too
The old principle still holds; only the recipient has changed. Developers used to need fast feedback so they wouldn’t spend three days heading in the wrong direction. Today the same question applies to the AI agent.
Static analysis belongs in the harness as a tight control loop. Through an interface, often MCP, the findings flow straight back to the agent, which can then act on them.
Tests get trickier when the automated suite runs for hours or days. Then it slows the agent down. Test selection helps: a change to the export module doesn’t call for the tests of the accounting logic, but for the tests that give the strongest signal for that specific change. Research has discussed selection methods like these for a long time, and some have made it into practice.
Static Analysis Works Surprisingly Well with AI
The models often apply the quality feedback from static analysis with surprising reliability. That even lowers an old barrier.
Developers used to get annoyed when a tool dumped findings on them after the work was done. Feed the same findings into the agent and it cleans them up, and the code ends up looking better. Regression tests remain a must, though, so no functionality gets lost in the cleanup.
Interestingly, rules you would never have switched on before now make sense. A real example: in a Java system, a model wanted to get at the encapsulated internals of a class and went around the encapsulation with reflection. An experienced human developer wouldn’t come up with that. But because of the random element in the models, it does come up now and then, and when it does, you want to catch it before the code goes live.
Without Supervision, Internal Quality Erodes
Early studies suggest that a system’s quality declines over time when AI works on it unsupervised. Various quality metrics trend downward, and there’s anecdotal evidence that the models themselves then find it harder and harder to change the code.
That’s no surprise. Let lots of people work on a system unsupervised and you end up with so many dependencies that every change requires keeping seventeen things in mind at once.
With models, there’s also a technical limit. The context window is finite, and even when you fill it up, the model doesn’t take everything into account. It picks out some parts and misses others. A model struggles, too, when it has to hold too much at once. Be careful with analogies like this, though: terms like attention carry human connotations, even though in the end it’s all matrix multiplication.
Who Is Liable When the Airbag Doesn’t Deploy?
In the end, it always comes down to who is responsible for the code. For automotive software that controls an airbag, that question decides liability.
Going to OpenAI or Anthropic and holding their models responsible doesn’t work. It’s in the fine print. The risk stays with the business, and there have been cases where individual developers were held liable because they hadn’t developed and tested according to the state of the art. The bar is high, but those cases exist.
That’s why many industries are cautious. They choose one of two paths: either a review process that reads every single line of code, or tight restrictions up front where every proposed change has to be looked at. Both take a lot of effort, and after half an hour of nothing but reviewing, you just sit there clicking “Yes, yes, yes.”
Full-Time Reviewer Is a Dangerous Role
If most of your code is generated and you only review it, you end up in the role people are least suited for. Checking code for correctness by eye works for maybe thirty minutes if you’re focused. After that, you’re done.
In their own development, Benjamin’s team deliberately stays conservative. Every change was already reviewed across the board before, and that isn’t changing. Before the actual review, someone checks whether the code the agent delivered is even good enough, because dumping unfiltered code on the reviewer wouldn’t be fair.
Both review stages still turn up so many problems that Benjamin’s team won’t give them up. They aren’t always bugs. Often something is inconsistent or in the wrong place, and that comes back to bite you later during a bug fix.
One concrete countermeasure: deliberately slow down. Some colleagues are writing certain features by hand again, partly so they don’t lose the skill.
“Anyone who only reads code and no longer writes it can hardly judge what they’re actually doing.”
(Benjamin Hummel)
AI Code Review Is a Supplement, Not a Replacement
Having one AI reviewer checked by a second AI reviewer sounds like the next logical step. The numbers say otherwise. Across various studies and customer experiences, including a study by an Australian university, common tools come in at around 30 percent good review comments. The rest is irrelevant or even harmful to the system.
So accepting them blindly doesn’t make the code better. You have to filter out which comments are worth anything. That’s the fundamental difference between an AI reviewer and an experienced colleague whose comments you used to apply without a second thought.
Comparing it with static analysis makes the cost clear. An AI reviewer finds much of what static analysis finds too, but costs roughly 1,000 times as much, because expensive models have to run.
Even after an AI review, a person still finds plenty. The benefit is that the AI filters out certain classes of problems in advance. Just as nobody counts lines for duplicates by hand anymore, the human reviewer no longer has to worry about every class of issue a machine can check. Instead, they ask: Is the architecture right? Does this make sense from the user’s point of view?
What AI Reviews Really Cost
The most powerful models available drive costs up fast. Early experiments in Benjamin’s team came to more than 500 dollars a day for the whole team. Extrapolated, that’s six figures a year.
For some, that’s pocket change; for a mid-sized company, it’s a lot to swallow. Vendors of these tools face a trade-off: cheaper models push costs down, more expensive ones raise review quality. Every subscription strikes a balance between the two.
So the real engineering challenge isn’t the model but what you do with its output. How do you get the benefits without inheriting the drawbacks, and stay cost-efficient while you’re at it? For a six-figure sum, you could also hire a tester.
A side thought belongs here too: not every task needs AI. What a classic script handles cheaply and reliably shouldn’t be solved by an expensive model the long way round.
More Results Aren’t Better Results
The next wave is about the sheer volume of output AI produces. Security analyses are one example. Tools in this category produce a huge number of results, but not every reported vulnerability matters.
That’s familiar from static analysis. Is this a real threat scenario? Can it actually be exploited, or does it describe a situation that never happens in the real world? Teams quickly get overwhelmed by that assessment. Reading all the findings, deciding and then acting on them is the real bottleneck.
In security it’s particularly bad, because dependent libraries seem to reveal new vulnerabilities every week. The same pattern repeats with tests: if AI writes lots of tests, you get more tests that fail even though nobody changed anything, and more flaky tests. Every new capability drags new problems along with it.
Slowing Down Is a Skill
The constant acceleration leads to burnout, and you hear about it from many sides. The open-source community is hit particularly hard. Bots flood projects with security issues, while many maintainers do the work as volunteers alongside their day jobs. A large part of our digital infrastructure rests on their shoulders.
Sometimes it isn’t even real acceleration, just a very fast hamster wheel. New tools every month, everything keeps shifting, and management is calling for even more speed.
The counter-movement takes courage and an environment that allows it. Stepping back and asking what you’re actually doing is a skill in itself these days. Because the problem was never too little code. It was understanding what users really need and building exactly that.
Frequently Asked Questions
Does more AI-generated code automatically lead to better software?
No. Statistically speaking, doubling the amount of generated code also doubles the number of errors. This is particularly problematic for systems that don’t consist of 10,000 or 20,000 lines, but rather run into the millions: Such codebases are difficult for humans to make sense of, and models struggle with them as well. Success stories from small apps don’t tell us much about this.
Are companies already using agent-based code development on a broad scale?
The spectrum is broad, and no one has a fully automated “software factory” up and running. Some teams are experimenting with agent-based tools on a small scale, while others have rolled them out to all developers. Some are already rolling them back because operations cost money and require new management. Agent-based work consumes tokens, and an agent that goes its own way quickly becomes expensive.
Where can quality assurance even begin with AI agents?
At the harness, that is, the classically programmed framework surrounding the model. It feeds existing code into the model, processes changes, and provides tools: launching compilers, running tests, and responding to feedback. Intervening here drives efforts toward a cleaner structure and less redundancy. Static analysis belongs as a tight control loop, with its findings fed directly back to the agent.
Do AI agents reliably implement the findings from static analysis?
Yes, often surprisingly reliably. In the past, developers would get annoyed when a tool dumped findings in their laps after the work was done; if you feed those same findings into the agent, it cleans them up. Regression testing is still mandatory, however, to ensure that no functionality is lost during the cleanup. This makes it worthwhile to enforce rules that would never have been activated in the past, such as those preventing reflection access to encapsulated internals.
What happens to quality when AI agents work on a system unsupervised?
It declines over the long term. Initial studies show a downward trend across various quality metrics, and there are anecdotal indications that the models subsequently find it increasingly difficult to modify the code themselves. Added to this is a technical limitation: the context window is limited, and even a fully populated window is not taken into account in its entirety. The model picks out certain parts and overlooks others.
Can the provider of a language model be held liable for faulty code?
No, that’s stated in the fine print. Responsibility for the code remains with the company, and there have been cases where individual developers were held liable because they failed to develop and test according to the state of the art. The barriers to proving this are high, but such cases do exist. For safety-critical software, such as an airbag control system, this very question is decisive.
How many comments from an AI code review are useful?
About 30 percent. Across various studies and customer experiences, including a study by an Australian university, common tools yield roughly this percentage of useful review comments. The rest is irrelevant or even harmful to the system. Blindly adopting the suggestions does not improve the code, and a human reviewer will still find many issues after the AI review.
What is the cost of using powerful models for automated code reviews?
Significantly more than traditional tools: An AI review finds much of what static analysis also finds, but costs about 1,000 times as much. Initial experiments in Benjamin Hummel’s team showed costs of over $500 per day for the entire team, amounting to six-figure sums per year. That money could also be used to hire a tester.
