Agents Are Your New Developers

What changed

For two decades, developer adoption started with a person: someone searched, read, evaluated, and typed the first API call. That assumption is now quietly wrong.

An increasing share of first contact with a developer product is an AI system acting on a developer's behalf: a coding agent scaffolding an integration inside an editor, a chat assistant comparing options and quoting docs, or an autonomous agent following a runbook end to end. The developer is still in charge, but they arrive later: after a model has already read your docs, formed an opinion, and maybe written the first hundred lines against your API.

This is not a prediction, it is observable in traffic patterns most vendors already have: AI crawlers and agent user agents in server logs, signups with no preceding web session, and support questions that quote model-generated code.

What agents need, versus what humans need

Human developers tolerate ambiguity. They skim, infer, hold context across pages, and forgive a stale screenshot if the idea is clear. Agents fail differently, and what they need is stricter:

1. Deterministic quickstarts. A step that "usually works" or depends on unstated environment assumptions will stall an agent every time. Every prerequisite must be written down, in order, with no hidden state.
2. Copy-paste-complete snippets. Code blocks that are runnable as-is, with imports, versions, and placeholders clearly marked. An agent will run exactly what you wrote, including your typo.
3. Exact error messages. Agents match errors verbatim against your docs. Documenting the precise string of every common failure, with its fix, is now one of the highest-leverage docs tasks that exists.
4. Stable URLs and anchors. Retrieval systems and model memories reference URLs; every broken link is an answer your product no longer appears in.
5. No marketing in the critical path. A human skips the value proposition paragraph; a model treats it as signal and repeats it instead of the setup steps. Keep positioning on marketing pages and keep task pages about the task.

Notice that every one of these also makes docs better for humans. Optimizing for agents is not a separate track; it is the strictest version of docs quality you already believed in.

The new funnel

The classic funnel was search, docs, signup, first call. The agent-era funnel has different stages, and DevRel can influence every one of them:

1. Model training data. Models learn your product from public text: docs, blog posts, forum answers, open-source code. Influence: publish substantial, accurate, openly accessible content and keep it consistent, because contradictions in public text become contradictions in model answers. This compounds slowly and is hard to reverse, in both directions.
2. Agent retrieval. At question time, many assistants fetch live pages: your docs, your /llms.txt index, community threads. Influence: serve clean Markdown, keep an accurate llms.txt, make key pages reachable without JavaScript, and answer recurring questions in indexable places instead of ephemeral chat.
3. Tool docs and machine surfaces. Agents that act, not just answer, work through machine-readable surfaces: OpenAPI specs, SDK types, MCP servers, CLI help text. Influence: treat these as first-class documentation, because for an agent they are the product.
4. First successful call. The agent runs the quickstart. Either it works deterministically, or the developer watching concludes your product fights their tools. Influence: instrument time-to-first-successful-call and treat every agent stall as a bug.

Audit your quickstart with an agent

The single most useful exercise: have a coding agent follow your quickstart cold, in a clean environment, with no help.

1. Start a fresh session with a capable coding agent and give it one instruction: "Integrate this product into a new project, following its documentation."
2. Watch where it stalls: the unstated prerequisite, the placeholder it cannot resolve, the step that assumes a dashboard click, the error message that appears nowhere in your docs.
3. Fix every stall point in the docs, not in the prompt. The next thousand agents will not have your prompt.
4. Repeat monthly and after every breaking release, the same way you would run any regression test.

What this means for the DevRel role

The work shifts in emphasis, not in purpose. The mission described in the definition of DevRel stands: build trust with developers and remove friction between them and the product. What changes is where the friction lives:

• Documentation work moves further up the priority list, because docs are now both the human interface and the machine interface.
• Community answers become training data: a correct, well-written answer in a public forum keeps teaching models for years.
• Developer experience work gains a new test subject: the agent-run integration, which is stricter than any human tester.
• Measurement needs new instruments, covered in measuring adoption you cannot see.

The rest of this section covers the concrete practices: writing docs LLMs can use, MCP servers are the new SDK, and measuring AI-driven adoption.

Related

• Writing docs LLMs can use for the documentation practices in depth
• Understanding developer personas - agents arrive on behalf of personas you should still know by name
• The importance of DevRel for the compounding logic that AI distribution accelerates