This week my team announced a name change from "Developer Relations" to "Builder Relations". This isn’t really about a rebrand, or another flavor-of-the-month trend. It’s about how our teams are changing, because the people coming through the door (or the ones who never bothered with the door) aren’t just “developers.” For us at HubSpot, this shift started once we noticed more and more folks who didn’t fit the classic developer profile—but absolutely fit the description of “builder”, and we are not the only ones. MongoDB, for example, made the move—renaming their team to focus on builders rather than developers. They saw exactly what we did: the next wave of creation is coming from people with ideas, not just code.
Why “Builder” and Not Just “Developer”?
This isn’t about watering down what it means to be a developer. It’s recognizing that there’s an entirely new group of people, armed with a clear sense of the problem they want to solve—and empowered by AI and no/low-code tools. It’s not about credentials; it’s about intentions and curiosity. In my opinion, the one skill that truly matters now is knowing what outcome you want and being just curious enough to experiment.
Honestly, we’re finding that the best “builders” today are people who start with a process that’s broken or a workflow they want to automate—not someone looking to show off lines of code. Devs are still here, and honestly, we need them more than ever. It’s just that now, they’re a (critically important) subgroup of the bigger “builder” category.
What Stays the Same
No matter what badge you give the team in Slack, the mission doesn’t really change. It’s still about fanatical end-user focus: helping someone achieve an outcome they probably didn’t believe was possible. What it means tactically, though, is that content matters, all content. Written docs, code, videos, and now, prompt libraries. I can’t overstate this: prompts are the new code samples.
Content Evolution: Content for the 101 Era
We’re doubling down on 101-level content. A ton of what we’re creating now starts at business value and walks back—“here’s a real-world problem, here’s a prompt or two, here’s how to put it together.” People aren’t looking for permission to build, they need to see what’s possible, right up front, in a menu format, not buried in a manual. This is so different from old-school DevRel, where we assumed a baseline of skill and just tried to level people up from there.
The New AI-First Builder Journey
A while ago, we mapped out our developer journeys, and I realized there was this whole new path emerging. It goes something like: “I’ve got an idea, I don’t have the faintest idea what’s possible, and I honestly don’t know where to start.” This is the AI Builder Journey. It’s way more about confidence and curiosity than tech onboarding. My job, and the job of the team now, is to make sure the path from zero to “I built something” is smooth, if not dead simple.
Challenges of Builder Relations
Here’s where it gets real: most builders don’t think like traditional developers. Teaching AI basics, showing why a prompt works (or doesn’t), explaining the difference between an “easy button” tool and a real, robust solution—this is the day-to-day grind. The tooling space is noisy, and the learning curve isn’t about syntax anymore; it’s about learning how to steer an AI. Sometimes, that’s even harder.
Looking Ahead: Builder Literacy Will Be Table Stakes
I honestly believe “builder literacy”—being able to think up a solution and bring it to life, especially with AI—is going to be part of everyone’s job description sooner rather than later. Engineering isn’t going anywhere, but more and more, I see engineers evolving into system architects, people who know how to orchestrate agents, test automatically, and spot the places where AI can go spectacularly wrong if you’re not paying attention.
A Note of Caution—and Hope
It’s super tempting to say that “everyone’s a builder now.” But let’s be honest—not everyone is, or should try to be, an AI architect. There’s a spectrum: everyday builders, the architects shaping agent systems, prompt specialists, and yes, the purist devs who keep the rails strong. The job, my job, our job, is to embrace all sides: support new builders, and make sure we’re still championing the people who create the underlying platforms and context layers.
If you’re considering switching your team from DevRel to Builder Relations, don’t get caught in the branding trap. This is about listening differently, teaching differently, and making content that helps someone go from “I wonder if I could…” to “I did, and here’s what happened.” And keep an eye on those new builders, they’ll change the shape of your platform before you know it.
