Back to blog

Ubiquitous Journal

AI Coding Agents Don’t Need Better Prompts. They Need Better Documentation Access.

We keep expecting AI coding agents to build production software from prompts. That’s kind of insane when you think about it.

We give an agent a task like:

“Add authentication.”

“Connect Stripe.”

“Deploy this to Vercel.”

“Use Convex for the backend.”

“Build this with Next.js.”

Then we expect the model to somehow know the current APIs, SDKs, configuration patterns, breaking changes, environment variables, version differences, framework integrations, deployment requirements, and implementation details for every tool involved.

And when it gets something wrong, we call it an AI problem.

A lot of the time, it’s actually a context problem. The agent simply wasn’t given the information it needed to do the job correctly.

Prompting Is Not Documentation

There’s been an enormous amount of focus on prompts. Better system prompts. Longer prompts. Coding-agent prompts. “Act like a senior software engineer.” “Follow best practices.” “Think step by step.”

But none of those instructions magically give the agent the latest Better Auth documentation. They don’t tell it whether a Clerk integration changed last month. They don’t give it the current Vercel deployment configuration. They don’t guarantee it understands the latest Convex APIs. They don’t tell it which version of an SDK the project is actually using.

A brilliant prompt attached to incomplete or outdated technical knowledge is still incomplete. You cannot prompt missing information into existence.

So I'm Building a Documentation Registry for Agents

The idea is simple: create a structured, machine-readable directory of the technologies we actually use to build software. Authentication providers. Databases. Backend platforms. Hosting companies. Frontend frameworks. Programming languages. AI providers. Agent frameworks. Payment systems. Storage. Email. Testing. DevOps. Observability. APIs. Everything.

Each technology gets a structured page containing the authoritative places an agent should look before it starts writing code. Official documentation, API reference, framework integrations, GitHub repository, changelog, migration guides, supported runtimes, current SDK information, relevant configuration documentation.

Then instead of telling the agent “figure out how Better Auth works,” the workflow becomes: identify Better Auth, retrieve the registry entry, load the relevant first-party documentation, determine the installed version and framework, build against the actual documentation, verify the implementation. That is a completely different operating model.

The Registry Isn't the Documentation

This distinction matters. I don’t want to copy every company’s documentation and create another giant knowledge base that immediately goes stale. The registry is the routing layer. It tells the agent where authoritative information lives and how to retrieve the right information for the task.

Think of it like DNS for technical knowledge. The agent knows what it needs. The registry knows where the source of truth is. The documentation provider owns the actual knowledge.

Why This Matters More as Agents Get More Autonomous

When humans wrote most of the code, documentation was designed primarily for humans. A developer searched Google, opened the docs, read the relevant page, checked Stack Overflow, looked at GitHub, and implemented the feature.

Agents increasingly need to perform that process themselves. But we haven’t really redesigned technical documentation discovery around autonomous software agents yet. We are giving agents execution ability without consistently giving them reliable knowledge retrieval. That creates predictable failures: outdated APIs, invented configuration options, deprecated packages, incorrect environment variables, wrong framework patterns, broken integrations, dependency mismatches.

The model gets blamed for hallucinating, but sometimes we effectively asked it to guess.

The Better Workflow

User gives the coding task.

The agent identifies the technologies involved.

The agent queries the documentation registry.

The registry returns authoritative documentation sources.

The agent retrieves only the relevant documentation.

The agent builds an implementation plan based on those sources.

The agent writes the code.

The agent verifies the result against the documentation.

That turns documentation retrieval into part of the coding process itself. Not an optional step. Not something buried inside the model’s training data. Not something we hope the model remembers. A required dependency.

Documentation Should Become Infrastructure

For autonomous agents, documentation can become callable infrastructure. Structured. Versioned. Searchable. Machine-readable. Source-aware. Connected directly to agent workflows. Instead of trying to make the model memorize every SDK on Earth, give it reliable access to the source of truth when it needs it.

There are thousands of frameworks, APIs, databases, deployment platforms, AI providers, authentication systems, and developer tools. They change constantly. No static model can perfectly remember all of them forever. And it shouldn’t have to. The model should reason. The documentation should provide the facts.

The Future of Coding Agents Might Depend Less on Bigger Models

A lot of people assume the next leap in coding agents will come entirely from more capable models. Maybe part of it will. But I think another major leap is going to come from giving agents much better access to the systems surrounding the model: memory, context, documentation, tools, execution environments, verification, source-of-truth retrieval.

The agent doesn’t need to magically know everything. It needs to know how to reliably get what it doesn’t know.

That is the system I want to build. Not another prompt library. A documentation access layer for AI agents.