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.

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.

I spoke at the betterCode() ArchDoc 2025 conference a couple of weeks ago about the Seven Action Documentation model. It was a very nice experience and I thank the organizers for inviting me and letting me post the video. Here is the full recording of the presentation (it’s about 40 minutes long):

We all want to do a good job. Some of us also want to get better at our craft for a number of reasons, either practical or slightly delusional. Those include getting a raise, strengthening our résume, or simply ending the day with a fragile feeling of satisfaction after surviving failure for the nth time. They’re all good goals, though the ways of achieving them are not always straightforward. Moreover, the path to career growth is riddled with self-doubt and impostor syndrome.

While some developers wrinkle their noses at the sight of Copilot and similar AI-powered tools, tech writers find them to be great sidekicks. Creating a script to automate edits or content migrations takes at most a few minutes of tinkering. The same goes for code examples and snippets for dev documentation, docs sites’ enhancements, and even wacky experiments in retrocomputing. With local LLMs running at decent speed on laptops, not even carbon footprint is a concern.

I’ve recently upgraded some of the hardware I use for work and leisure, so it’s a good time to refresh my list of tech writing gear. At the same time, after working as a documentation engineer, I also picked up new favorite tools, especially AI-powered ones. Some I already use at work, while others I keep for personal projects. Let me tell you of some of the recent additions to my personal inventory and why I think they’re making me more productive.