DevRel in 2026: Thematic Shifts, Product-centric Advocacy and the Rising Tide of Coding Agents

DevRel, in 2026. Let’s talk about it. A lot to unpack because developer relation has been going through a massive change since 2020, and this agentic shift is no different.

Cycles of DevRel, Market Economics, and the rise of ChatGPT

Just prior to 2020, I’ve seen takes on X about “DevRel hits it peak”. Primarily by someone who was doing DevRel themselves. Completely disagreed with this somewhat spicy take back then but I can see what drove them to that conclusion. Back then, DevRel was a lot about being on the road and doing talks. Primarily obvious is if you attended a conference, at least a third of the speakers were titled “Developer Advocate” and it felt like Developer Relation practitioners of all forms were in a golden age, in-demand by conferences and companies alike.

Then the pandemic hit on March 2020 and the world changed, for a little while, at least. Everything became “online”, and DevRel had to adapt. The focus shifted from in-person events to virtual engagements, webinars, and online communities. Producing content, both written and video was also a primary focus. Ultimately, this COVID-19 period saw a surge in content creation, with DevRel professionals producing more blogs, videos, and online tutorials to engage with their audiences. That’s something that I anticipate will change fundamentally with AI but we’ll get to that in a bit. So DevRel folks who were primarily “on-the-road” needed to adapt and many were quite confused by this.

At the same time, from an economic perspective, and the zero interest rate phenomenon (or just ZIRP as we call it on X), the world was in a boom and the market demonstrated a V shape recovery. This meant that companies were hiring aggressively, including in DevRel, and there was a lot of demand for DevRel professionals.

Then in 2022 the market tumbled again. Company layoffs were a common theme and every week some other tech company announced layoffs, including in DevRel, across big-name Co’s, and the rise of inflation and bye-bye of ZIRP made the economic environment even more bearish and challenging for companies to hire. Many tech companies also shifted their focus from growth to profitability or cash flow positive. That also meant a very visible shift in DevRel from an “awareness” and “outreach” mindset which was coupled with PLG strategies (Product-Led Growth) to a more revenue and enterprise-level focus.

Then came ChatGPT. The Chat that changed it all.

One signal that was telling from the early days of 2023 was that of the “Master Builder” DevRel role that was emerging and possibly the most prolific person I can think of who’d I associate with that role is Hassan El Mghari.

We’ll get back to this. But let’s fast forward to 2026.

DevRel in 2026

Here are some hot takes the make up the current state of tech in 2026 and as a derivative, DevRel. See if you can spot the pattern: code is cheap, oh this blog post? claude wrote it, we have to ship fast, did you see all those meetups in SF fully booked on a Saturday??, we need to hire more engineers, we dont need engineers we can just claude code. Yes, welcome to the world of confusion, chaos, fast moving targets and we’re all trying to figure out what the heck is going on. If you thought DevRel was hard before… well, it’s only getting more interesting.

Fundamentally, a lot has changed with LLMs and AI agents becoming more capable and ubiquitous and if you’re working in DevRel you have to really question everything to the core. To break things down to the very basics and then re-build up.

Let’s start with questioning the very building blocks that make up a lot of activities in Developer Relations - written content: blogs, tutorials, cheat sheet, listicles, and so on:

• Written content before AI: previously, they made a lot of sense. Devs would google for “how do I protect myself against npm malware?” or “how do I build production ready Node.js containers?” and they’d land on my articles which were also featured on newsletters and I know how valuable it was for devs. I could harness my own expertise and deep roots and experience in those ecosystems and being an SME to create that content.
• Written content after AI: What’s the point though now? LLMs not only trained on all of that content, and more, but they can also search, analyze, and synthesize the information from multiple sources in real-time. Developers can now ask a coding agent directly for the information they need, and it can provide a comprehensive answer without them having to sift through multiple articles. And that’s for just one kind of content where potentially you as a DevRel would be able to provide some sort of valuable and unique perspective. What about general content creation? for the sake of SEO? Well, that’s likely a losing battle. At the very least, we can probably agree that this content can be generated and automated entirely at scale with AI agents, which means dedicated content writers for the sake of producing content is likely not the best investment you can make.

The point I’m making isn’t that written content no longer has value, but rather that the value is shifting elsewhere and that other aspects of written content creation are becoming more important, especially with AI. One example of the shift, in my domain of work in cybersecurity, is that of zero-days and malware campaigns. Pre-AI, it would take a large investment of hours to days to research the timeline, attacker payloads, cross-reference with other researchers and other signals, analyze the payloads and trace the IoCs (Indications of Compromise), and then put down down the findings in a blog post. These days, when a signal for a malware campaign happening on npm or PyPI I fire up a coding agent setup I have that performs all of that in matter of minutes, review, then publish.

Content shifting away is just one example, but what are the bigger themes that are emerging in DevRel?

Thematic shifts in DevRel post 2026 and coding agents

More than ever, I think that if you’re in DevRel you should really question to the core what your role is and what value you bring.

I have personally gone through an exercise myself of re-thinking DevRel from first principles and what does that look like. Is your mission statement still relevant? Is your persona still developers in the pure sense of “programmers” or has it shifted to be “AI builders” for example, a wider audience? Maybe your persona is now agents and you should be building for agents. Yes, serving the machines. Feels weird? Malte from Vercel built just-bash which is Bash for Agents. That’s right. Not an SDK for humans, not a library for developers. A building block for the machines. Many other examples of this. Here’s another one from the DX field, did you consider turning your CMS / Blog platform to serve agents so that when they fetch an article or a product page, identifying themselves using a specific user-agent, you can serve the Markdown version of that content rather than the messy HTML version? This is a very real thing and something that I think DevRel should be thinking about, especially if your role centered on DevEx. Perhaps your persona now shifted over to AX (Agent Experience).

So going through a first principles exercise myself, I’m going to focus on primarily 3 themes that I’ve seen emerging over the past 2 years:

DevRel Engineering

DevRel Engineering strongly connects with the “Master Builder” type of work that I’ve seen emerging in the past couple of years. Not only me, but also swyx recognized Master Builder importance in DevRel.

Now that “code is cheap” (heh, story for another article), it’s not that the value of DevRel is no longer in writing code. It’s not that code isn’t valuable. It’s that it has been democratized and accessible to all. Even if you were a very skilled engineer with hands-on daily habits of coding, putting together a working prototype, let alone pushing something to a semi-production system like say building a game for your events, or building a webapp like one of those “advent of code” yearly summaries or hackathons, would take a considerable investment and effort on your end. Now, though? whip up a coding agent and you’re golden. Prototyping and building full-fledged apps, deploying them, all within hours, or days at most.

This huge shift in the DevRel landscape where we can spin up experiments, build-up open source projects, demo applications, integrations and various CLIs or tools is a part of DevRel activities that I’ve not only seen already happening by others but one that I think is going to be accelerating.

But to what end? As the saying goes, the fact you can do something doesn’t mean you should. So we go back to first principles and ask ourselves, what is the value of DevRel? If you deconstruct to the undeniable truth and say “DevRel is about building relationships, connecting and reaching developers” then the question becomes, how and where these days do developers want to be reached and on what grounds? Perhaps AI builders today don’t “google a topic to learn about it” but rather “go find a Skill they can give the agent to review their code for security”. If that’s a shift you identified, then DevRel Engineering effort for you might mean you need to be building various Agent Skills, publish them to skills.sh, or tessl.io/registry and this becomes the “consumable artifact” that your developer audience gets value from.

Other value streams hidden inside DevRel Engineering I want to call out are:

• Growth Engineering: Going back again to first principles, if an undeniable truth of the basics of DevRel is outreach, growth and down the funnel activation too, then DevRel Engineering is now center stage. A good example from my own DevRel team on this, and before ChatGPT - we built the Snyk Advisor. We, the DevRel team, built a web app that allows developers to search and query for package health and security information. This was part of the shift we did in 2020 when we first built-out our own DevRel Engineering function. Snyk Advisor, as a web asset, grew quite quickly to become top 3 source of traffic to the Snyk website, and second most vehicle of user adoption. Growth Engineering in this sense means not just about building for the narrow domain you work at, but also building for a wider lense of interest that fuels growth. At the end of the day that means this work is actively creating tools, integrations, and experiences that help developers discover, adopt, and advocate for your product or platform. Now that building apps is so much easier, fun, and accessible, what will you build?
• Experimentation: DevRel in 2026 should mean we can experiment in rapid cycles. I call it “Stop fast, Start fast”. Build something. Put it out there. Push it a bit. Measure how well it does. Does it work? Amazing, keep pushing. No traction? No problem. Stop it. Move on to the next bet. Experiment more. Launch more often, quicker.
• Market validation: My personal observation is that DevRel, even before ChatGPT and coding agents in 2026, is an extremely valuable function for market validation. We most often work in an outward facing role, live and breath the industry, the ecosystem shifts, the trends and the bleeding edge. We see the drama unfold on GitHub comments or hacker news, and we can tie a lot of signals together to a more coherent picture to then assess where the market is going. This isn’t just about “what’s trending” but also about “what’s the next big thing” and “what should we build?” and informing the internal product about the direction. Leaning in to all of the above points on DevRel Engineering only makes this more possible.

All of the above also goes hand-in-hand with a core aspect of building software that Developer Relations team are often proud of - open source.

X is dead, long live X

A lot of water under that bridge for X/Twitter. Regardless of whether you’re a fan of X, there’s no denying that everything, and I mean everything, just happens on X. Not only so, but if you “live on X” then you’re basically living about 6 months into the future, sometimes more. The trends, the news, the drama, the hot takes. Everything is on X before it is elsewhere.

If you’re building a product, want to connect with the builder community, launch a new feature, or get a pulse of things, you simply can not afford not being on X.

I don’t know how this comes off, maybe this feels synthetic or forced, so let me sprinkle some examples of what I mean for “you should be on X” statement:

• Product launches: Forget those big quarterly product launches. Please do not, by all means, cave to postponing announcements to some big event timeline, or “save” a feature/product/news launch to some “bigger release”. Everything moves so fast. A week in AI days is like a month, and a month is more like a year. Whatever you want to launch, just launch it, post it on X (and elsewhere). I truly do not see the value of holding back anymore. Keep a note that momentum is everything and the moat is execution. If you’re not publishing fast enough, someone else will.
• Product feedback: If I had a dollar for every time I had a PM ask me “I want to run a survey for devs, how should we do it?”. Well, dear Product Managers, if you want to reach devs guess where you should be? yes, where devs are at, and that’s on X. Yes yes, not all of them. But a good chunk? The chunk you might care about because you want that brutal feedback, from those who are the most opinionated, vocal, and likely seeing the same market trends as you are hopefully also building towards.

I already wrote about this in a previous article on DevRel Failures? Maybe Your Marketing and Product Strategies Are Outdated which I highly recommend skimming through, especially if you’re looking for further validation as I cite PMs from Cloudflare, Vercel and the VS Code team too.

The bottom line I’d leave you with on the X argument is that you should re-evaluate your DevRel strategy to shift to be more X-centric. Low hanging fruit examples:

• You have a YouTube channel? Great. Consider shifting that content to be posted more primarily and featured on X via the live streaming feature, videos produced specifically for X. Similarly, take advantage of the “Spaces” feature and you’ve got yourself a live podcast as easy as cake, or a live Q&A session with your audience.
• X has “Articles”, start posting your content there.
• Engage. Reply. Take part of the conversation. Just please please do not become an AI reply bot. I block those accounts on a daily basis. Be real, be authentic, be you.
• Your team is announcing a new feature? forget webinars, an official blog post or the updates.company.com page. Go post it on X with a tasteful thread, lively demo, images, fun video and drop a link at the end to the product so we can try it out.

Product-centric advocacy

I estimate that more than the two themes I covered above, this one is going to be the more controversial one :-)

If there’s one absolute truth about DevRel is that we’ll all agree to say that we’re not sales. We’re not doing a conference talk which is sales pitch. Totally agree. This hasn’t changed and shouldn’t changed. However…

I feel that we as developer advocates may have shifted too far away from the product and its mission to benefit developers, that we’ve become too shy and embarrassed to talk about it or mention it. Many talks have become too abstract, too high level, and while there’s value in market education and generally in teaching broader concepts, I think that this is the time to lean in to the real thing. I’ve been feeling that way for at least a year, where I wanted to sprinkle more of the product into my talks, not in a form of a sales pitch, but rather in the form of a real example, a genuine case study and workflow that solves a real pain. It’s hard to disconnect from the cringe feeling that overtakes because I get guilty about being disingenuous or “selling” something, and probably there lies the art of telling a good story that strikes the balance of being authentic, educational, and product-centric.

That subjective estimation I’ve made of DevRel needing to lean more into the product is drawn and validated from what I’ve seen happening in the market too, mostly at meetups but at times at conferences too (to a lesser degree). At meetups, from the busy SF scene, to world-wide events, which I’ve personally attended both types, there’s a clear trend of talks that center on the product. They’re not a pitch or a demo delivered to enable you. The good examples I’ve seen are done with taste. The product is demo’ed in a way that solves the problem.

Is it bad faith evangelism or is it exactly what your audience is expecting of you? I think the latter. Last year, I spoke at a Cursor meetup in Haifa with 300 developers in the room tuning in to my MCP security talk. I still have the slides to show you. There was no “Snyk” product mention until the very last slide as a brief sort of CTA to learn more about our MCP security product in relation to the attacks and security incidents I talked about in the talk. I finished the talk. Q&A starts. Everyone are asking me “ok so how do we use MCP servers safely?”, “can Snyk scan the MCP servers?”, and so on. In my attempt to be authentic in my talk, avoid any sales pitches, I ended up leaving the audience with more questions that I could’ve easily closed the loop on if I had featured the product a little more in the talk. Not to be confused with a full demo, but just enough to explain how we solve the problem, what it looks like, and how it works. A short demo of that is priceless and IMO does not erode trust or authenticity.

Now I want you to zoom out of this specific example of product value in talks. Zoom out more. Think about the broader state of the industry. The entire software industry. Just think about it. What are you seeing?

• Developers are confused and are facing an identity crisis.
• Companies are trying to find their moat.
• Technical leaders are unsure what “best practice” looks like anymore.

The point I’m making is that everyone are confused and more than ever before, developers are looking for guidance and direction. The market is moving extremely fast under their feet, and they are hungry for someone to help them navigate the chaos. Show them the demo. Show them how it works. Whatever they take from it is now their choice.

A meetup talk is one example where product leans in heavily but it’s not the only one. Re-evaluate your community events strategy, Re-evaluate your content strategy. Should you still be making generic videos about X and Y or perhaps you want to show AI builders how your product solves skill security, how to audit the code that Codex wrote for them to find vulnerabilities in it, what are hooks and how to use your product’s hooks to connect it to Cursor and add a guardrail so that Cursor doesn’t go all rogue on you and downloads a malicious package, or commits secrets to the repo? All real genuine concerns if you ask me, that developers are facing today and you have an opportunity not just to educate them about these problems, but also to leann in and show them how to solve it.

Yes, there are nuances here with leaning into the product. The product you’re advocating for isn’t gated behind a paywall. They can easily try it. It’s free. The onboarding isn’t some dark pattern they can never escape your newsletter campaign drip. Best, as always, if it’s open source.

The TL;DR here is that you should lean in to the product, not completely ignore it. Remember I wear that green Yoda hat? balance is key and just as hard to master it.

Next in Developer Relations

There’s a lot more to unpack in how DevRel is impacted as a whole department within devtool companies. If that’s even a thing…?

If everything is changing around you, maybe you should start questioning everything you do. Are you bound by Newton’s first law and still doing what you’re doing because of intertia? What are you cargo-culting? Perhaps more importantly than everything else - what should you stop doing? What activities no longer make sense? Where did the value shift to?

Fun times! ;-)