DevRel in AI: What Works for AI Companies

TL;DR

• DevRel (developer relations) in AI is the work of getting developers to try your product, trust it, and keep using it, and carrying what they hit back to your engineers.
• AI developers trust what they can run. A notebook, a trace, or a repo that works on their own machine beats a launch post.
• What works is something runnable, a way to reach a person from inside it, honest notes on where it fails, a feedback loop into the product, and one audience at a time.
• What wastes money is events before a strategy, a megaphone as the first hire, content quotas, and vanity metrics.

Most writing about DevRel in AI is a list of famous people. This is a guide for the person who has to decide what to do on Monday.

I've worked in developer relations for AI companies since 2020. I led DevRel and developer advocacy at Deci AI, which NVIDIA later acquired, and since then I've embedded with AI and developer tool teams, mostly in computer vision and robotics. This guide is for founders, heads of product, and engineering leads who are deciding whether to build a DevRel function, hire one person, or bring in outside help.

It pulls together what I've written on the topic this year, and it ends with the work I've built so you can check it yourself.

What DevRel in AI is

DevRel sits between your engineers and the developers who might use what they build. It covers five jobs:

• Teaching people how to use the product.
• Getting them to a first working result.
• Collecting what goes wrong.
• Building a community.
• Publishing content.

Most companies need one or two of these at a time, not all five. Developer marketing makes people aware you exist. Developer advocacy teaches, demos, and listens. Community gets developers talking to each other. If you hire for the wrong one, you get a busy calendar and no change in adoption. I wrote more on telling them apart in DevRel vs developer marketing vs community.

Why DevRel in AI is different

Developers who build with AI have been burned. They've seen benchmarks that don't reproduce, agent demos that work once, and model updates that change behavior under their feet. So they've learned to ignore claims and test them.

That changes what counts as proof, and it differs by audience.

What works

Ship something that runs

A runnable artifact does the job a launch post can't. It lets a developer check your claim on their own machine. That can be a notebook, a repo, a dataset with a loader, or a command line example.

This is the idea behind the forward deployed engineer model. Someone works inside your product, builds against the real API, and reports what broke. I make the full case in use the forward deployed engineer model for your DevRel. The test for any piece of developer content is whether it still holds up with the adjectives removed, which I cover in developer content that doesn't feel like marketing.

Put a way to reach a person inside the artifact

A developer who hits an error at step four should not have to go find a support page. The YOLO-NAS notebooks I wrote at Deci open with who I am and three ways to reach me: an email, a community Discord server, and a GitHub issue. The object detection one also lists starter datasets, so the reader can try the method on data that isn't mine.

Write down where it fails

Developers trust you more when you tell them what doesn't work. I think of trust as a running balance. Specific, honest, reproducible things add to it. Vague, broken, or exaggerated things take from it. I lay that out in the developer trust ledger. Publish the failure modes next to the demo.

Turn repeated questions into evidence for engineering

Don't forward every comment to the product team. Collect what developers say, sort it, check that it reproduces, send it to a named owner, review it on a schedule, and close it when it's fixed. Product teams act on patterns that come with severity and a reproduction, and they ignore anecdotes. The full loop is in how to build a developer feedback loop product teams will use.

Pick one audience, one path, and one metric

Early DevRel doesn't need an ambassador program, a conference calendar, or a big community. It needs one audience, one path from reading about the product to a first working result, one content rhythm, one feedback loop, and one number to watch. The zero-to-one developer program walks through it.

Positioning comes before all of that. Name the developer, the problem, why your product fits, and why they'd pick it over the default. DevRel strategy starts with positioning, not events covers how. If you want a schedule, use a 30/60/90 day DevRel plan.

What wastes money

• Events before a strategy. An event is an expensive way to find out you didn't have one. A small workshop with the right developers can beat a large booth. See the anti-playbook for DevRel events.
• A megaphone as the first hire. A big following helps with reach. It doesn't tell you whether the person can build, write, and talk to your engineers. See the first DevRel hire should not be a megaphone and how to hire a developer advocate who can actually build.
• Content quotas from a team that never touches your product. Ask one question before you sign. Will you build something against our API, or only write about it?
• Vanity metrics. Impressions and badge scans measure activity. Pick the stage of the developer journey you want to move, name the behavior you expect, and track that. See how to measure DevRel without vanity metrics and community metrics that survive CFO review.

When you don't need DevRel yet

If your positioning is unclear, your docs are broken, or onboarding fails, fix those first. A DevRel hire will only make a confusing product louder. The usual order is product clarity, then the developer journey, then technical proof, then a feedback loop, and only then DevRel at scale. When your AI product needs DevRel and when it doesn't goes through the signs, and the developer journey audit shows how to find the friction before you spend on a hire.

What I've built

This is work you can inspect. I'm not quoting adoption numbers, because those belong to the companies.

At Deci AI, I led developer relations and advocacy. A large part of the work was runnable notebooks for SuperGradients, Deci's open source library for training computer vision models. They covered object detection with YOLO-NAS, pose estimation and fine-tuning with YOLO-NAS-Pose, knowledge distillation, and instruction tuning for language models. The YOLO-NAS ones carry the three ways to reach me described above.

Since then I've worked as a Hacker-in-Residence with AI and developer tool teams. At one computer vision data platform, I wrote 35 technical posts, each built around code a reader can run. A few of them are on this site:

• Eight tactile robot datasets compared
• Eleven robot datasets for training vision-language-action models
• Six silent bugs when writing MCAP robot data files, and how to fix them
• Finding edited copies of images with pHash and CLIP
• Building document understanding pipelines with GLM-OCR

Several of them are about what breaks, like the MCAP post on silent bugs.

A five-question check for your own program

1. Can a developer run something of yours today without talking to anyone?
2. Can they reach a person from inside it?
3. Do you publish what doesn't work?
4. Does a named engineer review repeated developer feedback, with examples, on a schedule?
5. Can you name the one audience and the one behavior you want from them?

Each no is a place to start.

Next steps

• If you're deciding whether to hire, start with when your AI product needs DevRel and when it doesn't.
• If you've already hired, run the developer journey audit and set a 30/60/90 day plan.
• If you want a second opinion or hands-on help, the DevRel & Community page explains how I work, and the contact form is the fastest way to start.

Resources

• DevRel vs developer marketing vs community
• DevRel for AI agents
• DevRel for AI developer tools
• DevRel for physical AI and robotics
• DevRel for research and ML tools
• Use the forward deployed engineer model for your DevRel
• The developer trust ledger
• How to measure DevRel without vanity metrics
• SuperGradients on GitHub

Frequently asked questions

What is DevRel in AI?

DevRel in AI is the work of getting developers to try an AI product, trust it, and keep using it, and carrying what they run into back to the engineers who build it. It covers teaching, getting people to a first working result, collecting feedback, community, and content.

How is DevRel at an AI company different from regular DevRel?

AI developers have been burned by benchmarks that don't reproduce, demos that work once, and models that change behavior. They test claims instead of believing them, so proof has to be something they can run, inspect, or reproduce themselves.

When should an AI startup hire its first DevRel person?

Hire when adoption depends on developer trust, education, getting people to a first result, and feedback. If your positioning, docs, or onboarding are still broken, fix those first, because a DevRel hire will only make a confusing product louder.

What should I ask a DevRel agency or consultant before signing?

Ask them to show the last thing they built against a client's API, who will use your product, what success looks like as a developer outcome instead of a content count, how feedback will reach your engineers, and whether the people pitching are the people doing the work.

How do you measure DevRel at an AI company?

Pick the stage of the developer journey you want to move, name the behavior you expect from developers at that stage, and track that behavior. Impressions and badge scans measure activity, so use them only as context.

This post first appeared as the original article. I'm Harpreet Sahota, Hacker-in-Residence at The Employable Data Scientist, where we help AI and developer-tool teams ship prototypes, evaluations, and technical content. I also host the Artists of Intelligence podcast. For new field notes by email, subscribe on Substack.