Your Next Developer Audience Isn't Human.

I noticed it in my own behavior first. When I start building a new demo, I don't open the documentation anymore. I ask an agent. It reads the docs, writes the first version, and tells me what it found. And when something is wrong, I don't open the documentation either. I ask the agent to fix it.

Now think about what that means. The docs your team spent months on were read, but not by me. The getting started guide was followed, but not by a person. The first contact between a developer and your product went through a model.

More and more developers work like this. They ask Claude, Copilot, or ChatGPT before they read your docs, watch your video, or come to your talk. Which leads to an uncomfortable question for everyone in developer relations:

If an AI explains your product wrong, whose problem is that?

It's yours. It's a DevRel problem now.

If an AI explains your product wrong, whose problem is that? It's yours. It's a DevRel problem now.

Go where the developers are, again

In my first post in this series I shared the best advice I ever got in this field, from Jeff Sandquist: go where the developers are, and bring them in.

For years that meant channels, meetups, conferences, and cities. The answer to "where are the developers" keeps changing, but the advice does not. And right now, the developers are in a chat window, asking a model about your product.

So that's where you need to be. Not with a booth or a banner. With good answers.

What DevRel for models looks like

This sounds abstract, but the work is very concrete.

Write docs for retrieval, not just for reading. A model doesn't read your docs from start to finish. It pulls out pieces and uses them to answer a question. That changes how you write. Every page should make sense on its own. Every code example should be complete and correct without the three pages before it. Clear headings, real error messages, working samples. The good news: this also makes your docs better for humans.

Treat your MCP server as the new SDK. An SDK helps a developer use your product. An MCP server helps a developer's agent use your product. If an agent can connect to your service, try things, and get real results, the model doesn't have to guess anymore. It can check. I organize MCP Connect because I believe this is the biggest shift in how developers will touch products, and most companies haven't noticed yet.

Make your quickstart something an agent can actually run. Test your getting started guide by giving it to an agent and watching what happens. This is the cheapest usability test that exists, and almost nobody does it.

Check what the models say about you. Ask the big models the questions your users ask. Where are the answers wrong or outdated? That's your content backlog. Fixing what the model gets wrong reaches more developers than your next ten blog posts.

New numbers to watch

If this is the new work, the old numbers don't cover it. Page views tell you nothing when the reader is a model. Video views tell you nothing when the developer asked an agent instead of watching.

Some numbers that do say something:

Can an agent complete your quickstart? Yes or no. Track it per release, because every product update can break it. This one number tells you more about your onboarding than any survey.

How often are the models right about you? Take your top twenty developer questions, ask them to the big models every month, and score the answers. Right, outdated, or wrong. Watch that score move when you fix your docs. This is the new version of checking your search ranking.

Is anything actually using your MCP server? Connections, calls, errors. If you built one and nothing talks to it, you have your answer about how discoverable it is.

None of these are perfect. But a DevRel team that reports "an agent can now complete our quickstart in one try, and the models answer 16 of our top 20 questions correctly, up from 11" is telling leadership something real. That beats another slide with reach numbers.

What stays human

A lot of people in DevRel see this shift as a threat to their job. I don't. It does not make DevRel smaller. It splits it in two.

The model takes the long tail. The thousand small questions, the syntax, the setup problems, the "how do I" at two in the morning. Honestly, the model does that part better than we ever did. Let it.

What's left for humans is the part that was always the real job. Trust. Judgment. Someone who built the thing for real and can tell you when not to use it. And yes, I build my demos with agents now, but the rule from my earlier post still stands. I decide what to build, I hit the real problems, and I know why every part works. The way of building changed. The requirement to have done it yourself did not.

And one more thing no model can do: the moment at a conference where you see a talk and think, I want to be able to do that. A model can answer every question about Cognitive Services. It could never have been Jennifer Marsman on that stage at NDC London, giving the talk that made me want to try it myself.

I wrote earlier that developers don't trust logos, they trust people. That's still true, and it's becoming more true. When every answer is generated, the person who actually did the work is worth more, not less.

When every answer is generated, the person who actually did the work is worth more, not less.

What happens to events

Follow this through and you land at an interesting question: if every answer is free and instant, why would anyone still come to a talk?

I see the answer at every AgentCon stop. People don't come for information anymore. They can get that at home, faster, from a model. They come to build something together, to meet the person behind the project, and to be in a room with people who care about the same things.

That changes what a good event looks like. The talk that walks through a feature list is dying, and the model is killing it. What works now is hands-on. Build something in ninety minutes. Bring your own problem. Sit next to someone who is stuck on the same thing. Our Construct format exists because of exactly this: stop watching, start building.

For event organizers this is actually good news. The bar for talks goes up, but the value of the room goes up with it. A conference used to compete with other conferences. Now it competes with a chat window, and the only way to win that is to offer what the chat window can't: the people.

What to do this quarter

If you lead a DevRel team, start with three things:

Give an agent your quickstart, with no extra help, and watch where it fails. Where the agent gets stuck, a human gets stuck too. Fix that first.

Ask the big models the top twenty questions about your product. Every wrong or outdated answer goes on the content plan, at the top.

And keep doing the human part. The events, the community, the stage. Not because it scales, but because it's the only part that can't be generated.

The audience changed. The advice didn't. Go where the developers are, and bring them in. Right now, that's two places at once: in the room, and in the model.