The second kind of review fatigue
Review fatigue has two shapes, and they are usually treated as one. The first is volume: there is more diff than there is reviewer, and the response is to help the reviewer read less. That is real relief, and it is not the one this post is about.
The second shape is quieter. It is not how much you have to read; it is how much you have to already know before you can judge any of it safely. Take a reviewer who is fresh, unhurried, and reading a diff that has been perfectly triaged down to the twelve lines that matter. Often they still cannot approve it safely, not because the diff is long or unclear, but because nothing in it answers the question that actually decides the review: is this a good idea here, given what we already decided?
Two things that both get called review fatigue
The first kind is volume, and it is well understood. There is more diff than there is reviewer, so relief means cutting how much you have to read: ranking by risk, surfacing the twelve lines that matter out of four hundred, filtering the mechanical churn out of the way. People are working on it.
The second kind is not solved by reading less. It is the amount you have to already know before you can judge what you are reading, and no amount of triage supplies it.
The question a diff cannot answer
A diff is very good at showing what changed. Read carefully, it will tell you what the code will do after the change lands. That is a real question, and it is mostly the one tooling has addressed.
It is not the question that decides whether the change should be approved. That one has no access to what was already decided, and the diff cannot supply it.
So the things that get missed in review are not usually the subtle bugs. They are the changes that read perfectly:
- A change that quietly reverses a decision someone made deliberately, for a reason that still holds, which nobody in the thread remembers.
- A refactor that re-introduces a pattern an earlier commit explicitly removed, cleanly and with tests.
- A constant that looks arbitrary and gets "tidied", because the incident that set it is two years and one team reorganisation ago.
Every one of these is invisible to a reviewer who lacks the history, and every one of them is invisible no matter how small you make the diff. Rank the change by risk and you hand the reviewer a shorter diff they still have no history for. The volume problem and the knowledge problem are genuinely separate, and only one of them is fixed by reading less.
The reviewer who catches these is the one who happens to have been there. That is not a review process. It is institutional memory in a single person's head.
Why the context is missing in the first place
It is tempting to file this under discipline: people should write down their reasoning, and reviewers should read up before approving. We argued in the authoring tax that this quietly fails, because the record is owed by exactly the person for whom it feels redundant, at the moment they have least room to produce it.
Review is where that failure gets its bill. When nobody writes the record, the cost does not vanish; it moves. It lands on a second person, later, with less context than the author had and less time, being asked to make a judgement the author could have made instantly.
And it lands unevenly, in the worst possible pattern. The decisions least likely to have been written down are the ones made under pressure, and those are the same decisions most likely to be quietly overturned later, because the pressure that produced them is exactly what stopped anyone recording why. So the reviewer's context is thinnest precisely where the stakes are highest. Not by accident: by the same mechanism.
The knowledge thins as the volume grows
The two problems do not merely sit side by side; they pull in opposite directions. Agents produce more change, so more of it arrives at review. They also do more of the work that used to teach the reviewer what they now need to know. The engineer who once hit an API call that did not match the schema, went and found the doc, and understood why the constraint was there increasingly does not: that exchange happens inside the agent's session and is settled before the change reaches a human. The reviewer inherits the corrected code without ever acquiring the context that used to come free with the work. The stock of already-known things is drawn down exactly as the volume to judge goes up.
What actually changes the second kind
If the reasoning has to be authored by hand, it will be missing where it matters most. If it is captured from the work itself, it exists without anyone having chosen to spend the time, including for the change made at 6pm under a deadline. The reviewer's hard question then has a recorded answer, tied to the commits that enacted it, rather than one that depends on who was in the room.
This is the relief we think is underrated. Not cutting how much a reviewer has to read. Cutting how much a reviewer has to already know.
The measurement behind the feeling
The sense that pull requests are bigger than they were, and that there are more of them, now has measurement behind it, though it comes from an interested party. In July 2025, Faros AI, which sells engineering-intelligence tooling, analysed 1,255 teams across a set of large software organisations, comparing each team's two quarters of lowest AI adoption against its two quarters of highest. Between those two points, average pull request size was 154% larger, and pull request review time rose by roughly 91%. Their reading of it: AI-generated code "may be more verbose and less incremental, making it harder to review", and human review "remains a bottleneck".
Two honest caveats: These are correlations, not demonstrated cause. The study reports Spearman coefficients, and they are weak (ρ = 0.07 for pull request size, ρ = 0.08 for review time) even where the percentage changes are large. And the quality picture in the same report is genuinely mixed rather than uniformly bad. AI usage there also correlated with fewer code smells and higher test coverage. The direction worth taking from it is narrow: more code is arriving at review, in larger units, and the reading of it is still done by a person.
What we are not claiming
inkentry does not review your pull requests. There is no review surface, no diff-scoped retrieval, no risk ranking, and this post is not a trailer for one. What inkentry does is narrower: it captures why a change was made, from the work rather than from a form, and keeps it anchored to the code so it can be asked for later, by a person or by whatever agent that person is using.
The claim here is an argument, not a feature. Review fatigue is treated almost entirely as a volume problem, and volume is only half of it. The other half is that we ask reviewers to make decisions that require knowing things the codebase never recorded, and then we are surprised when the change that undoes last year's careful call sails through with an approving comment.
git tracks what changed. inkentry remembers why.
inkentry is open source and code-aware, built to be called from whatever agent you already use. Repo and docs: inkentry.com.