01System diagram with time travel
Every repo on one map, and you zoom to the part you care about instead of reading the whole thing — plus a slider to pull it back to any week you like.
02Risky things your agent decided
trade-off Outages stall the queueretries were removed after double-charging
assumption Webhooks arrive in ordernever checked against the provider
The trade-offs and assumptions accepted along the way — taken from the agent’s own reasoning, not guessed from the diff.
03What your agent rejected
chosen Orders go on a queuethe provider can be down and the order still stands
rejected Charge the card in the requesta timeout double-charged twice in March
The option it considered and turned down, with the reason it gave. That is the part nobody can reconstruct from the code afterwards.
04Who has worked where
Read from your commit and pull-request history, so “ask whoever knows” has a name attached on day one, with nobody answering anything.
05Knowledge coverage
Two numbers per area: what your history implies, and what somebody has actually explained. History on its own stops at half.
06Learning in the flow
What moves the second number arrives inside the coding agent while it is thinking — no training programme to run, and nothing that blocks anyone.
Onboarding time
Days until a new hire ships a safe change to a service they have never seen. They start from the map and the reasoning behind it, not a tour and a Slack thread.
Your weakest areas
The parts of your system almost nobody has ever worked in. Read from your own commit and review history, so you see which ones on day one — before anybody has been asked a thing.
Time your seniors spend explaining
Your best people answer the same questions every week. They stop having to when everyone else can answer them.
Decisions that reach you
Big decisions wait for the two people who understand everything. The more people who understand, the shorter that wait.
Comprehension time
Engineers spend most of their week working out what code does. It is the largest line in your budget that nothing currently measures.
Knowledge coverage
How much of your system your team can explain, area by area — kept apart from what your history merely implies. You have never been able to see this before.
See it on a real codebase.
An open-source system, read end to end — the map, the reasoning behind each change, and the coverage on top of both.
Your code stays yours.
Nothing leaves unredacted
Code and command output are stripped on your own machine before anything is sent. The client is open source — read the exact code.
We never store your source
Today the analysis runs in a sandbox that is destroyed when the job finishes. What we keep is the map and the reasoning.
Read-only, revocable
A GitHub App with read access you can withdraw at any time. Private repos stay private.
Extraction runs on your side.
Today we clone your repo into that throwaway sandbox, so “we don’t keep it” is still something you have to take our word for. Next, the analysis moves onto your own CI runner: it checks out the code with the token GitHub already issues it, runs the same open-source extractor we run, and sends us only the derived graph — which we validate before it is stored. Your source would never leave your infrastructure, and we would no longer need permission to read your code at all. We would still ask to read pull requests, because that is how we know a decision actually shipped.
One command. Any agent.
Connect your repos once. Your team’s next session starts feeding the map.
$25 per seat. Free for 14 days.
- everything on, from day one
- one repository included, $10 for each one after
- the trial clock starts at your first build, not at signup
- no card to start
The ones we actually get.
Why not just ask Claude when I need to know?
Because you have to know what to ask, and whether the answer is right. Asking helps the person who already understands the system. It can’t hand that understanding to someone who doesn’t.
What if my engineers never answer anything?
You still get the picture. Ownership and coverage are read from your own git and pull-request history first — who committed in an area, who reviewed there — so day one takes zero participation from anybody.
What history cannot tell you is whether a person actually understands that area. So it stops at half. The top half is only earned by explaining something, and that is the part your engineers opt into.
Do developers even need to understand everything now?
No — and we don’t claim they do. The agent handles the line-by-line. What can’t be handed over is the shape of the thing: what it’s for, how the parts connect, what breaks when you move one.
Is there any evidence behind those numbers?
For the mechanism, yes; for our effect on your org, not yet — we are too young to have that, and we will not invent it.
Shared understanding really does change how a team performs. A meta-analysis of 231 correlations from 65 independent studies found team cognition positively related to team behavioural process (ρ=.43) and to team performance (ρ=.38). DeChurch & Mesmer-Magnus, J. Applied Psychology, 2010
Reviewers miss things because they do not understand the change. Microsoft’s study of modern code review — 17 developers observed, 570 comments classified, 165 managers and 873 programmers surveyed — found that finding defects is the top-ranked motivation, yet only 14% of comments concerned defects, and those mostly addressed micro-level and superficial concerns. Understanding the change and its rationale emerged as reviewers’ clearest challenge. Bacchelli & Bird, ICSE 2013
Comprehension is most of the job. An instrumented field study of 79 professional developers across 7 industrial projects — 3,244 monitored hours — put program comprehension at about 58% of developers’ time at the keyboard. Xia, Bao, Lo, Xing, Hassan & Li, IEEE Trans. Software Engineering, 2018
Onboarding benchmarks do not measure understanding. The current industry figure is 33 days to a tenth merged PR — and its authors state plainly that it says nothing about the depth of understanding new hires have. DX Engineering Enablement benchmark, 2026
One number we deliberately do not print: that a defect costs 100× more to fix in production. It traces through a textbook to 1981 course notes nobody has produced. Separately, the largest study on record — 171 projects — found no evidence for the delayed-issue effect. Bossavit, The Leprechauns of Software Engineering · Menzies et al., Empirical Software Engineering, 2017
Does using an agent really cost my engineers understanding?
It depends entirely on how they use it, and that is the whole design of this product. In a randomised trial (n=52), developers who used AI to learn a new library scored 50% on a comprehension quiz, against 67% for those who wrote the code themselves. Among the AI users, the authors observed — without claiming causation — that heavy delegation clustered below 40% while conceptual questioning clustered at 65% or above. Shen & Tamkin, Anthropic, 2026
The psychological name for it is cognitive offloading, and it is well established. “Brain rot” is the popular name for it; the phrase has been applied to social media users and even to AI models, but not yet to engineers — though the phenomenon is being studied under other names.
In a 2025 randomised trial, developers believed AI made them 20% faster while measurement showed them 19% slower (n=16) — a result METR has since marked historical. Self-report from your team is not evidence about your team. Becker et al., METR, 2025
What does an individual engineer get out of it?
The reasoning behind code they did not write, at the moment they are about to touch it — why it was built this way, what was rejected, and what breaks if they move it. It arrives inside the coding agent they already have open.
There is no training programme to run and nobody is ranked on anything. Ignore it and nothing happens.
Won’t this slow my engineers down?
It uses the time they’re already losing — the pause while the agent works. Nothing blocks them.
How is this different from documentation?
Docs describe the system to whoever opens them, and nobody opens them.
There is a newer problem underneath that. Documentation is increasingly written for agents. Which means the reasoning behind your system is now addressed to a machine, and there is no longer anyone on the human end of it.
This puts the question in front of a person instead, and tells you what came back.
We already write our reasoning into the repo.
Good — that’s the raw material, and it makes us better. But a file being there isn’t the same as a person having read it. That gap is the whole product.
Find out what your team knows.
Connect your repos. The first map takes a few minutes, and it’s free for two weeks.