CHABOT

Humans and agents

5 minute read 1,172 words

Developer Relations now serves human developers and the AI agents acting on their behalf. A quickstart, tool schema, or launch video may help both, but each audience has different information needs.

The two audiences

Audience A: AI agents (execution)

Cursor, Claude Code, GitHub Copilot, Windsurf, Aider, Continue, Replit Agent, Bolt, and background coding agents can:

  • Read your docs and code samples programmatically, often via retrieval-augmented systems.
  • Through compatible clients, invoke MCP tools and retrieve llms.txt, OpenAPI specifications, and sample-app repositories during a task.
  • Generate code on a human developer’s behalf, often without that human inspecting every page of your reference material.
  • Perform more reliably with complete examples, explicit version metadata, stable URLs, deterministic tool schemas, and no omitted setup.

DevRel work for agents makes product capabilities explicit and machine-readable.

Audience B: Human developers (inspiration and evaluation)

Developers decide whether to use a product, what to ask an assistant about it, and whether to recommend it inside their teams. They:

  • Encounter products on X, Bluesky, YouTube, Reddit, Hacker News, Discord, podcasts, and at conferences.
  • May first encounter a product in an AI response, podcast discussion, or sponsored tutorial rather than on its homepage.
  • Judge claims partly through the speaker’s public record, whether that speaker is a founder, advocate, creator, or peer.
  • Use presentation, voice, stated trade-offs, and technical detail to decide whether an explanation is credible and relevant.

DevRel work for people gives them a technically credible reason to evaluate the product, a reason to care about the result, and an accountable person to learn from.

Different requirements on the same page

For retrieval and agent execution, a quickstart needs:

  • One concept per page.
  • Complete, runnable code blocks with all imports.
  • Explicit dateModified.
  • Stable URL.
  • No marketing copy.
  • Linked from llms.txt.

For a person evaluating and learning the product, it may also need:

  • A direct statement of the working result and expected time.
  • Explanation of the use case and relevant trade-offs.
  • A reason the result is worth pursuing.
  • A screenshot or demonstration when it helps verify the result.
  • Embedded video or animated demo.
  • A clear, opinionated path with the author’s voice.

One documentation site can meet both sets of requirements. Stripe, Mintlify, Vercel, and Cloudflare combine structured reference material with examples and human-facing explanation. Problems arise when retrieved passages omit execution context or when a complete reference gives a person no help choosing an approach.

How teams split the work in 2026

Some DevRel teams assign separate outputs and owners to agent execution and human evaluation.

For agents:

  • Authoritative reference documentation, structured cleanly.
  • llms.txt and llms-full.txt files.
  • Public MCP servers exposing the product’s capabilities to AI agents.
  • Sample-app repositories with disciplined READMEs and complete runnable code.
  • OpenAPI / GraphQL schemas published canonically.
  • Clear, deterministic error messages.
  • Versioned URLs that survive site reorganisations.

For humans:

  • Live-streamed coding sessions and engineering vlogs.
  • Signed founder posts on X, Bluesky, and LinkedIn.
  • YouTube tutorials embedded in trusted creators’ channels.
  • Podcast guest appearances by senior team members.
  • Conference talks with vivid demos and personality.
  • Vlogs, ship-week blog series, in-public build threads.
  • Participation by named staff in Discord, Reddit, and social discussions.

Agents need enough explicit context to complete a task. People need to understand the product, decide whether it fits their situation, and remember the explanation. Those requirements call for different writing even when both versions live on the same page.

Why the split is likely to persist

Four differences make the split likely to persist:

  1. Agents and humans receive different context. An agent often receives retrieved passages and tool schemas; a person can navigate the site, compare alternatives, and bring prior knowledge. Documentation must support both conditions.
  2. Agents account for a growing share of first-touch discovery. Surveys published in 2025 and 2026 generally reported more developer research beginning in AI assistants rather than Google. The exact share is difficult to measure, but the behaviour is established enough to treat as a separate discovery path.
  3. Recommendations still have accountable authors. Developers, maintainers, and technical leaders choose what to integrate and defend in architecture meetings. Their published work also becomes part of the evidence available to AI systems.
  4. The work uses different skills. MCP servers require schema design, permissions, and reliability. A useful video requires teaching, editing, and an identifiable presenter. Larger teams may assign those surfaces to different specialists.

How the dual audience changes hiring

A DevRel team that designs for the split needs:

  • Agent-focused roles. Often called Developer Experience Engineers, Documentation Engineers, MCP Engineers, or Agent Experience Engineers. They work on schemas, completeness, error-message design, and machine readability.
  • Human-focused roles. Developer Advocates, Educators, Content Creators, and Community Managers work on explanation, events, community trust, and editorial quality.

Early-stage companies may combine these responsibilities in one role, while larger teams can assign documentation, engineering, education, and community work to specialists.

See DevRel hiring and careers and DevRel job market, mid-2026 for hiring patterns.

How the dual audience changes measurement

Two largely-separate metric stacks:

Agent-side:

  • Share of Model / Share of Voice in AI assistants. How often do ChatGPT, Claude, Perplexity, Gemini mention your product favourably when asked about your category? (See GEO and AEO for DevRel.)
  • MCP server adoption. Connections, tool-call volume, error rate.
  • Doc completeness / llms.txt health. Coverage, freshness, machine-parseability.
  • Agent-mediated activation. Developers who arrive having “tried it via Claude Code” or similar; success rate of agent-initiated integrations.

Human-side:

  • Traditional content metrics, but with new emphasis on authority signals: named-author content, Discord active members, podcast-guest reach, conference speaker placements.
  • Sentiment in named-developer-influenced channels (high-reputation X/Bluesky accounts, prominent YouTubers, top podcasts).
  • Community-led growth signals (organic mentions, fork-and-build patterns, OSS contributor growth).

A combined dashboard can show both paths, although many teams still measure human and agent use separately.

What goes wrong when teams collapse the dual audience back into one

Common failure modes from observed 2025 to 2026 programs:

  • “AI-readable” treated as the only goal. Docs may provide complete schemas without enough explanation for a person to evaluate an approach.
  • “Authenticity” treated as the only goal. Highly personal copy may leave terminology, examples, and constraints inconsistent across pages.
  • One owner without enough capacity. Running a video channel and maintaining exhaustive agent-facing reference material require different schedules and skills; assigning both without sufficient time degrades one or both.
  • No support for agent-mediated use. If customers use agents, incomplete schemas, examples, and errors can produce failed integrations or force developers back to manual work.

Operating model

Teams serving both audiences maintain machine-readable product surfaces and human-facing education, community, and explanation. They assign ownership and metrics to each kind of work instead of assuming one content programme will cover both.

See also