When Agentic Coding Breaks Code Review

Two code review failure modes: code review surrender and exploitation

I’ve been working with developers and organizations to improve their code review practices for over 10 years now. In this post, I share two phenomena I see emerging with the increased use of agentic programming: code review surrender and code review exploitation.

Both are related and amplified by the use of GenAI during software development, but the underlying failures are distinct. I am not primarily referring to developers using GenAI for autocomplete or generating small snippets that are easy to fully inspect. The pressure rises as teams delegate more substantial and autonomous work to agents.

Code review surrender is a capacity failure. Reviewers may still believe that code reviews matter, but because of the fast pace and volume with which code now can be generated, they can no longer keep up with meaningfully reviewing the submitted code changes. This causes more code to wait to be reviewed, to be accepted with a superficial review, or even to go through unreviewed.

On the other hand, code review exploitation is a responsibility failure. It occurs when author-side scrutiny and verification is absent or invisible, and reviewers feel they are the first people to seriously understand and validate a change. In this case, the reviewer might feel exploited by their colleagues or the system.

Neither phenomenon is entirely new. Review overload and uneven responsibility existed before GenAI. What GenAI, especially agentic-programming, changes is the speed, volume, and opacity with which these failures can emerge, because of the underlying characteristic of agentic coding: code can now be generated faster than people can meaningfully understand and verify it.

Why these Phenomena Emerge

Generative AI is forcing us to rethink and adapt our code review practices. Not because code review is no longer necessary, but because for decades, code review relied on an asymmetry: producing a meaningful code change usually took longer than reading, understanding, and evaluating it. Because of that, it was a cost-effective technique that allowed developers not only to find defects, improve design and architecture, and prevent accidents, but also to distribute knowledge, mentor and teach, and create shared understanding of how the systems evolved.

With agentic coding practices, that asymmetry is not only disappearing, but can also flip.

A developer can now generate a code change within seconds. In addition, with increased use of GenAI for coding, both the volume of code changes needing review, as well as the size of the changes have increased. Yet, the human effort required to reconstruct a change’s intent and verify its behavior has barely changed. Review still means building a reliable and accurate mental model of the code’s intent, dependencies, and consequences for the wider system.

When that gap becomes unsustainable, reviewers may surrender. And, when author-side scrutiny and verification is absent or invisible, they may experience the work as exploitation.

Data Highlighting the Review Bottleneck

Our code-review capacity is under pressure. More work is entering the review queue, and at the same time changes are becoming larger and harder to reason about.¹

For example, Salesforce reported that code volume increased by approximately 30%, while pull requests regularly expanded beyond 20 files and 1,000 changed lines. Review latency rose quarter over quarter. More concerningly, review time for the largest pull requests plateaued or declined, which Salesforce interpreted as a sign that reviewers could no longer engage meaningfully with every change.

The 2026 Faros AI Engineering Report, which analyzes telemetry from 22,000 developers, describes the downstream effects of increased review volume. Higher AI adoption was associated with more pull requests per developer, larger PRs, increased median review times (up ~440%), and longer average waiting times to first response (up ~157%).

With respect to surrender, the Faros Report also shows that the number of PRs merged without review is up by ~31%. Also, other industry data show the same patterns.²

More pull requests can of course reflect productive work; larger pull requests can sometimes reflect legitimate refactoring or cross-cutting changes. But the overall pattern is difficult to ignore: machine-speed generation is increasing both the amount of work entering review and the cognitive cost of understanding and evaluating the growing code changes. And human reviewers struggle to keep up.

Code Review Surrender

Given this pressure, it is not surprising that code review surrender is a phenomenon that I encounter in my consulting and training work with development teams. It’s present enough that I’ve started investigating this in my ongoing research on code reviews at LESE Lab.

Code review surrender is not the belief that reviews do not matter. It is not a deliberate decision to replace human code review with automation. It is what happens when developers still believe review is important, but when they can no longer meaningfully keep up with the volume, demand, and organizational pressure surrounding them. It is primarily driven by capacity, but the point at which teams reach their breaking point is also influenced by organizational incentives, review norms, and workflow design.

Code review surrender can also happen when capacity pressure flips the perceived cost-benefit equation of code review. It can lead to situations where you are having code changes wait for a review that will never happen, or that happens but cannot be done sufficiently. From the outside, in those situations, the decision to remove review can look rational. The team no longer sees the value proposition. Yet, it is only a strategic move when the team has deliberately and successfully replaced the essential functions of code review: independent verification, accountable sign-off, risk detection, and the creation of shared system understanding amongst team members.

Surrender can happen even in strong, healthy teams and among excellent, caring developers. It is not a moral problem. It is merely a capacity and workflow problem. A good foundations may delay, mitigate, or change the form of the problem, yet does not guarantee that review capacity will scale indefinitely.

Surrender can look different. Reviewers might stop asking for smaller or more coherent pull requests. They might give up trying to understand the deeper architectural implications of a change or accept suboptimal AI solutions. Surrender also shows up in superficial approvals, where reviewers approve changes they have not meaningfully reviewed at all. Developers also might start to even skip the complete code review cycle for some or all changes.

One developer described this reaction bluntly:

Another described the practical exhaustion behind it:

The pressure created by larger and more frequent code changes hits almost every team. This includes teams with high engineering rigor or discipline. Also, they find themselves impacted as they scale up their AI usage and strive for more autonomous agent work.

Surrender also happens when code authors use AI carefully and take responsibility for verifying their work, because as soon as you involve your peers in review in the traditional code review process, they still need time to reconstruct the change’s intent, understand its context, and assess its consequences, even when the code is good.

Code Review Exploitation

Alongside code review surrender, I am seeing growing evidence of another human response to the changing economics of code generation and review: a feeling of exploitation.

Here, we are dealing not only with a capacity problem, but also with a shift of responsibility that lands on the shoulders of an already overburdened reviewer.

Code review exploitation is a feeling that arises between colleagues when AI creates a substantial imbalance in how the work, effort, and responsibility of coding and code review are distributed or perceived. The feeling of exploitation can occur either through actual responsibility transfer or perceived responsibility transfer.

AI allows us to generate plausible-looking code within seconds. Pure code generation is indeed cheap, and almost effortless.

Given the pressure to deliver, the incentives that favor code production over review, and the ease of code generation, situations can arise where reviewers are asked to review code a developer, or now, with AI, also a product manager or another non-technical person, may have created just from a short prompt or a pasted ticket, with limited effort and subsequent evaluation. The code may look polished and plausible, but the reviewer may be the first person to take the time to discover that it is not of high quality or not solving the actual problem. This is a case of actual responsibility transfer. The reviewer not only overtakes the review work, but also work that should already have happened before the pull request.

Using AI, does not automatically lead to exploitation. AI only creates the potential for authors to generate code with little effort. For complex changes, generating code that really solves the right problem with the right approach, fits existing architectural and design patterns, and is maintainable still takes a lot of effort and expertise from the author side. The problem is, that right now, our ways to transparently display whether the author has fulfilled their responsibilities to understand, judge and verify their own change is limited. This makes it hard for reviewers to observe or trust author-side verification. That lack of observability is itself a workflow and tooling problem.

Thus, the feeling of exploitation can arise both when responsibility has actually been shifted onto the reviewer but also when the reviewer has no credible way to establish that the author has done the necessary verification.

I want to highlight that shifting the responsibility to the reviewer does not have to involve any malicious intent. It can also stem from overwhelm on the author’s side. As agents take on more of the implementation, they can produce changes at a pace that even the authors may struggle to fully follow, understand, and verify. This can become even more likely when people with less technical background are able to generate and submit code with AI assistance. Reviewers then inherit an even harder task: assessing changes that might not have been completely clear even to the person submitting them. In that case, they also have to compensate for the author’s lack of understanding and verification.

A variation of this is, when an inexperienced author, creates a substantial review burden. The reviewer might not see that the author tried their best. In that case, the underlying problem is learning and mentoring, which GenAI can aggravate and which calls for new tools and processes.

Finally, environments that heavily incentivize delivering features over the expense of quality control work, contribute to the experience of such feelings. One person can claim productivity, while the other person might need to absorb the hidden cognitive, quality, and maintenance costs.

It is not an accusation that every developer using AI is careless, or that reviewers generally feel exploited. It is a description of a system in which the costs of fast generation can be externalized onto reviewers, open-source maintainers, and eventually on-call engineers.

A 2026 position paper, describes a closely related dynamic. It argues that AI-generated software artifacts are cheap to produce but expensive to evaluate, externalizing costs onto reviewer capacity, codebase integrity, collaborative trust, and the broader software ecosystem.

Exploitation can make surrender more likely because reviewers withdraw from work they experience as unfair or unbounded. So, let’s look at the costs of code review surrender and code review exploitation.

The Hidden Cost of Code Review Surrender

A direct cost of code review surrender is that potentially unfit code changes can enter the system. Even as agents become better at writing and verifying code, they often still produce changes with short-term to mid-term consequences, such as defects and security issues, and long-term consequences, such as unnecessary complexity, code duplication, architectural drift, and code that is hard to maintain. Waving those changes through as good enough during code review can have a rippling effect.

Emerging evidence suggests that lower code health makes agent work less reliable and increases the likelihood of unintended effects, although the precise mechanisms and effect sizes remain an active area of research. This operating mode is therefore not a clear flywheel to success. This creates a credible risk of more production failures and makes safe system evolution harder. It is also consistent with DORA’s finding that higher AI adoption remains associated with lower delivery stability when organisations lack sufficiently strong feedback loops and control systems.

In addition, circumventing code reviews for the sake of having code enter production faster is a bet on code representing value. We have long known that code is often more a liability than a feature, in the sense, that it can impose future maintenance, operational, security, and comprehension obligations. Even though there are only a few studies yet, data points already suggest that this might still be true even in this new agentic era.

Code review does not merely catch mistakes. It is also an important practice that allows teams to build and refresh their shared understanding of the system, its design and architecture, and the context in which it operates. Thus, another direct cost of code review surrender is that teams lose understanding of the systems they are responsible for.

Margaret-Anne Storey describes this loss of shared understanding as cognitive debt: “the accumulated gap between a system’s evolving structure and a team’s shared understanding of how and why that system works and can be changed over time.” When cognitive debt increases, a team’s shared theory of the system, which includes its intent, rationale, structure, and safe paths for change, erodes.

The combination of architectural drift and technical debt from barely reviewed or unreviewed changes, together with accumulating cognitive debt, can make system evolution and maintenance very expensive in the long run. This evolution might not be clearly visible in the present but can haunt teams and organizations for a long time.

The Hidden Cost of Code Review Exploitation

In environments where developers feel exploited through code reviews, the negative impact and hidden costs can have psychological and social consequences.

Feelings of exploitation can limit reviewers’ willingness to engage deeply, lead them to reduce or withdraw from quality-assurance work, and cause deeper problems that affect trust between developers.

Feelings of exploitation may also indicate that the work environments developers find themselves in are not entirely healthy. Environments that heavily favor code production over quality work, measure productivity through activity, and create pressure on engineering teams for showing productivity gains through GenAI are most prone to this phenomenon. Feeling exploited can lead to behaviors that further aggravate the negative dynamics within the team or company.

Unbounded or unfair-feeling verification work weakens trust and willingness to engage. That withdrawal reduces mentoring, careful review, and quality work, which in turn makes code review surrender more likely.

But be aware that exploitation is often a hidden problem that developers do not talk about openly. You might see it in their actions, but seldom on a metrics dashboard that tracks superficial activity and output metrics.

Conclusion

Developers talk and complain about the code review bottleneck and the pressure that agentic software development puts on established review practices. I believe many of these concerns stem from two distinct failures: a capacity failure and a responsibility failure.

As we increase our use of agents or even agentic-loops, code changes are likely to become larger and more frequent. At the same time, businesses are calling for faster delivery and often continue to favor feature output over quality work. Under these conditions, code review can quickly become the bad guy and the easy solution might seem to be to get rid of code reviews.

But code review itself is not the problem. The deeper problem is that code can now be generated faster than people can meaningfully understand and verify it.

Code review surrender is a signal that the team’s review capacity and workflow no longer match its rate of change. Developers can no longer reasonably review the growing volume and size of changes using traditional practices, so they stop, with little to no alternative.

Some of this surrender may be presented as a deliberate strategy. But it is only a strategy if teams have managed to replace code review with practices and mechanisms that ensure code and system quality and build an ongoing shared understanding of the system among team members. Simply removing review because the queue has become unmanageable is not transformation. It is surrender.

This does not mean that code reviews must remain exactly as they are today. In fact, with all changes see, we have to conclude code reviews must change and evolve to ensure we can keep up.

But giving up on understanding and verification is not the answer, and neither is expecting human reviewers to operate at machine speed. The goal is to redesign where understanding, verification, and accountability happen, and to make author-side responsibility visible before work reaches a peer reviewer. Visibility cannot be satisfied by an agent-written summary or a checked box; it must give reviewers decision-relevant evidence of what the author understood, chose, and verified.

In my next post, I will explore which transformed code review practices are already emerging and beginning to prove valuable, for an increasingly agentic way of working.

Never miss a post! Subscribe to my newsletter!

Footnotes:

1: The figures in this section come primarily from platform, company, or vendor telemetry. They identify patterns in large real-world datasets. Their commercial incentives, customer samples, and measurement choices should therefore be kept in mind.

2: Span found that developers using AI shipped around 67% more pull requests per week on average, and that AI-assisted pull requests were roughly twice as large as their predominantly human-written counterparts. GitHub reported a 20,4% increase in pull requests created in 2025, and a growing number of those PRs are now created by coding agents, significantly increasing the demand for review.

Acknowledgements

I thank Laura Tacho, Margaret-Anne Storey, Leif Singer, and Robert Göritzer for reading this article and providing valuable feedback.

Updated on July 7th, 2026