Doc-as-Code
A documentation philosophy that treats docs the same way as code: stored in version control, written in plain text, reviewed in pull requests, deployed via CI. Specsight goes one step further and derives docs from code itself.
Doc-as-code is the modern engineering discipline's answer to wiki sprawl. Documentation is treated as a first-class engineering artefact: stored next to the code in Git, written in Markdown or MDX, reviewed in pull requests, deployed automatically via CI. The result is documentation that engineers actually want to maintain, because it lives in their workflow rather than in a separate tool.
Doc-as-code is a meaningful improvement over wiki-based documentation — but it doesn't, by itself, solve the drift problem. The docs still have to be written by humans, and humans still have to remember to update them when the code changes. The format is better. The discipline is better. The structural problem is the same: the link between code and docs is human, and human links break.
Specsight is the next step beyond doc-as-code: instead of treating docs like code, it derives docs from code. The spec is generated from the codebase on every release — there's no markdown file to update, no PR to review, no engineer to remember. The doc is no longer parallel to the code; it's downstream of it.
Related Terms
Documentation that is structurally incapable of falling out of sync with the product, because it is derived from the code rather than written separately.
The gradual divergence between written documentation and the product it describes. Different framing of the same problem as specification drift, more common in everyday usage.
A written description of how a product behaves — feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.