CHABOT

Humans and agents

5 minute read 1,196 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 the growing class of background autonomous coding agents. They:

  • Read your docs and code samples programmatically, often via retrieval-augmented systems.
  • Are increasingly likely to consume your product’s MCP server, its llms.txt, its OpenAPI spec, and your sample-app repositories before any human sees them.
  • Generate code on a human developer’s behalf, often without that human inspecting every page of your reference material.
  • Need exhaustive, structured, machine-parseable content: complete examples (with imports), explicit version metadata, clean URL hierarchies, deterministic tool schemas, no half-finished snippets.

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

Audience B: Human developers (inspiration)

The actual humans who decide whether to start using your product, whom to ask their AI assistant about, and which products to advocate for inside their teams. They:

  • Form opinions on X (still), Bluesky (growing), YouTube (dominant), Reddit, Hacker News, Discord, podcasts, and at conferences.
  • Increasingly never visit your homepage. The first time they encounter your product may be in an AI assistant’s response, in a podcast guest’s casual mention, or in a YouTube tutorial’s sponsorship segment.
  • Care about who says something. Trust transfers through human reputations: founders, advocates, content creators, peer recommendations.
  • Respond to aesthetics, voice, ambition, humour, vulnerability, and craft. They tend to discount marketing that hides trade-offs and trust identifiable people who explain their decisions.

DevRel work for people gives them a technically credible reason to evaluate the product and a trusted person to learn from.

Why a single piece of content rarely serves both

Consider a quickstart guide. The optimal version for an AI agent:

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

The optimal version for a human:

  • A vivid hook (“In five minutes, you’ll have a working chat app”).
  • Personality. Maybe a joke. Maybe a screenshot.
  • A reason to care alongside the procedure.
  • Embedded video or animated demo.
  • A clear, opinionated path with the author’s voice.

One documentation site can meet both sets of requirements, but the work needs to be deliberate. Stripe, Mintlify, Vercel, and Cloudflare combine structured reference material with examples and human-facing explanation. Writing a single undifferentiated version often leaves gaps for agents and gives people little reason to keep reading.

How teams split the work in 2026

Mature DevRel teams have begun structuring their outputs around the split deliberately.

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.
  • Founder posts on X / Bluesky / LinkedIn with strong personal voice.
  • 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.
  • Authentic Discord/Reddit/X conversations from named people.

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 have different information needs. Agents must reconstruct context they don’t have. Humans bring their context but need emotional reasons to engage. These are different jobs.
  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.

The unified “Developer Advocate who does everything” still exists, but is increasingly best for early-stage companies. Mature teams specialise.

See ../02-foundations/hiring-and-career.md and ../02-foundations/job-openings.md 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-aeo-for-devrel.md.)
  • 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 become flat, voiceless, optimised for parsing. Human developers find them sterile and never form an opinion about the product as a brand.
  • “Authenticity” treated as the only goal. Quirky human-voice content fills the website. AI agents get inconsistent answers and stop citing the product. Developers who arrive via AI assistants encounter contradictions.
  • One person doing both audiences. Burnout and quality collapse. The energy required to operate a YouTube channel is incompatible with the discipline required to maintain an exhaustive llms-full.txt.
  • Pretending agents aren’t an audience. Some old-school DevRel teams have stayed in pure-content mode. They are losing share of AI-mediated discovery to competitors who treat agents as first-class users.

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