Get an overview of who knows what in your codebase

A codebase knowledge map shows, per area, which people hold a working model of which parts of the system. Every commercial version is computed from commit authorship, which stopped meaning much once agents started writing the code. Backthread draws it differently: it captures the reasoning behind each merged change from agent sessions and pull-request discussion, infers a capped estimate of understanding per area from git, then lets the team earn the rest by explaining decisions.

What is a codebase knowledge map, and what do the existing ones measure?

The category is older than the name. Since about 2015 the standard answer to "who knows this part of the system" has been a treemap coloured by author, with a risk score for areas that only one person has touched. Every tool that ships one derives it from the same place: the version-control log.

The wording differs; the input does not.

Read down the second column. Lines contributed, commits made, files created, files edited most, commit activity. Every row is a way of asking git who was here, and then relabelling the answer as who understands this.

That relabelling was reasonable for twenty years, because typing a module by hand forces a minimum of comprehension on the person typing. CodeScene's own documentation states the assumption out loud when it explains why an original author keeps a score after their code is replaced: "Even if one developer completely rewrites a piece of code, its original author will still retain some knowledge in that area since they're familiar with the problem domain." True, when a developer wrote the code. It is the premise that is now in question, not the arithmetic.

Why does authorship stop working once agents write the code?

Because the person on the commit did not necessarily read it.

On a team that ships with Claude Code, Cursor or Codex, the typical merged change was drafted by an agent, skimmed by an engineer, approved by a second engineer under time pressure, and merged. Git records the first engineer as the author. Every tool in the table above will now count that module towards that engineer's knowledge, and if they are the only name on it, flag the area as a knowledge island with them as its owner.

A June 2026 position paper by Brett Wheeler makes the general point: once an agent generates a module and a human merges it, the attribution "no longer licenses any conclusion about comprehension," and authorship-based knowledge metrics are "invalidated as a class." Not degraded, not noisier. The signal they were reading has been disconnected from the thing they were reporting.

Two consequences follow for anyone looking at one of these maps today:

1. The map is optimistic in exactly the wrong places. The areas with the most agent-written code are the areas with the most commits, so they render as well-covered. They are also the areas most likely to have been merged without anyone holding a model of them.
2. The one-name areas are no longer where the risk is. An engineer who committed 80 percent of a service may know it well, or may have prompted it into existence over an afternoon. The map cannot tell those two apart, and the difference is the whole question.

The measurement problem is not that the tools are bad at counting. It is that on an agent-heavy team there is no longer anything in git that counting can recover. We wrote out the full argument in a merged pull request is not evidence of understanding.

What would a map of understanding look like instead?

Start with the two things a leader wants from the picture: which areas does nobody hold, and which areas does exactly one person hold. Both are answered per area, not per file, and both need evidence that a person can explain the area, not evidence that they were near it.

The map Backthread renders works in three layers.

The system, cut into areas a person can hold

The map is built from the code itself: modules grouped into subsystems, connected by the edges that exist in the source. That much is shared with any architecture diagram. The difference is what the colouring means. It is not code health, not churn and not author. It is knowledge coverage: how much of each area the team can account for.

A first estimate, from git, capped at 50 percent

On day one nobody has explained anything, and a blank map teaches nothing. So the first picture is inferred from exactly the history the other tools use: who authored and reviewed the pull requests in each area. It is treated as what it is, a prior, and it is capped at 50 percent and labelled an estimate wherever it is shown. Having touched an area is worth something. It is never worth more than half.

An area with no pull requests and no captured reasoning reads "nothing on record here." Not 0 percent. Zero is a measurement of something; a blank is an honest statement that nothing has been measured.

Coverage earned above the cap, from the recorded reasoning

Above the estimate, coverage comes from the reasoning captured behind each merged change: the decision, the alternatives that were weighed, the trade-offs accepted, the assumptions made. Those are captured from the agent session and the pull-request discussion, held until the work merges, and taught back inside the coding agent while the engineer is working in that area. Coverage rises when a person can account for the decisions in an area, and that is the only thing that moves it past 50 percent.

The map, read this way, distinguishes the two cases a git-derived map collapses: the engineer who wrote a service and can explain its decisions, and the engineer who merged a service their agent wrote. The second shows up as touched, estimated, and not held. That row is where a leader should be looking.

How to read the map once you have it

Three shapes matter, and they call for different responses.

• Estimate only, nothing earned. Lots of merged pull requests, no reasoning on record, coverage sitting at the cap. Code arrived faster than understanding. Route the next change in that area through someone who will read it, and capture the why before the change rather than after the incident.
• One name above the cap. A single person can account for the area. This is the resignation risk, and on an agent-heavy team it is usually not where the authorship map said it was. The full playbook for that case is in keep the knowledge when an engineer leaves.
• Held, but not recently touched. The person who designed the area two years ago and has not committed since. Their model is real and decaying, and they are the cheapest teacher you have for it.

Use the map to route reviews and pairing, and to decide who should be walked through what. Do not use it to rank people. The moment a coverage number becomes a performance number, engineers claim areas to look good and the honest "nothing on record" disappears. The map's value depends on being allowed to be unflattering.

If you would rather first build the picture by hand, the spreadsheet version is in how to find out who on your team actually understands each part of the codebase. It is worth doing once, mostly because it reveals whether your team agrees on what the areas are.

When is a git-derived knowledge map still the right tool?

Often, and it is worth being plain about it.

If your team writes most of its code by hand, authorship still tracks understanding well enough, and CodeScene has ten years of practice turning git history into a knowledge map, an off-boarding simulation and a hotspot view that needs no agent, no plugin and no change to how anyone works. It runs on any repository's history the day you connect it. On the Pro plan, where Knowledge Distribution lives, it costs €27 per active author per month billed yearly, against Backthread at $25 per seat per month with one repository included and $10 per additional repository. The two are compared row by row in Backthread vs CodeScene.

If what you actually need is a reviewer to auto-assign, LinearB's Code Experts or a maintained CODEOWNERS file answers a routing question, and routing does not need the comprehension question answered first.

The case for measuring understanding directly is narrower than "everyone": it is the 10-to-100-engineer team where agents write most of the merged code, where review is approving more than it can hold, and where the leader has stopped trusting the answer "ask whoever's name is on the blame." That is the team the map with knowledge coverage is built for, and the only team it is built for.

Connect one repo and the estimated picture is on the map the same day, capped and labelled as the guess it is; from there coverage moves only when someone can account for the decisions. The trial is fourteen days with everything on, and the map stays honest about what it has not measured.