If AI generates the docs from the code, is the technical writer the writing or the ownership of whether the docs are true?

The shift

Turning a codebase, an API surface, or a feature spec into fluent, well-structured, correctly-formatted documentation goes from scarce (a skilled writer's hours) to abundant and near-instant. What stays scarce is knowing whether the generated doc is actually true against a shipping product — something a model can produce with total confidence and no ability to vouch for.

The axioms

• A technical writer's core skill is turning complex systems into clear prose. Rests on drafting-and-explaining competence being scarce and slow to acquire.
• Docs are hard to keep in sync with the product; drift is the chronic failure mode. Rests on the manual labor of re-writing docs after every code change being expensive.
• Good docs require someone who can hold the whole information architecture in their head — what to document, where, at what depth. Rests on structural judgment about a large surface being scarce.
• A writer must understand the product deeply enough to explain it correctly. Rests on product understanding being the input that made the prose trustworthy.
• The deliverable is the doc set — the pages that ship. Rests on the artifact being the scarce output the role is measured on.
• Published docs carry an implicit warranty: someone checked this is how the product actually behaves. Rests on accountability for accuracy being tied to the human who wrote and reviewed it.
• Fluent, well-organized documentation signals it was produced by someone who knew the material. Rests on the cost of producing correct-looking docs being high enough that fluency implied competence.
• Documentation volume is capped by writer hours, so teams triage what gets documented. Rests on production capacity being bound to headcount.

Invalid axioms

1. A technical writer's core skill is turning complex systems into clear prose. Given the code, a spec, or a diff, a model now produces clear, correctly-structured, on-brand documentation instantly. The explaining-and-drafting craft that gated who could produce a usable doc is commoditized. Habit-trap: hiring, leveling, and self-image still treat "writes clean technical prose" as the scarce credential, when it's now the floor a model clears by default.
2. Docs are hard to keep in sync with the product; drift is the chronic failure mode. Regenerating docs from the current code on every change is cheap, so mechanical staleness stops being the hard problem. Habit-trap: teams still budget quarterly "doc refresh" sprints and treat drift as an unavoidable tax, when the expensive part is no longer re-writing — it's confirming the regenerated version is correct.
3. The deliverable is the doc set — the pages that ship. When pages are near-free to produce, shipping more of them is no achievement. Habit-trap: output metrics — pages published, articles closed, coverage percentage — still measure the role by volume of prose, when volume just stopped being the constraint.
4. Documentation volume is capped by writer hours, so teams triage what gets documented. Coverage is no longer gated by how many hours a writer has; the whole surface can be documented at once. Habit-trap: roadmaps still ration doc coverage as if each page cost a day, and staff the function to the old capacity ceiling.
5. Fluent, well-organized documentation signals it was produced by someone who knew the material. Fluency and structure are now free and decoupled from understanding — a model writes an authoritative-sounding page about behavior it never verified. Habit-trap: reviewers and readers still read polish as a proxy for correctness, exactly the signal that no longer holds.

Unchanged axioms

1. Published docs carry an implicit warranty that someone checked this is how the product actually behaves. A model can generate a doc that is fluent, plausible, internally consistent, and wrong — describing a flag that was renamed, an endpoint that now returns a different shape, a default that changed last sprint. It cannot be accountable for the gap between what it wrote and what ships. Someone answerable must own that the doc is true, and that ownership didn't get cheaper because drafting did.
2. A writer must understand the product deeply enough to catch a confident-wrong doc. The scarce input flipped from "understand it well enough to explain it" to "understand it well enough to notice the generated explanation is subtly false." Spotting that the AI documented the intended behavior rather than the shipped behavior is a verification act against ground truth, not a pattern-match — and it requires knowing the product, not just reading the doc.
3. Someone must own the information architecture — what to document, where, at what depth, for whom. A model fills a structure fluently; deciding the structure — which concepts are load-bearing, what a specific audience needs, what to cut so the important thing is findable — is judgment about readers and goals, not text generation. This gets more valuable as generation gets cheaper, because more plausible pages make findability and hierarchy harder, not easier.

New axioms

1. A flood of plausible docs that are subtly wrong, at a volume verification can't keep up with. When the whole surface can be regenerated in an afternoon, the correctness-checking capacity doesn't scale with it — and confidently-wrong pages are the model's default failure mode. The bottleneck moves from producing coverage to verifying it, and nobody has sized the verification function to the new production rate.
2. Who owns doc-truth when no human wrote the doc by hand. The old warranty rode on authorship: the person who wrote it had, in the writing, checked it. When generation and authorship split, accountability for "this is accurate" needs a new owner explicitly assigned — reviewer, curator, whoever signs off — because it no longer comes bundled with the act of writing.
3. How readers and teams tell a verified doc from a generated-but-unchecked one. Polish stopped signaling correctness, so both readers and the teams shipping docs lose the cue they leaned on. There's no settled provenance marker for "a human confirmed this against the running product," and without one, every fluent page is trusted equally regardless of whether anyone checked it.
4. Keeping regenerated docs anchored to shipped behavior, not intended behavior. A model trained on the spec and the code will happily document what the system is supposed to do; the doc's value depends on it describing what the system actually does after the bug, the hotfix, the config drift. Closing that gap at regeneration scale is an open verification problem, and it's the one most likely to move fast as models get better at reading live systems and running them.

Where it breaks

Teams are leaning into "regenerate the whole doc set from the code, ship more coverage faster" now that drafting is free (INVALID: pages-as-the-deliverable and volume-as-the-metric stopped being the constraint) at the same moment the verification function is unstaffed and unnamed (NEW: a flood of plausible-but-wrong docs nobody has capacity to check). More coverage compounds the truth deficit it was meant to close — every unverified page reads as authoritative as a checked one.

Second collision: the role is being downleveled or cut because "the AI writes the docs now" (INVALID habit — prose competence read as the scarce skill) exactly as the thing that made docs trustworthy — a person who knew the product well enough to catch a confident-wrong page and answer for it — becomes the scarce input (STILL HOLDS: accountability and product-deep verification). The org removes the person right when their remaining function stops being writing and starts being the only thing keeping the generated docs honest.

ai-axioms.vercel.app/axioms/media/technical-writer-ai-axioms