There’s a line I keep coming back to when people ask whether AI is a threat to technical writing.
Producing text has become cheap.
Deciding whether that text is right, whether it’s needed at all, whether it’s in the right place, has not.
Those were always different skills.
They just used to arrive bundled together, because the person producing the words was necessarily the person thinking about them.
Now they’ve come apart, which changes what an experienced writer should spend their day doing.
⚖️ What judgement actually means here
Judgement sounds vague until you list what it covers.
On a typical documentation job, these are the calls somebody has to make.
- Whether this needs documenting at all, or whether it’s telling you the interface is wrong
- What to leave out, which is harder than what to include
- Whether the SME is describing the real process or the one they wish existed
- Which 20 procedures matter for go live, which can wait until month 2
- Whether a screenshot helps, or whether it just dates the document
- Where this lives so someone finds it while a customer is waiting
- Whether the reader is under pressure, distracted, or unfamiliar with the terminology
None of those are writing decisions.
All of them determine whether the writing gets used.
A tool can produce a competent procedure for any of them.
It can’t tell you the procedure shouldn’t exist.
🧠 Why generation being cheap changes the day
When drafting took most of the week, strategy work got squeezed into whatever was left.
Which is why most documentation sets are a collection of documents rather than a system.
Each one was requested, written, published, then nobody had capacity to think about the whole.
The economics have shifted.
Producing a draft procedure takes minutes, so the time that used to go into production can go into decisions.
What that looks like on a program.
- Working out the structure of the whole set before writing anything
- Auditing what already exists, rather than adding to a pile nobody’s read
- Agreeing where documents live, who owns them after handover
- Sequencing the work so day 1 critical material comes first
- Spending real time with SMEs instead of rushing 1 conversation
That last one is where accuracy comes from, so it deserves the hours.
🔍 Verification is judgement too
There’s a misconception that checking AI output is clerical work.
It isn’t, or at least it shouldn’t be.
Reading a generated procedure properly means asking a series of questions only experience answers.
- Does this step match what the system actually does, or what it plausibly does?
- Is the field name real, or has it been inferred from context?
- Are the prerequisites complete, given what access this user has?
- Has an exception been dropped because it only came up once in the transcript?
- Is the terminology what this organisation uses, or generic industry wording?
- Does the order match the system behaviour, or just read well?
Text that reads confidently is harder to check than text that reads awkwardly, because nothing signals a problem.
So verification takes more concentration than transcription ever did, which is exactly why you want capacity available for it.
🎯 Where the strategy time goes
If drafting is faster, the honest question is what fills the gap.
The wrong answer is more documents.
Volume was never the problem.
Some better uses.
Documentation strategy.
What are we writing, what aren’t we, who owns it in 12 months, how does it get updated when the system changes.
Information architecture.
How 200 documents relate to each other, how someone searches under pressure, what the naming convention is.
Stakeholder work.
Building the relationships that get you honest answers, which is a slow business that doesn’t compress.
Feedback loops.
Actually finding out whether the documentation is being used, then fixing what isn’t working.
Pushing back.
Telling a program that a 5 page procedure is evidence of a design problem, not a writing problem.
That last one takes standing, which comes from having done the work long enough to be believed.
🤝 The pairing that works
The split I’ve settled into is fairly simple.
The tool handles volume, structure drafts, first passes, mechanical editing.
The writer handles accuracy, priorities, the reader, everything to do with what should exist in the first place.
That works well, provided nobody confuses the 2.
The failure mode isn’t AI writing bad documentation.
It’s an inexperienced person publishing plausible documentation without knowing what to check for.
Which means the value of an experienced writer has gone up, not down, since they’re now the only quality control in the process.
✅ Where it leaves the profession
Technical writing is becoming less about production, more about decisions.
That’s a better version of the job, honestly.
The frustrating part was always spending your week formatting and reformatting while the structural problems went unaddressed.
There’s room to address them now.
Generation is cheap.
Knowing what’s worth generating still isn’t.
About the author
Aiver is an IT consultant based in Melbourne.
For 19 years he’s worked on enterprise digital transformation programs across 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.
His clients have spanned government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
He has worked 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
