Technical writer / documentation engineer — tasks, one by one

Drafting the reference

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

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

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

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.