From Technical Writer to DevEx Engineer: The AI Shift in Documentation

With AI coming in, the shift in technical writing is rapidly changing. I used to always introduce myself as a technical writer, but not anymore. If you look at most of the JDs for tech writers, they don't feel like tech writer JDs. It feels like a DevEx engineer.

This shift is real because what I have been doing for the past couple of years, I totally relate to this, and I will explain why this is happening in this blog.

---

The shift

If I reflect on my work, most of my job does not look like “writing” anymore. Sometimes I am building style enforcement with Vale, putting quality gates around commits or designing docs for AI coding tools, debugging how assistants used our pages, and treating documentation like a developer product with release checks, failure modes, and ownership, and this is the shift I feel all the time.

AI did not replace my writing work, but I feel it definitely changed what my job role used to be. When docs became something humans, bots, and agents all consume together, the writer’s responsibility moved beyond publishing doc pages to owning how a developer interacts and feel with your published content.

Now, a tech writer needs to focus on developer experience and make sure they can find the right product, get the right answer, and use it without getting lost or misled. Writing is still part of technical writing, but it is not the whole role anymore. A big part of it has become DevEx engineering for documentation. Let's understand this more.

What “DevEx engineer” means for documentation people

Let's be clear about what I mean when I say the role is DevEx: I do not mean that it's a coding or backend engineering role.
DevEx in documentation, for me, is the work of making developers successful with a product integration.

For a long time, we used to think that only SDK engineers, API designers, or developer advocates had to take care of this, and we all treated documentation work as additional support material. This understanding does not hold anymore.

If your docs are wrong, outdated, hard to navigate, or easy for an AI tool to misread, developers fail in the same way they fail with a bad SDK error or a confusing API. So, docs are not support material but are part of the product experience, not an attachment around it now.

So when I say technical writers are moving into a DevEx role, I want to emphasise that: we still write, but now have to focus more on designing the system around the writing framework. We need to care about how developers discover, trust, and use what we publish.

With DevEx, we measure problems in developer outcomes, not only in “page is live.”

This is a big shift. We now write scripts, configure systems, define
rules for AI systems, and make sure that readers get what they need at the right time. This also brings down to one more challenge: we need to write and read code more than before.

The core skill of a tech writer did not change; we still need to understand the product and make it usable for developers. It's just that the toolkit we used to have around our skills got bigger because of AI.

The change in Job descriptions says it all

Open a few Technical Writer or Documentation Engineer JDs from the last few months, and you instantly notice sentences that used to live in other roles such as:

• docs-as-code and CI familiarity
• OpenAPI / SDK documentation experience
• Information architecture for multi-product platforms
• AI search, assistants, or “AI-ready documentation”
• Style guides with automated linting and checks
• GitHub workflows for automation and CI/CD

All of these make the JD less about we need a good tech writer to someone who can write well, but also takes care of entire doc systems to create a clean developer experience for the end readers.

Here is a simple way I think about old vs. new JD and the expectations it brings with this shift:

Older TW expectation	What the work often includes now
Write and update pages	Write new or update pages and keep product language consistent across the whole site
Follow a style guide	Enforce the style guide with tools like Vale
Publish after review	Pass checks before merge: links, anchors, validation, version drift
Support human readers	Support humans, docs assistants, and AI coding tools
Fix docs after feedback tickets	Catch failures earlier from bot chats, support teams, and broken journeys to fix automatically
Own content quality	Own content quality plus docs tooling and release processes in an automated way

If your company has multiple products under one docs site, this expansion happens even faster, and this is something I can say from my personal experience, where I handle multiple products under one docs site.

How my week changed as a technical writer

I still spend a lot of my time writing documentation, but it has drastically changed from what I used to do five years ago. Usually, my first draft is AI-driven now, followed by rigorous checks and reviews. Sometimes the docs are automatically generated from Docs Gap directly from the site, where I just review, make changes and publish.

For new docs that are written, I usually do this now.

1. Understand what shipped in the existing product
2. Update the docs pages led by AI and human review
3. Check whether naming and IA still hold for that new page
4. Run quality gates before merge
5. Think about how an AI tool or docs assistant will use this page to answer a human
6. Fix the failures that show up after publish

Sometimes the writing is normal too; for instance, when a new API comes for documentation, I talk to engineering, draft the guide using OpenAPI spec, edit examples, get it reviewed, and finally ship using the automated CI/CD process.

But sometimes it may look totally different. I get warnings from my automated checks that Vale is flagging terminology drift or that a change log is out of sync with a package version. An AI coding workflow needs a clearer skill or index, or a docs assistant is answering from the wrong product section in the RAG pipeline. Those days do not look like “technical writing” but more like a DevEx engineer who is trying to fix these problems.

This is a shift in role that not everyone is ready to adapt to.

Vale and style systems are not “nice to have” anymore

Let’s talk about Vale, because this is one of the clearest examples of the DevEx work. As you all know, Vale is a prose linter. You define its rules, and it checks your docs the way a code linter checks code. If the rule fails, the change can be blocked or skipped based on what you want to do when a new doc is pushed.

Earlier in my career, my manager used to say that style guides were mostly documents people were supposed to remember. Some teams followed them well, and some did not. Inconsistencies stayed in the site for months until someone flagged and tagged us via a ticket.
With AI writing content, it became a bigger problem because inconsistent naming fails RAG pipelines that my docs bot uses to retrieve content.

For example, if Product A’s auth concept is named one way on three pages and another way on two pages, a developer reading the docs may still guess, but a docs assistant or coding agent may pick the wrong meaning and give a wrong answer.

So in my work, Vale stopped being “grammar help” and became part of daily checks that run on every commit.

If you want to set it up, it will look like this in practice:

• Protect exact product names and API/SDK names
• Stop writers and AI drafts from rewriting code identifiers
• Keep body writing rules separate from UI title rules
• Catch banned vague phrases that hide missing detail
• Make the style guide rules

I call this DevEx thinking, which is applied to language:

Human style guide
      ↓
Vale rules in the repo
      ↓
Same language across pages
      ↓
Fewer mixed-up answers for people and AI tools

I did not need to become a full-time engineer to do this. I treated documentation language like a contract and enforced it. This alone already pulls the role away from a technical writer who only writes the page.

Quality checks: treating docs like something you release

The second big change that I do almost all the time is maintaining a release discipline. Software teams do not merge backend code just like that. They run checks; PR are approved, etc. Same way I do for docs now. For example, if your docs say Package X is on version 1.2, but the package already shipped 1.4, developers will get confused.

If an AI tool reads that outdated page and generates integration code, the problem multiplies. If a heading change breaks deep links, both humans and assistants lose the citation path, and I have seen this happening with my docs.

So docs work starts to include checks, for example:

• Terminology checks with Vale
• Broken link and anchor checks on commit and PR merges
• Docs site validation
• changelog/package version drift checks using custom GitHub flows
• A real review of product claims before publishing using PRs

You can imagine the flow like this:

flowchart TD
  A[Update docs] --> B[Vale / terminology]
  A --> C[Link and anchor checks]
  A --> D[Version / changelog drift]
  A --> E[Docs site validate]
  B --> F{Ready to merge?}
  C --> F
  D --> F
  E --> F
  F -->|No| G[Fix the docs system issue]
  F -->|Yes| H[Publish]
  H --> I[Humans + AI tools use it]

This is one reason JDs sound like DevEx. They are asking for people who can keep documentation reliable under change, not only people who can write a clear paragraph. For me, the mindset shift was simple: Publishing a page is not the finish line.

Passing the checks that protect developers is part of the finish line.

Designing documentation for AI coding tools like Cursor

This is something that feels newest to me. Developers are not only browsing docs sites now. They are also asking coding assistants like Claude or Cursor to implement from your documentation. Some teams now publish skills, MCP access, or curated indexes so tools can find the right pages faster.

This completely changes how you write and organize your pages now.

It is really important that you start asking questions like:

• Is the task structure clear enough that a tool can follow create -> configure -> verify?
• Are Product A and Product B separated cleanly in navigation and page titles?
• Are auth concepts named exactly, every time?
• Do we give agents a trusted map of important pages, or do we make them guess from a giant site?
• Are examples complete enough that a model does not invent missing steps?

This is still documentation work. But it is documentation work with a second audience in mind: The AI Coding agents.

A useful way to think about it is as follows:

One docs repo
   ├── Human reader: skims nav, examples, tutorials
   ├── Docs assistant: retrieves pages into chat answers
   └── Coding agent: follows skills / tools / structured guides

If you only optimise for the human reading, the other two audiences feels left out and if you only optimize for machines, it is hard for human readers. So, how do we solve this? This is where thinking like DevEx engineer is keeping all three usable.

I will be honest: this part of the work can feel strange at first. You are writing for readers who do not get tired, do not ask clarifying questions the same way, and will confidently continue from a doc page that is wrong. That is exactly why structure, naming, and completeness matter more than ever now.

Docs assistants

A lot of modern docs site have AI assistant built in to ask questions related to docs. My doc site also has one. Once your site has an assistant on top of the docs, the assistant becomes another way developers experience your documentation. If it mixes Product A with Product B, or cites the wrong guide, that failure is attached to your docs IA whether you personally trained the model or not.

So tech writers needs to fix:

• Reading chat failures
• Deciding whether the fix is copy, IA, naming, or assistant behavior
• Writing clearer product boundaries
• Testing important questions again after a fix

This is one of the moments where the old title feels outdated. You are not only the person who writes the page but now you are part of the team making sure developers get the right help from the docs platform.

If you want the evaluation side of that work in more detail, I have written about docs-as-evals separately.

Here, the important career path is simpler: AI assistants made documentation failures visible in a new way. Visible failures create ownership and it pushes writers into DevEx-shaped work.

Skills technical writers need to add in this shift

If you are wondering what skills actually grow in this transition, this is the list I see from my own work and from those JDs:

Product and systems thinking

You need to stop thinking page by page and start think in journeys like onboard, authenticate, create a session, handle errors, upgrade versions, move between Product A and Product B.

Docs-as-code habits

Using Git, generating PR for reviews, branches, checks, and do not merge broken docs should be the part of your writing workflow. Not because you want to copy engineering processes but to keep things consistent. Docs break the same way code breaks when process is weak.

Tooling upgrades

Vale rules, validation commands, small scripts, config files, maybe a dashboard for assistant feedback. You do not need to build everything, but you need to add these in the repo may be my doing some coding work.

Information architecture under multi-product documentation

Shared words are dangerous in a complex product docs. Good IA and naming consistency become developer experience work. So, as a tech writer you need to decide and figure out what needs to get done to achieve this.

AI literacy for docs

Do no only focus on better prompt writing but also learn how assistants retrieve, how coding tools consume pages, where they fail, and what content patterns reduce those failures.

Collaboration with engineering and product on outcomes

You need to gather constant feedback on your docs work with engineering team to improve the process and consistency.

None of the above replace writing skill but they are the add ons to a tech writer now.

What did not change

Writing is not change. As a tech writer your core skill is still a strong structured writing. You need to write correctly both factually and conceptually. If the source docs are wrong, every assistant and coding tool will scale that wrongness. Honest limitations matter, talking to engineers are important and knowing when a sentence is hiding missing product truth is a key skill a tech writer needs to have.

AI did not remove the need for technical writers who understand the product but added pressure on those writers to also own the systems that distribute and interpret the writing. So the identity shift is not:

technical writer -> not a writer anymore

It is closer to:

technical writer -> technical writer + docs DevEx owner

If you are a new technical writer reading this

If you are new to this field, this is one of the best time to be a tech writer as it opens a lot of opportunities for you. You can develop these DevEX skills without rewiring your brain too much.

Here is a starting path that I would recommend:

1. Make your style guide enforceable. Put 5 to 10 high-value Vale rules around product names and confusing terms.
2. Add one quality gate that catches real pain. Broken links or version drift are good first gates.
3. Map your multi-product collisions. List words that mean different things in Product A vs Product B. Fix naming and nav around those first.
4. Watch how AI tools use your docs. Read assistant failures or ask a coding tool to implement from your guide, then fix what it gets wrong.
5. Redefine “done” with your team. Done should include the checks and follow-ups, not only the merged page.

Do this for a few months and your JD anxiety will make more sense. The industry is not randomly renaming roles as the the work changed, JD is catching up to that.

Conclusion

Technical writing is still the foundation of my work. I still write, edit, structure, and explain but AI changed the scope around that foundation. Docs are now read by humans, answered through assistants, and consumed by coding tools. That means the person closest to the docs often ends up owning consistency systems, release checks, AI-facing structure, and the failures that show up after publish.

That is why so many technical writer JDs feel like DevEx engineer JDs and this relate to the shift so strongly from my own last couple of years experience. If your title still says technical writer, that is fine. Keep learning and enjoy what you love.