DevRel in AI: What Works for AI Companies

Posted on Oct 30 • Originally published at employabledatascientist.com

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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:

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

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.

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.

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.

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.

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.