DEV Community: uncompacted

Grounded, not vibes: understanding backed by evidence you can open

uncompacted — Wed, 07 Oct 2026 21:44:18 +0000

There is a quiet problem with most AI-generated summaries of a codebase. They sound right. They are confident, fluent, and often wrong in ways you will not notice until an agent acts on them.

The issue is not the model. It is that a summary with no evidence behind it cannot be checked. You either trust it or you do not, and once the code moves on, you have no way of knowing which parts are still true.

Every claim has a source

Naetive takes a stricter view. A claim about your code is not a sentence someone wrote. It is a statement tied to the code it came from, down to the file and lines an agent actually opened. "Auth is JWT, verified server-side" is not an opinion in a doc. It points at the function that does it.

And a claim with nothing behind it says so. It shows as not yet checked, so nobody builds on it until somebody does.

That changes what you can do with the understanding. You can open the evidence. You can see whether the claim is still describing the code that exists today. You can disagree with it, on the record, and the disagreement stays with the claim.

Drift is surfaced, not hidden

Code moves. The dangerous thing is not that a claim becomes false, it is that nothing tells you. A doc that was right in March is silently wrong in June and still reads the same.

Because each claim points at real code, Naetive can notice when that code changes underneath it. Instead of quietly going stale, the claim is marked for a re-check. A changed file is a prompt to look, not proof the claim is wrong, so the next agent working in that area checks it against the code. You see what drifted. An agent sees what it should not rely on yet. The understanding stays honest about its own uncertainty.

What is grounded, and what is not

Not everything about a project lives in the code. A decision to use one vendor over another, a constraint from a customer, a question nobody has answered yet. Naetive keeps those too, but it is clear about the difference. Claims about the code are checked against the code. Decisions and constraints are backed by their record, the moment they were made and why. Open questions are marked as open.

That distinction matters. An agent reading the understanding knows which parts are verified against the source and which parts are recorded judgement. It does not have to guess.

The same rule travels with the code. When the understanding is exported into your repo as a folder, the citations go with it, so a fresh agent can still open the evidence. The grounding docs cover the details: what counts as cited, how re-checks work, and what happens when two readings disagree.

Why this is the whole point

Understanding that cannot be checked is just a nicer-looking log. The reason to give a project a living understanding is so an agent can act on it with confidence. Confidence has to be earned, and it is earned by evidence you can open.

Grounded, not vibes.

Why your AI agents redo each other's work (and what fixes it)

uncompacted — Fri, 02 Oct 2026 09:21:37 +0000

If you run more than one AI coding agent on the same project, you have felt this. Each agent is fine on its own. Together they collide. One makes a decision, another quietly undoes it. Two solve the same problem in parallel. You end up as the person carrying context from one window to the next.

It is tempting to blame the model. Usually the models are fine. The problem is that nothing they figure out reaches the others.

Your files are shared. Your understanding is not.

Here is the part that trips people up. The agents already share your files. Claude Code and Codex can both read the same repo. Sharing the code is solved.

What is not shared is the understanding around the code. The decision one agent made ten minutes ago about how to structure the auth flow. The constraint the other one discovered. The thing you ruled out an hour ago. That lives in one agent's context, and only there. The next agent reads the same files and reaches a different conclusion, because it never saw the reasoning.

Redoing each other's work is what it looks like when understanding does not transfer.

The fixes people try

Most people reach for the same things.

A CLAUDE.md or AGENTS.md. Great for stable rules. Useless for what got decided this week.

Pasting context between windows. Works, briefly, and makes you the bottleneck. You are now the switchboard.

A bigger context window. Still one agent's context. The other agent does not get it.

Each of these treats the symptom. None of them make the understanding belong to the project.

What actually fixes it

The fix is for understanding to live somewhere every agent reads from and writes to. Not a chat. The project.

When one agent commits a decision, grounded in the code it touched, the next agent inherits it. It does not have to be told. It opens the project and the decision is already part of what the project knows about itself. Two agents working the same codebase stop being two private worlds and start working from one picture.

That is what Naetive does. It is not a coordination layer that schedules your agents. It is the shared understanding they all inherit, so they stop redoing each other's work because they finally know what each other decided.

A better model won't fix your multi-agent problem

uncompacted — Tue, 29 Sep 2026 11:33:45 +0000

Every few weeks a new model drops and the same hope comes with it. Maybe this one will finally make my agents work together. Maybe a smarter model just handles it.

It never does. Not because the models are not getting better. They are. It is because the multi-agent problem does not live where the model lives.

A smarter agent is still an agent working alone

Give the best model in the world your whole repository. It will read the code beautifully. It will still not know the decision you made yesterday, the approach you rejected last week, or what the other agent concluded an hour ago. None of that is in the repo. It is in a chat, or in your head.

Intelligence does not conjure context that was never written down. A better model reasons more sharply over what it is given. It is given the same nothing.

The problem sits above the model

Think of the layers. At the bottom, the code. Above it, the model, reading and writing that code. Above that, the understanding: why the code is the way it is, what has been decided, what is still open.

Model releases improve the middle layer. They do nothing for the top one. That is why you can upgrade every agent you own and still find them redoing each other's work. The understanding still does not transfer, because nothing you upgraded was responsible for transferring it.

What actually moves the needle

The lever is at the understanding layer. Make the understanding belong to the project, captured as you work, grounded in the code, inherited by every agent that opens it. Then a better model helps enormously, because it finally has something worth reasoning over. And a model switch stops being a reset, because the understanding was never inside the model to begin with.

That is where Naetive sits. Not competing with the model. Above it, holding the thing the model cannot hold for you.

So, next release

Enjoy the new model. Use it. Just do not expect it to fix a problem it was never positioned to see. The understanding layer is a separate job, and it is the one that makes every model you use better.

AI coding agents don't have a workspace. Here's what that costs you.

uncompacted — Fri, 03 Jul 2026 22:12:52 +0000

This week half my feed is people switching AI models. A new one drops, the old one gets throttled, everyone re-evaluates their setup. It happens every few weeks now.

Watch those threads long enough and you notice the real complaint underneath. It is not the model. It is that switching costs you everything you had built up: your rules, your context, what the last agent figured out. All of it lived inside one tool, and now you are rebuilding it somewhere else.

That is not a model problem. It is a workspace problem.

Your setup is not a workspace

Think about what an AI coding setup actually is today. You have a chat window. You have your codebase. Maybe a terminal, maybe an IDE extension. And that is it. Nothing sits above them holding the work together.

So where do your decisions live? The reasons you chose one approach over another? What you already tried that did not work? What another agent, in another window, concluded an hour ago? Nowhere durable. It is scattered across chat histories that each tool keeps to itself, and most of it is gone the moment you close the tab.

Your files are shared. Your thinking is not.

Your files are shared already. Claude Code and Codex can both read them. But your files are only the code. They are not the thinking around the code, and the thinking is the part that is expensive to rebuild.

This is why a better model never quite fixes it. A smarter agent is still an agent working alone, with no idea what the others did. Give it your whole repo and it still opens cold on everything that is not in the repo.

What a workspace actually gives you

What would help is a workspace. Not a chat window. A place the work lives, that every agent reads from and writes to. Concretely, that means a few things.

One shared memory. What one agent learns, the next already knows, even on a different model. You stop re-explaining your project every time you open a new chat.

Visible work. Every task, decision and change is something you can see, not something buried in a chat transcript you will never scroll back through.

Many agents, one project. Claude, Claude Code, ChatGPT and Codex working from the same source of truth, so they stop redoing each other's work.

Continuity. Close your laptop, come back tomorrow, and it picks up exactly where you left off.

None of that is about the model. It sits above the model, which is exactly why no model release touches it.

The model will keep changing

This is what we are building Memeri to be. Not another memory tool. The workspace your AI coding agents never had, so the next time you switch models, or run three agents at once, the work comes with you instead of starting over.

The model you use will keep changing. Your workspace should not have to.

You've become the switchboard between your AI agents

uncompacted — Wed, 01 Jul 2026 14:06:07 +0000

If you have started running more than one AI coding agent, you have probably hit a strange kind of friction. Each agent is capable on its own, but together they trip over each other. One makes a decision, another never sees it and quietly undoes it. Two of them solve the same problem in parallel. You end up as the human switchboard, carrying context from one to the next.

It is tempting to blame the model. Usually that is not it. The models are fine. The problem is that they do not share anything.

Each agent lives in its own bubble

A single agent session is a closed world. It knows what is in its context window and nothing else. Open a second agent, in another tool or another tab, and it starts from zero. It cannot see what the first one decided, what is already done, or what you agreed an hour ago. There is no shared view, just several private ones.

That is fine when you work with one agent at a time. It stops being fine the moment there are two or three, or a teammate and a couple of agents, all touching the same project. The cost of that fragmentation grows with every participant you add.

The fixes everyone tries, and where they break

Most people reach for the same workarounds, in roughly this order:

A CLAUDE.md or AGENTS.md file. Great for stable, per repo instructions. It does not capture the live, changing state: what got decided this week, what is in flight, what just changed.
A running "decisions" doc you paste in. Better. It works well for one person and one agent. It falls apart the moment two agents write to it out of sync, or it quietly goes stale and an agent builds confidently on a decision you already reversed.
Bigger context windows. These push the wall back. They do not move it. More room per agent does nothing for the fact that the agents cannot see each other.

Each of these helps a single agent remember more, when the real problem is that several agents cannot agree.

Why this is really a coordination problem

This is the shift that matters. "My agent forgot" is a memory problem, and the labs are steadily solving it. "My agents do not know what each other did" is a coordination problem, and no model upgrade touches it.

Coordination needs three things the private bubbles cannot provide on their own:

One shared record every agent and person reads from and writes to, instead of many private contexts.
Current state, not just history. The hard part is not storing more. It is knowing what is still true. A stale "we decided X" is worse than no note at all.
The right slice, not the whole pile. Handing an agent five relevant facts beats burying it in two hundred. Dumping everything into context just makes things worse.

In practice that looks like an append only decision log, so nothing is silently overwritten and you can see when something was superseded. Shared tasks that live outside any single chat. And a quick view of what was just worked on, so a fresh agent gets grounded in seconds rather than re explained from scratch.

Where this is heading

The interesting frontier right now is not a model that remembers more. It is the layer that lets many agents, and the humans alongside them, work from the same source of truth. That is the problem we are building Memeri around: structured memory and visible work, shared by every agent you connect over MCP, so opening a new agent means it already knows the project.

If you run multiple agents day to day, the single most useful thing you can do, with or without a tool, is give them a shared and current record of what has been decided and what is done. It changes how they behave.

If you want to try it, Memeri is in early access: https://memeri.ai