The Future of DevRel: Let a Million Ideas Bloom

Back in 2014, I was at Salesforce when the entire company pitch was that cloud computing was the end of software. I'm not exaggerating. "No Software" was on the badges, the booth walls, the keynote. And I watched seasoned Java and .NET developers get genuinely scared, like the skill they'd spent a decade sharpening was about to evaporate overnight. At the same time, I started seeing people without a computer programming background showup at meetups, looking at the low code tools we offered. One of them, a hairdress I believe, later wrote a post that stuck with me for years. The title of the post was "The Best Thing I Built on Salesforce: My Career." It is still available. Do yourself a favor and give it a read.

Sound familiar? It should. I'm watching the exact same fear right now, except the word on the badge is AI. Coding is supposedly done. Developers are supposedly cooked. And every DevRel person I talk to is quietly wondering if their job survives the year.

After fifteen years of this, it's pretty clear: DevRel isn't dying, but most DevRel teams are about to spend 2026 polishing a funnel that no longer exists, and I'd hate for that to be you. The job is turning into something better. We just have to be honest about what's already dead.

The original mission is dead, and coding is a solved problem

Coding is a solved problem. Not "getting easier," not "increasingly assisted." Solved, for the vast majority of what your users actually need to build. I know that sentence makes some people furious, and good. Sit with why it bugs you, because the discomfort is the whole point.

For most of my career the job was easy to describe. Core DevRel meant getting developers successful with your tech, which really meant one question: can they get started? Good DevRel meant smoothing the experience and killing onboarding friction. Great DevRel meant getting developers to believe in your vision so they stuck around when the tech underneath them changed. I've lived all three. I've written more getting-started guides than I can count, and I was proud of a few of them. They're mostly obsolete now, and pretending otherwise is how DevRel teams sleepwalk into irrelevance.

All three rungs assumed the same thing: that the hard part was the code. That assumption is dead. A developer hits a wall, asks Claude Code, Codex, or Cursor, and is past it before they'd have finished reading your quickstart. When was the last time you went to StackOverflow? So if your DevRel strategy in 2026 still revolves around the getting-started guide, I'll be blunt: it's already over. You just haven't scheduled the funeral. The reason I'm not writing an obituary is that something far more interesting is moving into the space it leaves behind. That's what really gets me excited to be in DevRel.

A million new builders, and most of them aren't developers

The people showing up to build aren't who they used to be, and honestly this is the part of all of it that excites me most. Roughly 63% of people doing vibe coding don't come from a traditional development background, and adoption in that group has been climbing fast. I'm talking about marketers, founders, designers, ops people. They describe what they want in plain English and they ship it. Andrej Karpathy only coined the term "vibe coding" in early 2025, and it already describes how a huge share of new software gets made.

And we are early. Really early. Gallup's 2025 data shows most US workers still rarely or never use AI in their jobs, with daily use only in the low teens. If you live in the San Francisco bubble like a lot of us do, it feels like the whole planet already builds with agents. It doesn't. That gap isn't a problem to worry about, it's the runway. The audience for "you can build this yourself" is about to get an order of magnitude bigger, and almost none of those people will ever read your docs cover to cover. You better be ready.

So what should DevRel even do all day now?

The answer I keep coming back to is a flywheel. Three parts, and they feed each other. Better agent experience pulls in more developers. Inspirational content pulls in builders who never called themselves developers. And the outcomes compound, because once your product reliably gets people to a result, the models start recommending it by default. More apps, more commits, more authority. Then it spins again, and each turn makes the next one easier.

Win the agents: AX is the new getting-started guide

Your product's first user is a language model now. Sit with that for a second. Before any human reads your docs, an agent has already tried to use your API on their behalf and either pulled it off or quietly gave up. There's a name for designing around this: agent experience, or AX, a term Netlify helped popularize. It's the same instinct as good developer experience, just pointed at a user that can't infer intent, can't read between the lines, and will never file a support ticket when it gets confused. It just fails silently and moves on.

In practice that means machine-readable docs, clean OpenAPI specs, tools scoped tightly enough that you're not dumping your entire surface area on the agent at once, and actually testing whether an agent can finish the task end to end with no human in the loop. I cared about this enough that I built AXRank, a leaderboard that grades how well frontier agents can use a company's developer surface. I'll be honest with you: watching an agent flail against a product I thought was well-documented was humbling. It's the most honest usability test I've ever run. If you've never done it, go do it this week.

Let a million ideas bloom

DevRel is moving from helping someone solve a coding problem to helping them bring an idea to life, and for me this is the heart of the whole shift. Those aren't the same thing, and we keep confusing them. A founder doesn't want a tutorial on your SDK. She wants her thing to exist, and she wants it to make money. That's the "I built my career on Salesforce" moment, reborn for a generation that will build careers, side projects, and whole companies on tools they couldn't have touched three years ago.

Most DevRel teams are still writing content for the developer who's walking out the door and ignoring the builder walking in. That's backwards, and it's costing you the next decade of adoption.

I get this one personally, because I'm one of those builders too. I'm always making something at night when I should be sleeping: My Camino Guide, Bitwit, AXRank. The tools that let me ship those didn't exist a few years ago. So when I say DevRel needs to serve builders and not just developers, I mean people like me, and people far less technical than me. You don't need to teach a non-developer to write a for loop. You need to make them aware of what to ask the model, and you need your product to be the thing the model reaches for when they ask. Put founders and marketers on your stage. That does more for this audience than another reference doc ever will. I've argued for years that developers respond to learning, not marketing, over on The DevRel Collective, and that holds even harder when half your audience would never call themselves developers.

Sell outcomes, not features

Features were always a proxy. We sold features because we couldn't measure the thing people actually wanted, which was the outcome. Now we can measure it, and selling features is going to age about as well as selling shrink-wrapped CDs. The market is already there, and you can see it in how companies price. Replit and Lovable don't sell you a coding environment, they sell you a working app. Zendesk and Cognition aren't really selling seats, they're selling a closed ticket and a finished task. The unit being sold is the outcome, and some of these companies are building their whole pricing model around it. If your product gets judged on the outcome, then DevRel has to get people to that outcome and keep them there. Surviving onboarding isn't the win anymore.

The speed behind this still stops me cold. GitHub's Kyle Daigle pointed out there were a billion commits in all of 2025, and by early 2026 the platform was doing 275 million a week, on pace for something like 14 billion for the year. Agents are writing a serious chunk of that. When ideas turn into running software that fast, DevRel earns its keep by being customer zero: the first to feel the friction between an idea and a shipped result, whether the one stuck is a human developer or an agent failing against your product. If your DevRel team can't get from idea to deployed app quickly, neither can the people you're trying to help. And this is where evals come in, because the only way to honestly promise an outcome is to measure whether you actually delivered it.

The catch: AI slop and sameness

There's a real downside to everyone building with the same handful of models. Everything starts to look identical. Adam Wathan, who created Tailwind, joked that he'd like to formally apologize for making every button in Tailwind UI indigo five years ago, because that one default is now baked into what feels like every AI-generated interface on earth. It's funny because it's true. When the models converge on the same defaults, brands quietly converge with them.

If your demo could have been generated by the same model your competitor used, it isn't a demo. It's noise. I go back and forth on how worried to be about the slop, but the optimistic read is that it's good news for us. All those hours we used to sink into getting-started guides can go into the stuff that resists sameness. Creative demos. Real events. A point of view. A brand that doesn't dissolve into the average of everything the model has ever seen. When the baseline gets automated, taste becomes the differentiator, and taste is something a good DevRel team has always traded in.

Where this leaves us: DevRel as a startup incubator

Put it together and the future of developer relations looks less like a docs team and more like part incubator. The mission shifts from teaching people to get started toward helping a much bigger crowd of builders turn ideas into businesses, with your product as the vehicle. Picture creator funds, bootcamps, programs in the spirit of GitHub for Startups or community efforts like Claw Camp.

All of it pointed at one thing: get more people from idea to outcome, and let a million ideas bloom.

If you run a DevRel team, don't try to do all of this at once. Pick one and run at it this quarter. Watch an agent try to use your product and fix what breaks. Put a non-developer builder on your next stage. Define the outcome your product promises and measure whether people actually reach it. The teams that do this won't be mourning the getting-started guide. They'll be too busy helping the next wave of builders ship. If you want to compare notes, that's most of what I write about over at The DevRel Collective, and you can always find me on LinkedIn. Tell me where I'm wrong.