How to find out who on your team actually understands each part of the codebase

You find out by separating two things git history has always blurred: who touched an area and who holds a model of it. Under coding agents those diverge fast, because an engineer can merge a service they never read. Backthread exists for exactly this: it captures the reasoning behind each merged change from the agent sessions and maps how much of the system the team genuinely understands, per area. But the method below works with a spreadsheet, and you should run it once by hand before you trust any tool's version of the answer, including ours.

Why the old proxy broke

For twenty years the honest shortcut was git log. If someone wrote the billing module, they understood the billing module, give or take a rewrite. Ownership files, CODEOWNERS, "ask whoever's name is on the blame" all rest on that one assumption: authorship implies comprehension.

A position paper from June 2026 puts the break plainly. When an agent generates a module and a human merges it, the version-control record still attributes authorship, "but the attribution no longer licenses any conclusion about comprehension." The author's conclusion is not that authorship metrics got noisier. It is that they were "invalidated as a class."

That matches what we hear from engineering leaders. Nobody says "our git history is wrong." They say "nobody understands the whole thing anymore" and "we're approving PRs we don't really understand." Same fact, felt from the inside.

The method, in five steps

1. Cut the system into areas a person can hold

Not files, not packages. Areas the size of a mental model: checkout, the ingest pipeline, auth and sessions, the notification fan-out. A 40-engineer product usually has 15 to 40 of these. If you cannot name an area in three words, it is two areas.

Write them down in one column. This list is the unit of everything that follows, and it is the first place teams discover they disagree about what the system even is.

2. Record what git can honestly tell you

For each area, three columns from history:

The third row is the one most teams have nothing in. Fill it from wherever the reasoning lives: ADRs, the PR descriptions that say why, agent session summaries if your plugin commits them, the Slack thread everyone remembers. If an area has none of this, write "nothing on record." Do not write zero. Zero is a measurement; blank is the truth.

3. Treat authorship as a prior, capped

Here is the step that changes the answer. Take the git columns as a starting estimate of understanding, and cap it. We cap the inferred picture at 50 percent of the way to "understood," because having been in an area is worth something and is never worth everything. The cap is a judgement call; pick your own, but pick one, and label the result an estimate wherever it is shown.

What this produces is a first picture on day one with nobody asked anything. It is honest about being a guess, and it is already more useful than CODEOWNERS, because it shows the areas where the only signal is a merge button.

4. Refine with evidence from real work, not a quiz

Do not send a questionnaire. We tried the quiz-shaped version of this on five engineering teams and five out of five rejected it before we finished the sentence: it reads as a test, it competes with asking a colleague in Slack, and without a mandate participation dies in about two weeks. One team had built its own who-knows-what matrix. It lasted a fortnight.

What does move the estimate is evidence that arrives inside work people are already doing:

• A review comment that names the trade-off the change makes, rather than the typo it has. That is comprehension leaving a trace.
• A written why on a PR, produced by the person or their agent at the moment of the change. If you want that to exist, make the agent write it at PR-open time; we described one way to do that in a hook that records the reasoning behind agent pull requests.
• An incident post-mortem where the person who diagnosed it was not the person who wrote it.
• A design discussion where an engineer argues about an area they have never committed to.

Each of these is a small, dated upgrade from "was near it" to "holds it," and none of them cost anyone a new action.

5. Read the picture for the three shapes that matter

Once the table exists, look for three patterns:

1. One name per area. A critical area where a single person has any evidence of understanding. This is the resignation risk, and it is usually not where the leader guessed.
2. Merges without models. An area with plenty of authored and approved PRs and nothing in the decision column. Code arriving faster than understanding. This is where the next misunderstood-subsystem incident comes from.
3. Understanding without recent touch. The engineer who designed the area two years ago and has not committed since. Their model is real and decaying. They are also your cheapest teacher for that area.

The response to each is different, which is why the picture has to be per area. Pattern one wants a second person deliberately routed into that area's reviews. Pattern two wants the reasoning captured before the next change, not after the incident. Pattern three wants a recorded walkthrough while the model still exists.

What to do with the picture, and what not to

Use it to route work: who reviews what, who pairs with whom, who gets the walkthrough. Rerun it after any large merge and after anyone leaves.

Do not use it to rank people. The moment the table becomes a performance measure, every incentive on it flips: engineers will claim areas to look good and avoid the honest "nothing on record." The value of the picture is that it is allowed to be unflattering.

If you would rather not maintain the spreadsheet, this is what Backthread's map with knowledge coverage does continuously: the inferred prior from git and PR history, capped and labelled as an estimate, then refined from the reasoning captured in agent sessions and PR discussion. The spreadsheet version is still worth doing once. It tells you whether your team's disagreement is about the answer or about the areas.

Connect one repo and the first per-area picture is there the same day, labelled as the estimate it is; the trial runs fourteen days with everything on.