Two Loops, One Sprint: Keeping Docs at the Pace of Code
What happens when your software developers bolt on twin turbochargers while the documentation team is still trying to get the lawnmower engine started.
On the 31st of March 2026, the Cloud NAT team announced what they clearly believed was a tiny, harmless little tweak. The default TCP TIME_WAIT timeout was being dropped from 120 seconds down to 30 for brand-new gateways1. To a programmer, that is trivial. It is one constant. It requires about four calories of physical effort and takes less time than sneezing. In the documentation, however, this solitary flick of the wrist detonated four separate sections across the manual: the timeout reference table, the policy governing which gateways inherit which number, the terminal incantation to verify the live setting, and the cautionary guidance warning engineers not to reduce it any further unless they enjoy chaos2.
Someone with a pulse had to spot the pull request, decipher the diff, hunt down every last mention of the obsolete number across a sprawling labyrinth of markdown, and rewrite the whole lot. That is the daily grind of a technical writer. Up until now, it has worked. Just. The docs usually cross the finish line alongside the code.
Except now there is a snag. A rather substantial one. Software engineers have discovered generative AI. Today, more than a quarter of all new code checked into Google’s repositories is spat out by silicon before a human engineer even glances at it3. The 2025 DORA report noted that a staggering 90% of development professionals are now leaning on AI, happily driving software delivery throughput straight through the roof4. The code side of the business has just dropped into sixth gear, mashed the throttle, and engaged nitrous. Meanwhile, the documentation department is still pedalling an ancient bicycle up a very steep hill.
Which brings us to this: a design I call the Autonomous Author5. It is an agentic system engineered to catch code the precise second it merges, compile a clean first-draft documentation PR, test every single factual statement against the source code with forensic brutality, and present it neatly on a silver platter to a human writer. We shall inspect this contraption through two lenses—first the writer’s, then the developer’s. And then we shall look at the cold, hard numbers for the enterprise, laying out every assumption for inspection.
On the two loops
Anyone who has spent ten minutes near an enterprise engineering board knows the standard DevOps loop: plan, code, build, test, release, deploy, operate, monitor, and back round we go. "Docs as code" is the sensible idea that documentation ought to live in the same Git repositories, endure the same linters, suffer the same pull requests, and survive the same automated CI pipelines as the software itself7. In theory, both loops run in tandem. Figure 1 shows how that looks in the real world.
Cast your eye over the stages. Build, test, release, deploy—all of these hum along smoothly inside automated CI pipelines. But then you hit the dashed line: Write. And suddenly modern computing grinds to a dead halt. Because Write is not automated at all. Write is an actual human being sitting in an office chair, squinting at an arcane Git diff, and wondering what on earth the developers have done now. And because Write is manual, it determines the maximum top speed of the entire enterprise machinery.
| Stage | Code loop | Docs loop | Where they meet |
|---|---|---|---|
| Plan | Epic and sprint planning | Doc kickoff, Jira doc ticket | same epic |
| Code / Write | Engineers, with AI help | Writers, by hand | merge starts docs work |
| Test | Does the code work? | Is the text true and usable? | same CI |
| Release, deploy | Rollouts and rollback | Publish a docs version | same release tag |
| Monitor | Errors and incidents | Broken links, support cases | shared support signal |
On writers and drafts
On the Write arc
Figure 2 illustrates the administrative purgatory required for a single, modest code change. None of the individual steps requires a degree in rocket science. The trouble is that this whole cumbersome exercise must be repeated for every single merge in the sprint. Worse still, finding which pages need changing relies entirely on keyword searches and personal memory—a method with all the structural reliability of a chocolate suspension arm.
Consider the TIME_WAIT change again. The critical rule—that this 30-second default applied exclusively to gateways deployed after the 30th of September 20262—did not exist in the code commit anywhere. Not a shred of it. A writer looking purely at the diff has two choices: miss the nuance entirely, or make an educated guess. In enterprise production networking, guessing is a brilliant way to bring down half the internet on a Tuesday afternoon.
On the waiting draft
With the Autonomous Author fitted to your workflow, the moment an engineer merges their code, the machine springs into action. Barely five minutes later, a fully formed documentation PR appears on GitHub, carrying three rather clever features: