Documentation that fixes itself
Two new feedback loops — Tell AI and runtime validation — close the gap between what your docs claim and what your product actually does. Available on every paid Git2Docs plan starting today.
The drift problem
Every documentation tool we've used has the same lifecycle: write the docs, ship the code, watch the docs drift, eventually rewrite. The drift is the killer — by the time someone notices, the wrong example has been copied into ten support tickets, the wrong endpoint has been linked from three blog posts, and the wrong CLI flag has been pasted into a customer's production deploy.
Git2Docs already kept docs structurally in sync — it regenerates pages when code changes and validates that flags and endpoints exist in the source. The two new features close the remaining loop: keeping docs behaviourally in sync with the deployed product, with the maintainer in the loop at the propose step but not at the rewrite step.
Tell AI
Open the audit view. Read any section. See a problem? Click Tell AI. Type a sentence about what's wrong. Repeat across as many sections as you want — comments stay open and batch.
When you're ready, hit Submit Review. Claude reads all your feedback at once, proposes a brief patch plus a list of pages to regenerate, you click Apply, and the changes are live. No more hand-editing the AI brief field by field. The brief is still there if you want it, but most teams won't need to touch it after the first generation.
The consolidator is the bit that earns its keep: a Claude pass over the entire open-feedback batch + the brief + each section's context. It deduplicates ("this same issue is flagged on five sections, fix the underlying naming once"), spots contradictions ("two comments want opposite changes — flag for clarification"), and translates ad-hoc prose into structured brief updates so the next regen avoids the same mistake instead of just patching it.
Runtime validation
Tell AI catches what you can see. Runtime validation catches what you can't — the documented endpoint that doesn't exist, the CLI subcommand that was renamed two releases ago, the response code that quietly changed from 204 to 202.
Open the validation hub. Copy one URL. Paste it into a coding agent — Claude Code is the path we've tested most, but Codex, Antigravity, and any other agent that can WebFetch + execute work with the same URL. The agent fetches the prompt, reads a manifest of every documented CLI command and API call across your published cohort, exercises each one against your live deployment, and writes a JSON file describing what behaved and what didn't.
Upload that file back to Git2Docs. The failures land on the validation-results page grouped by page → section. Click Tell AI on each real failure, Submit Review, Apply — the same consolidator-and-regen loop as hand-written feedback. Validator feedback and human feedback flow through the same pipeline, on purpose.
The numbers
Our first internal pilot — a customer-facing disaster- recovery product with 340+ documented CLI and API artifacts — ran the loop end-to-end:
- Initial validation pass: 43 documented-vs- actual mismatches across CLI prefix, endpoint naming, response shapes, and container / systemd unit names.
- One round of Tell AI → Submit Review → Apply — the consolidator wrote 7 component-level brief patches (including explicit "there is no
/v1/healthendpoint"-style negative assertions); the synthesizer regenerated 6 affected pages using the updated brief. - Re-validation: 1 mismatch remaining. A single stochastic slip on an examples section, fixable in another iteration.
Zero hand-editing of docs. Zero hand-editing of the AI brief. Forty-two corrections landed because the consolidator translated "the validator says this endpoint doesn't exist" into "there is no /v1/health endpoint" in the brief's component descriptions, and the synthesizer reads those component descriptions with strict authority on the next regen.
Why bring-your-own-agent
The protocol Git2Docs uses to talk to the validating agent is deliberately just two URLs: a manifest of artifacts to check, and a prompt that tells the agent how to check them. Anything that can WebFetch a URL and execute the instructions inside can be the validator.
That means you pick the agent you already use. If you have shell access from it to your deployed product, you have runtime validation. We test most thoroughly with Claude Code because that's the agent we live in; we've seen customers run the same prompt URL through Codex, Antigravity, and the JetBrains AI plugin with comparable results. Quality varies between agents — that's expected — but the protocol doesn't lock you in.
Pricing
Tell AI and runtime validation are included on every paid Git2Docs plan (Team and Enterprise) as of today. No new SKU, no per-validation pricing. The Builder plan keeps Tell AI but gates runtime validation as the upgrade reason for Team.
What's next
Two follow-ups are on the path, deliberately not rolled into this launch:
- Auto-resolve validator comments on Apply. Today the Submit Review counter still shows your validator- authored comments after Apply runs, because spec 056 keeps comment lifecycle manual by default. We'll auto- resolve validator-authored comments specifically (hand-written ones still need a manual resolve) so the counter clears the moment the regen lands.
- Direct submit from the coding agent. Right now the agent writes a JSON file you upload through the UI. Maintainer-issued ingest tokens will let the agent POST findings directly, skipping the file step entirely. We kept it manual for v1 because the review checkpoint is valuable; we'll add the direct path when the manual one is proven across enough customers.