When review becomes the job

What the paper argues

Review fatigue is not a capacity problem. It is a pattern problem. The job of review has changed shape, and the line-by-line technique most senior software developers were trained on is the wrong instrument for the new shape. Line-by-line review assumed code written by a colleague whose intent could be inferred from the diff, in a change small enough to hold in working memory, with a turnaround fast enough that context did not need to be rebuilt. None of those assumptions hold reliably any more.

Solving fatigue requires redesign at two levels: how the individual reviewer engages, and how the organisation structures review across pipelines. Both have to change for either to hold.

Key points

• The bottleneck moved. In Faros AI’s 2025 telemetry, teams with high AI adoption merged 98% more pull requests, PR size grew by 154% and time spent in review grew by 91%, while organisational DORA delivery metrics stayed flat.
• The obvious fixes treat fatigue as a quantity problem. Reviewing less, hiring more reviewers, trusting a second agent’s review and automating the review tooling each leave the underlying pattern unchanged.
• Four questions come before the diff: did the agent stay in scope, does the change hang together as a coherent move, what did it have access to that it didn’t need, and where would I look first if this broke in production.
• Three techniques reduce per-PR cost: group reviews by intent rather than chronology, read the agent’s claim before the code, and ration depth, so that every reviewer can give one sentence of justification for the depth they applied.
• Five organisational moves follow: move review earlier to design and task definition, tighten the agent’s blast radius, split review by aspect, make provenance routine and reform the metrics. Provenance is the single highest-leverage investment, because with it review becomes triage rather than forensic work.
• PRs reviewed per week is the metric that creates fatigue faster than anything else. Reviewers should be measured on substance: incidents prevented, architectural questions raised before merge, non-trivial change requests and the recovery time of the systems they own.