KBbridge Logo
· 5 min read· KBbridge

API documentation is no longer written for people: the shift to AI-first

aiapidocumentationmcp
API documentation is no longer written for people: the shift to AI-first

For a long time, API documentation looked the same: HTML pages with code examples, step-by-step guides, and diagrams. You read it, copied snippets, and tried it out. If the docs were bad, it cost you hours.

Today the first reader of documentation is no longer a person. It's a language model.

And that changes everything. This isn't a prediction — it's already happening, with standards being adopted rapidly. This post explains why it's happening, how it works in practice, and what it means for the way tools like KBbridge are built.

The problem: LLMs don't read like you do

When an AI agent needs to use a new API, what does it do? It tries to read the documentation. But it has two limitations you don't have:

  1. Limited context window. A full documentation site can be tens of megabytes of text. A model can't process it all at once — it gets cut off, loses context, and hallucinates endpoints that don't exist.
  2. HTML is noise. Menus, sidebars, scripts, tracking pixels, ad banners. All of that consumes precious model tokens without contributing any technical information. The result: broken code based on misread documentation.

The conclusion is obvious but the industry was slow to accept it: if agents are going to use your APIs, the documentation needs to be written for agents.

The answer: llms.txt

The standard leading this change is called llms.txt, created by Jeremy Howard (fast.ai / Answer.AI) in September 2024.

It's the AI-agent equivalent of robots.txt for search engines. A Markdown file at the site root that tells the agent: "here's everything you need to know, organized so you can read it in one go."

Two files:

  • /llms.txt — A structured index with brief descriptions and links to each section. The agent reads this first to see what's available.
  • /llms-full.txt — All documentation concatenated into a single file, ready for the agent to ingest completely in one fetch. No HTML, no navigation, no noise.

Adoption is fast. Stripe, Mastercard, X/Twitter, FastHTML and hundreds of platforms already have it. Tools like Fern, Mintlify and Speakeasy auto-generate llms.txt files from the same OpenAPI specification — you don't write twice.

How it works in practice

The typical agent flow today:

  1. Goes to {domain}/llms.txt to discover the API structure
  2. If it needs everything, reads llms-full.txt (all in one fetch)
  3. If it needs something specific, follows index links to individual .md pages — every page has a clean Markdown version at the same URL with .md appended
  4. If the API exposes an MCP server, it connects directly and can invoke endpoints in a standardized way

This replaces what used to be: reading HTML docs, copying snippets, guessing endpoints, testing in Postman.

The priority inversion

The most interesting thing isn't any single standard. It's the change in production priority:

  • Before: documentation for people (HTML, narrative, pretty UI) → then, if you got to it, something for machines
  • Now: first generate the AI version (structured, dense, machine-readable) → then derive the human version from it

Real limits: not everything is gold

It's worth being honest about what works and what doesn't:

  • Google (John Mueller, June 2025) stated that "no AI system currently uses llms.txt at inference" and that server logs don't show bots actively fetching it
  • A 2026 analysis of 300,000 domains found no measurable effect of llms.txt on AI citation probability
  • Yet the industry adopts it as forward-compatible infrastructure: even if not all models read it today, they will tomorrow

Adoption sits at ~10% of tech sites, but major platforms are integrating it fast.

How KBridge already lives in this world

This trend explains the design decisions behind KBridge — not as a reaction, but as a consequence.

KBridge externalizes binary knowledge into structured plain text in Git. Every method, every property, every pattern — including your API definitions — becomes readable content. Everything is text that an agent can read.

That's the key: since KBridge makes your entire codebase available as structured text, any AI connected through KBridge can automatically generate llms.txt documentation from your code. No manual writing, no separate OpenAPI spec to maintain — the AI reads your code as text and produces the documentation files that agents expect.

But it goes further. The AI doesn't just write documentation — it can read the documentation of another application it needs to integrate with, and using KBridge, automatically generate the GeneXus code and internalize it directly into your Knowledge Base. Documentation becomes not just a manual, but the raw material the AI uses to build the integration itself.

The AI-first documentation trend and KBridge share the same underlying thesis: structured text is the interface. Everything else is a view on top of it.

How you try it

If you want to see how a knowledge base looks when it's designed for AI agents from the start, watch the short videos on Getting Started, or try KBridge free for 15 days, no card required, at kbbridge.com.

Sources