kate astrid

Posted on Oct 26

Is Software Dead? Part Four: Developer Relations

#ai #devrel #programming #discuss

A while ago I wrote that developers scan docs. They open a page from a search result, hunt for the code block, copy it, and leave.

In 2026, many of them send an agent to do the scanning.

A study from April 2026 looked at how AI coding agents use documentation portals. It found that agents compress a whole multi-page visit into one or two requests. They skip the intro, the screenshots, and the friendly tour, and they take exactly what they need.

So our docs have a second reader now. That changes developer relations more than any other part of this industry.

This is part four of the "Is Software Dead?" series. DevRel is the work I care about most. I organize the UXDX meetup in Amsterdam and speak at developer conferences, and my favourite part of the job is the moment someone finally gets it. So this one is close to my heart.

Two readers, one set of docs

Developers and agents come to our docs with different needs.

A developer needs	An agent needs
The story of why this tool exists	The exact steps, in order
Examples that teach	Examples that run as they are
Encouragement when they get stuck	Error messages with a clear fix
A community to ask	A current, structured reference

The good news: a lot of what helps agents also helps tired humans at 11pm. Clear steps, complete examples and honest error messages make everyone's life easier.

What "agent experience" looks like

People have started calling this AX, or agent experience. Microsoft's developer advocates describe it as a discipline for testing how AI coding agents find and use our SDK, API or CLI. Mintlify's CTO argues that developer experience is turning into agent experience.

In practice, teams are trying a few things:

Markdown versions of every page, so agents can read the content and skip the layout around it.
An llms.txt file, a short Markdown introduction that links to the most useful docs. Early evidence is mixed. Drupal's founder Dries Buytaert observed that the bots it was designed for rarely request it, while plain Markdown pages get requested much more often.
MCP servers that give agents up-to-date docs, code examples and tools directly inside the editor.
AGENTS.md and skills files that tell an agent how to use our API well, beyond what the reference covers.

My favourite idea is the simplest one. Give an agent a real task with our SDK and watch where it gets stuck. It's user testing, with a very literal user.

Our metrics need a rethink

For years, DevRel teams watched time on page, pages per session and bounce rate. The April 2026 study found that agent traffic makes those numbers weak signals. When an agent reads three pages in one request, a "short visit" can be a perfect visit.

Better questions for 2026:

Can an agent finish a typical task with our docs alone?
How much of our traffic comes from AI tools?
Which errors do agents and humans hit most often?
How long does it take a developer to reach their first working result?

What only humans can give developers

Agents can read docs, so it's tempting to think developer relations is shrinking. I see the opposite.

Trust. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, and 46% said they distrust the accuracy of the output. Developers still want a person who says "Here's what goes wrong in production, and here's how we fixed it." That person is often a developer advocate.

Feeling capable. I've written before that the fastest way to lose a developer is to make them feel stupid. An agent shrugs off docs that assume too much. A person feels it right away and closes the tab. Protecting that feeling is human work.

Community. Agents skip meetups, hallway conversations and the questions people ask over drinks after a talk. Those are the places where developers decide which tools they love and which people they trust.

Judgment. An agent can pick a library that matches a prompt. A community can tell us which library is still maintained, which one has a kind maintainer and which one breaks on every upgrade.

The new DevRel job description

If I wrote a DevRel job post today, it would include:

write docs that work for a person and for an agent;
test our product with agents the way we test it with users;
publish MCP servers, examples and skills files as part of the docs;
measure task success, beyond page views;
keep showing up in person, at meetups, conferences and in the comments.

So, is developer relations dead?

DevRel has a second audience now, and the first one matters more than ever. Agents bring developers to our tools faster. People decide whether to trust those tools and stay.

In part five, the finale, I look at the hardest question in this series: when an agent breaks production, who gets the blame?

What did a docs site or a developer advocate once do that made you trust a tool? I'd love to hear the stories.

DEV Community