Agent discoverability vs hiring a developer advocate
A DevRel hire costs more than the service and does different work. What each one is actually for, and which one to do first.
This comparison comes up because both are a similar line in a budget, and they are frequently posed as either-or. They do different work.
The short answer
A developer advocate builds relationships with people and produces artefacts: talks, examples, repositories, posts. Agent discoverability measures whether coding agents install your product, and works the levers that move that number. The first is a communication job. The second is a measurement job with an infrastructure problem behind it.
What a developer advocate does that a service cannot
- Builds real relationships in a community, which compounds over years.
- Represents the company in a room, on a stage, in a thread.
- Brings back what users actually say, unfiltered.
- Produces artefacts with credibility because a person's name is on them.
- Handles the parts of adoption that are social rather than technical.
None of that is replaceable, and a company with no presence in its own developer community has a real problem that no measurement fixes.
What agent discoverability does that a hire cannot
The measurement, mostly, and the specific reason is cost.
Measuring install share properly means running real coding agents on real tasks inside realistic repositories, at enough volume to see past noise. The same agent on the same repository disagrees with itself about a quarter of the time, so a category needs hundreds of sessions rather than tens. One session is a dollar to fifteen in tokens and about nine minutes.
Then something has to read every transcript and record what was chosen, and a person has to check that reader.
That is an infrastructure and data problem. A single hire, however good, does not build that alongside their actual job.
Side by side
| Developer advocate | Agent discoverability | |
|---|---|---|
| Reaches | People | Agents, and the repositories they work in |
| Output | Talks, examples, repositories, posts, relationships | Install share by agent, language and persona; the changes that move it |
| Feedback loop | Slow, qualitative, hard to attribute | The agent's own recorded reason for rejecting you |
| Compounding | Yes, over years | Yes, through templates and integrations |
| Typical cost | More than $60,000 a year fully loaded, plus travel | From $5,000 per month |
| Fails when | Adoption is decided without a human in the room | The market is genuinely social rather than technical |
What changed for developer relations
The classic case for a developer advocate assumed the decision was made by a person who could be reached and persuaded.
A growing share of decisions now happen differently. A developer types one line into a coding agent, and the agent reads the codebase, decides what is needed, sometimes searches, installs a product and writes the integration. A conference talk does not reach that.
Two numbers that frame it:
| Agent | Ran a web search on decision tasks |
|---|---|
| Claude Code | 1.6% of runs |
| Codex | 53% of runs |
And the repository outweighs both. The same request produced one winner in 111 of 111 JavaScript sessions and 48 of 132 TypeScript sessions. A written instruction naming a preferred product lost 2 times out of 3 once a rival library was installed.
So developer relations still works, and the mechanism shifted. The talk reaches fewer decisions. The repository, the example and the written post it produces reach more, because those are artefacts an agent can read.
That is worth telling a developer advocate explicitly, because it changes what they should optimise for: fewer stages, more maintained templates and official integrations.
Which to do first
Measure first, if you can only do one thing. It is cheaper than the hire and it tells you whether the hire's usual playbook will work. Running 300 sessions yourself costs a weekend and a few hundred dollars in tokens.
Hire if the answer comes back social. If agents mostly hand the choice back to a person in your category, the decision is still being made by humans and you should go and talk to them.
Do both if you can. They are not substitutes and the good version of each makes the other work better. A developer advocate who knows that install share drops 30 points on TypeScript repositories has a much better idea of what to build next than one who does not.
The cheap experiment either way
Three repositories that look like your users' projects. Ten requests written as symptoms rather than category names. Five runs each with Claude Code and Codex.
Read the sessions you lost. If the reasons are technical defects, you have a documentation project. If they are genuine preferences, you have a positioning project. If the agent never considered any vendor, you have an education project.
Those three conclusions imply three completely different hires.
Common questions
Should I hire a developer advocate or buy agent discoverability?
They do different work. A developer advocate builds relationships with people and produces artefacts. Agent discoverability measures whether coding agents install your product and works the levers that move that number. If your adoption is increasingly decided inside agents, measure it first.
What does a developer advocate cost?
A fully loaded senior hire in the United States or Western Europe is typically more per year than a $5,000 per month service, before travel and event budget.
Does developer relations still matter in the agent era?
Yes, and partly for a new reason. A talk reaches fewer decisions than it used to, but the repository, the example and the written post it produces are artefacts agents can read and cite.
Can one person do both?
Rarely well. Measuring install share properly means running hundreds of real agent sessions per category, which is an infrastructure job rather than a communication job.
Where this comes from
Armature ran 5,292 judged sessions with Claude Code, Codex and Cursor inside 51 realistic codebases, and published every run. The numbers on this page come from that work.