The dam of AI-written doc contributions might be about to break. It’s already cracking for code, with posts wondering how to review a vibe-coded pull request consisting of nine thousand new lines of code. In the midst of what Tom Johnson describes as acceleration, docs-as-code writers wonder how to contain the seemingly inescapable wave that could bury their backlogs in AI slop. The answer could lie in taking a stance. This means crafting an AI policy for docs.

If you’ve been following the AI space for a while, the MCP acronym might be a familiar sight: it’s an open standard for connecting large language models (LLMs) to tools and data. Without the ability to use tools and get data, AI agents are powerless, their knowledge limited to their training set and the context at hand. Giving in to my curiosity, I created an MCP server to demystify this piece of tech and gain a better understanding of its potential.

Not all is rosy, but if there’s a place where doc tools need to grow, it’s this.

You might have read Annie Mueller’s post poking fun at developers’ tutorials. If you haven’t yet, do it now. On the surface, it’s an exquisite rendition of the kind of technobabble we tech writers get to tame every day. Reactions among devs ranged from nervous snickering to outright shame. Like all the best parodies, Annie’s goes deeper than that, though: It puts a finger on “documentation theater”, a state where docs are performative and not addressing a need nor caring about it. Let me explain why I think writing docs because you are forced to is worse than not having docs at all.

I sometimes lurk on /r/technicalwriting to gauge the interests and sentiments of the community. What I’ve noticed over the years is that pessimism and anxiety have always been quite high; Reddit, it seems, can be a powerful outlet for all sorts of feelings. Here I’d like to analyze and address some of the challenging ones. If you had similar thoughts, I hope my words will prove useful.

Docs are a product. Contributing to them is among the finest forms of product engagement. Bystanders can become builders and authors: They contribute a verse so that the powerful play can go on. They cease being the product to become the owners of the product narrative. And in this AI age, where docs matter more than ever, users who write can steer the future of products.

I’ve been noticing a trend among developers that use AI: they are increasingly writing and structuring docs in context folders so that the AI powered tools they use can build solutions autonomously and with greater accuracy. They now strive to understand information architecture, semantic tagging, docs markup. All of a sudden they’ve discovered docs, so they write more than they code. Because AI must RTFM now.

I’ve been writing documentation and technical articles for more than a decade now. One piece of feedback I consistently got from managers and peers during all these years is how fast I am when producing and releasing docs. For example, I was once asked to document a new feature from a team I wasn’t serving two weeks ahead of launch. Everything was new to me, but I had most of the docs drafted after four days. By launch, the docs had been deemed ready to go live.

Strategy, Michael Porter wrote, is choosing what not to do. Now, the problem with knowledge work such as the one tech writers carry out is that it’s full of things that seem to require equally important, time-consuming decisions. While engaging in lengthy disquisitions might be alluring, endlessly combing the Zen garden of theory doesn’t solve the basic problem of the docs hierarchy of needs, which is writing the damn docs and making sure they’re accurate and useful.

This last weekend I created another LLM-powered tool, Impersonaid (all puns intended). It’s a docs user simulator: you provide the URL of a document (or its Markdown source), select the virtual persona, and start a conversation about the content. Right after I released it, I realized that I had been talking to an imaginary friend to create more fictional interlocutors to interact with. It’s not as bad as it sounds, though. In fact, I would argue this is what writers are meant to do.

A colleague recently asked how I find time to blog about technical writing after hours. The answer is surprisingly simple: I prioritize writing above other things. I could have posted that exchange on social media and called it a day, but there’s more nuance to that simple reply. Let me elaborate, it might be useful.