Your mental model of the codebase is one week old

The half life of what you know about your own codebase used to be measured in months. It is now measured in weeks. That was the argument in the Coldtea essay behind PR Lens, and the numbers published since have not been kind to the habit of keeping up by reading. LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, found that AI-generated pull requests wait 4.6 times longer for someone to pick them up: over 16 hours, against about 200 minutes for the rest. The code lands anyway. The reading does not.

What a mental model of a codebase actually is

It is the answer you can give without opening the editor. Where does a signup request go. Which service owns the email. What breaks if the queue backs up. Who calls the thing you are about to change.

You built that model by reading pull requests, one at a time, over months. Review was where it happened, which is why review always cost more than the defects it caught could justify. In the Coldtea essay I listed four reasons we read a pull request: to develop the mental model, to judge whether the design fits, to judge complexity, and to check everything else. Three of those four have automated answers now. Linters judge consistency. Type checkers and test suites judge correctness. A finder like Greptile or Bugbot, as both do in September 2026, reports the null dereference on line 214 before a human opens the tab.

The first one has no automated answer. A tool can tell you the change is correct. It cannot tell your team that the system is now shaped differently than it was on Friday.

Why the shelf life dropped from three months to one week

Before agents, knowing the state of the software three months ago was stale knowledge. That was the boundary. Come back from a quarter of parental leave and you would need a day to catch up. Come back from two weeks and you were fine.

The boundary moved because the write rate moved. Microsoft's study of its early-2026 rollout of Claude Code and GitHub Copilot CLI, published as arXiv 2607.01418, found that adopters merged roughly 24 percent more pull requests. Faros AI reports feature-branch throughput up 59 percent year on year under high AI adoption. Meanwhile the reviewing side did not grow at all, because the reviewing side is people.

I want to be honest about the figure. The one-week number is my judgement from watching our own repositories, not a measured constant, and it will be different for a two-person project than for a monorepo with six agents in it. Treat it as an order of magnitude.

Reading every diff does not scale, and it never did

The thing that hides the problem is that review still looks like it is happening. A pull request opens, a green check appears, someone approves it. The paper "These Aren't the Reviews You're Looking For" (arXiv 2605.02273) went looking at 33,596 agent-authored pull requests and found that 61.38 percent received no recorded human review at all. Of the review comments that did exist on agent pull requests, 71.58 percent were written by other agents.

So the model is not being built. Nobody decided to stop building it. The volume simply outran the reading, and reading is the only mechanism most teams have.

Faros AI puts a number on the same slippage from the other direction: under high AI adoption, the share of pull requests that skip review outright rose 31.3 percent.

What review is for when the machine can do the rest

This is the reframe that made PR Lens worth building. If three of the four reasons to read a diff have automated answers, the human's remaining job is the one with no shortcut: knowing what the system looks like now.

You can do that job from structure alone: which component is new, which existing one now calls it, what used to handle this and no longer does. A diff is a poor carrier for structure, because a diff is a list of line edits sorted by file path, and structure only emerges once you have held all of them in your head at the same time.

That render is a five-component change. You read it in about two seconds and you now know something durable: signup publishes an event, a worker drains it, the inline mailer is gone. Next month, when someone asks why the welcome email is late, you already know where to look. The diff for the same change runs across five files, and reading all of them leaves you with the same three facts and a headache.

A baseline is a mental model you do not have to hold

The reason a diagram of a diff is not enough on its own is that a diff has no memory. It knows what changed. It does not know what the changed thing sits next to.

The hosted PR Lens App keeps a baseline of the repository and tracks it across commits, so each pull request is drawn against the system rather than against nothing. That is why the untouched parts stay on the page. When you look at the hero render at the top of this post, the broadcast composer on the left was not modified by the pull request. It is on the page because a reviewer needs to know what the new batch path plugged into.

This is also the answer to the returning-from-leave problem. You do not need to have watched every change to read one diagram of the current system, because the diagram carries the context that your absence removed. It is the difference between a changelog and a map. A changelog assumes you already know where everything is.

What this looks like in practice

My habits changed in a few small ways, none of them heroic.

I look at the picture before the diff, every time. If the shape matches what I expected the change to do, the diff is a verification pass rather than an investigation. If the shape surprises me, I now know exactly which files to open, and I open four of them instead of twelve.

I treat a surprising diagram as a design conversation rather than a review comment. A new node in a lane where nothing should have been added is worth a five-minute call. Nobody has that call about an indentation nit.

I stopped feeling guilty about not reading everything. Reading everything was never the goal. Knowing the system was the goal, and reading everything was the only route we had to it. The route changed.

Where to go from here

If your team is currently trying to solve this with more discipline, more reviewers, or a rule that pull requests must be under 200 lines, read the pillar guide on reviewing AI-generated pull requests first, because the method matters more than the tool. For why the reading itself is expensive in the first place, cognitive load in code review covers the working-memory side. And for the specific case of walking into unfamiliar code, which is what a stale mental model turns every review into, there is how to review a pull request you didn't write.

The uncomfortable version of all this: your team's shared understanding of the codebase is now a thing you have to maintain deliberately, the way you maintain a test suite. It used to maintain itself as a side effect of review. It does not any more.