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

The State of Docs Report 2026 – Introduction and Demographics

The State of Documentation Report by GitBook

Today's Featured Links post links to articles about how scientists are going to transport antimatter, using AI for technical documentation, why your next TV shouldn't be smart, and more.

https://coredump3.blogspot.com/2026/03/featured-links-march-18-2026.html

#AI, #History, #Medical, #Politics, #Science, #Software, #Space, #TechnicalCommunication, #Technology

Featured Links - March 18, 2026

Things I found interesting but didn't want to do a full blog post about. Birds wintering on the Bay Please drive carefully: scientists plan ...

"I’ve used AI to accelerate all my work, and yet, I’m still busy as ever. This is what I wrote about in Changing the AI narrative from liberation to acceleration. This notion that AI will do our work while we focus on other things … uh, yeah, that big chunk of time where Gemini does my work for me while I have time to daydream about system design and content architecture — that chunk of time never seems to materialize on my calendar. My days (which are often meetingless, actually) are filled with an endless queue of doc requests, needed updates, release notes, new features to document, and more.

So maybe as we peer into the future, signs of how it will play out are already present. It’s a bit like watching children grow up — the personality traits visible in the toddler years turn out to be the same ones you see in the adult. Five years from now, we might look back and say, why didn’t we see what was so clearly right there?

What is the pattern of the present? Acceleration, being busier than ever, all while using AI more than ever. If I instead noticed the opposite, a kind of winding down of my own activity and involvement while AI gradually takes on more and more of the activity of my day, that would tell a different story. The paradox is that AI is taking on more activity, but it’s pulling me along with it. I’m an active collaborator, shaping conversations, providing context, evaluating outputs, running verification, deciding the approaches, and so on. AI augments and accelerates our work rather than replacing it. We have the most powerful tools available to us, more so than at any time previously. Is it any wonder that we’re now building skyscrapers instead of doghouses, and that those skyscrapers require a lot of work?"

https://idratherbewriting.com/blog/nobody-knows-two-years-from-now

#AI #GenerativeAI #Automation #Productivity #TechnicalWriting #TechnicalCommunication

Nobody knows what it will look like in 2 years

Nobody knows what programming will look like in two years by Charles Humble (published Feb 18, 2026, on LeadDev.com) is an honest, refreshing take from a programmer wrestling with the uncertainty of the future of programming. He looks at historical trends of new technologies (terminals) replacing old ones (punchcards) and grapples with what programming skills are still relevant. The article connects nicely with what I was exploring in 10 principles of the cyborg technical writer.

I’d Rather Be Writing Blog and API doc course

"The people best positioned to configure AI agents like Claude Code aren't engineers. They're technical writers.

It's a bold claim, so let me back it up.

Here's a file that powers an AI agent:

AGENTS.md

# AGENTS.md — API Documentation Repository

## Workflow Rules

- Human review required for API reference changes
- Style guide compliance checked automatically via CI
- Maximum 3 AI revision cycles before human takeover

## Escalation

- Writer agent fails after 3 attempts → human writer takes over
- Reviewer agent flags accuracy concern → SME review required
Markdown syntax, structured headings, rules about workflows and handoffs. If you've written a README, a style guide, or onboarding documentation, this looks familiar because it that's effectively what it is. The files that configure AI agents are Markdown files with structured frontmatter. They're documentation.

The difference is the audience: instead of a human colleague, you're writing for an AI model that's highly knowledgeable but has zero institutional memory. The challenge is one technical communicators already navigate: deciding what to include, how to structure it, and what level of detail serves the reader.

So what kinds of files are involved?"

https://instructionmanuel.com/agent-configs-are-docs

#TechnicalWriting #AI #LLMs #AIAgents #AgenticAI #TechnicalCommunication #Markdown #README

The Most Actionable Docs Around: Agent Configs | Instruction Manuel

Agent Configurations Are Documentation banner

"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

10 principles of the cyborg technical writer – brief notes and bullet points on how to use AI to augment your role

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.

I’d Rather Be Writing Blog and API doc course

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

The writing was always the cheap part

Last December, quite unrealistically, I took a solemn oath: I would not write again about AI for at least another year. I was growing tired with the incessant noise, the lack of stability, and the self-imposed stress of keeping up with all the attention we must spend on factoids such as how well an LLM can draw a pelican riding a bike, which bury the important aspects of our craft as if they were mere prompt flourish. With my passionate epistle, I thought I’d said all I had to say. I was wrong.

"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

Improving API Documentation Describing One Parameter at a Time

By Robert Delwood, a lead API documentation writer

Medium

Architect Elevator Complete Collection by Gregor Hohpe is the featured bundle on Leanpub!

Own all three books in the Architect Elevator series for 900 pages of large-scale IT architecture! First, rethink the role of the architect, and then apply it to two major anchors of any IT strategy: cloud computing and platforms.

Link: https://leanpub.com/b/architectelevatorcollection

#SoftwareArchitecture #ComputerProgramming #DigitalTransformation #EnterpriseArchitecture #BusinessItAlignment #TechnicalCommunication

Architect Elevator Complete Collection

Own all three books in the Architect Elevator series for 900 pages of large-scale IT architecture! First, rethink the role of the architect, and then apply it to two major anchors of any IT strategy: cloud computing and platforms.

"Over the years, we’ve had the pleasure of hosting many exceptional speakers on the Nordic APIs stage. Our most memorable talks span architectural deep dives, anti-patterns, emerging trends, personal journeys, and hard-earned lessons on what it takes to build great API platforms.

To the audience, these presentations often look effortless. But the truth is, there’s a lot of preparation that goes on behind the scenes. This is especially true for the talks that resonate with the audience the most. So what separates an average tech talk from a standout one?

We checked in with a few of our most well-regarded speakers to pull the curtain back on their process, from originating an idea, all the way through to rehearsing it and nailing it with confidence on the day. The result is a set of practical tips for crafting tech talks that land. While the tips come from the API community and are geared toward tech talks, much of the wisdom applies to any public speaking engagement, whether you’re a first-time speaker or industry veteran.

And if reading these conference speaking tips leaves you inspired to take the stage yourself, we’d love to hear from you. Consider submitting a talk proposal for Platform Summit."

https://nordicapis.com/10-tips-on-giving-standout-talks-at-developer-conferences/

#DeveloperRelations #DeveloperExperience #DX #Presentations #TechnicalCommunication #APIs

10 Tips on Giving Standout Talks at Developer Conferences | Nordic APIs |

Practical tips from experienced speakers on preparing standout talks for developer conferences, from narrative to delivery.

Nordic APIs

"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

Agent-Friendly Docs | Dachary Carey

In which I ask an agent to view hundreds of docs pages - and feel sad.