DevRel for the Agent Era

Developer experience used to have one main reader: the human developer.

Now it has two.

The second reader is the coding agent. It reads docs, SDKs, schemas, examples, changelogs, and error messages. Then it tries to turn that material into working software.

That changes DevRel.

Agents read differently

A human can skim a docs page, infer missing context, and tolerate a little ambiguity.

An agent is more literal. It looks for the auth model, endpoint shape, required fields, examples, error meaning, and recovery path. If those pieces are inconsistent, it can produce broken code with great confidence.

This is why docs are no longer just educational material. They are part of the integration runtime.

The developer portal is now an interface

Your website is not only read in a browser.

It is retrieved, chunked, summarized, embedded, copied into editors, and used inside agentic workflows. A messy docs site becomes a messy tool surface.

Good DevRel now means designing for both people and machines:

clear concepts
tested examples
strong OpenAPI specs
useful SDK comments
structured changelogs
error messages with next steps
pages that make sense when retrieved out of order

This is the broader version of the personal harness in From Copilot to Agentic Engineer.

Examples are contracts

A broken quickstart is more damaging in the agent era.

Why? Because agents reuse examples aggressively. If the example is stale, the generated integration is stale. If the SDK call is wrong, the agent spreads the wrong pattern into a real codebase.

Treat examples like product surfaces. Run them in CI when possible. Keep dependencies current. Show expected output. Explain common failure modes.

The best docs do not merely describe the happy path. They help the agent recover when the happy path breaks.

Error messages are onboarding

An error message is not just for a support ticket anymore.

It may be the next instruction an agent reads.

“Invalid request” is a dead end. “customer_id must be a UUID. You passed an email. Look up the customer first.” is a repair path.

That kind of message helps humans too. Agent-ready DX is usually just good DX with fewer vague edges.

DevRel should run evals

DevRel teams should test whether agents can integrate the product from public materials.

Can an agent create a working project from the quickstart? Can it choose the right auth flow? Can it recover from the top ten errors? Can it upgrade from one API version to the next?

These are not academic evals. They are adoption tests.

If an agent cannot integrate your API using your docs, a human developer will probably struggle too.

The opportunity

The teams that treat DevRel as publishing will produce more pages.

The teams that treat DevRel as adoption infrastructure will produce more successful integrations.

That is the real shift. DevRel becomes the owner of the agent experience layer: the surface that helps humans and their tools understand, use, and recover around a product.

The next layer is product workflow design: agents pursuing goals, verifying outputs, and escalating safely. That is the subject of Loop Engineering Turns Agents Into Products.