AI doesn't replace tech writers — it gives them leverage
There is a version of the AI narrative that goes like this: AI writes content, therefore writers are obsolete. After a few months of building AI deeply into my daily workflow (from early experiments in October 2025 to a three-layer OpenCode architecture with 30+ custom commands, agents and skills), that has not been my experience. Not because AI is not capable, but because it fundamentally misunderstands what tech writers do.
Here is what actually happened when I gave AI an increasing role in my work, what changed, and what stayed exactly the same.
What my day used to look like
Before I started building AI tools, a typical documentation ticket went through a predictable sequence:
- Open the ticket. Read the description. Read all the comments, sometimes a dozen back-and-forth messages between PMs, engineers, and support.
- Try to identify what's being asked when tickets have no information, which sometimes meant searching for clues in chat threads with hundreds of messages.
- Search the internal wiki for related documents: PRDs, architecture docs, engineering notes. Some are somewhat easy to find. Some are buried in spaces with titles that do not match what you are looking for. All of them are hard if there is no information in the ticket because the wiki's search function is less than great.
- Check what documentation already exists. Open the docs site, navigate to the product area, read through existing pages to understand the current state. Figure out which pages need updating versus which gaps need new content.
- Identify reviewers. Who knows this feature? Who wrote the original docs? Who filed the ticket?
- Now write.
Steps 1 through 5 could take anywhere from a few hours to a few days, depending on the scope. For a cross-product ticket that asked me to compare an internal training course against hundreds of existing documentation pages, the research alone could easily take a week or more.
The actual writing was often the fastest part.
What my day looks like now
Here is a real day from my work log. I was working on a ticket that required comparing a training course against existing documentation to find content gaps. The research phase, spread across a few sessions between other tasks, used my /research command three times. Each session took a few minutes. The command pulled the ticket with all its comments, searched the wiki and found the training course and related architecture docs, mapped existing documentation pages, and identified stakeholders. Total AI processing time across all three sessions: roughly 60 minutes.
When I sat down to write, I had a structured research brief in front of me. I could see the gaps between what the training course taught and what our docs covered. The biggest gap was clear: there was no conceptual page explaining why a customer would use this particular product capability. Our docs explained how to configure things, but not what problem the feature solves.
By the end of the next morning, the page was written, reviewed, and merged. Six existing pages were updated with cross-links. Three follow-up tickets were created for remaining gaps. The ticket was closed.
Days of research, compressed to about an hour of AI processing and a morning of focused writing.
But here is what the AI did not do
The AI did not decide that the missing page should be a conceptual page rather than a how-to guide. I made that call based on understanding what a customer evaluating the product needs: context and framing, not another configuration walkthrough.
The AI did not notice that its first draft assumed readers already understood the domain terminology. I caught that because I know our audience includes engineers evaluating the product for the first time, but might also include decision makers who don't have deep technical knowledge.
The AI did not know that its brief language was drifting toward marketing copy, using phrases like "revolutionize your network" and "seamless integration." Developer docs need to be precise and factual, not promotional.
The AI did not decide which of the five content gaps to prioritize. I chose based on what the ticket was asking for and what would be most useful to customers right now, then created follow-up tickets for the rest.
The AI did not coordinate with the product manager. It did not decide when to loop in the subject-matter expert for review. It did not know that the product naming had changed the week before and that all the URLs in the research brief needed re-checking.
Every one of those decisions required judgment that comes from knowing the product, knowing the audience, and knowing the team.
What changed about the job
Here is a concrete comparison of where my time goes now versus five months ago:
| Task | Before | Now |
|---|---|---|
| Researching a ticket | 2-3 days of manual context-gathering or more | ~60 min AI processing + review |
| Scaffolding a new page | ~30 min setting up content type, frontmatter, imports | ~5 min via /draft |
| Product rename across docs | 2-3 weeks estimated | 3 days for 695 files across 4 products |
| Image audit | Rarely done (too many to review manually) | Routine via /check-images |
| Style guide review | Inconsistent, reviewer-dependent | Systematic via /review-doc |
The pattern is clear: the AI absorbed the mechanical parts of the job. The fetching, the scaffolding, the formatting, the searching, the bulk editing. These are tasks that require effort but not expertise. They are necessary but not creative. And they used to consume most of my time.
What I do more of now is the part that actually requires a tech writer: deciding what to write, how to frame it, what the customer needs to understand, and what order to present information in. I spend more time on editorial judgment and less time on logistics.
This is not a reduction in skill. It is a shift in where skill gets applied.
The multiplication math
Let me put specific numbers on this.
In a recent three-week period, my work log shows: 12 PRs authored and merged in the docs repo, 8 PRs reviewed, 6 tickets closed, 3 follow-up tickets created, 7 merge requests for the command tooling, and regular meetings and reviews on top of that.
In a comparable three-week period before the AI tooling, my output was noticeably lower. Not because I was working less, but because the research and setup phases consumed more of each day.
The quality has not dropped. If anything, the AI's systematic style checks catch things that manual review sometimes misses. The PRs still go through human review. The stakeholders still validate the content. The only thing that changed is how quickly I get to the point where meaningful human review can happen.
This is what I mean by force multiplier. The same writer, with the same product knowledge and the same editorial standards, producing more output at the same quality. The AI did not replace the expertise; it gave the expertise more surface area to operate on.
What the AI will (probably) never understand
There is a deeper point here that goes beyond productivity metrics.
Tech writing is not content generation. It's talking to stakeholders about the feature or product, and trying to understand it. It's converting engineer-speak to something that's useful for customers and they can understand. It is customer empathy expressed through documentation. When I write a decision page (the page that helps a customer figure out which product they need before they start configuring anything), the value is not in the words on the page. The value is in understanding that the customer doesn't know about everything the product offers, and that this might cause them to make wrong decisions that cost them time and support tickets.
The AI can write clear sentences. It can follow a style guide. It can scaffold a page structure. But it does not know what it's like to be an engineer staring at five different options wondering which one to pick. That understanding comes from reading support tickets, talking to solutions architects, sitting in product meetings, and paying attention to where customers struggle.
Every command I built encodes a human decision about what matters. The /research command exists because I recognized that the research phase was the bottleneck. The /escalation-gaps command exists because there are too many support tickets to go through manually. Automating that search lets me find patterns and see where customers are struggling the most, so I can decide what to tackle first. The discovery system exists because I noticed that a growing toolkit creates its own discoverability problem. None of those insights came from the AI. They came from doing the work and paying attention to the friction.
Personal insights on AI
If someone asks me whether AI is going to replace tech writers, here is what I have observed over five months:
The AI made me faster at things I was already good at. It did not teach me what to write. It did not give me product knowledge I did not have. It did not build relationships with PMs and engineers on my behalf. It took the slowest, most tedious parts of my workflow and compressed them.
The writers who benefit most from AI are the ones who already have strong judgment. If you know your product well, AI amplifies that knowledge across more documentation faster. If you understand your audience, AI helps you reach them sooner. If you have good editorial instincts, AI gives you more time to apply them.
The biggest gain is getting time back for the work that matters. When you spend less time on the mechanical parts (searching, scaffolding, formatting), you get more time for the parts that only you can do: understanding the product, talking to stakeholders, and making editorial decisions. That is time well spent, and AI can help you get more of it.
The bottom line
After a three-layer AI system, 30+ commands, hundreds of docs pages, and five months of daily use, my conclusion is straightforward: AI is the best research assistant and mechanical executor I have ever worked with. It is a terrible editorial director, though. It has no customer empathy. It does not understand organizational context. It cannot tell when a page needs to exist versus when it does not.
Tech writers who learn to use AI as a force multiplier, offloading the mechanical work so they can focus on the judgment calls, will produce more, better documentation in less time. The job does not get smaller. It gets more focused on the parts that matter most.
The expertise was never in the typing. It was in knowing what to type.