The Hardest Part to Give Up
This year’s State of Docs report found that seventy-six percent of documentation practitioners now use AI regularly—up sixteen points in a single year. And the people who produce the most documentation, technical writers, report some of the smallest time savings of any role in the survey.
One writer said the quiet part out loud: “it’s often faster for me to just do the thing than it is to try to tell an AI to do the thing for me.”
That sounds familiar. It’s how I felt when I first started fine-tuning prompts to do technical writing tasks. But I don’t feel that way anymore. So what are those 76% of respondents missing?
You Can’t Go Half Way
A productivity gain is a ratio, and you only ever get to see your own denominator.
If you’re an engineer who’s spent a decade dodging release notes—who opens the template and feels a specific kind of dread—AI is a miracle. Four hours of misery become twenty minutes of editing. That’s a real gain, and you feel every point of it.
If you’re a writer who could already draft those notes in forty minutes, you get maybe a twenty percent boost, and less once you count the time spent specifying, reading, and un-hallucinating. Another writer put a number on the gap between the demo and the desk: “When you try it, it looks like you should be getting these 500% efficiency gains, and then when it actually comes down to it, it’s maybe like 20%.”
Same tool, roughly the same output, a completely different experience of using it—and the difference is almost entirely about where each person started.
Prompt-Level Thinking Is a Trap
That writer I quoted at the top is right, by the way. It probably is faster for them to just do the thing than to explain the thing to an LLM carefully enough to get a good output. But look at the shape of the sentence—it takes for granted that the unit of work is a single task, done once, by prompting. Draft this release note. Rewrite that section. Tighten this paragraph. Do that a few hundred times a quarter and of course the twenty percent barely registers. You’re doing the old job with extra steps.
The ceiling writers keep hitting is the ceiling of the task, not the tool.
The gain isn’t hiding in a better prompt. It’s one level up, in the thing most writers haven’t been given the time—or the compensation—to build.
The Weeks You Spend Once
Technical writers are being told “use AI” and looking at the work in front of them. So they start prompting the AI to do that work. But looking at the To-Do list is the wrong place to start.
Instead, they should be building the thing that does the work: a pipeline that reads the style guide, watches Jira for what shipped, pulls context from the CMS, runs its own QA pass, and opens a GitHub PR for a human to review. You spend a week (or two… or six!) building that once. But once that’s built, you stop spending twenty minutes prompting for something you could’ve written yourself in twenty minutes—because you’ve stopped prompting. The work week goes to refining the automation, doing the editorial that actually needs a person, and finding the next thing worth building.
One writer renamed six hundred files across an information architecture in an afternoon—six days of work, gone. Another built a QA loop that caught a third-party permission model the docs had been describing wrong for who knows how long. Neither of those is writing. Both of them are the job now.
That trade—going from content creator to content engineer—asks you to give something up, and it isn’t the writing, exactly. It’s the title. “Writer” names the smallest part of the work and, sometimes, the hardest part to give up. The real efficiency lives in owning the pipeline, and owning a pipeline doesn’t feel like writing—it feels like operations, or systems design, which is a weird thing to reach for if “writer” is the word you built a career around.
It’s hard to build any of this inside an established company, where process is load-bearing and nobody is looking to mess with a system. In a young or fast-growing one, it’s close to the whole point—the process doesn’t exist yet, and someone has to be the person who builds it instead of the person who keeps feeding it by hand.
The Wrong (If Not Understandable) Takeaway
None of this would matter much if the people getting the most visible gains weren’t also the people who decide whether documentation gets funded.
A VP who has never written a doc in their life now produces a passable one in a chat window and lands on an entirely reasonable conclusion: huh, that was easy. And they’re right. It was easy—at the level she was working, which is the only level they’ve ever had to see. The trouble is the next thought, the one that arrives so smoothly it doesn’t feel like a leap: so the writing must have been easy all along. And if the writing was the whole job, then the whole job just got easy.
One writer described what that does to your calendar: “People’s expectations of tech writers have shifted—’this should be faster because of AI, so why aren’t you being faster? Let me load more stuff on you.’”
The small gain on the writing doesn’t get read as evidence you were already good at it. It reads as resistance.
Some of that resistance is real. Just not the kind anyone means. It isn’t that these writers won’t work faster—it’s that a lot of them are stuck, prompting through the same tasks one at a time, inside organizations that were never going to hand them the time and support it takes to build something better. When I read those quotes now, that’s mostly what I hear: not people who’ve found the ceiling of what AI can do, but people who’d build the better thing tomorrow if anyone let them.
And some of it, honestly, is pride. A lot of us don’t want to give up the writing. It’s the part we’re good at; for plenty of people it’s the reason they took the job at all. I’d miss it too.
I just don’t think it’s the part the job is going to keep asking for. And it might be a sink or swim moment for many writers.
Need someone to build the thing that does the work?
That's the trade I already made—content creator to content engineer. If your documentation still runs on someone prompting through a to-do list, let's talk.
Get in touch