AI pull request review: code quality and the growth of developers in training.

The problem of confusing pull requests has come up often in conversations with colleagues, on different occasions.

The method I describe comes from there and from my experience as a senior developer and team lead, which has always included training and mentoring junior developers.

I have not yet applied it on a project. To really put it to the test, you need a real team: several developers, tasks of varying complexity, and a period long enough to see a trend. It is part of a harness shared by the team which, as I explain in Quality and coding agents, I have not built yet. What follows is therefore a methodological proposal.

• Ensure the quality of the code that reaches the product.
• Properly support developers in training, and understand whether they are really growing, even when they write code with the help of AI.

The threshold for approving a pull request would be the same for everyone: security, correctness and the project's important rules block approval regardless of who wrote the code. AI would carry out a first review against the team's guidelines; the final word would stay with a person.

Author and reviewer should be kept separate: the session that reviews the code must not be the one that wrote it. A review is only as good as the project's written rules are clear.

What changes is how you get to approval. For a junior developer, comments explain the reason and point to the rule, and minor issues such as naming or style are flagged but do not block; for a senior developer, brief comments are enough. For every blocking issue, the author explains in a few lines what they changed and why; if they disagree with a comment they can challenge it, and a reasoned challenge is a good sign.

Within a single pull request I would set a limit on review rounds: once it is reached, it is better to sit down with a senior developer than to keep iterating.

The risk to avoid is a developer who passes the review without understanding. A controlled study by Anthropic of 52 developers, mostly junior, found lower comprehension scores among those learning a new library with the assistant (50% against 67%), without a significant time saving. Those who used AI to have concepts explained scored similarly to those working without it. The study is small and preliminary, but it shows what to look at: not whether developers use AI, but how they use it.

As pull requests, or months, go by, you expect someone joining a project to reach approval more quickly. At the start it may be normal to need a senior developer alongside: it depends on the project, how complex it is and how well it is documented. If after five or six pull requests the situation is still repeating itself, there is something to understand. The figures are indicative.

The person is not necessarily the problem: the tasks assigned, a poorly documented part of the code or an unclear rule may all play a part.

With several developers being onboarded, it is hard to keep track of each person's path from memory. A review log, with the issues raised, the area of the application and the rounds needed, shows whether the same mistakes come back or disappear, and how long it takes to become autonomous on different kinds of task.

Read by area of the application, the same log says something else too: if several junior developers run into the same problem in the same part of the code, the weak point is probably not them but the harness, that is, the documentation, rules or checks for that part. It is also a way of telling, over time, whether the harness works.

Commercial review tools already collect this data: CodeRabbit's documentation, for example, describes metrics that can be filtered by individual developer. So the question is not whether the data exists, but how it is used.

A confusing pull request often starts from a vague task. Preparing the work before assigning it does two things: the developer knows what to deliver and how to verify it, and the agent works on precise requests instead of exploring the code aimlessly, using less. This matters more and more, because many companies are putting limits on AI spending.

Tools and responsibilities in a team →

The tool does not assess people. It provides technical data on pull requests: issues, rounds, recurring mistakes, defects found after approval and their cause. This data feeds into the growth assessment processes the company already has, where the judgement stays with a person.

Some conditions I consider necessary:

• developers see everything their manager sees about them, and can respond;
• no rankings between people and no overall scores;
• only data on the technical content of pull requests is collected, not working hours or conversations with AI, and the excluded data is written down;
• data is kept for a defined period.

A system that follows individual developers' work over time should be checked with a lawyer before it is introduced. The fact that it does not decide on its own does not remove the obligations: EU AI legislation also classes as high-risk the systems that monitor and evaluate workers' performance. In Italy, the points to check include at least:

• the Workers' Statute (Statuto dei lavoratori, art. 4);
• the GDPR;
• the Italian AI law (Law 132/2025, art. 11), which refers to the obligations to inform workers;
• the AI Act, whose obligations for these systems, after the postponement decided in 2026, apply from 2 December 2027.

This is not legal advice.

The method is a proposal drawn from experience and discussions with colleagues; the sources support individual points, not the method as a whole.

• Anthropic — How AI assistance impacts the formation of coding skills (opens in a new tab): controlled study of 52 developers, January 2026; small sample and preliminary results, measured straight after the task.
• Claude Code — Manage costs effectively (opens in a new tab): vague requests make the agent explore the code and use more; planning and giving verification targets avoid rework.
• CodeRabbit — Dashboard (opens in a new tab): review metrics that can be filtered by individual developer; vendor documentation, for a tool I have not used.
• TechCrunch — The token bill comes due (opens in a new tab): companies that have put limits on AI spending, June 2026.
• Regulation (EU) 2024/1689 (AI Act) (opens in a new tab): Annex III, point 4(b), systems that monitor and evaluate workers' performance.
• Council of the EU — final approval of the AI Act amendments (opens in a new tab): press release of 30 June 2026, new dates for high-risk systems.
• Law no. 132 of 23 September 2025 (in Italian) (opens in a new tab): art. 11, use of artificial intelligence in employment.