A few years ago I could keep up with the pull requests my team shipped in a week. Not skim. Actually read. Follow the logic, notice the shortcuts, remember a month later where the interesting bits lived when I needed them again.

I can’t do that anymore. Not because we added engineers (we didn’t). Because AI writes more code per engineer per week than I can read.

Some of it is mine, through Claude or Cursor. Some of it is my teammates’. A surprising amount of it, if I’m honest, nobody on the team can quite reconstruct from memory.

The part nobody says out loud

The industry spends a lot of time celebrating how fast AI lets us ship. Less talked about: the rate at which we understand what we’re shipping hasn’t kept pace. We still read at the same speed. We still form mental models at the same speed. We still ask a teammate “hey, why does this work this way” at the same speed.

Code output keeps going up. Understanding throughput basically doesn’t.

What fills the gap is a specific kind of technical debt. Not messy code, but unclaimed code. Functions that work but nobody has a story for. Modules that pass CI but nobody can explain the invariants of. Whole flows that were prompted into existence three weeks ago and are now load-bearing.

Classic onboarding pain now hits incumbents. I’m a senior engineer on a codebase I’ve worked on for two years, and I’m the new hire every Monday morning.

Why chat doesn’t fix this

The reflex is: just ask Claude. Or Cursor. Or whatever agent is in the editor this week. And for the first question, fine. It reads the file, gives you a summary, moves on.

But every new conversation starts from zero. Every fresh tab is an amnesiac. The agent has to retrieve and re-read whatever parts of the repo it decides are relevant; your employer pays for that reconstruction every single time; and the answer varies from run to run because the retrieval step is a lossy compression of your codebase, not a faithful copy of it.

The deeper issue is architectural. An agent builds up real understanding within a session. After it’s read ten files, it’s smarter about your codebase than it was an hour earlier. But that understanding dies with the session. It doesn’t survive your next /clear. It doesn't carry over to the teammate asking the same question in their editor ten minutes later. It doesn't transfer to the different agent you evaluate next month. Every new conversation starts from source and pays to reconstruct context from scratch, and you get a slightly different answer each time because each reconstruction is a slightly different compression.

What engineers actually need, and what agents desperately need, is a shared, persistent, grounded understanding layer. Not a chatbot. Not a wiki. Not documentation that rots. A thing that reads your code once, thoroughly, produces structured understanding, and then serves that understanding to whoever needs it, human or machine.

That’s the product I ended up building. It’s called SourceBridge.ai. The more interesting question is how you actually plug it in.

Four doors into the same understanding

Once you accept that the thing you’re building is a shared understanding layer, the surface question becomes interesting. It’s not “what should our UI look like.” It’s “how do different consumers want to plug in?”

I ended up with four.

The web. Browser-based exploration. This is for the person who’s new to a codebase and wants to see the shape: cliff notes, learning paths, code tours, architecture diagrams. It’s how you onboard. It’s also how you explain a system to a non-engineer stakeholder, which matters more than people admit.

The CLI. The scriptable one. A terminal command that asks questions, generates field guides, returns structured output. This is where automation lives. Your CI pipeline, your pre-commit hook, your release notes generator, your “comment on the PR with an impact summary” GitHub Action. If a process is already mechanical, this is its integration point. Same understanding as the web, just wearing a shell-friendly hat.

The editor. A VS Code extension that shows you which requirements a function implements, lets you ask questions about highlighted code with Cmd+I, generates a field guide for the active file. The point isn't "another copilot." The point is that the grounded understanding follows you into the editor where you actually work, so you're not alt-tabbing to a browser every three minutes.

The agent protocol. This is the one that matters most for the AI-outpaces-understanding problem. MCP (Model Context Protocol) lets an agent like Claude Code, Cursor’s agent mode, or Windsurf query the understanding layer directly instead of re-reading source. Ask Claude “how does auth work here.” Under MCP it doesn’t have to reconstruct context by scanning dozens of files. It calls explain_code against the indexed understanding, gets a grounded answer with citations, and moves on.

Four doors. One understanding inside.

The agent story is bigger than it looks

The pitch I’d give a CTO is this: you’re paying to re-teach every new agent conversation about your codebase from scratch. You don’t have to.

Once your code is indexed and summarized into a structured graph, every agent query becomes a small lookup plus a small generation, instead of a full retrieval plus a large context window plus a generation. Token cost drops, often meaningfully so on repo-scale questions. Latency drops with it. And the answers get more consistent, because instead of re-reading ten snippets of source code the agent is reading a pre-digested explanation of what that code does and why.

The analogy I keep coming back to. You wouldn’t give a new hire the git repo and say “figure it out.” You’d give them a tour, some docs, access to someone who’s been there a while. Agents deserve the same infrastructure. They’re new hires that start over every conversation, and we should at least hand them a guidebook.

The side effect is that humans benefit from the same infrastructure. The field guide the agent reads is the same field guide I read on Monday morning when I’m trying to remember why a module exists.

The surfaces mirror how you actually work

If you step back, the four surfaces map pretty cleanly onto how software actually gets made:

• You explore a system in a browser.
• You automate it from a shell.
• You modify it in an editor.
• You reason over it with an agent.

A tool that only handles one of those is a tool that forces you to break your workflow every time you cross a boundary. A tool that handles all four, backed by the same indexed understanding, stays out of your way. You don’t have to think “which tool tells me this.” You just ask wherever you already are.

That’s the shift. Not “another AI developer tool.” A single understanding layer that shows up wherever you’re working, in the shape appropriate to that place.

This isn’t actually a new problem

Understanding has always been the bottleneck in software. Before AI, we papered over it with six-week onboarding, stale wiki pages, and the cultural norm that “only Dave knows why that’s there.” AI didn’t create the gap. AI just made it visible, and impossible to ignore, by removing the other bottleneck that was hiding it.

The goal isn’t to slow down the code. That horse is out of the barn. The goal is to give the understanding layer the same treatment we gave the code layer a decade ago when we invested in language servers, tree-sitter, better grep, better IDEs. Systematize it. Index it. Make it queryable. Let both humans and machines pull from the same well.

If you do that, and you do it right, you stop asking “can we keep up with AI?” and start asking the more interesting question: “now that understanding is cheap, what do we build?”

That’s where I think this is going. It’s why I’ve been putting the hours in.

About SourceBridge.ai

SourceBridge.ai is open source under AGPL-3.0. You can try it, read the docs, or grab the code at sourcebridge.ai.

Fair warning: it’s pre-1.0. The core path works and I use it daily (indexing, field-guide generation, requirement linking, the MCP server, the VS Code extension, the streaming answer flow, the CLI). But there are rough edges. Docs that haven’t caught up to the code. Onboarding that assumes you know what you’re doing. Settings screens that work but could be kinder. A full polish pass hasn’t happened yet.

If you try it and something’s broken or unclear, I’d love to hear about it.