LO
Worker adoptionCognitive automation2026-08-26
Interviews with 31 technical writers found documentation relies on engineers' technical review and outsiders testing it end to end, and 25 found LLM review feedback unreliable
Technical writer / documentation engineeroccupation page →
Event date / reported
2026-08-26
Evidence stage
Worker adoptionMeasured, large-scale use of a tool for real work, where the decision to use it was the worker's rather than an employer's. It is more than a capability record — the work is real, not a demo — and less than a deployment record, because no employer put it into production, required it, or built a process around it. Weighted `cautious`: `automating` means the machine can do the task AND there are adoption signs, and this is an adoption sign — but usage can be experimental, and much of the measurement comes from a party with a stake, so one record is never enough and two independent ones are. Note who is counting. Vendor telemetry sees this directly and sells the tool, so such a record names that stake in its scope; a statistics agency asking firms whether their workers use AI in tasks sees the same channel with no stake at all, and that is the better source where it exists.
Tasks this bears on
Actually using the thing you are documenting
Following your own instructions on a clean machine and finding the step that was obvious to the engineer and impossible for everyone else.
Still human-led✓ Evidence-backed
Getting the answer out of an engineer
Working out which of five people knows why it behaves like that, and getting fifteen minutes of their time to find out.
Still human-led≈ Platform inference
Where this applies
Semi-structured interviews with 31 experienced technical writers at startups, enterprises and open-source projects. The authors describe five review stages: 28 participants described technical review by engineers or other subject experts, which surfaces knowledge not written down elsewhere; 13 described play testing, where people with product knowledge who did not write the documentation follow it end to end to find what the writer is too close to see, mostly for tutorials; and 25 described LLM-generated review feedback as unreliable, partly because the context a review needs sits in confidential internal systems they cannot share with model providers. Writers report they hold no authority to compel review and must negotiate for it. It is a qualitative study of self-reported practice; one author works at a company that sells language models.
What this means
When experienced writers describe how documentation actually gets good, two steps stand out: an engineer checking it and someone who did not write it trying to use it — and most of them say a model's review cannot stand in, because it cannot see what is missing. The social and hands-on parts of this job are where quality comes from.
What it does not yet show
Interviews about practice, not measurements; it does not show how often teams still fund these steps or whether they are being cut.
What you can check
Open arXiv:2608.26232 ("A Second Set of Eyes") and find "An LLM can only act on positive matches in my experience".
Does it change the assessment?
No. The impact index is never moved by a single event. Of the 2 linked judgements above, 0 moved from inference to evidence with this record; the other 1 already rested on earlier evidence.
Source
Avinash Bhat, Ian Arawjo, Disha Shrivastava, Jin L.C. Guo (McGill, Université de Montréal, Google DeepMind) — "'A Second Set of Eyes': The Process and Challenges of Software Documentation Review", arXiv:2608.26232v1 (26 August 2026) · verified 2026-09-28 · Claude (VOLO agent) · interpreted 2026-09-28 · Claude (VOLO agent)
Primary source — published by the party that did this, or the authority of record. No co-signature needed.