On the developer documentation sites that Mintlify runs for its customers, most visitors are no longer people. AI agents now account for roughly 80% of that traffic, up from about 15% a year earlier, and only about one request in five still comes straight from a human’s browser. The obvious reaction would be to rebuild docs for machines. Mintlify’s CEO argues for the opposite: keep designing documentation for human comprehension, and layer agent-friendly features on top. Here is the reasoning behind that advice, and what teams that ship APIs and developer tools can do about it now.
The numbers behind the shift
Mintlify powers documentation and knowledge bases for more than 20,000 companies, and its network draws more than 100 million visitors a month. A shift at that scale is hard to dismiss as a niche trend.
| Metric | Figure |
|---|---|
| Companies whose docs run on Mintlify | More than 20,000 |
| Monthly visitors across Mintlify-powered sites | More than 100 million |
| AI agent share of traffic a year earlier | About 15% |
| AI agent share of traffic now | About 80% |
| Requests coming directly from human browsers | About 20% |
Numbers like these force a basic question: who is documentation really for? The CEO says that an 80% agent share fundamentally changes how software companies need to think about and build their products.
Yet human readers have not gone away. Even as agent traffic grew by orders of magnitude, the absolute number of people visiting documentation sites kept rising. More developers are entering the tech industry than ever before, and they still need content written for people. Humans have become a minority of the traffic, but in raw numbers they are still a growing audience.
▲ Agent and human visitors both growing
Why agent-only docs backfire
Faced with an 80% figure, a company may be tempted to stop investing in the human reading experience. The extreme version is a single giant raw Markdown file for agents, with a chat window as the only way in. The CEO calls this a common overreaction.
In practice, products that ship agent-only or chat-only documentation make it hard for people to judge what the product can actually do. That sets off a chain reaction:
- Engineers cannot browse the docs to understand the product’s capabilities.
- They skip trying it and do not recommend it to colleagues.
- Few positive mentions build up on Reddit, developer forums and blogs.
- AI agents, which draw on that public conversation, do not recommend the product either.
The last step may be the least obvious. Agents do not have preferences of their own. They reflect the consensus of human developer communities, filtered through their training data and the search indexes they pull from. That makes generative engine optimization (GEO), the work of getting a product to show up in AI-generated answers and recommendations, a function of what human developers say in public. In the CEO’s view, winning over those developers remains the priority.
There is also the question of whom agents serve. They act on behalf of people rather than as independent economic actors. Before an agent can do useful work, a person has to know what to ask and how to prompt it. To trust the result, that person needs transparent sources, verification links and information they can review. The CEO compares abandoning human documentation to abandoning books: people still read books and browse websites in the age of generative AI.
Agents write the code, people still pick the stack
Looking at what agents now handle and what people still decide helps explain why docs must keep persuading humans.
| Type of work | Examples | Who handles it |
|---|---|---|
| Low-level implementation | Boilerplate code, endpoint queries, small syntax details | Heavily automated by AI coding agents |
| High-level decisions | Choosing core infrastructure such as Supabase, ClickHouse or AWS | Human engineering leads make the final call |
Infrastructure choices carry financial commitments, performance tradeoffs and long-term business consequences, so people still insist on deciding. According to the CEO, feedback from teams at frontier AI labs, including Anthropic’s Claude team, points the same way: agents still look to a human when money or a critical commitment is involved.
Some vendor choices are already fading from view at the scaffolding stage, when an app’s basic structure is generated. Lovable, for example, can decide on its own to set an app up with a Supabase database and roll the cost into a single bill. Ask Claude Code to build a working app without connecting GitHub or any other account, and the project can end up deployed at a public Vercel URL. Agents also often run under predefined instructions, prompts and harnesses, the software wrappers that steer them, which favor particular vendors and hosting setups.
Even so, the CEO does not expect developer platforms to become anonymous plumbing. Once a prototype turns into a team or enterprise project, a person still has to opt in and set up a payment account with a hosting provider such as Vercel. Commercial software needs someone accountable for the bill and a vendor that person trusts. Agents with digital wallets and preset spending limits might one day skip that step, but for now the human decision point is still there.
What agent-ready docs actually look like
Engineering teams regularly come to Mintlify asking for complex architectural tricks to make their docs readable by agents. Some worry that docs built on an older framework such as Docusaurus will not parse well in agent workflows. The CEO’s answer is simple: write better docs.
The reason lies in how agents read. Large language models (LLMs) and the agents built on them take in technical information in fundamentally the same way human engineers do, only much faster and in far greater volume. They rely on context clues, intuitive section hierarchies and clear conceptual organization to navigate an API and produce a correct implementation.
That is why dumping everything on them backfires. Converting docs into giant raw JSON files or handing over an entire unstructured code repository does not help. Mintlify’s research found that large, unstructured, poorly maintained or truncated documentation severely degrades agent performance compared with cleanly segmented content. Agents understand less and produce more hallucinated code, meaning code that looks plausible but is wrong.
Standards such as llms.txt, a plain-text file that summarizes a site’s content for language models, and Model Context Protocol (MCP) servers, which connect AI models to outside tools and data, are useful. Teams often treat them as silver bullets, though, and they cannot make up for content that is inaccurate, missing or out of date.
| Instead of | Do this |
|---|---|
| Publishing one giant Markdown or JSON file | Split docs into clear, well-organized sections |
| Feeding a whole codebase to an agent | Provide clean docs and verified code examples |
| Counting on llms.txt or an MCP server alone | Make sure the content is accurate and current first |
| Offering only a chat interface | Keep quick starts and visual aids people can scan |
▲ Raw dumps versus well-segmented docs
Agents draft the docs, people steer
Who writes documentation has changed over the past year as well. Engineering teams now ship updates, new SDKs (software development kits) and API changes at a record pace, which makes it virtually impossible for technical writers to keep docs current by hand. Agents are stepping in as the main drafters and maintainers.
That does not make technical writers or developer relations (DevRel) staff obsolete, the CEO argues. Code is extremely literal, so people are still needed to spell out what a product is meant to do and how the overall system is designed. And because agents read documentation in huge volumes to build applications for users, clearly explaining product behavior, SDK integration steps and use cases matters more than ever.
The job shifts from drafting sentence by sentence to steering:
- Curating customer stories
- Defining edge cases
- Directing what agents produce
Looking a year ahead, the CEO expects documentation work to become far more autonomous, with people in an oversight and steering role. Mintlify is building self-updating documentation in which agents watch code repositories, detect changes and send engineers targeted clarifying questions when an update is ambiguous. The goal is to keep the docs in sync with the software that actually shipped.
What to do now
Agents may now be the largest audience for developer docs, but the standard for good documentation has barely moved. Docs that people can read easily also work well for agents, and what human developers recommend shapes what agents recommend. For teams that build APIs or developer tools, a practical checklist looks like this:
- Give people a fast way to evaluate the product: quick starts, visual aids and verified code examples.
- Break docs into clearly segmented sections with an obvious hierarchy and context clues, and spell out use cases and SDK integration steps.
- Confirm that the content is accurate and current, then add agent-facing layers such as llms.txt and MCP servers.
- Keep sources and references visible so people can check an agent’s output.
- Keep investing in earning the support of developers on forums, Reddit and blogs.
- Let agents draft and update docs, and spend human time on product intent, customer stories and edge cases.
An 80% agent share looks less like a signal to start writing for machines and more like a sign that documentation quality now shapes the choices of both people and agents.