Documentation as code started as a reaction to docs living in a disconnected wiki, edited by whoever remembered, with no history and no review process. The fix was to treat docs like source: version controlled, written in plain text, reviewed through the same pull-request workflow as code.
That solved the ownership and history problem. It did not solve the harder problem: someone still has to notice a change happened and write about it.
Direct answer
Documentation as code is the practice of managing documentation the way you manage software: stored in version control, written in plain text formats like markdown, and updated through pull requests with review and history, instead of living in a disconnected wiki or CMS. The original version still requires a human to write every update by hand; it just gives that update better tooling. A natural extension of the same idea is generating the documentation update directly from the code change that prompted it, closing the gap between "docs live near code" and "docs are derived from code."
What the original practice actually fixed
- Version history: every change to a doc is tracked, same as code.
- Review process: doc changes go through pull requests, catching errors before publish.
- Proximity to code: docs often live in the same repo as the feature they describe, reducing the chance they get forgotten entirely.
- Plain text: markdown or similar formats are diffable and mergeable, unlike a rich-text CMS.
All of this improves how documentation is stored and reviewed. None of it automatically ensures someone actually writes the update when the product changes.
The gap it leaves open
Storing docs next to code makes it easier to update them together, but easier is not automatic. A pull request that changes behavior does not require a matching doc change unless a human remembers to add one, which is the same discipline problem documentation as code was never designed to solve on its own.
The natural extension: docs derived from the diff
If code and docs already live close together and go through the same review process, the next step is generating the documentation change from the code change directly, rather than expecting a human to write both. That keeps the version control and review benefits of documentation as code, while removing the dependency on someone remembering to also write the docs half of the PR.
Frequently asked questions
Is documentation as code the same as auto-generated documentation?
Not by default. The original practice is about where docs live and how they're reviewed, plain text, version controlled, pull-request based. Auto-generating the content from code changes is a separate, newer idea often layered on top of it.
Does documentation as code guarantee docs stay current?
No. It improves tooling and history, but a human still has to write the update in the traditional practice. Docs can still drift if nobody adds the doc change to the PR.
Do I need my help center in the same repo as my code for this?
No. The underlying idea, generating updates from the diff, works whether your help center content lives in the code repo, a separate CMS, or a hosted platform, as long as something is watching the repo for changes.
Conclusion
- Documentation as code fixed how docs are stored and reviewed, not whether they get written.
- The gap it leaves is the same one manual documentation always had: someone has to remember.
- Generating docs from the diff itself is the natural next step.
- See how DocsKoala works, or check pricing to try it.