Documentation is a Tax on Velocity. Here's How to Stop Paying It.

The sprint ends. The code is merged. The tests are green. The release is ready.

Then someone asks: "Where are the release notes?"

This is the moment that repeats, every sprint, at every company that ships software faster than its documentation process can keep up. And most of them do. Research from Stripe found that developers spend over 17 hours a week on maintenance tasks classified as toil. A meta-study of 60+ academic papers on software quality found that documentation alone takes up 11% of developers' work hours. A 2024 developer experience report from DX and Atlassian found that 69% of developers lose at least eight hours a week to inefficiencies, with insufficient documentation as a primary cause.

Documentation is a tax on velocity. In teams that deploy multiple times a day, it compounds fast. Every release requires changelogs, API references, integration guides, and deprecation notices. When the documentation lags, support tickets spike, internal teams get blocked, and the maintenance backlog grows every sprint.

The question is not whether to pay this tax. It is whether to keep paying it manually.

The two moves that don't work

The first move is to make the engineers write it.

This burns goodwill and produces inconsistent output. Engineers are good at solving complex technical problems. Translating a commit message like fix null pointer exception in data validation into a user-facing benefit requires a different skill. When forced to do it, developers are pulled out of their flow state. Stack Overflow's 2024 developer survey found that developers spend more than 30 minutes a day searching for solutions to technical problems, a direct consequence of documentation that was written by someone who had already moved on to the next ticket. The documentation gets written. It just doesn't get written well.

The second move is to hire more technical writers.

Skilled technical writers are genuinely valuable. But scaling headcount linearly with release velocity is a losing bet. The median annual wage for a technical writer in the US was $91,670 in 2024. Hiring numbers for generalist roles are staying flat as companies face cost pressure. An elite engineering team that ships code multiple times a day will outrun any headcount model you can build.

The result is a structural gap. The code ships fast. The documentation doesn't.

What the system actually looks like

The operational pattern that works is simpler than it sounds: automate the first draft, then apply human oversight to validate and elevate it.

The raw material is already there. Engineers produce commit history, pull requests, and API definitions as a byproduct of doing their jobs. These artifacts contain almost everything needed to generate documentation. The problem is that no one has been systematically turning them into documentation.

One of Europe's largest banks ran into this directly. Engineers were required to write detailed changelogs for every merge request. In practice, most changelogs were skipped or incomplete. The process was time-consuming, the output was inconsistent, and the engineers resented it. They built an LLM-powered changelog generator that integrated directly into their CI/CD pipeline. The system generated structured changelogs from the code diffs. As engineers edited and approved the AI-generated drafts, those revisions were automatically used to improve future outputs. The documentation got done. The engineers stopped resenting it.

YugabyteDB ran into the same problem at a different scale. A single release could encompass up to 1,000 distinct changes. By extracting text from issue summaries and commit messages, and applying careful prompt engineering, they transformed technical jargon into clear, user-facing release notes. A ticket titled [#18748] CDCSDK: Change default checkpointing type to EXPLICIT while stream creating became: "Alters the default checkpoint type to EXPLICIT during stream creation, ensuring no upgrade or rollback issues." The output was not perfect. It was a first draft. That turned out to be enough.

The academic research on this is converging. A 2026 comparative study of LLMs for commit message generation found that fine-tuned models produced messages with higher semantic adequacy and clearer phrasing than zero-shot approaches. A research team at FSE 2025 introduced SmartNote, an LLM-powered tool that generates personalized release notes directly from commit history and pull request data. The pattern is consistent across the literature: AI tools reduce the time required to create documentation while maintaining quality, provided there is appropriate human oversight.

The artifacts map cleanly to documentation types. Commit history feeds changelogs and release notes. Pull requests feed feature documentation and integration guides. API definitions (OpenAPI specs, for instance) feed API reference docs that stay in sync with the code. Issue trackers feed deprecation notices and migration guides. None of this requires a new workflow. It requires connecting the workflow that already exists to a generation engine.

Where the writers go

The obvious concern is that automating first drafts eliminates the need for technical writers. The evidence points the other way.

PwC's 2025 Global AI Jobs Barometer found that workers with AI skills command an average wage premium of 56%, and that jobs are growing even in roles considered most automatable. The writers who are losing ground are the ones doing work that AI can now do faster. The writers who are gaining ground are the ones managing AI systems, refining prompts, validating output, and ensuring that the documentation that ships is accurate and on-brand.

This is not a consolation prize. It is a genuine upgrade. A technical writer who spends their day reviewing AI-generated first drafts, catching errors, and improving tone is doing higher-leverage work than one who spends their day writing first drafts from scratch. DX research found that organizations with strong documentation practices show 4 to 5 times higher productivity metrics, and that poor documentation costs a mid-sized engineering team $500K to $2M annually in lost productivity. The value of a writer who can maintain that quality bar at scale is higher, not lower.

The system works because AI is good at coverage and humans are good at judgment. AI can parse thousands of lines of code and generate a structured first draft in seconds. It eliminates the blank-page problem. It ensures that every release has a changelog, every API has a reference, every deprecation has a notice. Humans catch the cases where the AI missed the point, used the wrong tone, or described a feature in a way that would confuse the person who needs to use it. The combination produces documentation that is faster, more consistent, and more complete than either approach alone.

Anyway. The tax on velocity is optional.

Doc Holiday generates release notes, API references, and changelogs directly from your engineering workflows, connecting commit history, pull requests, and API definitions to a generation engine that produces first drafts your team can validate and ship. It gives a lean team the structure to scale documentation output without rebuilding headcount. If the problem described above sounds familiar, that is the place to start.