What an assistant adds to documentation that readers already search

Why does my request fail, what is wrong with this configuration, why does it work locally and not in the pipeline. The assistant cannot run anything, cannot see the repository, and cannot reproduce the failure. It has documentation, and documentation does not contain the reader's mistake.

The useful behaviour is to answer the documented part (what the error means, what usually causes it) and be explicit that it cannot debug this case. A developer told plainly that this needs a human will take the handover. A developer given three confident wrong guesses will write about it somewhere public.

During an incident this becomes the only question on the site, and it is the one the assistant is least able to answer. It reads indexed material, so what it knows is what your status page said the last time the material was read, which during an outage is precisely the wrong thing to repeat.

Word the handling so it never asserts current availability. It should point at the status page and the incident channel rather than reporting a state, unless you have separately connected a source that carries live status.

Roadmap questions, feature requests, and will this ever work with a given runtime. Anything unshipped is undocumented, and an assistant that infers a plan from an old blog post has just committed your engineering team to a date. Route these to a person or to wherever you collect requests.

Whether a key is valid, why a quota was reduced, whether an account is being rate limited. It can explain how keys and quotas work and how to rotate one safely. It cannot look one up, and on a developer site the pull towards sounding authoritative about this is strong because everything around it is precise.

An answer drawn from documentation for a release the reader is not running is worse than no answer, because it is plausible, specific and wrong in a way that costs an afternoon. This is the one failure mode unique to this trade, and it is almost entirely a content problem rather than a model problem.

The mitigations are practical. Keep versioned documentation on distinct paths so the distinction survives indexing, drop archived versions out of the index rather than leaving them to compete, and raise the caution setting so a weak match refuses instead of reaching into an old page.

A snippet assembled from a plausible reading of an API is the most dangerous output an assistant can produce on this kind of site, because it looks exactly like a snippet copied from documentation and it goes straight into an editor.

The setting that governs this is caution: cautious behaviour returns the documented example with its citation rather than adapting it to the reader's situation. Every answer carries numbered citations back to the source page, which on a docs site is not decoration, it is how the reader checks which version the code came from before trusting it.

Technical documentation is written in the imperative mood. Run this, set that, ignore the previous step, disable verification for local testing. Some of it sits inside code blocks, some inside comments in sample configuration, and some arrives from pages a crawl picked up along the way.

Retrieved material is treated strictly as data rather than as commands, so a page containing something that reads like an instruction is quoted rather than obeyed. On a documentation corpus that distinction is not theoretical, it is a property you need holding on every page you index.