When documentation becomes infrastructure

When documentation becomes infrastructure

When documentation becomes infrastructure

When documentation becomes infrastructure

Overview

We didn't set out to build AI infrastructure. That's what made it work.

The documentation strategy for the Epic Design System wasn't designed with AI in mind. It was designed to be useful: consistently structured, clearly reasoned, written with enough precision that a designer or engineer could read a component page and know exactly what to do. The goal was clarity for humans. What that clarity turned out to enable was something different entirely.

When AI-assisted workflows became a real conversation inside the team, the documentation was already ready for them, not by accident. It was ready because the work had been done right from the start.

Epic Games

2026

Process

The AI readiness wasn't planned. It was a byproduct of doing the work right.

The gap between the documentation that exists and the documentation that machines can use is wider than most teams realize. Point a model at a typical component page, and it returns something generic. Not because the model is wrong. Because the documentation it's working from was written to be read, not used.

A component page written for browsing might say: use this button for primary actions, avoid using it more than once per screen, and make sure it's accessible. A designer reads that and fills in the gaps. They know what "primary action" means in context. They know what accessible implies. The documentation assumes a reader who brings judgment.

The Epic Design System's documentation didn't work that way. Every component had its intent stated, not implied. Constraints were written as constraints. Behavior across states was documented the same way, every time, across every component.

That consistency turned out to matter in ways no one had planned.

Three things got built on top of that foundation.

The first was an LLM file, a packaged version of the documentation integrated directly into Claude Code. Engineers could reference system guidance without leaving their workflow. The documentation stopped being something you navigated to and became something that came to you.

The second was a custom chatbot built for conversational access to the system. Instead of searching the documentation, teams could ask questions, drawing on the same structured content that the reference site was built on.

The third was component metadata extraction. Because the documentation had been written with a consistent structure, usage rules, constraints, and design intent could be extracted programmatically, turning content written for humans into source material for automated tooling.

The real test came when designers started building with AI.

When the team began running serious AI prototyping experiments — using Claude Code and Figma's MCP to build functional prototypes directly from designs — a pattern emerged quickly. The results were good when Claude had something structured to work from. When it didn't, it improvised. It pulled components from outside the system. It made assumptions about tokens. Output that looked right but drifted from the system in ways that would compound over time.

The LLM file held that together. Structured with component specs, usage guidance, and patterns written for how a model actually reads, it meant Claude could identify the right component without being told explicitly. Designers realized they didn't need a separate layer mapping design components to code. The documentation was doing that work. The experiments were impressive. The documentation is what kept them from becoming a divergence problem.

The most granular version of this work was at the component level inside Figma.

Component description fields had existed but carried minimal, largely unusable content. Getting AI to work correctly with a component required its intent to live where AI would actually encounter it. That work had its own heuristic framework, its own evaluation process, and its own automation layer.

Outcome

AI doesn't make unstructured content useful. It makes well-structured content powerful.

Teams that are retrofitting their documentation for AI readiness are learning this the hard way, rebuilding content architecture that should have been right from the start.

The work at Epic was proof that documentation built with clarity and consistency, actually built to serve the people using it, turns out to be exactly what machines need, too.

That's not a coincidence. It's the point.

Have a project in mind?

Whether you're looking for a consulting partner or building a team, I'd love to talk.

Have a project in mind?

Whether you're looking for a consulting partner or building a team, I'd love to talk.

Have a project in mind?

Whether you're looking for a consulting partner or building a team, I'd love to talk.