AI writing tools solved drafting. Who still owns the reader?

Table of contents

• The drafting problem is solved. That’s not the argument anymore
• Feels faster is not an accountability standard
• There is no one-time setup
• What AI cannot fix: the writer as first user
• The PO/BA objection, and why it doesn’t cover ownership
• The rename: context engineering, ontologies, and where the salary went
• What’s actually being lost
• Why you can’t outsource the sign-off
• When a developer plus AI writing tools is enough
• Conclusion
• Book a consult
• Additional resources

AI writing tools have already solved drafting for most teams. Most engineering leaders have watched a developer run a style guide through one and produce a passable reference page in an afternoon instead of a sprint. So the headcount question is no longer theoretical: if a developer and AI writing tools can cover the docs, why keep a writer on the org chart at all? That is a staffing decision, not a tooling one, and it deserves a straight answer instead of a tool roundup.

The drafting problem is solved. That’s not the argument anymore

Let’s concede this fast, because pretending otherwise wastes everyone’s time. A developer with a decent style guide and any mainstream AI writing tool can produce most of what used to take a writer a full sprint: reference pages, changelog-to-release-notes conversion, consistent formatting across a docs set. If your mental model of “technical writing” is drafting sentences, that model is already obsolete, and no amount of defending it will make it less true.

The economics behind that shift, why generation got cheap while reading and verification got expensive, are covered properly in our technical writing best practices for when reading is the expensive part. Go there for the foundation. This piece picks up where that one leaves off: drafting is solved, so who is accountable for what ships?

Feels faster is not an accountability standard

Here is the trap engineering leaders keep falling into: judging whether “a dev plus an AI tool for writing” is good enough by how it feels in the room. It feels fast. The page exists. Ship it.

The most rigorous controlled trial of AI on real engineering work found the opposite of what almost everyone expected. Experienced open-source developers using AI tools on their own repositories were measured to be 19% slower than without AI, while believing the whole time that they were working faster. The gap between felt speed and actual speed didn’t close once the task was done and they had direct experience of the slowdown. It persisted. External forecasters, economists and ML researchers among them, had predicted large speedups going in, and got it wrong in the same direction the developers did (METR, 2024).

Translate that to documentation. If experienced engineers can’t reliably self-assess their own speed on code they wrote, a developer skimming AI-drafted docs for “does this look right” is not a verification process. It’s a vibe check wearing a verification process’s clothes. Someone still has to measure the output against what the reader actually needs, not against how fluent the paragraph sounds.

There is no one-time setup

A common pitch for the dev-plus-AI model treats it as a fixed asset: write the style guide once, wire up the AI writing tool once, and the pipeline runs itself from there. It doesn’t. Products change shape, APIs deprecate fields, pricing models get restructured, and every one of those changes invalidates assumptions baked into the style guide and the prompts built on top of it. Models change too, sometimes mid-quarter, which quietly shifts tone, structure, and what gets hallucinated with confidence.

This is ongoing operational work, not a one-time investment: someone has to own the prompts, the evals that catch regressions, and the structural decisions about how content is organized as the product grows. Skip that ownership and the docs don’t fail loudly. They drift, page by page, until nobody can say when they stopped matching the product.

What AI cannot fix: the writer as first user

Developers writing their own docs run into a problem no AI writing tool resolves, because it isn’t a drafting problem. It’s a knowledge problem. Once you understand how a system works, you lose the ability to accurately imagine not understanding it. This is the curse of knowledge: a well-documented cognitive bias where a person with specialized knowledge unconsciously assumes other people share that knowledge, even when they very clearly don’t (Wikipedia).

What makes this bias dangerous for documentation specifically is how stubborn it is. It doesn’t meaningfully reduce when people are warned about it in advance or explicitly asked to imagine the other person’s perspective. Once you know something, you can’t reliably reconstruct what not knowing it felt like, which is exactly the mental state your reader is in (Sue Behavioural Design).

An AI writing tool doesn’t fix this. It amplifies it. The model writes fluently and confidently from whatever context it’s handed, thin or rich, correct or wrong, and gives no signal about which one it got. A developer who already knows the system feeds the tool context that feels complete to them and gets back prose that reads as complete, which is precisely the failure mode the curse of knowledge predicts. A writer acting as the first real user of the docs, someone outside the system who has to actually learn it from the page, is one of the few reliable ways to catch the comprehension gaps the author structurally cannot see.

The PO/BA objection, and why it doesn’t cover ownership

The next objection is usually: “We already have product owners and business analysts who know the domain. They can review the AI’s output.” This sounds like it solves the problem. It solves a different one.

BAs and POs write for the build. Specs, acceptance criteria, and tickets exist to get a feature built correctly. Docs exist for a different moment entirely: using what shipped. Those two audiences think in different units. A spec is organized around what the team changed. A reader is organized around what they’re trying to do. When that difference gets ignored, docs end up structured by feature instead of by task, which is exactly the split the documentation model a developer-plus-AI workflow still needs exists to prevent.

We’ve watched this exact failure play out from the inside. On one project, three squads each owned a slice of the same product area, and each squad’s BA used a slightly different word for the same underlying concept: one called it an “account,” another a “wallet,” a third a “ledger.” Nobody owned the term across squads, because no single BA’s job was to look sideways at the other two. The docs inherited all three words, sometimes on the same page, and support tickets started asking whether an account and a wallet were the same thing. They were. Fixing it meant going back and enforcing one term per concept instead of trusting the model’s word choice, which is slower and less glamorous than it sounds, and nobody’s existing role covered doing it proactively.

It’s worth being honest here too: the BA role is under the same AI pressure as drafting is. “The BA will handle it” is not a durable answer if BAs are themselves being asked to do more with AI assistance and less dedicated time. Domain knowledge distributed across several specs is not the same thing as one person owning consistency across the reader’s experience of the whole product.

The rename: context engineering, ontologies, and where the salary went

Here’s the part that’s uncomfortable to say out loud: the skill didn’t disappear. It moved, and it got a raise.

What technical writers used to call structure, the deliberate decisions about what information a reader needs, in what order, with what shared vocabulary, is now being described in engineering terms as context engineering. Anthropic frames it as the natural evolution of prompt engineering: not writing a clever instruction, but curating the full set of information a system acts on, which becomes the core skill as systems get more agentic (Anthropic). That is information architecture. It has a new name and it sits inside engineering org charts now, not writing ones.

The same pattern shows up in ontology and knowledge-graph roles, which are information architecture by another name, built with formal rigor instead of a style guide. Ontology engineer postings average around $134,707, with senior ontologist roles listed as high as $180,000 to $230,000 (ZipRecruiter). If you want the analogy a technical reader will recognize instantly: an ontology is roughly an XSD for meaning, a strict schema for what concepts exist and how they relate. A knowledge graph is closer to XML that’s been let loose to form a web, with the same concepts connected in multiple directions instead of one strict tree.

None of this is writing work in the traditional sense, but it’s the exact discipline that used to live inside a documentation team: deciding what the “account” concept is, how it relates to “wallet,” and which one the reader should see. It survived. It got better paid. It mostly ended up under engineering titles, and most writers never followed it there, because the job postings never said “writer.”

What’s actually being lost

It would be dishonest to frame all of this as purely an upgrade, so let’s not. Real things are under pressure and they deserve to be named plainly rather than quietly mourned.

The craft of the sentence, the instinct for rhythm, precision, and economy that took years to build, has far less commercial demand than it did five years ago, because an AI writing tool can produce an adequate sentence instantly. The writer as the reader’s dedicated advocate, the person whose only job was to ask “will this confuse someone,” is disappearing from a lot of teams because the role got folded into “whoever has time.” And the junior writing roles where people used to learn the trade by drafting thousands of ordinary pages are mostly gone, because drafting ordinary pages is the exact work an AI writing tool does now. That’s a real loss for the pipeline of people who would otherwise grow into the judgment-heavy work this piece has been describing. Naming it honestly is also what keeps an argument like this from reading as job protection dressed up as analysis.

Why you can’t outsource the sign-off

Whatever the staffing model, a human verification pass before publishing is not optional, and a detection tool is not a substitute for one. A controlled study of 14 AI-text detectors found that 6 of them produced false positives and all 14 of them produced false negatives, with accuracy degrading further once the text had been lightly edited, paraphrased, or translated. The documented bias ran toward calling AI output human-written, meaning detectors both let real AI text through and wrongly flagged genuine human writing (AI Weekly). If your accountability plan leans on a detector catching the gaps, it will fail quietly in both directions.

There’s a commercial cost here too, separate from accuracy. In a survey of 3,000 US adults, content merely suspected of being AI-written cut reader trust by nearly half and lowered purchase consideration by 14%, even in cases where the content was actually written by a person (Raptive). That means the stakes of “who signed off on this” aren’t limited to whether the docs are technically correct. They extend to whether readers trust the company enough to buy from it. This is exactly why disclosure, not detection, is the accountability mechanism that actually holds up, and why it matters that the four things AI-written procedures still get wrong are the kind of gaps a named human has to close before anything ships, not an algorithm.

When a developer plus AI writing tools is enough

None of this is an argument that every product needs a dedicated writer regardless of size. For a single team shipping a small-surface product to one audience, a developer with a style guide and capable AI writing tools genuinely is sufficient. The coordination problem that makes ownership expensive, multiple teams, multiple audiences, drifting terminology, regulated content, doesn’t exist yet at that scale.

Writers become load-bearing again exactly where that coordination problem shows up: once there are several squads who all touch the same concepts, several audiences who need different entry points into the same product, or compliance requirements where a wrong statement has legal weight. At that point the job isn’t drafting sentences. It’s owning structure and terminology across people who each have good reasons not to own it themselves.

Conclusion

The honest version of the ai writing tools question isn’t “which one is best.” It’s “now that drafting is nearly free, who is accountable when the output is wrong, inconsistent, or confusing to the one person who matters, the reader.” That accountability didn’t go away when drafting got automated. It got harder to see, because it stopped looking like writing and started looking like context curation, terminology enforcement, and sign-off. The paradox worth sitting with: the cheaper writing gets, the more expensive it becomes to publish the wrong thing, because nothing in the pipeline slows down to catch it unless someone is explicitly assigned to.

If you’re staring at a headcount sheet trying to decide whether that someone needs to be a dedicated role on your team, we’d rather have that conversation directly than let a tool comparison make the decision for you.

Book a consult

If you’re weighing whether a developer and AI writing tools genuinely cover your documentation, or where ownership needs to sit as your product and teams grow, book a consult at weesholapara.com/book or reach out through weesholapara.com/contact. We’ll look at your actual docs, not a generic checklist.

Additional resources

• METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity
• Anthropic: Effective context engineering for AI agents
• Wikipedia: Curse of knowledge
• AI Weekly: Study finds AI-text detectors “neither accurate nor reliable”
• PPC Land: Raptive study shows AI content cuts reader trust by half