Do These Violent Delights Have Violent Ends? Measuring the Post-Merge Fate of Agentic Code
This longitudinal study of 182 repositories reveals that while agentic code contributions achieve merge rates comparable to human code, they subsequently incur significantly higher corrective maintenance burdens and introduce more security vulnerabilities, particularly in projects with low review rates.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you've just hired a fleet of super-fast, tireless robot assistants to help you build a massive, sprawling city of code. These robots, powered by the latest "agentic" AI, can whip up entire neighborhoods of software in the blink of an eye. The tech giants are cheering, saying these robots are writing 30% to 75% of the code in their cities. The metrics look amazing: the robots are churning out pull requests (construction permits) faster than anyone can count, and most of them get approved and merged into the city plan.
But here's the twist: What happens after the permit is signed and the building is officially part of the city?
That's exactly what this study investigated. Instead of just counting how many buildings the robots built, the researchers followed the code for a full year (from May 2025 to May 2026) across 182 real-world projects. They tracked every single line of code like a detective following a suspect, asking: Does this line survive, or does it get torn down and rebuilt? Who fixes it when it breaks? And does it hide any dangerous traps?
The Big Surprise: It's Not About "How Much," It's About "How Bad"
You might expect that robot-built code would be a total disaster, crumbling immediately. Or, you might think it's perfect. The truth is a bit more subtle.
The paper found that, overall, robot code doesn't get "torn down" (terminated) at a significantly different rate than human code. If you just look at the raw numbers of how long a piece of code lasts, the robots and the humans seem to be on equal footing.
However, once you look closer at why that code gets changed, the picture changes dramatically.
- The "Bug Fix" Magnet: Robot code is a magnet for corrections. The study found that agentic code receives 46% more corrective maintenance (fixing things that are broken) than human code.
- The "Bug Fix" Specifics: Specifically, robot code gets 45% more bug fixes. While human code gets plenty of bug fixes too, the robots seem to be introducing more of them.
- The "Trap" Factor: Robot code is also more likely to bring in security weaknesses and dangerous dependencies. The study measured this using tools like Semgrep and OSV-Scanner. Robot code introduced security findings at 1.14 times the rate of human code, and high-severity (really bad) findings at 1.51 times the rate.
Think of it like this: The robots are great at building the walls, but they often forget to install the fire alarms or use flammable paint. The building stands, but it needs a lot more fire safety inspections and repairs later on.
The "No-Review" Danger Zone
One of the most critical findings is about how the code gets approved. The researchers looked at what happens when projects merge code without a human reviewing it first.
They found a direct link: The more code a project merges without a human review, the heavier the maintenance burden becomes.
- Specifically, for every 10 percentage-point increase in a project's "no-review rate," the maintenance burden on agentic code goes up by roughly 6%.
This suggests that the robots aren't just making mistakes; they are making mistakes that only a human reviewer would have caught. When you skip the review, you're letting the robots run wild, and the bill for fixing their mistakes comes due later.
The "Velocity Asymmetry" Problem
The paper argues that we have created a dangerous imbalance, which they call a "generation-review asymmetry."
- Generation (Writing): The robots can write code infinitely fast, unbound by human fatigue.
- Review (Checking): Humans are still the ones checking the work. They get tired, they get busy, and they can only read so fast.
The study suggests that trying to fix this by just "reviewing faster" or "automating the review" isn't the answer. If you let the robots write code faster than humans can check it, you eventually build up a massive backlog of hidden defects. The paper argues that the solution isn't to stretch the review process thinner, but to fix the tools themselves so they produce code that is actually safe and maintainable from the start.
What the Paper Rules Out
It's important to know what this study didn't find, too:
- It did NOT find that robot code is universally "worse" in every way. The overall survival rate (how long code lasts before being changed) is statistically similar to human code. The difference is in the type of changes (more bug fixes, not more feature additions).
- It did NOT find that the problem is random. The maintenance burden isn't just bad luck; it's tied to specific project characteristics, like how much code is merged without review.
- It did NOT prove that robots are "evil" or "useless." It simply measured that they currently introduce more bugs and security holes that require human cleanup.
The Bottom Line
The study concludes that while the robots are impressive at making code, they are currently less reliable at staying code. The "success" of these tools shouldn't be measured by how much code they generate or how many pull requests get merged. Instead, the real test is: Does the code stay secure and stable after it's merged?
The paper suggests that as we rely more on these agents, we need to stop celebrating the speed of generation and start worrying about the cost of the cleanup. The robots are fast, but if they leave a trail of bugs and security holes, the humans who have to clean it up are going to be working overtime. The goal shouldn't be to build a city that looks great on day one; it should be to build a city that doesn't need constant emergency repairs a year later.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.