AI Agents Won't Read Your Docs (But They'll Execute Your Code)

My first job after working as a technical writer was something that didn’t yet have a stable definition: developer evangelist. This was around 2001, in the long shadow of JavaSoft. I was responsible for explaining an absurdly complex set of public-key infrastructure and cryptography APIs to developers who had every reason to avoid them. The work was equal parts translation and persuasion. If the docs were too obstuse, developers gave up. If the examples were too thin, they got lost.

Luckily, I was also managing the team of engineers building the client SDKs and toolkits. We broke our heads refactoring very complicated PKI services into high-level, simple-to-use APIs that helped developers adopt a very complex technology. Good documentation was essential, but it was never enough on its own. The real unlock was combining clear explanations with opinionated, well-designed interfaces that made the “first successful call” feel achievable.

The Journey Never Went Away

Years later, when Caroline Lewko put formal language around the developer journey, it clicked instantly for me. She mapped out what many of us had been doing intuitively: a series of stages from awareness to evaluation, onboarding, building, and advocacy. Documentation, SDKs, sample apps, community content—each piece played a role in helping developers move from one stage to the next.

That model is still right. What’s changing is who (or what) is actually walking that path.

AI Steps In

Today, developers are increasingly offloading the “figuring it out” part of the journey to AI. Instead of reading three comparison blog posts, they ask their assistant which options fit their constraints. Instead of slogging through an OAuth guide, they paste a couple of keys and say, “Generate the minimal example that works with our stack.” Instead of scanning pricing tables, they ask, “What will this cost at our current scale versus these two alternatives?”

And that’s where MCP gets interesting.

With this background, I noticed that MCP could play a role on top of APIs, to help developers adopt APIs and tech stacks more quickly, with great awareness and context of how to use them appropriately. All of this impacts the traditional dev journey, which has been given its canonical form by Caroline Lewko.

Model Context Protocol (MCP) gives you a structured way to expose your product’s capabilities directly to AI agents—securely, predictably, and with context. Instead of hoping a model has scraped, understood, and remembered your docs, you define tools and resources that the AI can call in real time: list capabilities, fetch schemas, hit test endpoints, and get structured feedback.

What’s cool about MCP is that it enables you to build in use cases, pricing comparisons and estimates, performance benchmarks, and the voice of your CTO and your SEs, with guidance on how best to adopt a particular technology for your specific use case. This helps developers make better decisions more quickly, and it enables tech companies to hit their product-led growth targets with more accuracy and overall developer satisfaction.

In other words, the developer journey doesn’t disappear—it gains a second track. One is still human: blog posts, conceptual docs, architecture guides, migration stories, conference talks. The other is agent-first: a set of machine-readable capabilities and guardrails that let AI assistants explore, test, and implement your product on the developer’s behalf.

Docs Still Matter, But Differently

This doesn’t mean documentation is dead. Writing for developers is hard, and AI is nowhere near replacing good content strategists or great technical writers. Humans still need context, narrative, and judgment. They still need to understand tradeoffs, patterns, and failure modes. They still look for honest explanations of what your product is good at, what it isn’t, and how it fits into a messy real-world stack.

But the role of docs is shifting.

If an AI assistant can already generate the correct “hello world” and handle the basic API flows, you don’t need five slightly different onboarding tutorials. You need strong, opinionated content about architecture, performance, reliability, security, and real-world use cases. You need the story behind the API, not page after page explaining how to make the first request.

MCP lets you move the repetitive, mechanical parts of the journey—the comparison, the wiring, the basic error handling—into a form that AI agents can work with directly. That frees your humans to do what only humans can: frame the problem space, speak to strategy, and connect your product to the real constraints and pressures your buyers are living with.

Product-Led Growth Needs A Second Track

If you care about product-led growth, this matters. Your future “first impression” won’t just be your landing page or your docs. It will be the experience a developer has when they ask their AI assistant, “What should I use for this?” and your product either shows up ready to help—or doesn’t appear at all.

At devmcp.ai, I’m exploring this second track of the developer journey: how to design MCP servers and AI-first interfaces that make your product discoverable, testable, and adoptable by both humans and their agents. Not as a replacement for documentation, but as the missing execution layer that documentation has never been able to provide on its own.

The developers are still there. The journey is still there. What’s changing is who they bring along for the ride—and whether your product knows how to talk to it.