GitBook’s State of the Docs 2026 is an annual industry report that surveys technical writers on everything from AI adoption to team structure to career development. It covers topics like purchase decisions, docs tooling, measuring success, and how AI is changing both how documentation is created and how it’s consumed.
I read the report and want to highlight the parts I found most interesting — including a few quotes from other practitioners that really made me think. Below are my top five takeaways.
Insight #5: AI Is Breaking the Metrics We’ve Always Relied On
This quote from the report stuck with me:
“The clearest illustration is a story Ian Alton at Airbyte recounts about Tailwind CSS: their documentation became so good that AI agents could write Tailwind code on users’ behalf. Page views collapsed — not because the docs had failed, but because they’d succeeded in a way the metric couldn’t see.”
Page views are dropping — not because the docs are bad, but because users no longer need to visit the site. AI agents are consuming the documentation and delivering the answers directly. The docs worked. The metric just couldn’t see it.
Sarah Tandowsky puts it plainly in the report: “I don’t know if the docs site will exist in a few years in the same fashion.”
This is where I think Generative Engine Optimization (GEO) comes in. Just like SEO helped technical writers think about structuring content for search engines, GEO is about structuring content so that AI tools can surface it accurately. The good news? About 80% of what made great SEO — clear headings, plain language, structured lists, metadata — is the same foundation for GEO. The major shift is the goal: in SEO, you wanted a #1 ranking so users clicked through to your site. In GEO, you want your content pulled into the answer itself. Success looks different, but good writing fundamentals haven’t changed.
Insight #4: A Surprising Number of Teams Still Don’t Track Any Docs Metrics
The report asked which metrics documentation teams track. Here’s what they said:
| Metric | % |
|---|---|
| Page views / engagement | 33% |
| Written user feedback | 32% |
| Search queries / analytics | 26% |
| User satisfaction scores | 25% |
| We don’t track any metrics | 24% |
| Support ticket deflection | 23% |
| SEO / organic traffic | 18% |
| Time to value / activation speed | 14% |
| Revenue impact | 12% |
| Conversion rate | 12% |
| Lead generation / trial sign-ups | 11% |
| Bounce rate | 10% |
Page views at #1 makes sense — at some of my previous employers, technical documentation was the highest-trafficked web property at the company. That’s a powerful number to bring to a department all-hands.
But the stat that jumped out at me: 24% of teams don’t track any metrics at all. That’s a quarter of the industry flying blind. Even a basic combination of page views, unique visitors, and written user feedback gives you a meaningful picture of how end-users are engaging with your docs. I think the technical writing community could benefit from an industry-standard framework for documentation metrics — something with broader adoption and recognition, similar to what exists in product or marketing.
Insight #3: Context Engineering Is Becoming a Core Skill
Sarah Sanders of PostHog shared this in the report:
“We want [the agent] to enable PostHog engineers to own documentation from start to finish, ideally getting them 60% of the way on the first try. When we weren’t giving it good context, it was just all over the place.”
I can relate to this firsthand. When I write vague prompts or skip the context, I end up going through multiple rounds of refinement just to get something usable. The quality of the input shapes the quality of the output — every time.
This is why context engineering matters. It’s not just about writing better prompts. It’s about intentionally shaping the information an AI system receives so it can produce accurate, useful results.
The report also points out something I think is underappreciated:
“When a user reads documentation, they can compensate for a confusing instruction, skip ahead, or search for a better explanation. When an AI agent consumes documentation, it follows what’s written literally, may only see a fraction of the page, and has no way to signal that something felt off.”
That changes the stakes. Humans bring intuition to reading. AI does not. So technical writers now face the same challenge from two angles:
- When writing prompts: provide clear, structured, complete context
- When writing documentation: ensure content is explicit, self-contained, and unambiguous
The goal in both cases is the same: reduce ambiguity. That’s just good writing — applied to a new kind of reader.
Insight #2: How Teams Are Actually Implementing AI in Docs
A question that comes up constantly at the Write the Docs Bay Area meetups I organize is: how are you actually using AI in your day-to-day work? The report’s survey results gave me some useful data points:
| Feature | % |
|---|---|
| Conversational AI interface | 38% |
| AI-enhanced search | 35% |
| Translation | 23% |
| Auto-generated summaries | 20% |
| MCP server connections | 20% |
| Personalized content recommendations | 14% |
| Code generation from docs | 14% |
| None yet | 27% |
| I don’t know | 7% |
Conversational AI interfaces and AI-enhanced search are the top two — and I think they make sense together. They solve different problems. A conversational interface shifts users from navigating pages to having a guided experience: ask a question, get a contextual answer. AI-enhanced search improves precision and retrieval, especially for experienced users who know what they want but can’t find it fast.
These two aren’t competing — they’re complementary. Search helps users find information; conversational interfaces help them understand and apply it. Together, they reduce friction across the entire user journey.
What’s also worth noting: 27% of teams have implemented nothing yet. AI adoption in docs is still early. There’s interest, but there’s also a clear gap in implementation.
Insight #1: The Skills Technical Writers Are Prioritizing
This was my favorite section because professional development is something I care a lot about. The survey asked which skills technical writers believe they should be leveling up in:
| Skill | % |
|---|---|
| AI / prompt engineering | 50% |
| Information architecture | 40% |
| Content strategy | 38% |
| Developer tools (Git, IDEs) | 35% |
| Proofreading / content editing | 34% |
| Product management | 30% |
| API design knowledge | 25% |
| Coding / scripting | 24% |
| Data analysis | 23% |
| Developer relations / community | 20% |
AI and prompt engineering at #1 with 50% makes total sense. Technical writers are no longer just writing content — we’re increasingly shaping how AI systems generate and consume it.
Information architecture at #2 with 40% is directly tied to this. As AI retrieves and processes documentation in chunks, how content is structured becomes as important as what it says. Modular, self-contained content that can be retrieved accurately is the new gold standard.
Content strategy at #3 is evolving too. It’s no longer just about planning what to write — it now includes deciding what should be human-facing vs. AI-consumable, ensuring consistency at scale, and identifying content gaps that affect search and retrieval.
A few others worth calling out:
- Proofreading and editing (34%) — As AI generates more content, technical writers become quality gatekeepers. Reviewing and refining AI output requires sharp editorial judgment.
- Product management (30%) — Documentation is increasingly being treated as a product. Writers who understand user needs, prioritization, and metrics become strategic contributors, not just content producers.
What should technical writers actually do next?
- AI / Prompt Engineering: Experiment with ChatGPT, Claude, and similar tools. Practice writing structured prompts with clear goals and constraints. Notice how different inputs change the output.
- Information Architecture: Audit your docs for modularity. Break large topics into self-contained sections. Standardize templates and headings.
- Developer Tools: Get comfortable with Git basics — branching, pull requests, reviews. Look into docs-as-code workflows.
- Editing & Quality: Practice reviewing AI-generated content critically. Focus on accuracy, consistency, and clarity.
- Product Thinking: Look at support tickets and user feedback. Track how your documentation is being used. Think in terms of outcomes, not just outputs.
Final Thought
What I appreciate most about the State of the Docs 2026 report is that it confirms what many of us have been sensing for a while: the role of the technical writer is expanding, not disappearing. The skills that matter most right now — clear writing, solid structure, critical thinking, user empathy — are the same ones we’ve always needed. AI is changing who reads our docs and how they get used. But the fundamentals of good documentation remain the same.
Stay up to date with Write the Docs Bay Area events by subscribing to my LUMA calendar.
If you’re in the San Francisco Bay Area, join us for the State of the Docs 2026 Live Panel — sponsored by GitBook.
About the author: Doug Purcell is a technical writer and community organizer based in the San Francisco Bay Area. He organizes Write the Docs Bay Area and is passionate about the intersection of AI, documentation, and professional development. Connect with him on LinkedIn.
