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.
Top comments (0)