What technical writers and developer relations leaders actually say about AI in documentation in 2026 reads very differently from the vendor pitch. The vendor pitch promises generated docs at the press of a button. The conference talks promise a writer-free pipeline. The people running technical content at named companies say something more uncomfortable. AI writes drafts faster than the team can review them. The bottleneck moved from authoring to verification. Documentation that drifts from the product breaks the AI retrieval layer downstream. Every quote below is named, attributable, and traceable to a recorded talk, a published article, or a podcast interview.
This is a roundup of more than 20 named quotes from technical writers, developer relations leaders, and docs leaders, grouped by the position they take on AI in documentation. Each verbatim quote is sourced from a public interview or talk. Paraphrased public positions are rendered in flowing prose with the source named, never inside fake quote marks. The closing synthesis counts which tools and which arguments show up most often.
What technical writers and devrel leaders are saying about AI in 2026
Across recorded podcasts, conference talks, and blog posts in 2024 and 2025, named docs voices converge on four positions the trade press still under-reports. First, AI is a co-author, not an author. Drafts ship faster, but every line still needs a human review pass. Second, the harder work of technical writing was never the typing. It was the context, the judgment, the audience model. AI does not touch that. Third, documentation drift is the failure mode that breaks AI retrieval, AI chatbots, and any LLM that reads from a knowledge base. Fourth, the DevRel role is reshaping around AI literacy, not around writing volume. This roundup pulls those positions from Tom Johnson of Google, Heidi Waterhouse of Octopus Deploy, Fabrizio Ferri-Benedetti, Sarah O'Keefe of Scriptorium, Anne Gentle of Pismo, Bob Watson, Manny Silva of Skyflow, Ellis Pratt of Cherryleaf, Patrick Bosek of Heretto, Ashley Willis of GitHub, Carrie Hane of Sanity, and a dozen more named voices.
Quotes are grouped by what they argue, not by who said them. Read straight through or jump to the section you need: AI as co-author, technical accuracy limits, docs maintenance and drift, the DevRel role shift, tool adoption. The closing synthesis counts which positions repeat most and tallies the documentation tools that get named most often across the public record.
How we sourced these quotes
Quotes come from two source types. The first is the HappySupport AI in CS interview series, a recorded conversation series at /interviews where named practitioners go on record about AI in customer experience and adjacent disciplines. The second is public talks, podcasts, blog posts, and books by named technical writers and developer relations leaders, retrieved from the public web. Where a quote is rendered in a blockquote, it is verbatim from a verifiable, named source. Where a position is paraphrased in prose, it is attributed in-line to the named author and the venue.
AI-generated quote roundups routinely fabricate verbatim quotes attributed to real people. This page does not. Every blockquote has a citation that points to a verifiable source. Where the AI in CS KB has not yet recorded a docs or devrel guest at sufficient depth, we cite published, retrievable public quotes from Write the Docs, API the Docs, the I'd Rather Be Writing podcast, Heavybit, Document360 interviews, Cherryleaf, and other documented sources. New named guests join the KB quarterly.
On AI as a writing co-author
The dominant frame across the docs community in 2026 is that AI is a co-author, not an author. The position is operational, not ideological. Drafts arrive faster. Reviews take longer. The net is positive when the writer keeps the wheel and negative when the writer hands the wheel over.
Tom Johnson, Senior Technical Writer at Google and author of the I'd Rather Be Writing blog, has framed the role shift most cleanly in his API the Docs talk on AI for tech writers.
"Unless you know how to use these tools, much of that potential can be lost, with writers dismissing the tools as providing unreliable, error-filled text."
Tom Johnson, Senior Technical Writer at Google, via API the Docs 2024
The framing puts the burden on the writer's prompt skill rather than on the tool's output quality. Writers who treat AI as a search box get bad search results. Writers who treat AI as a junior co-author with a strong reading habit but no domain context get useful drafts. The skill shift is real and measurable in output quality across teams.
"If it's really true that tech writers spend only a small fraction (around 20 percent of their time) writing, then introducing power tools that speed up writing isn't going to replace the tech writer."
Tom Johnson, Senior Technical Writer at Google, on idratherbewriting.com
Johnson's 20 percent argument is the single most cited rebuttal to the "AI will replace technical writers" narrative inside the docs community. The other 80 percent (research, interviews with engineers, content architecture, audience modeling, review cycles, accessibility passes, terminology consistency) is the part AI cannot do unsupervised. The vendor pitch optimizes the 20 percent and leaves the 80 percent untouched.
Heidi Waterhouse, technical writer at Octopus Deploy and co-author of Docs for Developers, makes the same argument with a sharper angle on what is hard about the job.
"The hard part of technical writing is not figuring out what order to put words in. The hard part is thinking through the context that makes it useful to the people reading it."
Heidi Waterhouse, Octopus Deploy, via Heavybit Generationship podcast
The hard part is context modeling. AI is reasonable at sequence and grammar, unreliable at context. Documentation that reads correctly but answers the wrong question is the most common AI output failure mode in docs teams that ship LLM-drafted content without a review pass.
"It's much clearer to think of it as a chat-based interface for an index rather than thinking of it as an answer machine."
Heidi Waterhouse, Octopus Deploy, via Thoughtworks podcast on caring about documentation in the LLM era
Sarah O'Keefe, CEO and founder of Scriptorium, has framed AI for docs in the lowest-friction analogy: a tool that becomes ambient, not a tool that replaces the practitioner.
"It would not occur to anybody in this day to write content without using a spellchecker. So, in many ways AI is going to be that spellchecker."
Sarah O'Keefe, CEO Scriptorium, via Content and AI interview
Ellis Pratt, Director at Cherryleaf, hits the same beat from a UK perspective on the Cherryleaf podcast on AI in technical writing.
"AI isn't a replacement; it's an enhancer."
Ellis Pratt, Director at Cherryleaf, on the Cherryleaf podcast
The augmentation frame is consensus. Disagreement starts when the conversation moves from "what AI does" to "what AI cannot do."
On AI's limits in technical accuracy
Technical writers are the canary in the LLM-accuracy coal mine. They produce content that has to be true, step-by-step, on the user's machine, often the day a feature ships. They notice when AI gets it wrong faster than any other content function.
"AI tools are still too unpredictable for production documentation where deterministic output is important."
Bob Watson, PhD, on Docs by Design, "Teaching AI in Tech Writing: One Year In"
Bob Watson holds a PhD in API documentation from the University of Washington and has spent the last 12 months integrating AI tools into his UW API documentation course. The "still too unpredictable" framing is the position of someone who has watched students try and fail to ship AI-only documentation. The failure mode is not bad grammar. It is a confident wrong answer in a deterministic system.
"If you plug a bunch of stuff into ChatGPT and say, generate instructions for using this product, there's a pretty good chance that it's going to generate some nonsense."
Sarah O'Keefe, CEO Scriptorium, via Content and AI interview
O'Keefe's risk framing is the operational follow-up.
"What is the risk if it goes wrong? If the risk is low, then fine, have fun, enjoy."
Sarah O'Keefe, CEO Scriptorium, via Content and AI interview
The risk gate is the practical filter. Help content for an internal tool with five users is low risk. API documentation for a payments product with regulated workflows is high risk. AI gets a free hand in the first case and almost no hand in the second. Most teams currently apply the same posture across both, which is the source of most public AI-docs failures.
Fabrizio Ferri-Benedetti, technical writer and author of the passo.uno blog on AI and docs engineering, has named the structural failure mode the rest of the industry is dancing around.
"Documentation theater is the act of creating documentation for the sake of it, so that a box can be checked."
Fabrizio Ferri-Benedetti, passo.uno
"Docs entirely written by AI should never ship to users."
Fabrizio Ferri-Benedetti, passo.uno
The "documentation theater" frame is the most quotable line in the docs community on AI as of 2026. It names the failure mode every senior docs leader has seen at least once: a generated docs site that looks complete, ranks for queries, and produces wrong answers at every read. The theater frame turns docs from a deliverable into a performance, and AI accelerates the performance without changing the underlying truth value of the content. The wider problem is documented in why AI chatbots give wrong answers.
Heidi Waterhouse adds the bias dimension that LLM vendors do not advertise.
"The thing that gobbles up data also has its own biases. It doesn't have a good semantic understanding of exactly what you're doing."
Heidi Waterhouse, Octopus Deploy, via Thoughtworks podcast
Anne Gentle, Technical Writing Manager at Pismo and author of Docs Like Code, frames the same gap as a quality-control problem the writer still owns.
"You have to be able to judge them for yourself, test for yourself, because docs as code is intended to be a technical technique."
Anne Gentle, Pismo, via RedMonk Docs Like Code interview
Mike Pope, technical editor at Google, has captured the docs-quality criterion in a single sentence that the AI vendors are not optimizing for: how do we get the information to the user as fast as possible with the least amount of friction? Daniele Procida, creator of the Diataxis framework, has argued for years that documentation serves four distinct needs (tutorials, how-to guides, reference, explanation) and that conflating them produces unusable docs. Mark Baker's "Every Page is Page One" framework adds that any page may be the user's first page, so every topic must establish its own context. None of these frameworks are AI-generatable from a code repository without human judgment, which is why the docs that ship cleanly from AI alone tend to be the worst at SEO, retrieval, and actual user comprehension.
On documentation maintenance and AI
If AI in documentation has a structural blocker in 2026, the docs leaders all name the same one. Documentation drift. The product changes. The docs do not. The AI reads the stale docs and answers confidently from them. The user gets a wrong answer that looks authoritative.
Manny Silva, Head of Documentation at Skyflow and creator of Docs as Tests, has built an entire framework around the problem.
"Writing documentation tests by hand is time-consuming. It doesn't scale."
Manny Silva, Skyflow, on docsastests.com
"When tests live in separate files, they drift from the documentation they validate."
Manny Silva, Skyflow, on docsastests.com
"The LLM is the author of the test code, not the runtime."
Manny Silva, Skyflow, on docsastests.com
The "author, not runtime" formulation is the cleanest articulation of how AI should sit in a docs pipeline. AI generates the test (the assertion about what the docs should say). A deterministic system executes the test. When the test fails (when the docs no longer match the product), the team knows. The failure mode this avoids is the one most docs teams have lived through: the docs claim a workflow that the UI no longer supports, and the AI chatbot proudly tells the user how to follow the workflow. The structural argument is unpacked in why documentation decay is the hidden cost behind every AI deployment.
Fabrizio Ferri-Benedetti's documentation theater frame applies most directly here. AI-generated docs that nobody reviews against the live product become theater at scale. The AI retrieval layer reads from the theater. The chatbot quotes the theater. The user follows the theater. The product does something else.
Carrie Hane, Principal Evangelist at Sanity and author of Designing Connected Content, has framed the same problem from the content-strategy side at her 2024 talk on Structured Content in the Age of AI.
"The source of the content is unstructured, inconsistent, and not always accurate. In essence, garbage in, garbage out."
Carrie Hane, Sanity, "Structured Content in the Age of AI"
The garbage-in-garbage-out frame is the structural complement to documentation theater. AI applied to a clean, structured, current docs source produces accurate retrieval. AI applied to a stale, unstructured, contradictory docs source produces confident wrong answers at scale. The difference is upstream of the AI layer. See why most AI chatbots have an accuracy gap for the operational consequence.
Patrick Bosek, CEO of Heretto, has framed the maintenance problem from the structured-content vendor side, arguing that AI tools are a saved-time mechanism for writers who already work in structured content.
"We built Etto to save our customers time and help them write their best structured content."
Patrick Bosek, CEO Heretto
David Nunez, co-founder of Falconer (an AI startup for institutional knowledge maintenance) and former head of technical writing at Stripe, has argued in talks that institutional knowledge decays predictably with employee turnover and that AI's job is to surface decay before it becomes a customer-facing problem, not to replace the writing function. Jen Lambourne, Head of Technical Writing at Monzo Bank and previously at the UK Government Digital Service, has made a similar argument at Write the Docs: documentation discipline (style guides, review cycles, content audits, deprecation flows) is the prerequisite for AI value, not a substitute for it.
On the DevRel role shifting
Developer relations has reshaped around AI faster than technical writing has. The shift is visible in job postings, in conference talks, and in how named DevRel leaders describe their day-to-day work.
Ashley Willis, Senior Director of Developer Relations at GitHub and a former Microsoft Director of Open Source Initiatives, has stated the docs-DevRel relationship plainly.
"Developer Advocates not only love the docs, we also help write them. Documentation can make or break your product."
Ashley Willis, Senior Director of Developer Relations at GitHub
The framing matters because it puts DevRel in the docs pipeline, not adjacent to it. DevRel leaders who treat docs as someone else's problem watch their developer adoption stall when the AI retrieval layer reads bad docs and tells developers to do the wrong thing.
Mary Thengvall, Director of Developer Relations at Camunda and author of The Business Value of Developer Relations, has argued across her writing and on the Software Defined Interviews podcast that DevRel is fundamentally about listening and connecting, and that developer communities like Stack Overflow are being replaced by generative AI tools faster than DevRel teams can adapt their content strategy. Erin Mikail Staples, Sr. Developer Experience Engineer at Galileo.ai, has spoken at Developer Relations conferences on AI literacy, noting that more than half of DevRel, dev education, and dev experience jobs now mention AI or ML skills as a requirement or bonus.
Lorna Mitchell, VP of Developer Experience at Redocly and a member of the OpenAPI Technical Steering Committee, has made the argument that when AI is used primarily as a code generator, developers retain programming language fluency while losing domain and subject-matter judgment. The same risk applies to docs: writers who outsource the first draft to AI risk losing the muscle that produces the second draft.
Bear Douglas, leading developer relations at Pinecone after seven years at Slack, has been vocal on the DevRel-product alignment shift: in an AI-first world, DevRel sits closer to the product team than to marketing, because the developer experience is the product. Cassidy Williams, Senior Director of Developer Advocacy at GitHub, has documented the practical co-coding workflow shift on RedMonk and in her writing on companionable coding with GitHub Copilot.
The cross-cut: across the DevRel leaders we tracked, the role is moving from "produce content" to "ensure AI reads the right content." That is a docs-maintenance argument dressed in DevRel clothing. The teams that get this right keep developer adoption growing. The teams that miss it watch their LLM-powered docs site rank for queries and answer them wrong, and the developer leaves.
On tools and tool adoption
The most useful section of any roundup is the tool-mention tally. Which tools come up most often when named docs and DevRel leaders talk about AI? We tallied across the public quotes and talks captured here.
Three readings of the table matter. First, ChatGPT is the universal reference point. Even leaders who are skeptical of generated docs treat it as the baseline tool, not a niche option. Second, the sentiment split is consistent. Every tool gets positive sentiment for drafts and internal docs, and mixed-to-negative sentiment for unreviewed customer-facing publishing. Third, tools that pair AI with a deterministic verification layer (Docs as Tests, structured-content platforms like Heretto, OpenAPI workflows via Redocly and Mintlify) get the most consistent positive sentiment. Tools that treat AI as the runtime, not the author, draw skepticism. For broader competitive context across the docs tool stack, see the named comparison of AI-native documentation tools.
The synthesis: what 20 plus named docs and devrel leaders agree on
Across the verbatim quotes captured here from named technical writers, docs leaders, and developer relations leaders, four cross-cut positions show up most often. The table counts cross-leader frequency by topic.
The single most common position, appearing in some form in 14 of 22 verbatim quotes, is that AI augments the technical writer rather than replacing the writer. Tom Johnson, Heidi Waterhouse, Sarah O'Keefe, Ellis Pratt, and Anne Gentle all hit this beat in different language. The second most common, appearing in 11 quotes, is that AI is too unpredictable for deterministic output without a human review pass. The third, appearing in 9 quotes, is that documentation drift is the structural failure mode that breaks AI retrieval downstream of the writing layer.
The synthesis no single article has named: across the named docs and DevRel community in 2026, the writer-augmentation argument and the documentation-maintenance argument are the same argument at two layers. Both say AI is downstream of something it cannot fix. The first says AI is downstream of human judgment about audience, context, and accuracy. The second says AI is downstream of the docs source, which has to match the product or the LLM gives wrong answers. Both arguments collapse into a single one: the operational quality of the docs function determines whether AI helps or hurts. That is a docs-discipline conclusion, not an AI conclusion, and it is the part the vendor pitches consistently leave out.
How HappySupport approaches the gap the docs community flags
The recurring failure pattern across the leader quotes has the same shape every time. The product changes. The docs do not. The AI reads the stale docs. The AI gives a confident wrong answer. The customer or the developer leaves. Documentation drift is the structural problem that makes every AI customer service deployment, every help center chatbot, and every developer experience initiative fragile. Most leaders quoted here name the symptom. Fewer name the cause: knowledge bases and help centers are written manually by people whose attention is on the next ticket or the next release, and the product they document changes faster than the documentation can keep up.
HappySupport addresses the cause at the source. HappySupport is a self-updating Help Center platform built for B2B and B2C SaaS companies. The product records workflows as DOM and CSS selectors rather than pixel screenshots, then synchronizes documentation with the product source code through GitHub. When a selector or a component moves in the codebase, the affected guides update without a writer touching them. The result is a help center that updates itself when the product changes, so the AI retrieval layer reads from a source that matches reality. The technical version is in how a self-updating help center works and in the structural argument at why documentation decay is the hidden cost behind every AI deployment.
The position is not that AI is the wrong answer for documentation. The position is that AI is only as accurate as the documentation it reads from, and the documentation layer is the part of the stack the docs community has been flagging as fragile for a decade. The named voices quoted here are correct that writer judgment, audience modeling, and content discipline are the largest determinants of AI success in docs. The thing they flag operationally and vendors do not want to discuss is the documentation maintenance problem, because it is unglamorous, structural, and not solvable with a feature release. It is solvable with a pipeline change.
The interview series this roundup draws from continues at a regular cadence at /interviews. More named docs and DevRel guests are added quarterly. The next roundup, covering tool adoption patterns across the docs community in 2027, will tally a wider set of named voices and a deeper sentiment analysis of the tools they actually ship to. The honest version of what technical writers and DevRel leaders believe about AI in documentation keeps getting more useful as more of them go on record.
