AI-assisted software development generates more code, but not necessarily better quality: Statistically speaking, writing twice as much code results in twice as many errors. According to available studies, automated code reviews provide only about 30 percent of useful feedback. AI can supplement quality assurance, but it cannot replace it.
Key Takeaways
- Those who produce twice as much code statistically have twice as many errors: AI-assisted code generation exacerbates the quality problem rather than solving it.
- According to studies, AI-assisted code reviews provide only about 30 percent usable feedback; the rest is irrelevant or actively harmful to the system.
- Compared to static analysis, an AI review costs roughly 1,000 times more because expensive language models must be invoked for each check.
- Without targeted countermeasures, the intrinsic quality of a software system measurably deteriorates when AI agents generate and modify code unsupervised.
- Some developers deliberately rewrite individual features by hand to avoid losing their programming skills through code review alone.
Twice as Much Code Means Twice as Many Errors
Increasing the amount of generated code statistically increases the number of errors by the same amount. This is the blind spot in the current debate about AI-assisted software development. Most discussions revolve around the question of how to generate code even faster. Hardly anyone asks whether the problem in practice has ever been too little code.
For long-lived systems, this equation is uncomfortable. Benjamin Hummel works with clients whose software doesn’t consist of 10,000 or 20,000 lines, but runs into the millions. Such systems are difficult for humans to fathom, and an AI model struggles with them as well.
The success stories we often hear rarely show the other side of the coin. What works on a small scale—such as an app generated from a prompt—says little about whether the same approach will hold up in a mature, complex system.
Where Companies in German-Speaking Countries Really Stand
The spectrum is broad, and no one has a fully automated software factory up and running yet. The impression that everyone else is already further along does not hold up to reality.
Some teams are experimenting on a small scale with agent-based tools. Others have rolled out agent-based code development tools across the board to all developers. And some are already rolling them back because they’ve realized that operating them costs money and requires new management.
This reversal is not an isolated case. Agent-based work consumes tokens, and an agent that goes its own way quickly becomes expensive.
Why Quality Assurance Becomes a Real Bottleneck
When more code is produced up front, the bottleneck shifts to the back end. That’s exactly where quality assurance sits—whether it’s a person or a slow test process.
The tempting solution is to skip quality assurance because it slows things down. That might work for a prototype. But for a production system that sends out tax assessments or calculates insurance policies, it’s not a good idea.
Instead of cutting corners on quality assurance, the opposite logic applies: Quality assurance must grow along with the new volume of code. The question is whether existing processes can simply be scaled up, whether new approaches are needed, or whether a combination of both is required.
Harness Engineering: The Framework Around the Model
An LLM is a machine that takes in words and outputs words. For this to result in targeted code development, external control is needed. The term “harness engineering” has become established for this framework.
The harness feeds existing code into the model, processes changes, and provides the model with tools: launching compilers, running tests, and responding to feedback. This part has little to do with AI itself. The source code for Claude Code, which has been made public, comprises two to three hundred thousand lines—classic software engineering designed to make the AI usable in the first place.
For quality assurance, this harness serves as the docking point. Anyone who intervenes here can steer the model’s output in a better direction: a cleaner structure, less redundancy. Because generating code is inexpensive, models quickly recreate functions that have long existed in utility classes—with all the familiar maintenance problems.
Rapid Feedback Is Crucial—Even for the Agent
The old principle remains unchanged; only the recipient is new. In the past, the developer was supposed to receive rapid 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. Via an interface—often MCP—the findings flow directly back to the agent, which can then implement them.
Testing becomes more challenging when the automated suite runs for hours or days. In that case, it slows the agent down. Test selection helps: A change to the export module doesn’t require testing the accounting logic, but rather the tests with the highest signal relevance for that specific change. Such selection methods have long been discussed in research, and some have made their way into practice.
Static Analysis Works Surprisingly Well with AI
The models often implement the quality feedback from static analysis with surprising reliability. This even breaks down an old barrier.
In the past, developers would react with annoyance when a tool dumped findings in their laps after they had finished their work. If you feed those same findings into the agent, it cleans them up, and the code ends up looking better. Validation through regression testing remains mandatory, however, to ensure that no functionality is lost during the cleanup.
It’s interesting that new rules make sense that you would never have activated in the past. A real-world example: In a Java system, a model wanted to access the encapsulated internals of a class and bypassed them using reflection. An experienced human developer would never come up with this idea. But because of the random element in the models, it does occasionally pop up—and when it does, you want to catch it before the code goes into production.
Without supervision, internal quality erodes
Initial studies suggest that the quality of a system declines over the long term when AI works on it unsupervised. Various quality metrics show a downward trend, and there is anecdotal evidence that the models then find it increasingly difficult to modify the code themselves.
This comes as no surprise. If you let many people work on a system unsupervised, so many dependencies arise that every change requires keeping seventeen things in mind at once.
With models, there’s an additional technical limitation. The context window is limited, and even if you fill it completely, the model doesn’t take everything into account. It picks out certain parts and overlooks others. Even a model struggles when it has to keep too much in mind at once. Caution is advised with such analogies, because terms like “attention” carry human connotations, even though, in the end, it’s just a matter of multiplying matrices.
Who is liable if the airbag fails to deploy?
Ultimately, the question always comes down to who is responsible for the code. In the case of automotive software that controls an airbag, this question determines liability.
Going to OpenAI or Anthropic and holding their models responsible doesn’t work. That’s stated in the fine print. It remains a business risk, and there have been cases where individual developers were held liable because they did not develop and test the software according to the state of the art. The hurdles are high, but such cases do exist.
That’s why many sectors are cautious. They choose one of two approaches: either a review process that examines every single line of code, or strict upfront restrictions where every proposed change must be reviewed. Both are time-consuming, and after half an hour of pure reviewing, you just sit there clicking “Yes, yes, yes.”
The Role of the Full-Time Reviewer Is Dangerous
Anyone who has the majority of the code generated automatically and only reviews it ends up in the role for which humans are least suited. Visually checking code for correctness might work for about thirty minutes if you’re focused. After that, it’s over.
In their own development, Benjamin’s team takes a deliberately conservative approach. All changes have already been thoroughly reviewed beforehand, and that’s how it stays. Before the actual review, someone checks whether the code delivered by the agent even meets the requirements, because rejecting unfiltered code wouldn’t be fair to the reviewer.
Both review stages continue to uncover so many issues that Benjamin’s team doesn’t do away with them. These aren’t always bugs. Often, something is inconsistent or in the wrong place, which comes back to haunt them later during bug fixes.
A concrete countermeasure: deliberately slow things down. Some colleagues are writing certain features by hand again, partly to ensure they don’t lose that skill.
Anyone who only reads code and no longer writes it can hardly assess what they’re actually doing. Benjamin Hummel
AI Reviews Are a Supplement, Not a Replacement
Having an AI reviewer checked by a second AI reviewer sounds like the next logical step. The numbers, however, tell a different story. Across various studies and customer experiences—including a study by an Australian university—current tools yield around 30 percent of useful review comments. The rest is irrelevant or even harmful to the system.
So blindly accepting these comments doesn’t make the code any better. You have to filter out which comments are useful. This is what fundamentally distinguishes an AI reviewer from an experienced colleague whose comments you used to implement without question.
The comparison to static analysis highlights the cost. An AI reviewer finds much of what static analysis also finds, but costs roughly 1,000 times more because expensive models must be run.
Even after an AI review, a human still finds many issues. The benefit lies in the fact that the AI filters out certain problem classes in advance. Just as no one manually counts lines for duplicates anymore, the human reviewer no longer has to worry about every class that can be checked by a machine. Instead, they ask: Is the architecture correct? Does this make sense from the user’s perspective?
What AI Reviews Really Cost
The most powerful models available cause costs to escalate rapidly. Initial experiments in Benjamin’s team showed costs exceeding $500 per day for the entire team. Extrapolated, this amounts to six-figure sums per year.
For some, that’s a joke; for a medium-sized company, it’s a tough pill to swallow. Providers of such tools face a dilemma: cheaper models drive down costs, while more expensive ones improve the quality of reviews. Every subscription strikes a balance between the two.
The real engineering challenge, then, isn’t the model itself, but how to handle the results. How do you reap the benefits without inheriting the drawbacks—and remain cost-effective in the process? For six-figure sums, you could just as easily hire a tester.
There’s a related point to consider: Not every task requires AI. What a classic script can handle cheaply and with high reliability shouldn’t be solved by an expensive, cumbersome model.
More Results Don’t Necessarily Mean Better Results
The next wave concerns the volume of data that AI produces. Security analyses are one example. Tools in this category produce an enormous number of results, but not every reported vulnerability is relevant.
This is a familiar issue from static analysis. Is this a real threat scenario? Can it actually be exploited, or does it describe a situation that would never occur in the real world? This evaluation quickly overwhelms teams. Reading all the findings, making decisions, and then implementing them is the real bottleneck.
The situation is particularly acute in security, because dependent libraries seem to reveal new vulnerabilities on a weekly basis. The same pattern repeats itself with testing: If AI generates a lot of tests, you end up with more tests that fail even though nobody has changed anything, and more unstable tests. Every new capability brings new problems in its wake.
Slowing down is a skill
The constant acceleration leads to burnout, and you hear about it from all sides. The open-source community is hit particularly hard. Bots flood projects with security issues, while many maintainers do the work on a volunteer basis alongside their day jobs. A large part of the digital infrastructure rests on their shoulders.
Sometimes it’s not even real acceleration—just a very fast-spinning hamster wheel. New tools every month, the landscape is constantly changing, and management is calling for even more speed.
The counter-movement requires courage and an environment that allows it to flourish. Taking a step back and questioning what you’re actually doing is, in itself, a skill in these times. Because the problem was never a lack of code. It was understanding what the user really needs and implementing exactly that in a targeted way.
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 reliable. 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.
