For the forseeable future, AI tools will continue to generate such incomplete and sometime hallucinated outputs that there will be a continuing need for a "human-in-the-loop" to not only use several LLMs to review each other's output but to fact-check the final output. Using one LLM alone results in mediocre quality. Using two LLMs results in (sometimes very) good quality. Use three LLMs with human verification for great/outstanding results.

"1,131 people across the documentation industry responded to the 2026 State of Docs survey — more than 2.5x the number of respondents last year. But the size of the sample matters less than what it represents: a genuine cross-section of the people who create, manage, evaluate, and depend on documentation.

Documentation’s role in purchase decisions is stable and strong, and the case that docs drive business value is well established. The shift this year is in what documentation is being asked to do, and who — and what — is consuming it.

AI has crossed the mainstream threshold for documentation, both in how docs get written and how they get consumed. Users are arriving through AI-powered search tools, coding assistants, and MCP servers. Documentation is becoming the data layer that feeds AI products, onboarding wizards, and developer tools. The teams investing in this shift are treating documentation as context infrastructure, not just a collection of pages.

But adoption has outrun governance, and the gap matters. Most teams are using AI without guidelines in place, and documentation carries a higher accuracy bar than most content. After all, one wrong instruction can break a user’s implementation and erode trust in the product.
(...)
Writers are spending less time drafting and more time fact-checking, validating, and building the context systems that make AI output worth refining."

https://www.stateofdocs.com/2026/introduction-and-demographics

#TechnicalWriting #TechnicalCommunication #SoftwareDocumentation #DocsAsProduct #AI #GenerativeAI

"Start small:

Pick one repeatable task that an agent currently handles without explicit guidance. Document it as a skill with entry criteria, steps, and exit criteria.

Validate it. Install skill-validator and run skill-validator check against your skill. Fix what it finds.

Test it with the agent. Invoke the skill explicitly and observe whether the agent follows it as written. Where it deviates, the skill is probably ambiguous.

Add validation to CI. Once you have a few skills, the CI integration keeps them from degrading as the project evolves.

Perhaps unsurprisingly, this is the same pattern I described for project descriptions: start with one file, observe how agents respond, iterate. The difference is that skills demand more precision because they're more prescriptive. That higher quality bar makes deterministic validation tooling valuable; you get feedback on skill quality before the agent runs, not after."

https://instructionmanuel.com/writing-skills-agents-can-execute

#AI #AIAgents #GenerativeAI #Skills #LLMs #TechnicalWriting #Documentation #SoftwareDocumentation

"In my post The Emerging Picture of a Changed Profession: Cyborg Technical Writers — Augmented, Not Replaced, by AI, I mentioned an upcoming presentation I'm giving to students and faculty. I argue that the future of the profession is the cyborg model, where machines augment our capabilities rather than replace us. In this post, I share notes about what skills a tech writer would need to learn to thrive in this world of augmentation.

If you have feedback about these skills, let me know. My intent here is to demonstrate what actual skills should be emphasized for those entering the profession, or for those currently in the profession who want to get ahead with AI. Note that the following sections are mostly bullet points, in the form of notes."

https://idratherbewriting.com/blog/10-principles-of-cyborg-technical-writer

#TechnicalWriting #TechnicalCommunication #SoftwareDocumentation #Documentation #AI #GenerativeAI #LLMs

"I ask AI to explain things all the time. If I observe it do something that I want to learn more about, I ask it. I look at its outputs and ask it to explain decisions it made or how it implemented something. I ask it to help me brainstorm about things, help me think through edge cases or performance considerations, you name it. If the thing that it is explaining has some implication I need to verify, I ask it to find me a link that backs up what it is saying. And then I look at the link to make sure the content is real, comes from a reasonable source, and actually backs up what the AI says. And probaly also ask it questions about the surface area around the thing, until I’m sure I understand it.

If you approach the AI upskill process as a collaborative learning process, where you can interrogate the tool you’re learning about its capabilities, how and why it’s chosing to do the things it’s doing, and to explain anything you don’t understand along the way - you’re unlocking a super power.

AND you have the comfort of knowing you’re asking all your questions of a talking box that won’t remember what you asked the next time it chats with you. So even if you do think it’s judging you, it has amnesia and that judgement won’t last beyond closing the session!"

https://dacharycarey.com/2026/02/23/upskilling-in-ai-age/

#TechnicalWriting #AI #LLMs #AIAgents #Chatbots #SoftwareDocumentation

Indeed, we can't allow autopilot to head into a whirlwind...

"We may be doing docs-as-code, but docs are not code. Docs run on people, and people are a messy tangle of goals, skills, and emotions. When docs hit the brain, they meet varying expectations, knowledge levels, reading abilities, and needs. None of this can be reproduced or simplified to a single pattern, but good docs use structure and words wisely to produce the best possible linguistic shape that can land safely on most people’s heads. Only humans can decide whether that message is getting across in the right way.

Getting there is a balancing act between business needs, user needs, and your own. That’s the diplomatic tension that forces all good tech writers to slow down and consider all points of view in the room as if they were in the middle of a spaghetti Western standoff. Slowing down is a deliberate, necessary act in all crafts, and tech writing is no exception. No matter how fast LLMs can churn out drafts, they don’t understand the tension in tech writing, to which we’re adding AI itself as an additional consumer of docs.
(...)
The quality of the docs I produce is still high, I was saying. That’s because I’m not letting LLMs take the steering wheel, and because I’m building new habits around them: setting up guardrails, automating what can be automated, and keeping my hands on the decisions that matter. I can do that because I know what good docs look like, and because I’ve been doing this long enough to feel when something’s off. That intuition came from years of wrestling with products and watching users struggle with pages I thought were clear. AI can help me write faster. It cannot replace the slow accumulation of judgment that tells me when to stop."

https://passo.uno/real-cost-of-documentation/

#TechnicalWriting #SoftwareDocumentation #AI #DocsAsCode #GenerativeAI #LLMs #SoftwareDevelopment #AISlop #Programming #TechnicalCommunication #Documentation

"Too often, API documentation writing is introduced as a series of rules or gut feeling about what seems obvious. Beginning writing, that’s a good approach. They’re easily understood and conform to. They’re rarely wrong. They’re far from complete, however.

API documentation writing is an art, not a science. As the artist, your influence is no less important than anyone else’s. But you’ll need to understand more in order to take the writing to a new level. You’ll need to know theory, the hows and whys, and to think like a programmer. The theory here is not only to connect with clients but also to present information in the most efficient way possible. It’s the last points that learning API documentation writing does not do well.

The following is a talk through. I talk about an element in conversational detail. I aim to discuss the important points, why an approach may be inappropriate, what the goals should be, and how to fix it. Along the way, I may make blunt statements. I do that for effect. By exposing the reason for the critique, we can get an understanding of the solution. We’ll look at this from the writer’s perspective."

https://robertdelwood.medium.com/improving-api-documentation-describing-one-parameter-at-a-time-cb53a89637a2?postPublishedType=initial

#TechnicalWriting #APIDocumentation #SoftwareDocumentation #SoftwareDevelopment #Programming #APIs #TechnicalCommunication

"Test your documentation site against the Agent-Friendly Documentation Spec.

Agents don't use docs like humans. They hit truncation limits, get walls of CSS instead of content, can't follow cross-host redirects, and don't know about quality-of-life improvements like llms.txt or .md docs pages that would make life swell. Maybe this is because the industry has lacked guidance - until now.

afdocs runs 21 checks across 8 categories to evaluate how well your docs serve agent consumers. 10 are fully implemented; the rest return skip until completed."

https://www.npmjs.com/package/afdocs

#TechnicalWriting #SoftwareDocumentation #AI #AIAgents #Afdocs #Markdown #DocsAsCode #LLMSTXT

Exactly my thoughts!

"We’re at the same point with automation right now as autonomous cars. Autonomous driving is only possible on well-traveled, predictable roads with little variation or surprise, on routes that have been mapped and re-mapped, test-driven and re-driven, and constantly monitored. In the tech writer role, there are some repeatable tasks that are like well-traveled roads (for example, a weekly report), but more often, we tech writers find ourselves going down many new roads each day, each with their own unexpected twists, turns, and bumps. That unpredictability makes automation difficult, requiring frequent human steering and input to avoid crashing.

Until more tech workers have automated complex processes end-to-end, I’d like for the industry to more readily acknowledge a different model that better describes reality: the cyborg model. This cyborg metaphor comes from a research paper called The Jagged Edge, which I referenced in my book review of Co-Intelligence and explained in my post Why attitudes and experiences differ so much with regards to AI among technical writers. In short, the cyborg model is humans + AI working together. The machine augments, rather than replaces, the human, and vice versa. This cyborg model describes nearly every tech writer who uses AI: there’s a frequent back-and-forth collaboration to produce content.

This frequent back-and-forth collaboration is exactly the message I want to share with students and faculty: humans aren’t being replaced (at least not yet)."

https://idratherbewriting.com/blog/cyborg-model-emerging-talk

#TechnicalWriting #AI #GenerativeAI #LLMs #AIAgents #HumanInTheLoop #SoftwareDocumentation #Automation #Productivity

"After working with AI tools for a while, I am always thinking of that next tedious, large-scale documentation task, and how AI can help with building a reusable workflow. This project is what happens, I think, from taking my own advice. Not one command, but six tools, a standalone Python validator, and a workflow that made it possible to rename four products in three days.

The tools were not designed upfront. The image scanner was born when I realized I could not easily search screenshots. The validator came from a failed build caused by a missed YAML reference. The redirect tool came from the fear of breaking hundreds of bookmarks. Each problem, encountered during execution, became a conversation with AI, and each conversation became a tool.

In three days: 695 files touched, 71 redirects added, 486 images audited, 349 URL mappings verified. The tools did not just save time — they made the project feasible. Without them, this would have been weeks of error-prone manual work.

You do not need to plan an entire toolkit upfront. Start solving the immediate problem. As new problems come up, keep chatting with the AI. The tools will emerge naturally — and they will be better for it, because they are shaped by real needs, not hypothetical requirements."

https://www.linkedin.com/pulse/from-one-tool-full-toolkit-how-i-used-ai-rename-4-across-florindo-l2f2e

#TechnicalWriting #SoftwareDocumentation #AI #GenerativeAI #LLMs #SoftwareDevelopment #Programming #VibeCoding

"Over the weekend, I spent about 10 hours working with Claude to manually validate 578 coding patterns across a range of languages and coding tasks for my Agent Skill Report. We had to deep dive into standard library docs, package-specific documentation, large enterprise docs, and personal blogs. My goal was to ensure that every API and configuration pattern I was using in a behavioral evaluation experiment reflected the current guidance from official sources. My learnings about agent docs access patterns were secondary to this project, but the results are a rich treasure trove of data that may inform how I use agents with docs in the future. As a technical writer who has worked on SaaS and developer docs for the last decade, honestly, my findings made me a little sad.
(...)
My high-level takeaway was this: I expected an agent to try to use docs like I do, and was very surprised when it didn’t.
(...)
Over the course of validating 578 patterns across 20 different skills, my agent and I built up a pretty comprehensive picture of what documentation access patterns actually work for agents, and which ones don’t. I had my agent keep a running reference doc of its learnings, and by the end of the project, the patterns were clear enough to categorize."

https://dacharycarey.com/2026/02/18/agent-friendly-docs/

#TechnicalWriting #TechnicalCommunication #AI #AIAgents #LLMs #Chatbots #AgenticAI #SoftwareDocumentation #APIs #Docs #Documentation