Technical writing's center of gravity moved from documenting finished code to authoring the specs and context that agents read before they build. When an agent can draft prose in seconds, writing prose stops being scarce, and the precise specification becomes the highest-value document in the building.
Technical writing was about turning finished software into documentation a human could use. Read the code, interview the engineer, write the guide, keep it current. The craft was clarity, and the audience was always a person.
Agents changed both ends. They draft documentation in seconds, so producing prose stopped being the scarce skill. And they introduced a new reader that is not human at all: the agent itself, which consumes context, specs, and tool descriptions to decide how to behave.
From documenting output to authoring context
In the AIDLC method, the writer's leverage moved into the Spec phase. A specification is documentation written before the code exists, precise enough that both a human reviewer and a coding agent can act on it without a single clarifying question. That is technical writing at its most demanding, and it is now the highest-value writing in the building.
The skill that used to be a nice-to-have, writing a sentence with exactly one correct interpretation, became load-bearing. A vague spec produces wrong code at speed. A precise one produces the right thing. The writer who can eliminate ambiguity is now part of the engineering loop, not downstream of it.
Writing for two audiences at once
System prompts, tool descriptions, and agent context are documentation the machine reads. They have to be clear to a model the way a guide has to be clear to a newcomer. The writer who understands how an agent parses instructions can shape behaviour with words, which is a genuinely new and valuable craft.
Human documentation still matters, but the bar moved. An agent can draft it; the writer's job is to make it correct, current, and structured so the next agent can read it too. The same instinct that produces a good llms.txt produces good internal context.
If your team treats documentation as something written after the fact by whoever has time, you are leaving the highest-leverage writing, the spec, to chance.
The technical writers who win
They author specs, not just guides. They write for the agent as carefully as for the human. They treat ambiguity as a defect. And they measure their work in builds that went right the first time because the spec left no room to go wrong.
Leaving your specs and agent context to chance?
Most AI projects stall because nobody on the team knows how to design agents, manage token budgets, or wire production evals. I build that layer for B2B companies so the feature actually ships and keeps shipping.
Senior engineer turned AI specialist. React, Next.js, AWS, agent orchestration.
Direct collaboration across UAE, Europe, and US time zones.
Discovery, role design, MCP integration, evals, and production deployment.
If you want documentation and specs that both your team and your agents can act on, book a discovery call and we will set it up.