Example · Technical Writer
Anyone can generate a draft now, so knowing where it is wrong is what makes you valuable.
23 of your 40 hours still need you
- 15 stay yours
- 8 faster with AI
- 17 tools could take
A typical week at the middle pace. Your plan uses your own tasks.
Is technical writing dead because of AI?
By our task-by-task count, 23 of a typical 40-hour week as a technical writer still need a person. Tools could already take about 17 hours. Hand a current model your OpenAPI spec and the merged PR (pull request) and it produces first drafts, reference pages, release notes, how-to articles and copyedits in minutes, at a quality a docs lead would accept after a pass. About 42% of your week sits there.
Read more
Microsoft's study of real Copilot conversations ranks technical writers near the top of all occupations for AI applicability, and in March 2026 Snowflake cut most of its documentation team and said in public that models would do the work. That is where we start.
But docs work has always been more than the pages. It means finding out what the product actually does, deciding what deserves a page, and signing that it is true before customers rely on it. If support escalates to you and the hard questions come to you, you already do that. An agent can draft a page in a minute and also invent a parameter that does not exist. That mistake gets caught only if someone has tested the endpoint. When drafting is free, the valuable person is the one who can tell the draft is wrong and who answers for it. The plan moves your week toward that person. It also changes the part you may dread, chasing engineers for review.
The hard truth
Technical writing is a small field with few openings.
The whole country sees about 3,200 openings a year and almost no new seats. Most openings appear only when someone leaves or retires.
Sources (2)
- About 46,400 technical writer jobs in 2025, projected to grow 1%, about 400 jobs, by 2035. BLS Occupational Outlook Handbook, Technical writers, 2025
- About 3,200 openings a year, mostly from workers who retire or change occupations. BLS Occupational Outlook Handbook, Technical writers, 2025
What stays yours
Finding out what a feature actually does by asking the engineer instead of reading the ticket
The gap between what the PR says and what the product does lives in people's heads and in Slack. A model reading the diff sees what changed. It can't see what the PM promised a customer or which edge case was dropped.
Testing the procedure against staging before you publish it
Discovering that a published doc is wrong is expensive: a support ticket, a failed integration, a customer who no longer trusts the page. The person who runs the call before the page ships is the cheapest place that cost can be paid.
Being who support escalates to when "the docs are wrong"
Sorting "the behavior changed" from "the doc is wrong" from "the customer misread it" needs product history and a sandbox account, and it produces the one signal your docs quality can be measured by.
Deciding what pages exist and which quadrant they belong in
A model can fill any structure, but it cannot know that your enterprise customers read the webhooks page first and never open the tutorial. That is architecture, and it is the part of information design that lasts.
Holding the terminology
"Is this the right word?" is often a product decision. Consistency across app, docs and support is what makes a product feel finished, and someone has to own the list.
What's next for a technical writer?
Plan A is your best move inside the work you do now. Most sessions in the 13-week plan build toward it.
- A
Own the docs system
Why it fits
Why you. If you already catch what the agent invents, going from "the reviewer who catches it" to "the owner of what it may do" is a guardrails file, a linter, a test, and one conversation with your lead.
The gap. Today you may review in a browser rather than in the repo, with no Vale style rules and no doc test. If the lead set up the pilot, it is hers until your results make it yours.
The trade-off. You will write more YAML than prose, and some weeks you will feel like a build engineer. It is low-visibility infrastructure, so the value shows up in a review only if you keep the numbers. And if the platform team decides the pipeline is theirs, you will have built something you do not own.
Other moves that fit
These are also good bets in this field. Read them if Plan A doesn't suit you.
Own how machines read the product
Why it fits
Why you. You know how the product actually behaves. The readers now using your docs at scale are agents calling your API on a customer's behalf. They do not skim, forgive or ask support. llms.txt files, MCP tool descriptions, SDK (software kit) docstrings and clear error messages are the text these agents read. Writing them is technical writing for a reader who takes every word literally, and at most companies nobody owns that surface.
The gap. No developer-experience track exists at a mid-size company unless you create it. You need to know how an agent calls a tool (two free courses) and whoever maintains the SDK.
The trade-off. Developer relations is one of the most cyclically cut functions in software; whole teams went in 2023 independent of AI. The work drifts toward marketing if you let it. And the surface may be absorbed into engineering before it becomes a role, in which case writing for machines becomes a skill that strengthens your ownership of the docs system.
Product management, by way of what you already know
Why it fits
Why you. "I want to decide what the docs are" generalizes. Your interviews with subject experts are discovery, your escalation log is the company's best record of customer confusion, and you are in design files every week. That is most of an associate PM's inputs.
The gap. You have no roadmap or metric yet. Associate PM (APM) openings at mid-size companies are rare and usually filled internally, which is the good news; you are internal.
The trade-off. You would be junior again, in a function whose own drafting is exposed. Do not pay for a PM course; the path is one PM who lets you shadow discovery, which week 11 asks for. Treat it as a hedge.
What's a plan B for technical writers?
Plan B is a job AI is creating that these skills already fit. One session a week in the plan trains you for it, so it is ready if your job shrinks or you want a change.
BPlan B, picked for this role
Context engineer and knowledge curator
Deciding which pages exist and holding the terminology is exactly the knowledge curation AI agents need to give correct answers.
Other options
AI evaluation specialist
Testing a procedure against staging before you publish is quality checking, and AI teams need people who verify outputs the same way.
AI product manager
Asking engineers what a feature actually does gives you product depth, and many writers move into owning an AI feature from there.
In your own plan you can switch to any of the 47 roles.
The first two weeks
The first 2 of 13 weeks. Each week has three sessions of 45 to 90 minutes, about three to three and a half hours in all, plus one 40-minute Plan B session. Week 6 is a checkpoint: if your lead won't name you owner of AI draft quality, the second half points the same work toward a new job. By week 13 you'll have a rules file and style checks for the docs agent, two working doc tests, and a memo asking for a Senior Technical Writer or Documentation Engineer title.
- Week 1: Measure your week and the AI
What you do
- ALog your time for one week against the task list in this report.
- APull every page the drafting agent has written. Count your fixes on each by type: invented, out of date, wrong term or missing step.
- ACopy the docs repo to your computer and build it. Install Vale, a free style-checking tool, with a default style and run it.
- BTake the first half of Anthropic's AI Fluency: Framework and Foundations course. Pick one open-source project's public docs as your practice set.
- Week 2: Ask who owns AI quality
What you do
- AWrite a one-page list of the AI error types with the count for each.
- ASpend 30 minutes with your docs lead and show the tally. Ask who owns the quality of the AI drafts, and what it would take for that to be you.
- ATake the Linux Foundation's free OpenAPI Fundamentals course on API description files. It takes 60 to 90 minutes.
- BFinish AI Fluency. Read Anthropic's article on effective context engineering for AI agents.
Three courses from the plan
Checked 2026-09-22.
- Documenting APIs: A guide for technical writers and engineersTom Johnson, idratherbewriting.com · Free (optional paid PDF)
Yes, week 5, the OpenAPI and testing chapters.
- OpenAPI Fundamentals (LFEL1011)Linux Foundation Training · Free
Yes, week 2.
- DiátaxisDaniele Procida, diataxis.fr · Free
Yes, week 3.
Risks beyond AI: moderateCost-center risk
Documentation teams are cost centers and get cut in every downturn; the 2022–23 contraction hit docs and developer-relations teams hard for reasons unrelated to models. Some of today's anxiety is about AI and some is about interest rates, and the plan works either way.
Where this could be wrong
- The shares are estimates until week 1. If your log shows half your week is drafting, your entry-level pressure score rises and the week-6 checkpoint becomes a week-3 checkpoint.
- The docs lead may not be able to grant scope. If the week-2 answer is "that's up to Product," the memo goes to the Product director and the ask is harder.
- The employment base is ambiguous. BLS's count fell from 56,400 in its 2024 edition to 46,400 in its 2025 edition. Some of that may be reclassification. If not, the profession shrank by a sixth in a year and the moderate scenario is optimistic.
- The Snowflake figures are from press accounts, not a primary filing. The count might be off, but the direction is clear.
Also matched: technical writer, documentation writer, api writer. Research checked 2026-09-22. Page updated .