Most of the changes a coding agent proposes in public GitHub projects are reviewed by nobody, and when someone does review them, it is usually another agent. If something similar is happening in your team, your metrics dashboard probably won't tell the difference: an approval counts the same whether a person or a bot gave it.
Three papers with data on how agent-written code gets reviewed have come out this year, along with one that proposes to stop reviewing it. Read together, they leave your team with a question that comes before how much to review: what does a person actually read today before a change goes in.
A pull request is the request to merge a change into the team's shared code, and review is the moment when another person reads it and decides whether it goes in. When an agent opens several a day, that is the first point to come under strain: a study with data from 718 firms already found that the gain from agents ends up waiting in code review. This year's papers look at what happens when that wait is resolved by approving.
What GitHub shows
Kacper Duma and his colleagues at Nicolaus Copernicus University in Toruń (Poland) compared how AI-generated pull requests and pull requests written by people are reviewed in the same repositories, using the public AIDev dataset. Their conclusion, in a paper accepted at the EASE 2026 conference: most agent pull requests receive no review at all and, when they do, the review comes mostly from other agents. Human involvement, when there is any, usually takes the form of instructions to the agent to fix something.
The authors warn that this makes it harder to read review metrics as evidence of human oversight in large-scale studies. For a team, the same holds at a smaller scale: the share of changes reviewed before merging can sit at 100% without any person having read the agent's code.
Shyam Agarwal, Courtney Miller, Christian Kästner and Bogdan Vasilescu start from a similar analysis of public GitHub activity: agent pull requests are reviewed less often and merged several times faster than those written by people. And they immediately warn that the direction of those trends flips under other, equally defensible analysis choices. That is why they don't stop at the traces, which in their words show what is changing without explaining why: they gather 38,709 practitioner texts (engineering blogs and Reddit threads) and code a sample of 3,100 about code review. Their conclusion is that review is the control point where the agent's effect on the software is decided, and that the team sets that effect through its expertise and the way it organises review.
Heavier users approve more and also interrupt more
The third data point comes from real use of Claude Code, Anthropic's coding agent. Its Societal Impacts team published in February how oversight changes with experience, based on sessions from late 2025 and early 2026:
The more someone uses it, the less they grant permission for each action and the more often they stop the agent when something doesn't add up. Anthropic puts it this way: effective oversight doesn't require approving every action, it requires being in a position to intervene when it matters. These figures measure actions within a working session and the GitHub ones measure pull requests, but in both cases step-by-step permission stops being the usual way to oversee the agent.
The paper that proposes to stop reviewing
Martin Monperrus goes further in a position paper published in June. In his view, coding agents "have crossed a threshold of capability" and can meet every stated goal of code review at lower cost and higher throughput. He calls the setup of agents that write and humans who must review "a dead end", because it gives no real assurance and cannot keep pace with AI-accelerated development.
In practical terms he is partly right. A person does not carefully read ten agent diffs a day (the diff is the list of lines that change), and the GitHub data says that many projects have already stopped trying without deciding to. For a company team, his conclusion leaves another question open: who answers for what reaches production. Someone has to have decided which changes go in without a person reading them and why, and that decision has to be written where the team can see it.
Where I disagree is the early stages. Human review is still essential while the harness (everything that guides the model: subagents, skills, templates and checks) and the context are being built. That is where a person helps adjust and improve them.
It is also essential at the start of each feature, when it is defined, so that no open question is left unanswered. That is what people now call grilling.
Limit The two GitHub studies cover open-source projects (a company team has its own review rules), and their abstracts give no percentages, so no figures from them are quoted here. Agarwal and his co-authors warn that the trends they observe are not stable. Monperrus's paper is a position paper, without data of its own. The Claude Code data comes from a single product and its maker; Anthropic notes that the product asks for manual approval by default, so part of the increase may come from users changing their settings, and that the oversight labels were assigned by a model.
What to measure before deciding how much to review
Before arguing about whether your team reviews too much or too little, it helps to know what is happening now. One month of data from your repository answers three questions:
- Of the agent's merged pull requests, how many have an approval or a comment from a person? Those from bots and other agents don't count.
- How long do they take to merge, compared with those written by people? A 400-line change approved in two minutes has hardly been read.
- How many had to be reverted or fixed in the following weeks?
With those numbers, the team can set aside the debate between "review everything" and "review is no longer needed" and decide which changes a person always reads and which can go in without anyone reading them. How to split review by the risk of each change is something we covered when reading the Technology Radar 35.
What you want to avoid is letting the agent's pace write that rule. If nobody decides what gets read, the team ends up approving almost everything anyway, without knowing what it let through or who decided.
This is part of the work in AI-Accelerated Development. We build two things with your team that stay with you: the context the AI works in, and the process you work with, from idea to up-to-date documentation. If you want to look with someone from outside at what your team reviews today, the diagnostic is free.
Frequently asked questions
Do you need to review the code a coding agent writes?
Yes, but each team has to decide how deeply and which changes a person always reads. The 2026 studies on GitHub show that many agent pull requests are merged without human review, so the decision is already being made, even if nobody has written it down.
What do the studies say about how agent pull requests are reviewed?
A study accepted at EASE 2026 concludes that most AI-generated pull requests on GitHub receive no review and that, when they do, the review comes mostly from other agents. Another 2026 paper finds they are reviewed less and merged several times faster, with the warning that this trend reverses under other analysis choices.
Why can review metrics mislead when agents are involved?
Because an approval or a comment counts the same whether a person or an agent made it. The authors of the EASE 2026 study warn that this makes it harder to read review metrics as evidence of human oversight. In a team, the way to find out is to count how many of the agent's changes have an approval or a comment from a person.
What is auto-approve in a coding agent?
It means letting the agent carry out its actions without asking for permission at each step. According to Anthropic, in Claude Code it is switched on in roughly 20% of the sessions of people with fewer than 50 sessions and in over 40% from 750 sessions on, and more experienced users also interrupt the agent more often.
Is human code review coming to an end?
Martin Monperrus argues so in a June 2026 position paper: in his view, agents already meet the goals of code review, and requiring a person to review everything gives no real assurance and does not scale. A company team still needs someone accountable for which changes go in unread.
What can a team measure to know what it really reviews?
With one month of data from its repository: how many merged agent pull requests have an approval or a comment from a person, how long they take to merge compared with those written by people, and how many had to be reverted or fixed in the following weeks.
Sources
- Kacper Duma, Patryk Wróblewski, Jagoda Bobińska, Julia Winiarska and Piotr Przymus, "These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests", arXiv:2605.02273, 4 May 2026 (accepted at EASE 2026).
- Shyam Agarwal, Courtney Miller, Christian Kästner and Bogdan Vasilescu, "3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse", arXiv:2607.07980, 8 July 2026.
- Miles McCain et al. (Anthropic, Societal Impacts), "Measuring AI agent autonomy in practice", 18 February 2026.
- Martin Monperrus, "The End of Code Review: Coding Agents Supersede Human Inspection", arXiv:2606.13175, 11 June 2026.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →