DEV Community: Naetive Origin

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.