Code Review Surrender & Exploitation

This is a draft. If you read it, and want to give me feedback, I’d be more than happy. Please send it to michaela @ michaelagreiler.com

I’ve been working with developers and organizations to improve their code review practices for over 10 years now. In this post, I want to share two phenomena that I see currently emerging because of the use of GenAI: 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.

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 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. The reason is not that human code review has become obsolete or unnecessary, but that AI has dramatically lowered the cost of producing code without reducing the human effort required to reconstruct its intent and verify its behavior.

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 has not only disappeared, but has also flipped.

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 time it takes a human to review a change 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 humans 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, as well as 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.

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.

Surrender can look different. On an individual level, 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. This could then lead to superficial approval, where they might approve changes they have not meaningfully reviewed at all. On a team level, developers might start to even skip the complete code review cycle for some or all changes.

One developer described this reaction bluntly:

“Since I can’t stop caring, I simply removed myself. Let those teams do whatever they want.”

Developer in public Reddit discussion

Another described the practical exhaustion behind it:

“I’m not going to spend half an hour interrogating you, or looking at a giant diff, just to know what the PR is about.”

Developer in public Reddit discussion

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. Yet, generating code that really solves the right problem with the right approach, fits existing architectural and design patterns, and is maintainable still takes effort and expertise. For complex changes, responsible steering of agents takes time, and integration, testing, and verification may consume as much or more expertise than initial implementation.

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 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 read the code carefully enough to discover that it is not of high quality or not solving the actual problem. This is a case of actual responsibility transfer.

Using AI, does not automatically lead to exploitation. Yet, AI creates the potential for authors to generate code with little effort, and also does not transparently display the actual effort spend during generation. This makes it hard for reviewers to observe or trust author-side verification. That lack of observability is itself a workflow 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.

A feeling of exploitation can also arise when an inexperienced author, who lacks the skills to use GenAI responsibly, creates a substantial review burden. The reviewer might perceive the author as reckless, and can not see that they tried their best, but struggled. 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 contribute to the experience of such feelings.

The result is that the reviewer perceives an unfair transfer of responsibility. One person can claim productivity, while the other person might need to absorb the hidden cognitive, quality, and maintenance costs.

The difficulty is that reviewers often cannot tell, at the beginning of a review, which case they are dealing with. Are they reviewing code that was carefully developed and evaluated, or code produced through only lightly supervised generation? In both cases, the reviewer must invest substantial effort to understand and evaluate the code. Yet, when they realize they are the only person actually spending effort on this code change, a feeling of exploitation can emerge.

It is not an accusation that every developer using AI is careless. It is a description of a system in which the costs of fast generation are 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.

The Hidden Cost of Code Review Surrender

A direct cost of code review surrender is that unfit code changes enter the system without enough human oversight and verification. 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 a liability, 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 refresh their shared understanding of intent, structure, trade-offs, and safe paths for change. 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 be even more dramatic. Unlike code surrender, which is primarily a capacity problem, code review exploitation also has 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 with GenAI are most prone to this phenomenon. Feeling exploited can lead to behaviors that further aggravate the negative dynamics within the team or company. 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 practice we have to get rid of.

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.

Under this pressure, individual developers and teams may surrender. They can no longer reasonably review the growing volume and size of changes using traditional practices, so they stop, with little to now 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, they 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. In my next post, I will explore which transformed code review practices are already emerging and beginning to prove valuable, in 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 29% increase in pull requests in 2025, and a growing number of those PRs are now created by coding agents, significantly increasing the demand for review.