A merged pull request is not evidence that anyone understood it

No. It used to, more or less, and every tool that answers "who knows this code" still behaves as if it does. When an agent writes the change and a person merges it, the merge proves someone was willing to press the button. Backthread is built on the opposite premise: that a team shipping with agents has to find out separately whether anyone holds the reasoning behind the system, and that git history cannot answer that question any more. This post is the argument for the premise.

The assumption everything rests on

Blame, CODEOWNERS, "ask the person on the commit," the who-would-we-lose calculators, the onboarding doc that says "talk to whoever last touched it." All of it rests on a single inference: the author of a change understood the change. It was never perfectly true. It was true enough, because writing code by hand forces a minimum of comprehension on the writer. You cannot type a function you have no model of.

Agents remove that floor. A person can now open a pull request for a module they have not read, from a session they skimmed, with tests that pass. The version-control record attributes the change to them exactly as before. A June 2026 position paper puts the consequence in one sentence: the attribution "no longer licenses any conclusion about comprehension." Its stronger claim is the one to sit with. Authorship metrics are not degraded by agents. They are "invalidated as a class."

Why "then just review harder" does not fix it

The reflex is to push the comprehension floor from the author onto the reviewer. If the writer did not have to understand it, the approver must. But review checks the diff: is this line correct, is that case handled. The thing that went missing is above the diff: which approach was rejected, what the change assumes about the rest of the system, what it quietly leaves for later. We measured this on our own repository and found that for most agent-written decisions that reasoning never existed to begin with, so no amount of reading the diff would surface it.

A reviewer who approves a change with no recorded why has verified correctness and inherited a blank. That is not a failing of the reviewer. It is what review is for. Asking it to also produce a shared model of the system is asking a line-level tool to do an architecture-level job.

What to stop doing, and what to do instead

Stop treating authorship as a knowledge score. The moment a merged PR counts as understanding, every dashboard built on it reports a team that holds the system while the model quietly narrows to the two people who designed it. That is worse than having no dashboard, because it ends the question.

Do treat authorship as a prior, capped and labelled. Being near an area is worth something. Then look for evidence that comes from work, not from tests: a review comment that names a trade-off, a written why on a PR, an incident diagnosed by someone who did not write the code. That is the method in how to find out who understands each part of the codebase, and it is what Backthread's coverage map does continuously, with the inferred part shown as the estimate it is.

The uncomfortable version of this opinion is that a team can be shipping well, with green CI and fast review, and understand less of its own system every week. Nothing in the tooling will say so, because the tooling is counting merges. Someone has to decide to count something else.

Connect one repo and the per-area picture is there the same day, with the git-inferred part capped and labelled; the trial runs fourteen days.