LO
Get told when a verified record lands on this occupation →
Technical writer / documentation engineer
Turns what a system does into something a stranger can follow — and, in the process, is usually the first person to discover the system does not make sense.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Covers product and developer documentation — guides, references, API docs, release notes. Regulated technical writing (medical devices, aviation, pharmaceutical submissions) is a different job with a different exposure, because there the document is a compliance artefact and its form is prescribed. Marketing content and general copywriting are separate occupations here.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Drafting the reference
Automating≈ Platform inferenceThe API reference, the parameter table, the release note, the changelog entry — documentation whose content is determined by the code.
This is the most exposed writing task on this site, because the source of truth is machine-readable and the output format is fixed. Generating a parameter table from a signature was already partly automated by doc generators long before models; what models added is prose that reads as if a person wrote it, which removed the last reason to have a person write it.
A reference that is generated is a reference nobody read before publishing, and the failure mode is not wrongness but plausibility: documentation that describes what the code declares rather than what it does. That gap is only found by someone using the thing, which is the task below — so automating this raises the value of that one rather than removing the job.
Actually using the thing you are documenting
Still human-led≈ Platform inferenceFollowing your own instructions on a clean machine and finding the step that was obvious to the engineer and impossible for everyone else.
The input for this task does not exist in any repository: it is the experience of being confused in a specific place. A model trained on the codebase inherits the engineer's knowledge, which is precisely the knowledge that has to be absent for the test to work — the value here comes from not knowing.
This task is the strongest argument for the occupation and the weakest in a budget meeting, because its output is an absence — support tickets that did not happen. Where documentation teams have been cut, this is the task that went first, and nothing about the technology was required for that.
Deciding what does not get written
Still human-led≈ Platform inferenceChoosing which twenty per cent of the surface area gets documented properly, and refusing the rest.
Cheap generation makes this the most valuable task rather than the least, because the constraint moved: when writing everything became possible, choosing became the whole job. Deciding what to leave out depends on knowing which users exist and what they are trying to do, which is not in the code.
Being more valuable is not the same as being recognised: documentation is usually measured by coverage, and coverage is exactly the metric that cheap generation makes meaningless. A team judged on pages published will be rewarded for abandoning this task at the moment it becomes the important one.
Getting the answer out of an engineer
Still human-led≈ Platform inferenceWorking out which of five people knows why it behaves like that, and getting fifteen minutes of their time to find out.
The information required is undocumented by definition — if it were written down, this task would not exist. Extracting it is a social act performed against somebody's calendar, and the skill is knowing which question produces the real answer rather than the official one.
This task is what makes the job hard to do remotely, part-time or from a contractor's chair — which is exactly the direction cost pressure pushes it. The threat here is not automation, it is the job being restructured into something that cannot include this task, after which the documentation degrades for reasons nobody attributes correctly.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
The highest curve in the technology group and the steepest rise of any writing occupation on this site, for a reason specific to this job: the source of truth is machine-readable and the output format is fixed, so a reference can be produced from the code itself. Doc generators had taken part of it long before models; what models added was prose that reads as if a person wrote it, which removed the last reason to have a person write it. The flattening from 2025 is the part with no mechanism — following your own instructions on a clean machine and finding the step that is impossible. A model trained on the codebase inherits exactly the knowledge that must be absent for that test to work, so the value there comes from not knowing.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The task that used to hire you — producing the reference — is the most exposed writing task on this site. The one that is now scarce is the one nobody hires for directly: being the person who does not know, follows the instructions, and finds the step that is impossible. Make that visible in how you work, because it is the only argument that survives cheap drafting.
Your team will be measured on coverage and coverage has just become free, so the metric will look excellent while the docs get worse in a way nobody can see from a dashboard. The number worth putting in front of a manager is support tickets on the top ten pages, because that is the only measure that moves when the documentation is actually good.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Become the first user, formally
The only documentation input a model cannot have is the experience of being confused, and a team shipping fast needs somebody whose job is to be confused on purpose before customers are.
It requires access to builds before release, which is a permission question rather than a skill one and often has to be won politically.
Take your most-read page, follow it on a clean machine, and count the steps that failed. Bring the number, not the opinion.
Move to documentation that is a compliance artefact
In regulated fields the document has a prescribed form and a named person attesting to it, so it is held in place by law rather than by budget.
It is slower, more procedural work, and the domain knowledge takes a year before you are useful.
Find one regulated documentation standard in your industry and read its table of contents. If the form is prescribed, the job is defended by something other than cost.
Common questions#
Drafting the reference is the most exposed writing task on this site, because the source of truth is machine-readable and the output format is fixed — and doc generators had already taken part of it long before models. What does not move is the test: following your own instructions on a clean machine and finding the step that is impossible for everyone who is not the engineer. A model trained on the codebase inherits exactly the knowledge that has to be absent for that test to work.
No date. The signal is what your team is measured on. If it is pages published or coverage, the metric has just become free and will look excellent while the docs get worse — and headcount decisions get made off that dashboard. Watch whether anyone is tracking support tickets against the top pages, because that is the only measure that moves when documentation is actually good, and whether it exists tells you how the next budget will go.
It stopped being one the moment generation became cheap, and that is the most consequential change in this occupation. Coverage now measures how much text exists rather than whether anybody can do anything with it, so a team judged on coverage will be rewarded for abandoning the task that just became the important one — deciding what not to write. If your team still reports coverage, raising this is more valuable than writing another page.
Materially, and it is the clearest example on this page of a task held in place by something other than cost. In medical devices, aviation and pharmaceutical submissions the document is a compliance artefact: its form is prescribed and a named person attests to it, which means the work cannot simply be generated and shipped. That is a policy protection rather than a technical one — durable exactly as long as the rule stays — but it is real today.
Method and sources#
- Assessment date
- 2026-09-14
- Basis of the task judgements
- 0 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 0