We spent three weeks working out what our own code already did.
Not designing it. Not writing it. Reading. Then we went looking for a team this doesn’t happen to, and we could not find one.
gone before a line of code is written, almost all of it spent working out what the system already does.
the original estimate, reported consistently across teams. “Every single engineer I worked with including me was terrible at estimates.”
scope discovered mid-project on one large effort: a 120-item list finished at roughly 170.
Every one of these was one of us not having read the code.
Six places the work stops. On the right, what we wish we had been looking at.
We built it twice. The first one was behind a flag nobody turned on.
A request came in. Half of it had shipped two years earlier behind a flag that was never turned on, and the one person who knew that had left. So we re-specced it, re-estimated it and built it again. The first version is still sitting in our repository, unused.
bulk_export_v2, off in every environment since March.We spent three weeks in meetings about a file none of us had opened.
Scoping is the three weeks before any of us writes code, and we do it in meetings because the answer is in files none of us has open. The number we walk out with is a guess wearing a decimal point.
Half our design review is us correcting the doc.
Weeks two and three go to writing the doc and arguing about it. Most of the argument is us correcting assumptions the doc never checked against the code, which makes the review a very slow read of our own repository, out loud, in a room.
Exports are queued through a single worker with a concurrency of four csvWorker.ts:41. Failed jobs retry three times, then drop silently, so there is no user-facing failure state queue/retry.ts:88.
Saved filters serialise to a schema shared with the reporting API, so a new field here changes both surfaces filters/schema.ts:120.
Our agents opened forty PRs last week. We read three.
Our agents now write more code in a week than we can read line by line. Writing got cheap for us and reading did not, so whoever has time to read the path is the constraint on everyone else, and the rest of it merges unread.
Someone refactored main and our feature broke.
A refactor landed on main, broke the features that depended on the old mechanism, and a week of bug fixing appeared in a sprint that was already full. Nobody told us. We found out from a failing build.
Our wiki stopped being true eleven commits ago.
We write release notes from tickets rather than from what actually merged, and the wiki drifts one user story at a time. The next thing we scope then starts from a document that is wrong, and the nine weeks begin again.
Nobody taught me how to read a codebase. I was expected to already know.
The hard part of my first year has not been writing code. It is reading two hundred thousand lines of somebody else’s.
I read it for two days and still could not say whether changing line 400 breaks checkout. Nobody sat me down and taught me how to do this. It was assumed I arrived knowing.
The first four questions of the day are fine. The fifth one I swallow and guess instead, and the guess is what ends up in my PR. Nobody is keeping count. It feels like somebody is.
The actual reason is in a PR thread, a review comment and a ticket nobody linked. The diff tells me what changed. It has never once told me why.
I usually find out which one is true in review, in front of everybody. The page stopped being true eleven commits ago and nothing about it says so.
Three implementations exist. One is live, one sits behind a flag that never turned on, one is waiting to be deleted. Nothing in the repository marks which is which.
Checking the answer needs exactly the knowledge I was asking for. So I either trust it, or I go and read the code, which is the thing I was trying to avoid.
Nine weeks of work, three of them spent finding out what we had already built.
We got tired of it and built one index over our own code.
Every answer carries the file and the line it came from, so checking it takes ten seconds instead of trust. We point it at our own repositories first.
Play the demo: Why AI coding agents keep breaking production“Scoping used to be three weeks of meetings. Now the first meeting starts from a file list, and we argue about the two decisions that actually matter.”
The index updates on every commit. An answer reflects the branch as it stands right now, not last night's snapshot, which is the whole reason we trust it over our wiki.
Every language in common use. The gaps are the genuinely new and genuinely rare ones. Mojo, for example, is not supported yet.
Bring your own key. Anthropic, OpenAI Codex, Gemini, DeepSeek, Qwen, Z.ai, or anything reachable through OpenRouter. Your keys, your spend, your choice of model per workspace.
Hosted, on dedicated hardware, or fully on-premise inside your own network. On the second two, your source never leaves your infrastructure. Access is read-only in all three.
Index a thousand files before you decide anything.
Same index, same citations, same MCP connection on every plan. What changes is how many files it holds and whose hardware it runs on.
Enough for a service or a mid-sized repository. No card, and no feature held back.
- Every answer cited to a file and a line
- MCP connection to Cursor, Claude Code and Windsurf
- Your own model keys
2,500 files indexed, which in practice is three or four repositories. The point where a team stops asking one person what the system does.
- 2,500 files across your workspace
- Re-indexed on every commit
- Everything in Free
Runs inside your network. The index, the models you point it at, and your source all stay on infrastructure you control.
- Dedicated hardware or fully on-premise
- Anthropic, Gemini, Codex, DeepSeek, Qwen, Z.ai, OpenRouter
- Scoped to your repository count, not per seat
Start your next cycle from the code.
Point it at a repo. Discovery, scoping and specs all read from the same index, the way ours now do.