Originally published at netgain-systems.com
The first software job AI killed wasn't the developer.
It was the technical writer.
Think about what that role actually was. Someone who walked the floors, interviewed engineers, pieced together half-explanations across hallway conversations and JIRA tickets, then went away for two weeks to produce a 30-page guide that engineers would read and quietly say "mostly right".
That role had a structural flaw, and we all knew it. The technical writer was always working from a translation, never from the source. The further from the code they were, the more polished the prose; the more polished the prose, the more confidently wrong it could become.
Now ask AI to read the code
Just the code. The actual source. The configuration files. The error messages it emits. The test cases. The build logs.
Five minutes of prompt tuning later, what comes back is more accurate, more current, and more complete than anything a human writer has ever produced for me.
That's not because AI is brilliant. It's because the source code was always the truth, and now we have a translator that reads the truth directly instead of reading a human's interpretation of someone else's interpretation.
The bottleneck moved.
What we did at NetGain
We rebuilt all of NetGain's product documentation this way. You can see it live:
Every page is AI-drafted from the actual code, the actual product behaviour, the actual configuration surface. A human engineer then reviews — for tone, for what to leave out, for what to emphasize, for the things a customer needs to know that the code itself can't surface (history, design intent, common pitfalls).
The bottleneck moved from writing the doc to reviewing what AI wrote. One engineer now keeps an entire product's documentation current while continuing to ship features.
The honest math
Old way: 1 dedicated technical writer + 6 weeks per release cycle = stale documentation on launch day, full rewrite each major version, knowledge loss every time someone leaves.
New way: AI drafts in minutes from the current source. Engineer reviews in an hour. Docs ship with the build. No translation layer. No knowledge loss.
The cost difference isn't 2x or 5x. It's structural. The role of secondhand-information-translator-into-polished-prose has no economic basis once a tool can read the source directly.
Where I'd love to be wrong
I genuinely don't know if anyone is still hiring full-time technical writers in 2026. If you are, I want to understand the case — not to argue, but because I might be missing something.
Possibilities I've considered:
- Compliance-grade documentation (FDA, aerospace, defence) where the author needs to swear by every word. Maybe. Though even there, AI-drafted + human-attested feels like it would dominate.
- Product marketing copy disguised as docs. Different role.
- Domain experts who happen to write. Not really technical writers — those are subject matter experts who write.
What I don't see anymore: the pure "interview engineers, produce docs" workflow. That role has no defensible moat.
This isn't an "AI replaces jobs" rant
This is a "the role had a structural flaw and AI just removed the flaw" observation. Every role with a similar structure — a human translation layer between the source of truth and the consumer of that truth — is on the same trajectory.
Software engineers, you're on a longer timeline but the same list. The structural flaws in your role are getting exposed too. That's another post.
For now, take a look at docs.netgain-systems.com and tell me where the human writer would have done it better.
More from NetGain Systems:
- docs.netgain-systems.com — our AI-drafted, human-reviewed product documentation
- www.netgain-systems.com/blog — more posts on AI, observability, and engineering
Top comments (0)