Most AI doc tools can't tell you what they left out

An AI can write you a clean, confident wiki for your codebase and never once tell you what it skipped. That's the real problem with "point it at your repo" doc generators, and it's worse than the occasional wrong sentence. A wrong sentence you might catch. A missing one you won't, because nothing on the page says "the entire billing module isn't in here."

The reason is simple: a free-roaming summarizer has no idea what "done" looks like. It reads what it happens to retrieve, writes about that, and stops. There's no denominator. It can hand you 40% of your system, formatted beautifully, and call it a wiki.

Atlas takes the opposite approach. Before it writes a single page, it builds a ground-truth inventory of what your code actually exposes.

The spine

We call it the spine: a deterministic list of the real surface of a source. Not "what seems important", the actual enumerable things. HTTP routes, environment variables, CLI flags, database models, exported types, and, if you point it at your tracker, the issues. This is extraction, not generation. No model guesses here. Tree-sitter and friends walk the code and produce a flat list of everything a reader would reasonably expect the docs to cover.

The spine is the yardstick. Everything after it gets measured against it.

Coverage is a fraction, not a vibe

Once the pages are generated and every claim is cited back to its source, Atlas grades the pages against the spine. Coverage is literally: of the surface we know exists, how much is actually documented and cited somewhere in the wiki.

That gives you two things a summarizer can't:

• A number. 78% covered means something, because the denominator is real.
• A gap list, with exact file:line. Not "docs might be thin somewhere" but "these 14 things exist in the code and appear nowhere in your wiki, and here's where they live."

You can send effort where it's missing instead of rereading the parts that were already fine.

The exported-types story

Here's where the number earned its keep. We ran Atlas on a type-heavy backend service and it came back at 46% coverage. The prose looked great. Read a page and you'd have believed the docs were solid.

They weren't. Most of that service's real surface lived in its exported types and components, and the generator, left to roam, had written around them, summarizing behavior while quietly skipping the actual type contracts. On a Java, Go, or TypeScript codebase, that's most of the surface.

We added one deterministic move: a Components and Exported Types page that enumerates them with citations. Coverage went from 46% to 95%.

Nothing about the prose quality changed. What changed is that the 54% the generator had been glossing over was now visible, because the spine counted it and the coverage number refused to round it away. Without the spine, that gap is invisible. You ship the pretty 46% wiki and find out what's missing the hard way, six weeks later, when someone trusts it.

Why "ask the repo" tools can't do this

This is the honest dividing line. A chat-with-your-codebase tool can be genuinely useful, but it structurally cannot produce a coverage number, because it has no inventory. There's nothing to divide by. It answers what you ask and stays quiet about what you didn't. The confident-but-incomplete failure mode is baked in.

Coverage only exists if you commit to enumerating the surface first. That's the boring part nobody wants to build, and it's the whole difference between a summary and documentation.

What the number does and doesn't mean

Being straight about it:

• Coverage measures whether the important surface is present and cited. It does not grade the prose. A documented route can still be documented badly, and that's on a human reviewer.
• The spine is only as good as its extractors. If Atlas doesn't know how to enumerate some kind of surface, it can't count against you, which is a real limitation, not a feature.
• 100% must-cover is not "perfect docs". It's a narrower, more useful claim: nothing important is silently missing. That's the bar most wikis fail, and the one you actually want to guarantee before you tell people to trust the thing.

That's the point of the whole exercise. A doc generator you can trust isn't the one with the nicest prose. It's the one that can tell you, with a number and a file:line list, exactly where it fell short. The honesty is the feature.

Atlas is part of tela, self-hostable with a free cloud tier. Point it at a repo and it'll tell you how much of it is actually documented, down to the file and line.