Docs-as-Code 2.0: a new standard for AI‑ready user documentation

Published: May 29, 2026.

Imagine: last year you started writing documentation as code. You use Git, Markdown, CI — everything the YouTube experts told you to do. Then suddenly you realize: in 2026, that's no longer enough. AI agents are everywhere, but they can't make sense of your work. Why? Because Docs-as-Code 1.0 tools were built to create sites for humans, not algorithms. Enter Docs-as-Code 2.0. It builds a bridge between your text and large language models (LLMs). As AI documentation becomes the new baseline, traditional documentation standards are no longer enough to keep up with the pace of LLMs.

Where did Docs-as-Code 2.0 come from?

The first wave of Docs-as-Code emerged in the mid‑2010s. Developers tired of wikis and MS Word spread the approach. They wanted to write documentation in Markdown, store it next to code, version it with Git, and build it via CI.

By 2020, this had become a standard for many open‑source projects and IT companies. Sites built with Docusaurus, MkDocs, Hugo — these are the product of Docs-as-Code 1.0.

But in 2025–2026, things changed dramatically. AI assistants entered daily practice: developers use GitHub Copilot, users look for answers in ChatGPT, Claude, Perplexity, and technical writers experiment with LLM‑generated documentation.

Then a problem appeared: traditional doc sites are designed for people. To a neural network, they're just HTML or Markdown where structure is mixed with presentation. The AI can't tell instructional text from navigation buttons, doesn't understand where a feature description ends and a warning begins, or where a code example lives.

Docs-as-Code 2.0 is the answer to this new challenge. Fortunately, the next version of the approach doesn't throw away Git and Markdown – it adds machine‑readable layers: llms.txt files, JSON‑LD schemas, MCP servers, and meta‑descriptions for AI agents.

Status and adoption of the technology in 2026

By early 2026, llms.txt has become an informal standard. The specification was proposed in September 2024 by Jeremy Howard and his team at Answer.ai. A year later, almost all popular static site generators support it: Docusaurus, MkDocs (with plugins), Hugo. Mintlify supports llms.txt and an MCP server out of the box.

What is this file? It's your_site.com/llms.txt, written in Markdown. It acts as a map: it lists the key sections of your documentation, briefly describes them, and tells LLMs where to start. In some ways, it's similar to robots.txt.

What does llms.txt look like in practice? Below is an example from Anthropic's Claude AI documentation (available at platform.claude.com/llms.txt). The file is written in Markdown and lists the key sections an AI agent can use for navigation.

# Anthropic Docs 
    

  / → Overview of the docs 
    

  /claude-api → Reference docs for the Messages API, model info, etc. 
    

  /claude-api/get-started → Build a Claude-powered app 
    

  /claude-api/rate-limits → Information on rate limits 
    

  /claude-api/migration-guide → Migrate from Text Completions API 
    

  /build-with-claude → Tutorials, guides, and examples 
    

  /legal → Legal and policy information

Such a file helps an LLM immediately "see" the structure of your documentation and not get lost in navigation menus. You can view this live example by visiting the URL above. For larger projects, you can also create llms-full.txt – a flat version of all pages in a row.

Unfortunately, as of mid‑2026, there are no large‑scale studies from major analyst firms (Gartner, Forrester, W3Techs) on llms.txt. So it's better not to give any definitive statistics rather than rely on dubious ones. According to estimates from independent observers, the share of popular sites supporting llms.txt has grown to a few percent, comparable to the early adoption stages of robots.txt in the 1990s. Early adopters include Cloudflare, Microsoft (Azure, GitHub), Adobe, PayPal, Stripe, Slack, Zendesk, and WordPress.org.

Industry examples:

• Vercel added automatic llms.txt generation for all projects. Discussion of implementing this feature in Next.js is available in the official GitHub repository (Discussion #81215). AI agents can now read Next.js documentation in a structured way. The entire AI SDK documentation from Vercel is available as llms.txt at ai-sdk.dev/llms.txt – as confirmed by the official AI SDK docs.
• Mintlify generates llms.txt, llms-full.txt, and an MCP server out of the box.
• Anthropic (Claude) and OpenAI use structured data formats to improve the accuracy of RAG answers. If a site's documentation is not structured for AI, quality drops because models cannot efficiently extract needed information from noisy HTML.

While specific statistics about searching for answers in technical documentation (34% and 62%) cannot be found in available reports, the overall trend of active AI usage by developers is confirmed by the industry. Surveys show that more and more engineers are turning to ChatGPT, Claude, and GitHub Copilot for everyday tasks, and this increases demand for machine‑readable documentation. That makes structuring content for machine reading a critically important task for technical writers.

Demand for Docs-as-Code 2.0 is growing among companies that deploy AI assistants for support, and among projects with large documentation that is consumed via LLMs.

Docs-as-Code 1.0 vs 2.0: what has fundamentally changed?

As mentioned above, the first version solved the problem of human convenience: versioning, code reviews, automatic building. The second version adds machine convenience.

The key shift: documentation is no longer just a static site. It becomes raw material for AI. Now you are building a knowledge base that neural networks can use without distortion. (For more on what those distortions – hallucinations – are, you can refer to our earlier article on AI fundamentals for technical writers – but here we will focus on the new standard.)

The Shift Toward AI-ready Documentation and Machine-readable Documentation

When structuring documentation for AI, we need to move beyond simple Markdown. Adopting modern Docs-as-Code best practices is essential for creating truly LLM-friendly content that remains accurate and easy to parse. This is the foundation of AI-ready documentation and the shift toward machine-readable documentation.

Industry standards are shifting toward machine-readable knowledge bases. As AI agents increasingly become the primary consumers of technical documentation, the traditional static site is no longer sufficient. This shift is not just about the latest tech; it is a response to how technical information is being processed in 2026.

In May 2026, a piece by Naval Ravikant – the well‑known investor and entrepreneur – was published. The article is titled "Apple is dead, SaaS is next". The core idea: classic SaaS is living its last months. It will be replaced by one‑person companies that AI turns into teams of fifty specialists.

In this game-changing prediction lies the key to understanding why Docs-as-Code 2.0 is necessary. If companies become tiny, documentation will no longer be written by dozens of tech writers. It will be created by solo founders and small teams. But they have a different problem: they don't have time to duplicate the same warning across five guides. They need documentation that builds automatically and is ready for AI agents to consume.

Plain Docs-as-Code (Markdown + Git + site generator) solves half the problem – build automation. But it doesn't solve the other half: how to make documentation understandable to neural networks. If AI agents will soon be supporting users instead of human support staff, those agents must be able to read your documentation without distortion. That requires llms.txt, structured metadata, and MCP servers – i.e., Docs-as-Code 2.0.

How does an agent actually use llms.txt in a real conversation? Imagine a user asks in a support chat: "How do I set up stock notifications?" An AI agent with access to your llms.txt works like this:

1. It reads the llms.txt file and sees the section /guides/notifications described as "Setting up inventory alerts".
2. It requests that section (via HTTP or MCP).
3. It extracts the exact instructions and returns them to the user, optionally asking for the product version.

Without llms.txt, the agent would have to download the entire homepage, parse the HTML, filter out buttons and banners – and still might miss the right section. With the llms.txt map, it finds the answer in a fraction of a second, without wasteful computation.

More advanced agents (with MCP) can directly ask: "Give me the instructions for setting up notifications for version 3.2" – and the server returns only the relevant fragment.

Ravikant gives the industry 18 months to restructure. For technical writers, this means moving to Docs-as-Code 2.0 is not hype; it's preparation for a new reality where documentation will be consumed mainly by machines. And it will have to be done quickly, without huge teams, using AI tools. Those who start now will have a head start. Still, don't rush to overhaul your entire documentation portal – read the article to the end; maybe the next version isn't for you.

Hybrid approaches and tools

If you are wondering how to implement llms.txt without breaking your existing infrastructure, you don't have to start from scratch. You can keep your existing Docusaurus or MkDocs setup and add generation via plugins:

• Docusaurus → docusaurus-plugin-llmstxt plugin.
• MkDocs → mkdocs-llmstxt plugin.
• Hugo → hugo-llms-txt module.
• Mintlify – already supports it out of the box.

The hybrid setup: keep your old site for humans, plus a separate /llms.txt and an MCP server for AI agents. This works today and doesn't force you to abandon your familiar stack.

The Model Context Protocol for documentation (MCP) serves as a unified interface, allowing LLMs to access your content much like they would a file system or web API. Instead of downloading llms.txt and then following links manually, an agent can use an MCP server to directly request the needed section, specify the product version, or get only changes from a certain date. The MCP server acts as a middleware: it understands your documentation's structure and answers LLM requests with already structured data (JSON or Markdown). This reduces the number of calls and lowers the risk of hallucinations.

What about JSON‑LD and why do you need it? If llms.txt is a city‑wide map, then JSON‑LD is the street sign on each building. It's a small block of code embedded in the HTML that describes the page's content in a machine‑friendly language: which product it belongs to, its version, the author, whether it's a guide or an API reference. This helps AI agents instantly understand the page's context, even if they landed on it directly from search results rather than through the main llms.txt. Together, these two tools create a complete picture: a map of the whole city (llms.txt) and signs on every building (JSON‑LD).

Evaluating the move to Docs-as-Code 2.0

Adopting any new technology is like choosing a seat on a train: you can go first class with extra comfort, or you can save money and stand in the aisle. Docs-as-Code 2.0 is no exception. It's generous with benefits but hungry for resources. Let's see who should spend the budget on a first‑class ticket, and who is fine with economy for now.

Teams are increasingly adopting Docs-as-Code 2.0 to meet the needs of AI-powered workflows. While this transition offers significant advantages, its implementation depends on specific organizational requirements.

Common adoption patterns in 2026:

• High-volume AI integration: companies deploying AI support chats typically find Docs-as-Code 2.0 essential for data accuracy.
• Large-scale documentation: projects with extensive knowledge bases (1,000+ pages) often shift to this standard to maintain discoverability.
• Documentation-as-a-Product: teams that prioritize documentation quality as a core competitive advantage tend to lead this adoption.

When current architectures remain sufficient:

• Small-scale documentation: for projects under 50 pages, the overhead of maintaining machine-readable layers often outweighs the benefits.
• Non-AI use cases: teams not planning to leverage RAG or AI assistants may find that 1.0 architectures adequately serve their audience.

Adopting Docs-as-Code 2.0 requires not so much technical skills as a shift in mindset: you start designing documentation as a structured dataset for different consumers. For humans – a convenient website. For AI – machine‑readable layers.

Hidden complexities

Search and analytics. Even if you generate an llms.txt file, it's not guaranteed that your company's AI agents will use it. Optimizing documentation for RAG pipelines is more than just generating an llms.txt file; you need to manage embeddings and connect them to your tickets and chat workflows. That's not a tech writer's job – it's ML engineer work.

Maintenance. Documentation lives and changes. llms.txt and the MCP server also need updates. If you write complex redirects or versioning rules, you risk desynchronisation between the human‑facing site and the AI access.

Total cost of ownership (TCO). You get file generation for free. The paid part is integration with LLMs, hosting embeddings, maintaining MCP, and hiring a specialist who understands all this. For a large company, the expense may be justified. For a startup, unlikely.

Conclusion

Docs-as-Code 2.0 is not marketing noise. It's a natural response to AI's intrusion into our work. Git and Markdown stay. To them we add llms.txt, JSON‑LD, and MCP servers.

If neural networks are already trying to read your documentation (via Copilot or search), then moving to version 2.0 is a matter of the coming year.

While industry leaders are moving toward version 2.0 to support AI-driven consumption, those managing specialized, internal-only documentation often find that maintaining the current 1.0 architecture remains sufficient. The decision to transition should be driven by how your audience—both human and algorithmic—interacts with your content.

The main sign that it's time to think about it: you notice that users increasingly show up with answers generated by ChatGPT, but those answers are wrong. Most likely, the AI tripped over your markup. Give it a clear map – llms.txt.

So, the tools are already here, and so are real‑world examples from companies. In 2026, Docs-as-Code 2.0 is the choice for those who want their documentation to be used not only by people but also by neural networks. If Naval Ravikant's grim forecast holds, we have about eighteen months until the big shift. And time is ticking.