Developers aren't reading your docs

At least, not in the way they used to. They're asking AI from their IDE instead. Here's how to make that work for you.

A developer needs to set up authentication using your SDK.

Two years ago, they’d open your docs site and read the guide. Today, they type “How do I authenticate with this API?” in Claude Code. The AI answers, writes the code, and moves on. Your docs site never sees a pageview.

Some engineers at Anthropic and OpenAI report that AI now writes 100% of their code. If developers aren’t writing much of the code themselves, they’re certainly not browsing your docs to figure out how to write it.

We’re seeing this in the documentation projects we work on. AI-driven traffic to docs sites is growing while human visits drop. Mintlify reports that almost half of documentation site traffic now comes from AI agents, not humans. Your docs have a new primary reader, and it doesn’t browse. It queries.

From reading to asking

Documentation always competed with Stack Overflow, GitHub issues, and asking a coworker on Slack. AI coding assistants just won that competition. When you can describe your problem in natural language and get working code back, in context, inside your editor, there’s no reason to open a docs site.

But that doesn’t mean docs matter less. If anything, accuracy matters more now. A human reading a confusing paragraph will slow down, re-read, maybe search for other sources. An AI will pick an interpretation and ship it.

The problem with public AI models

When a developer asks an AI about your product, the model either relies on training data or searches the web, and both are broken.

Training data is stale. If you shipped a new SDK version last month, the model doesn’t know, and it’ll suggest deprecated methods with full confidence. Web search relies on SEO, so the model might surface a three-year-old Medium article instead of your current API reference. Your discoverability depends on how well you rank, not on how good your docs are.

Neither approach has any special relationship with your documentation. The model doesn’t know your custom error codes or the migration guide you published last Tuesday. So it generates code based on outdated examples and wrong parameter names, and the developer doesn’t find out the answer was wrong until something breaks.

It gets worse for internal docs

If public docs have a discoverability problem, internal docs are completely invisible.

Your internal wiki, your Confluence spaces, your private Notion pages. AI models can’t see any of it. A new engineer joins your team, asks their AI assistant “How do I deploy to staging?”, and gets nothing useful. The model wasn’t trained on your deployment runbook, and it can’t search your internal network. Every AI tool your developers use daily is blind to the documentation they need most.

Connect your docs to the tools developers actually use

There’s a fix. Instead of hoping AI models happen to find your docs, you can connect your documentation directly to the AI tools developers already use.

This is what the Model Context Protocol (MCP) enables. It’s an open standard that lets AI assistants connect to external data sources, a bridge between an AI coding assistant and your documentation. With an MCP server pointing at your docs, the assistant fetches answers directly from your content in real time, not from training data and not from Google.

The part worth understanding is how the assistant decides when to use it. You register a description of what your docs contain, and the AI uses that description to decide when to query them. If a developer is working with your SDK and hits an authentication problem, the assistant knows your docs are the right place to look. It isn’t a keyword search. The AI decides based on context.

What this means for documentation teams

Your docs go from a website people browse to a data source AI tools query, and that shifts what matters.

Content quality counts for more, not less. Every ambiguity, every outdated example, every missing step gets amplified, because bad docs now produce bad AI answers at scale. Good docs produce answers that make developers trust your product.

Internal docs become reachable too. That deployment runbook, your team’s coding standards, your architecture decision records: MCP can expose them to AI assistants inside your organization.

And you get better feedback than pageviews ever gave you. When AI assistants query your docs, you can see what questions are being asked, which is direct signal about what developers are actually trying to do.

What this doesn’t fix

MCP doesn’t fix bad docs. If your content is incomplete or outdated, AI will serve incomplete, outdated answers, just faster.

It doesn’t eliminate hallucinations either, though it gets things wrong less often when it has access to the right content. Your docs site is still the canonical source of truth. When AI gives a wrong answer, that’s where developers go to verify. MCP just makes your content reachable from more places.

Where to start

Start thinking about how AI assistants consume your content, not how humans read it. Structured content, clear headings, explicit examples: these matter even more when your new reader parses pages instead of browsing them.

Then look into how MCP can work for your docs. Connect it to the tools your team already uses, and see what questions come in.

Your docs are already being consumed by AI. The only question is whether you’re serving the right answers or letting the model guess.