Your team understands
the codebase your agents built.

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.

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.

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

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

It uses the time they’re already losing — the pause while the agent works. Nothing blocks them.

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.

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.