Second episode of the AI & Docs podcast series is up! In this episode, Tom and I talk about MCP servers with Anandi Knuppel. As Anandi says, “wherever there are words with regards to a technical product, that’s the technical writer’s domain”. Don’t miss it!

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.

Kate Mueller’s The Not-Boring Tech Writer is one of my favorite tech writing podcasts. In Growing as a technical writer in the AI era, Kate and I talked about the Seven-action Docs Model and how to grow as a tech writer. Don’t miss it!

It’s official! Tom Johnson and I teamed up to start an AI & Docs podcast! We had this idea brewing for a while and finally got to record the thing.

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.

Today I discussed how tech writers can use AI at work with Tom Johnson and Scott Abel. It all started from my post What’s wrong with AI-generated docs, though we didn’t just focus on the negatives; in fact, we ended up acknowledging that, while AI has limitations, it’s also the most powerful productivity tool at our disposal. Here are some of the things I said during the webinar, transcribed and edited for clarity.

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.