There’s a recurring frustration among experienced developers using AI coding tools, and it keeps surfacing in the same way: the code the model writes is fine, but I’m losing my grip on the codebase.
This isn’t about quality. The generated code compiles, passes tests, even follows reasonable patterns. The problem is subtler. Every time you delegate work to an agent and review a diff, you understand your system a little less. The diff tells you what changed. It doesn’t tell you how the change relates to the architectural decisions you made three months ago, or whether it’s consistent with the pattern you established across twelve other files.
The tools are optimizing for code output. They should be optimizing for shared understanding.
The mental model is the product
When you know a codebase well, you don’t navigate it file by file. You carry a compressed representation in your head: the type hierarchy, the data flow between subsystems, the naming conventions that signal intent, the architectural boundaries that keep concerns separated. This mental model is what lets you make decisions quickly and make them well. It’s the reason a senior developer who knows the system writes better code in an hour than a new hire writes in a day — not because they type faster, but because they see the whole board.
Current AI tools don’t participate in this mental model. They don’t even know it exists. They operate on text — retrieving files, generating files, diffing files. The structural understanding that makes a codebase coherent lives entirely in your head, invisible to the tool that’s supposed to be helping you.
This is the real cost of agent-first development. Not that the agent writes bad code, but that the loop between human and machine has no shared representation of what the codebase is. You’re co-authoring a novel where one writer has read every chapter and the other gets handed random pages.
A reviewable data structure
What if the mental model wasn’t just in your head? What if it was a first-class artifact in your development environment — a continuously updated data structure that encoded the type graph, the data flow, the architectural conventions, the thematic structure of your project?
This is what we’re building with Kaiso. Not a smarter retrieval system, but a semantic compression layer that both you and the LLM operate from. The compression isn’t a black box. It’s a reviewable, correctable representation of your project’s structure. You can inspect it. You can disagree with it. You can shape it.
This changes the nature of developer control. In the current paradigm, control means reviewing diffs — approving or rejecting code after the fact. In this paradigm, control means co-authoring the understanding that the LLM reasons from. You’re not just deciding whether a change is acceptable. You’re shaping how the system thinks about your code before it ever proposes a change.
New workflows for a new paradigm
This requires rethinking what the development interface actually looks like. If the shared mental model is the primary artifact, then the primary way you interact with your codebase should reflect that.
In practice, this means navigating your project by architecture and thematic structure rather than by files. Your codebase has a shape — a service layer here, a set of conventions there, a data flow pattern that connects these four subsystems. That shape is how you already think about your code when you’re making decisions. It should be how you interact with it in your IDE, and how the LLM interacts with it when generating changes.
Source code doesn’t go away. It’s still there as a drill-down layer — the ground truth you can always reach for when you need the exact implementation. But the primary interface, for both human and LLM, is the structural understanding of what the code does and why it’s organized the way it is.
This isn’t just a UI preference. It’s a necessity born from how LLMs actually work. A model operating on architectural structure and conventions will produce code that belongs in your codebase, because it’s reasoning from the same compressed understanding that you are. A model operating on retrieved text snippets will produce code that’s locally coherent but globally adrift, because snippets don’t carry architectural intent.
The co-authoring loop
Here’s what this looks like in practice. You’re working on a feature. The semantic layer encodes that your project uses a specific error handling pattern across services, that there’s a data validation boundary at the API layer, that components in this subsystem follow a particular composition pattern. The LLM sees all of this — not because it retrieved the right files, but because the compressed representation includes it by definition.
When the LLM proposes changes, they’re consistent with these patterns because the patterns are part of its input. When you evolve a pattern — deciding that a new approach to error handling is better — the semantic layer updates, and subsequent LLM output reflects the new convention. The mental model evolves as a shared artifact, not as something you maintain privately while hoping the tool catches up.
This is what co-authoring means. Not two entities taking turns writing code, but two entities maintaining a shared understanding of what the codebase is, and using that understanding to make it better.
What we’re building toward
We’re early. The semantic compression layer is the foundation, and getting it right matters more than shipping fast. But the direction is clear: an IDE where the developer’s primary relationship is with the structure and intent of their codebase, where the LLM is a collaborator that shares that understanding, and where control comes from shaping the model’s reasoning rather than reviewing its output after the fact.
If this resonates, sign up on our homepage to follow along. And if you’re an experienced developer frustrated by the drift toward agent-first, chat-first, code-second tooling — we’re building this for you.