Our first experience of AI began with documenting AI systems in the early 2020s. One product guided banking customers using spoken interactions through a decision tree, and another vectorised data. We thought we understood what AI did, and where it could be used. Then, in 2022, OpenAI released ChatGPT. In five days, ChatGPT had a million users. We started to see AI-generated images, and were fooled into believing the Pope was walking down a catwalk wearing a white Puffa jacket.
The first reaction for us and other technical writers was cautiously positive. It could be a useful tool for producing first drafts more quickly, repurposing content, cleaning up prose, and so on. Then people started asking: if the tool can do a task, why do we need the people who are doing it today?
Fast forward to today, and many are still asking that question.
A pattern that keeps repeating
Each new wave of AI tooling has arrived, created a new skill category, then partially automated that category before the next wave appears.
Prompt engineering was first
After ChatGPT launched, the skill that mattered was crafting precise inputs: learning which phrasings produced useful output, and how to break a complex task into smaller pieces. Courses and vacancies appeared. The title “prompt engineer” had its mayfly moment.
Then RAG
Retrieval-augmented generation changed the problem. Instead of coaxing answers from a general-purpose model, companies started building systems that pulled specific documents into context.
These were often using product documentation, procedures, or a company’s knowledge base. The relevant skill became system design: how to chunk data, write retrieval queries. How could you build something that knew your product, rather than something that fabricated plausible-sounding details about it.
Vibe coding came next
Tools such as Cursor made it possible to describe a working feature in plain English and create apps and utilities. It wasn’t always “good” code, but it worked as long as you didn’t stress-test it. And you could get a programmer to refine it into functional code.
The bottleneck shifted to product sense: knowing what you wanted well enough to describe it, and knowing whether what arrived was actually useful.
Then agents and orchestration
By this I mean systems that could chain tools together, browse the web, write and execute their own code, and then file pull requests.
Workflow design mattered more than any individual prompt. Building the pipeline became the work.
The direction now is towards goal-directed AI
Now the focus is moving to goals. You describe the outcome or goal. The system works out the steps, picks the tools, and it handles the sequence. The AI’s reasoning is less clear, and it’s more like a “black box”.
This is like a spiral
Each progression automates one more layer of execution, and the human role gets pushed further towards defining what success looks like in the first place. Some are asking, if AI systems can do what humans do, how do we each earn a crust?
What gets lost
What gets lost in this evolution is what the human actors learn along the way as they iterate their way through the process. We often learn by doing, and learn from the mistakes we make on the way to the solution.
AI can deliver for the Use Cases where the humans know exactly what they want. For those other problems, the AI can only approximate the desired outcome.
Where the value goes
Specifying a goal well is genuinely hard
Being able to define specific, measurable, achievable, relevant, and time-bound outcomes isn’t always easy.
“Make the onboarding experience better” is not a goal. “Reduce the time from account creation to first successful API call below four minutes for developers arriving from a Python background” is a goal.
The second version is workable, because it contains a success criterion, a scope, and a defined user. You can build against it, test against it, and know when you’re done.
Writing goals like that is a form of technical writing.
It requires deep subject-matter knowledge, the ability to anticipate misunderstanding, and the discipline to cut anything that doesn’t actually specify what you mean. It often requires knowledge and experience.
Most engineers write vague goals. Most product managers write vague goals. Technical writers are trained precisely for this kind of precision.
System prompts are another place the work goes
Arguably, this is one of the least discussed topics in AI. The instructions that define how an AI assistant behaves inside a product are, in practical terms, a high-stakes form of documentation. They’re interpreted literally, at scale, by a system where ambiguity creates failures in production.
Anthropic publishes what they call a model spec. This is a document that shapes how Claude reasons about ethics, appropriate behaviour, and contested situations. It runs to tens of thousands of words and is written with the care you’d give to a legal document. That is not a prompt. It is, in reality, governance.
Companies building AI products need people who can write at that level of precision and foresight. Most of them don’t have anyone who can.
Evaluation
Someone has to assess whether the AI’s output is actually correct, complete, and safe, rather than only fluent and confident. That requires reading critically with domain knowledge.
Technical writers already perform this function in reverse: they read what engineers write and find the gaps, the ambiguities, the steps that assume too much. The skill transfers directly.
The regulated world doesn’t go away
There is a category of documentation that automation doesn’t touch, and it’s larger than people assume.
A medical device company is unlikely to get to point at an AI interface and say, “ask it how to calibrate the device.”
The regulatory authorities require documented procedures, maintained by identifiable humans, auditable by regulators. The same is true for aviation, pharmaceutical manufacturing, nuclear operations, and financial services. The liability framework requires a human-readable record of what happened and who was responsible.
The EU’s AI Act requires traceability documentation for high-risk AI systems. As AI gets embedded into more consequential decisions, the compliance documentation requirements are expanding.
What survives?
What holds value is being able to:
- Take an ambiguous intention and produce something precise enough to build against, test against, and audit against.
- Read AI output and judge whether it’s correct or merely confident.
- Write the instructions that shape how a system behaves, with enough completeness that the system doesn’t invent something dangerous when it hits a case nobody anticipated.
The thing most predictions about AI displacement miss: specifying a desired outcome is harder than writing a procedure.
Goals require understanding deep enough to know what “done” actually means. That’s a task that resists automation for the same reason good editing resists it: it requires knowing what the thing is supposed to be, rather than only what it says today.
Technical writers who understood their role as “turning ambiguity into precision” are going to find the next few years interesting.
Note: This article incorporates some feedback from Bob Watson PhD and Claude AI. The image was generated using ChatGPT.
Leave a Reply