Everyone Can Write Documentation Now. That Turned Out to Be the Problem.
Back
to top
← To posts list

Everyone Can Write Documentation Now. That Turned Out to Be the Problem.

Alexander
Written by
Alexander
Last Updated on
August 25th, 2026
Read Time
7 minute read

Two dictionaries independently picked the same word of the year for 2025: slop. Merriam-Webster defines it as digital content of low quality, produced in quantity by artificial intelligence. Macquarie went with “AI slop” and added a detail I keep thinking about: content “not requested by the user.”

The dictionaries were describing social media. But what made that flood possible — content stopped costing anything to produce — isn’t unique to social media.

In documentation the same shift is harder to spot. It doesn’t look like junk. It looks like a portal that doubled in size over a year while the questions coming into support stayed exactly the same.

Writing got cheap. Scoping went with it.

The cost of writing used to do a job nobody credited it for. Documentation was expensive, so somebody had to decide what deserved a page. Economics forced that decision, not discipline.

That constraint is gone. Anyone on a product team can turn out a plausible page in minutes, so you no longer have to decide what’s worth documenting before you start writing. In a lot of teams, that decision stopped getting made at all.

Harvard Business Review named the workplace version last September. Workslop: AI-generated work that looks like good work but lacks the substance to move the task forward. People spend nearly two hours dealing with each instance. And that output doesn’t just sit there. It pushes the work downstream, onto whoever has to interpret it, fix it, or redo it.

Documentation is downstream of everything. It’s where that cost finally lands, on a customer who’s just trying to get something done.

When drafting was expensive, cost decided what got documented. Cheap drafting removed that filter, and nothing replaced it — scoping simply stopped being necessary to start writing.

The responsibility moved. The profession didn’t.

In March 2026, Snowflake cut about 70 roles, nearly all of them in technical writing and developer documentation. The company had just posted 30% product revenue growth, so this wasn’t a business in trouble making hard calls. The work went to an internal program that generates and maintains technical content using the company’s own AI models.

The documentation function stayed. The people who did it left the building. Coverage at the time put Snowflake in the same bucket as Amazon and Canva.

“AI replaced technical writers” is the lazy reading, and I don’t believe it. Companies aren’t deciding they need less documentation. They’re deciding they don’t need a dedicated role to produce it. Sometimes that means the responsibility lands on a product manager or a support lead who never signed up for it. Sometimes it means the writer stays and the job changes underneath them: less producing, more deciding what’s needed and answering for what other people and AI produced.

When a writer leaves, the writing is the part everyone notices. What leaves with them is a set of decisions that stayed invisible as long as somebody was making them every week:

Does this need a new article, or does it belong in one that exists? Has someone written it already? Who confirms the technical details are right? Is it finished, or just published? Has any of the old material stopped being true in the last three releases?

Nobody hands over the decisions a documentation professional was making, because nobody wrote them down. They were never a process. They were somebody’s professional habit.

Setting the task changed more than doing it

Hand a documentation task to an experienced person and they fill in everything you left out. They know which parts of the product matter, who to ask, what “good enough” looks like at your company, and when to come back and tell you the request doesn’t make sense.

Now the work gets done by AI, or by a person working with it. Neither fills in the gaps. Give a model an incomplete brief and it returns something confident and finished-looking, and the missing pieces won’t show up in the output. They show up three weeks later, in a support ticket.

So there’s a new object to review, and it’s the brief rather than the text. Someone takes a documentation task, writes the context they’ll feed the model, and brings that to you before generating anything. Thirty minutes up front saves a day of cleanup later.

Reviewing a draft means arguing about someone’s work. Reviewing a brief means agreeing on a task.

The definition of done stops being a formality at the same time. It used to be a checklist item everyone nodded at. Now it’s the only thing separating finished from plausible, and plausible is what you get by default.

The mechanics deserve more room than a few paragraphs, and they aren’t what this piece is about. We’ll dig into them at our upcoming webinar.

An experienced person fills in what you left out of the brief. AI fills it in too, with something that merely looks right.

Somebody is answering questions about your product today

A prospect wants to know whether your product can restrict exports by role. They don’t open your documentation. They ask the assistant that’s already up on their second monitor, get a clear answer in four seconds, and act on it.

That answer came from one of three places. A training snapshot: your docs as they existed at some point in the past, mixed in with forum threads and a competitor’s comparison page. A live fetch of your current pages, assuming the assistant could reach them and parse them. Or your own assistant, on your portal or inside your product.

You control the third, influence the second, and have almost no say over the first.

Models handle general concepts well and make up anything specific to your product with total fluency. Config schemas, webhook payloads, query syntax, error codes: the output looks exactly right and doesn’t run. Your customer can’t tell the difference, and neither can the salesperson repeating it.

The usual workaround makes it worse. A team exports its documentation to a file and hands that to a model, and from then on they’re maintaining a snapshot somebody has to remember to refresh. Same problem as the training data, only self-inflicted.

None of this comes back to you. No ticket, no analytics, no complaint. The customer walks away feeling well informed.

An assistant’s answer is exactly as current as the copy it can reach. If it can’t reach yours, it answers from somebody else’s version of your product, and nobody tells you.

Documentation finally showed up in someone else’s report

Making the case for documentation used to mean making it on faith. Everyone agreed it mattered; nobody could say what it moved.

That’s changed, and not because documentation teams got better at measuring things. It changed because documentation now sits directly in front of numbers other departments already report: ticket deflection, activation, time to onboard, how much of the product an account ends up using.

One number gives you the shape of it. HubSpot’s State of Service data puts teams whose help center was updated in the last 30 days at around 45% ticket deflection. Teams that haven’t audited theirs in six months sit at 18%. Same kind of product, same customers. The variable is maintenance, not writing quality.

A caveat, because you’ll hear inflated versions of this from people selling things. The market median for AI-assisted deflection is closer to 22%. Decks quoting 40% to 60% are usually counting conversations that ended, not problems that got solved. Gartner has found that most AI support deployments miss their deflection targets in the first six months, and the most common reason is the state of the knowledge base.

The headline number isn’t the point. The gap between a maintained help center and a neglected one is now big enough to show up in somebody else’s dashboard.

That changes the conversation about resourcing. Instead of “we should document things properly,” it becomes: here’s a number our support team already reports, and here’s what moves it.

The six questions nobody handed over

So documentation gets produced by more people than ever, with better tools than ever, and the person accountable for it has no framework for judging what comes out. These are the questions I keep hearing, in one form or another:

  1. What do you measure, now that counting pages tells you nothing? Every feature has a page. That’s not the same as a customer being able to finish what they came to do.
  2. You can hand off the writing. What can’t you hand off? Most of this work delegates cleanly, to a person or to a model. Deciding what deserves to exist, and deciding it’s finished, don’t — and those are usually the two with nobody’s name on them.
  3. Who signs off on the text, and against what criteria? The author is usually an expert: a developer, a product manager. But they wrote it with AI, so “the expert wrote it” doesn’t mean what it used to.
  4. What tells you a page needs writing or fixing? If the answer is “a release shipped,” you’re missing the questions your customers are already asking every day, in your search box and your ticket queue.
  5. Who’s actually reading it, and are they getting your answer? Increasingly the reader is an agent, and increasingly the answer isn’t yours.
  6. Why does all of this stop the moment you’re pulled away for three weeks, and what do you do about it? Anything that runs on one person’s attention ends with the first bad quarter.

Let’s go through this properly

Over the past year we’ve talked with 60+ product and documentation teams about how this work runs inside their companies: teams that lost their writers, teams that never had one, teams where the writers never left. The six questions above are what kept coming up.

We’re running a webinar to work through the practical half of it, using one real request end to end: we released SSO, document it. What that request is missing before anyone should start writing. How to work out what your user now needs to be able to do, and whether your docs already cover it. What AI can go and collect for itself, and what you still have to decide. Worked examples, not principles.

Everyone who attends gets our six-lesson course on the management side — the part no tool decides for you.

[Save your seat →]

It’s for whoever documentation now belongs to: the person expected to know whether it’s any good. Whether you’re a technical writer matters less than it used to. What matters is that you’re accountable for text you didn’t write, because AI wrote most of it.

Alexander Muravyov, CEO, ClickHelp

Creating online documentation?

ClickHelp is a modern documentation platform with AI - give it a try!
Start Free Trial

Want to become a better professional?

Get monthly digest on technical writing, UX and web design, overviews of useful free resources and much more.

"*" indicates required fields

Like this post? Share it with others:
Ask AI about ClickHelp
ChatGPT ChatGPT Claude Gemini Grok Perplexity