Contents
Unless you work in the perfect AI-driven environment where all the engineers share a common, well-defined agentic workflow, some of you might work in teams with uneven exposure, fluency and attitude towards agentic workflows. There are teams with developers who deliver features using agents end to end or developers who still find it quite difficult to let the agent run on its own.
However we produce the code, the sure thing is that there are still developers that need to read part or all of the code so they can review it. But even if nobody is reading the code, we need to make sure that we hand over the right information to the agent whose responsibility is to review it. That agent needs to know all the decisions made along the way, from the refinement of a ticket until its execution. This article is specifically for this. For the handover of code that is produced by an implementation agent to a developer or an agent or both who are going to review it.
Something changed in how I review
I was always the kind of developer who enjoyed reviewing code. I could spend 2–3 hours, or in some cases even more, in a PR review making sure I have understood my colleagues’ decisions, the business logic, trying to catch edge cases and bad architecture decisions. I was also spending a lot of time writing nice comments that I had verified against the code. Recently I started noticing a shift in this dynamic. I realized that I started putting less effort in the review process and that I was approving PRs more easily. I understood soon that this shift had two reasons. One was the increase in the incoming PRs. The other was a feeling of demotivation to review something that an agent had most likely reviewed already, before the PR or in the PR, and that was not written by a human being.
I started researching this topic more and the confirmation of this uneasy feeling of reviewing AI-generated code came from a paper which shows that there can be indeed a gradual drop in active inspection effort of PRs. In their recent paper (Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code) the researchers studied 400 repeat reviewers who submitted 11,429 reviews over a seven-month observation period. Their goal was to understand if human reviewers gradually lower their scrutiny for AI-generated code over time. What they found out is that:
- The reviewers started approving PRs more easily. The approval rates went up.
- There was a 22% decline in review comments.
- Reviewers approved more but approving took longer.
The way these results are explained is that over time, the reviewers had an increased workload (more PRs generated by agents) and approving was a way to avoid them being the bottleneck. They also developed a reflexive habituation due to accumulated positive experience and confidence from AI-generated PRs leading them to less scrutiny for AI-generated code over time.
The calibration we lost
In the past the review effort and the number of PRs coming to our plate used to be mostly balanced due to the fact that code was taking more time to be written. Also code decisions were discussed more between colleagues before even the PR was opened. This accidental calibration of the flow of PRs and reviews gave the necessary space to the developers to keep pace with the code reviews.
The aforementioned research is also supported by The AI Engineering Report 2026. What this research also points out is that more PRs were merged without any review due to the increased review workload (most often of the most experienced engineers in the team).
Pull requests merged without any review, human or agentic, are up 31.3%. We do not believe this reflects a deliberate decision to bypass oversight. The more likely explanation is that reviewers cannot keep pace with the volume of AI-generated code arriving for their attention
AI-generated code […] is often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase. The structural and logical failures, when they exist, are beneath the surface. […] That is slow, expensive cognitive work, and the data reflects it. Median time in review is up 441.5%.
From reviewing lines to reviewing decisions
So, the question now is how we can deal with this new reality. The pull request model we used to follow for years where a developer creates a PR and a colleague thoroughly reviews every line trying to catch bugs and bad practices has already reached an end. Our role in the review process as we knew it until today has already weakened to the point where it is difficult to defend on technical grounds. The agents can already review code much faster and much better than us. We cannot and we should not try to keep pace with PR reviews. What stays with us then? What is our new role? It’s mainly the evaluation of the decisions that were made by an agent or a human and an agent during the development process. These decisions can be technical architecture decisions or business logic decisions with long-term consequences in a project. Reviewing the decision log should be our priority and where we need to put our effort nowadays.
How the RPAC pattern can help us in this new role
In the agent-toolkit project we have created a set of skills and rules which assist our daily development workflow. Part of this project is the RPAC (Refine, Plan, Act, Consolidate) pattern. The RPAC is a workflow where a task is split into 4 different and independent phases. Each phase produces a result that can be reviewed and improved before going to the next phase. Each phase can be picked up by a new session with a fresh context.
The handover skill
In the Consolidate phase of the RPAC workflow we recently added a new skill called handover. There are three main reasons that motivated us to introduce this skill:
- In case a human reviews our PR, we need to respect the time and effort they put into reviewing our code even if it took just some thousands of tokens and a few hours for us to produce it.
- To support the developer in their new reviewing role. To avoid losing the decision log of the changes in a bunch of markdown files produced by agents during the development of a feature.
- To avoid lower levels of review effort (and thus lower levels of understanding of the changes by our colleagues) and beginning to approve PRs reflexively.
This handover skill should be called as the last step in our workflow, before we open a PR. It gathers what it needs from the sources we already have. If we follow the RPAC workflow, there is a REQUIREMENTS.md file and a PLAN.md file, and it reads both, plus the tickets one hop away when a decision depends on them. Then it matches the plan against the diff in both directions. Steps that were planned and never landed. Code that landed and was never planned. Acceptance criteria that we missed. Context from the session and the diff against the target branch.
The part I care about the most is that it never invents a why. It states a reason only where a source actually gives one. If a deviation has nothing behind it, it asks us once, and if we cannot answer, the line ships flagged, something like “nothing records why, worth confirming”. The reviewer sees the gap instead of a confident sentence nobody can verify.
The result is a file in the planning directory of the task, under 400 words, ready to be pasted in our PR description. It mentions only things the reviewer can open. No links to plans, no session, no commit hashes, because the reviewer has none of them. It includes the following sections:
- What and why — 2 to 3 lines.
- Decisions worth knowing — at most 5 lines, each: what was chosen or what departs from the plan, its why or the missing-why flag, and where in the code to see it.
- Review guide — the few files where judgment matters and why, and the rest named as mechanical.
- Known gaps — at most 3: shortcomings, assumptions, open questions.
Conclusion
Judging by the relevant research but also by our everyday experience, the volume of PRs is just growing. We can produce code faster than anyone can read it. The fair thing is to make that code cheap to review as well. Not by writing less of it, but by handing over the part that is expensive to reconstruct: what we decided, why we decided it, and what we are still unsure about. The reasoning already exists somewhere, in a REQUIREMENTS file, in a PLAN, in a session nobody will open again. Throwing it away and asking someone else to rebuild it from the diff is the expensive way to work.
That is also the part where our judgment still matters. An agent will find the bugs faster than us. But it will not tell our colleague whether this was the right thing to build in the first place.
The end of code review, as we once thought the absolute best practice of modern software engineering, is the beginning of a more productive way to build software.
References: 1: https://arxiv.org/html/2606.13175v1 2: https://arxiv.org/html/2606.22721v1 3: https://addyosmani.com/blog/agentic-code-review/ 4: https://www.faros.ai/blog/software-engineering-glossary#code-review