You’re not just writing docs. You’re building trust.
Manny Silva leads documentation at Skyflow, a privacy-as-an-API company. He’s also the creator of Doc Detective, an open-source documentation testing tool, and the author of Docs as Tests. His approach: if documentation tells users how something works, it should be testable — and those tests should run automatically.
“Documentation is creating a contract with the user that tells them how what they’re using is supposed to work. If any of those statements are invalid, it undermines their trust in your product.”
Doc Detective runs against production environments using real credentials, executing every testable procedure and comparing actual behavior to what’s documented.
“Docs need to pass tests before they go out. I have a production Skyflow account that I own as part of my team, and we use those credentials in our environment to test every procedure we can.”
Unlike synthetic behavior-driven development tests that verify isolated behaviors, documentation-based tests mirror the actual user experience. Engineering teams have welcomed this because end-to-end tests are the flakiest and hardest to design from an engineering perspective.
The approach has caught problems no other testing layer would — including third-party integrations that change without notice.
“I’ve had reports of folks finding out that a third-party changed their integration directly. Their engineers couldn’t have told them because it’s not an internal thing, but they found out because their tests started failing.”
Sean Huck at Adyen approaches the same problem from the organizational side. He manages nine writers and is working to formalize documentation’s role in the product development lifecycle.
“One of our big goals is to be included in every product team’s definition of done. If we can pull that off, I’m super psyched. Because then it’s part of the canon, and they have to adhere to it.”
Where Silva automates the docs-product connection through testing, Huck builds it through relationships and process. His team’s cross-product visibility becomes a strategic asset.
“We want to be that thought partner throughout the journey — that allows us to help guide the direction of the product.”
“The product team is only responsible for one slice. The docs team has to think about all of the considerations, which gives us a much broader view that actually becomes quite valuable.”
Mirna Wong at dbt Labs captures the evolution. Her team has set up automations to detect code changes, notify the docs team, and more neatly integrate into the product development lifecycle: “We’re using agentic workflows so engineers don’t have to remember to tell us when something needs docs.” They've also iterated beyond a “docs as product” approach — documentation as part of the product development cycle — to “docs as a product”, where documentation has its own personas, user journeys, and dedicated UX research.
Whether through automated testing, formal process integration, or embedded team structures, the most effective teams have found ways to detect, verify, and sometimes shape what the product becomes.
You’re not just writing docs. You’re building trust.
Manny Silva leads documentation at Skyflow, a privacy-as-an-API company. He’s also the creator of Doc Detective, an open-source documentation testing tool, and the author of Docs as Tests. His approach: if documentation tells users how something works, it should be testable — and those tests should run automatically.
“Documentation is creating a contract with the user that tells them how what they’re using is supposed to work. If any of those statements are invalid, it undermines their trust in your product.”
Doc Detective runs against production environments using real credentials, executing every testable procedure and comparing actual behavior to what’s documented.
“Docs need to pass tests before they go out. I have a production Skyflow account that I own as part of my team, and we use those credentials in our environment to test every procedure we can.”
Unlike synthetic behavior-driven development tests that verify isolated behaviors, documentation-based tests mirror the actual user experience. Engineering teams have welcomed this because end-to-end tests are the flakiest and hardest to design from an engineering perspective.
The approach has caught problems no other testing layer would — including third-party integrations that change without notice.
“I’ve had reports of folks finding out that a third-party changed their integration directly. Their engineers couldn’t have told them because it’s not an internal thing, but they found out because their tests started failing.”
Sean Huck at Adyen approaches the same problem from the organizational side. He manages nine writers and is working to formalize documentation’s role in the product development lifecycle.
“One of our big goals is to be included in every product team’s definition of done. If we can pull that off, I’m super psyched. Because then it’s part of the canon, and they have to adhere to it.”
Where Silva automates the docs-product connection through testing, Huck builds it through relationships and process. His team’s cross-product visibility becomes a strategic asset.
“We want to be that thought partner throughout the journey — that allows us to help guide the direction of the product.”
“The product team is only responsible for one slice. The docs team has to think about all of the considerations, which gives us a much broader view that actually becomes quite valuable.”
Mirna Wong at dbt Labs captures the evolution. Her team has set up automations to detect code changes, notify the docs team, and more neatly integrate into the product development lifecycle: “We’re using agentic workflows so engineers don’t have to remember to tell us when something needs docs.” They've also iterated beyond a “docs as product” approach — documentation as part of the product development cycle — to “docs as a product”, where documentation has its own personas, user journeys, and dedicated UX research.
Whether through automated testing, formal process integration, or embedded team structures, the most effective teams have found ways to detect, verify, and sometimes shape what the product becomes.
Documentation makes a promise to its readers. When a procedure is wrong, or a feature ships without docs, or the product changes and nobody updates the page — that promise breaks. The featured voices in this section have built their entire approach around closing the gap between what the product does and what the docs say, because they’ve seen what happens when that gap widens unchecked.
Thirty percent of respondents named keeping docs in sync as their single biggest workflow challenge, nearly double the runner-up. But the sync problem is only part of what’s shifting in the relationship between documentation and product.
The sources where users find documentation are changing. AI-powered search now accounts for 35% of discovery, and the gap is closing on traditional search engines. Where they access it is changing too, with MCP servers and coding AI assistants emerging as major channels almost overnight. This section covers all three: the challenge of staying current, the expansion beyond the docs site, and the new discovery landscape teams are navigating.
The #1 challenge: keeping docs in sync
Two-thirds (67%) update docs based on product changes, and 39% use a customer feedback loop. But 21% have no formal process at all.
This challenge varies significantly by role. Engineers feel it most acutely at 43%, compared to 26% for technical writers. This makes sense — engineers see the product changing and know the docs are falling behind, while writers juggle multiple priorities.
“We keep the documentation content close to the source code. That makes it easier to update it as we update the source code, and then we generate that with each release.”
Shahed Nasser
Medusa
“Features do not exist until we write about them and they’re released in the product. I can't skip that part of my job because the functionality doesn’t exist yet.”
Sarah Moir
Sigma Computing
“The work of a writer is of course to create documentation. But it is also to resist documentation when the writer sees it’s not really a documentation problem — it’s a design problem.”
Utsav Banerjee
New Relic
“You have docs written by great people who work hard and care about it, and then those docs go stale and nobody catches it. And there's nothing on the site to detect it and warn the user. That already undermines trust.”
Abraham Raher
Former Cribl, Cisco, Google
“We keep the documentation content close to the source code. That makes it easier to update it as we update the source code, and then we generate that with each release.”
Shahed Nasser
Medusa
“Features do not exist until we write about them and they’re released in the product. I can't skip that part of my job because the functionality doesn’t exist yet.”
Sarah Moir
Sigma Computing
“The work of a writer is of course to create documentation. But it is also to resist documentation when the writer sees it’s not really a documentation problem — it’s a design problem.”
Utsav Banerjee
New Relic
“You have docs written by great people who work hard and care about it, and then those docs go stale and nobody catches it. And there's nothing on the site to detect it and warn the user. That already undermines trust.”
Abraham Raher
Former Cribl, Cisco, Google
Documentation is expanding beyond the docs site
40% offer in-product help (embedded help, tooltips). AI-adjacent channels are emerging fast: 18% of users already access docs through coding AI assistants (Copilot, Cursor), and 16% through MCP servers. These numbers are notable for channels that barely existed two years ago.
These are also the channels teams plan to invest in most aggressively. AI assistants (+9pp gap between current and planned) and MCP servers (+8pp) show the largest planned expansion — far ahead of traditional channels.
“The goal is to get developers the information they need, right where they are, without breaking their flow.”
Usha Mandya
Docker
“I don’t know if the docs site will exist in a few years in the same fashion. I think it’ll be much more integrated into the product experience. The information that flows through it is still critical, but does that need to be distributed in the form of a website? I don’t think so.”
Sara Tandowsky
GitBook
“I would much rather push the information to you automatically, in a more forward-thinking way, than you having to pull the information. You’re in flow, you’re designing, and you don’t want to be clicking around a million search results.”
Sean Huck
Adyen
“The general trend going forward will be keeping the end user within your product. Whether it’s in-app callouts for new features or in-app documentation itself, rather than trying to push people away to your doc site.”
Richard Howard
parcelLab
“The goal is to get developers the information they need, right where they are, without breaking their flow.”
Usha Mandya
Docker
“I don’t know if the docs site will exist in a few years in the same fashion. I think it’ll be much more integrated into the product experience. The information that flows through it is still critical, but does that need to be distributed in the form of a website? I don’t think so.”
Sara Tandowsky
GitBook
“I would much rather push the information to you automatically, in a more forward-thinking way, than you having to pull the information. You’re in flow, you’re designing, and you don’t want to be clicking around a million search results.”
Sean Huck
Adyen
“The general trend going forward will be keeping the end user within your product. Whether it’s in-app callouts for new features or in-app documentation itself, rather than trying to push people away to your doc site.”
Richard Howard
parcelLab
How users discover documentation
The discovery landscape is shifting. While direct navigation (66%) and in-product links (54%) still lead, AI-powered search (ChatGPT, Perplexity, Google AI Overviews) already accounts for 35% of documentation discovery — not far behind traditional search engines at 45%.
This scales with company size: AI-powered discovery goes from 25% at micro-companies to 46% at enterprises. Larger companies are more likely to see their docs consumed through AI channels.
“Organic SEO through Google has historically been really important for most of our websites. That 3-4% of traffic coming from AI bots and tools is a big deal.”
Sandeep Medikonda
ServiceNow
“Previously, people would have searched on Google. I think now they're searching in ChatGPT and they're not necessarily linked. The formats that people have come to rely on no longer apply.”
Aleksandra Zolushkina
JetBrains
“There needs to be some kind of backend — product knowledge infrastructure — where the information lives, because that can't just live in AI. There needs to be more sources, human involvement, and accuracy in the data.”
Sara Tandowsky
GitBook
“We've moved on from the denial phase, and now we know that we're not writing for just readers anymore –we are also writing for LLMs. Some people are going to ask the LLM first.”
Funke Olasupo
Rocket.Chat
“Organic SEO through Google has historically been really important for most of our websites. That 3-4% of traffic coming from AI bots and tools is a big deal.”
Sandeep Medikonda
ServiceNow
“Previously, people would have searched on Google. I think now they're searching in ChatGPT and they're not necessarily linked. The formats that people have come to rely on no longer apply.”
Aleksandra Zolushkina
JetBrains
“There needs to be some kind of backend — product knowledge infrastructure — where the information lives, because that can't just live in AI. There needs to be more sources, human involvement, and accuracy in the data.”
Sara Tandowsky
GitBook
“We've moved on from the denial phase, and now we know that we're not writing for just readers anymore –we are also writing for LLMs. Some people are going to ask the LLM first.”
Funke Olasupo
Rocket.Chat
New for 2026
This section is new for the 2026 survey, reflecting documentation’s growing entanglement with product development. Most questions here — workflow challenges, documentation discovery, access channels beyond the docs site, and planned feature investments — are entirely new. However, one key question carried over from 2025 and is compared below.
Year-over-year comparison
The question “How do you ensure documentation evolves alongside the product?” appeared in both surveys, and not much has changed.
Despite other major developments in tech and documentation, the processes for keeping docs and product aligned have remained stable.
Strategic implications
Keeping docs in sync is a universal problem — and it needs systemic solutions. The 21% with no formal process are accumulating documentation debt. Teams like dbt Labs show what’s possible with AI-assisted change detection, but most organizations haven’t automated this yet.
AI-powered channels are the fastest-growing investment area. AI assistants and MCP servers have the largest gaps between current usage and planned expansion. Teams that don’t plan for AI-based documentation delivery will find their content is consumed through AI anyway — just without their control.
Documentation discovery is no longer just about Google. With 35% of users finding docs through AI-powered search, optimizing for traditional SEO alone is insufficient. Documentation needs to be structured for AI consumption — self-contained pages, explicit context, structured metadata.
