The prediction was that AI would make technical writers unnecessary.
A few years in, that hasn’t happened.
What has happened is that the slow parts of the job got considerably faster.
Research, note taking, first drafts, restructuring, and reformatting.
All of that used to take hours.
Now it takes minutes, which is a real change worth being honest about.
The part that hasn’t shifted is knowing what good documentation looks like in the first place.
🎙️ Where it genuinely saves time
The clearest gain is turning raw input into something usable.
A 50 minute SME session used to mean an hour of listening back, then another hour writing it up.
Now the transcript comes out automatically, so the summary takes a couple of minutes.
Some of the places it earns its keep.
- Meeting notes, transcripts, turned into structured summaries
- Pulling requirements or process steps out of a long recording
- First drafts of procedures, quick reference guides, and release notes
- Restructuring an existing document into a different format
- Checking terminology is used consistently across 40 pages
- Generating a first pass at an FAQ from support ticket data
None of that output is finished.
All of it saves you starting from nothing, which is where most of the time goes.
✍️ Prompting is where the quality comes from
A generic prompt gives you generic documentation.
The output improves enormously once you’re specific about style, audience.
I usually specify the Microsoft Manual of Style for technical publications, then tailor it to whoever’s reading.
A few things worth putting in the prompt.
- The style guide you’re writing to
- The audience, including their technical level, what they already know
- The document type, since a work instruction behaves differently to a reference guide
- Voice, tense, usually second person present tense for procedures
- Any terminology the organisation insists on
- Length constraints, otherwise you’ll get 6 pages for a 3 step task
The difference between a lazy prompt versus a considered one is roughly the difference between a first year draft, a competent one.
That’s a skill in itself, a technical writing skill rather than a technology skill.
🔍 Verification is still the job
Here’s the part people underestimate.
AI produces text that reads confidently whether or not it’s correct.
Which means someone has to check it against reality.
The things that regularly need fixing.
- Steps that sound plausible but don’t match the actual interface
- Field names that have been guessed rather than confirmed
- Missing prerequisites, because the model doesn’t know what access the user has
- Exceptions left out entirely, since transcripts rarely cover them
- Terminology that’s technically correct but not what this organisation uses
- A logical order that reads well yet doesn’t match how the system behaves
You can only catch those if you know the product, the audience, and what a good procedure is meant to do.
That’s experience, which doesn’t come out of a prompt.
🧭 Judgement is the part that doesn’t automate
Drafting is maybe 30% of technical writing.
The rest is decisions.
Deciding what to leave out.
Deciding whether something needs a screenshot or would be clearer without one.
Deciding that a 5 page procedure is actually telling you the interface is wrong, not that the writer needs to try harder.
Knowing when to push back on an SME who’s describing the process they wish existed.
Working out the information architecture so somebody can find the answer while a customer is waiting.
None of that is drafting.
All of it determines whether the documentation gets used.
📋 A workflow that works
The approach I’ve settled into looks roughly like this.
- Record the SME session, then get a transcript
- Summarise the transcript into structured notes, checking them against what I heard
- Draft in the target style with a properly specified prompt
- Rewrite the draft myself, because the first version is a starting point rather than an answer
- Verify every step against the actual system
- Send it for SME review with only the uncertain sections highlighted
- Publish it somewhere people can find it, with an owner plus a review date
The AI part sits in the middle.
The parts either side, gathering accurate information, then making sure it lands with the reader, are still where the value is.
✅ What this means for the role
Technical writing hasn’t become obsolete.
It’s become less about production, more about judgement.
Which is arguably what it always should have been.
If your value was typing up what an SME told you, that value has dropped.
If your value is knowing what the user needs, getting the truth out of busy people, and making complex things simple, that’s held up fine.
The tooling changed.
The underlying skill didn’t.
About the author
Aiver is the managing consultant at Aliso Digital, an IT consultancy based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs spanning ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design.
He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services — on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
