April 14, 2026
Developer Journey Tactics in the age of AI

Developer Journey Tactics in the age of AI

For developers navigating the five stages of the Developer’s Journey, a high-functioning DevRel team serves as a set of expert mentors providing content, events, and programs that lead developers through each stage, using tactics adapted to the requirements of the technology itself and tailored to your go-to-market strategy.

There’s a familiar parallel to this approach in the canonical form of the Hero’s Journey. Early in that cycle, a mentor appears to help the hero as he leaves home and embarks on his journey of supernatural wonder. Obi Wan teaches Luke about the Force, Gandalf advises Frodo, Sgt. Powell encourages John McClane to stay in the fight. If you’re leading a DevRel team, you are the mentor of mentors, guiding your team in their own journey to build and deliver the right tools and resources at the right time in the right way to be of optimal service to the developer community they steward. (And of course, if you’re a team of one, you are everything everywhere all at once.)

We’ll see how AI adds significant layers to each of the stages, but first, let’s look at the traditional tools a DevRel team should bring to bear on each.

DISCOVER

Discovery isn’t like a brand awareness campaign that can succeed with just a name, an image, a tagline, and a mood. You still have to grab a developer’s attention, but you’re doing it in a technically credible, authentically helpful way. The tools may seem familiar:

  • Blog posts with good organic search discovery. Only a limited percentage of your blogging output will get significant traction, but the key is to focus on search terms adjacent to your technology, related to problems your developer audience is trying to solve. Developers who don’t yet know your technology aren’t going to search for it by name. You have to write for problems you know they’re trying to solve as a means of introducing them to your technology as the solution.
  • Conference talks. To draw in net new developers, successful talks have two essential ingredients: a compelling title and abstract that connects the technology to a problem the community is already feeling (not merely your technology), and content that delivers on the abstract’s promise. It’s an extra win if your speaker is a developer advocate who is well known in a particular community.
  • Meetups. Again, these must be in spaces adjacent to your technology. For example, if you were promoting Terraform in 2015, you’d want to get your talk scheduled at DevOps Meetups. Some technologies are large enough and well-known enough to merit their own Meetup program, but when trying to get new developers to discover you, you must go where they are already.
  • Influencer advocacy. Nurturing the influence of popular voices in your industry is a force multiplier for discovery. When influencers blog, talk, or otherwise produce content about your technology, their audience becomes yours. This is a difficult tool to use well, so proceed with the understanding that less is more.

UNDERSTAND

The work your team does in the Understand stage is directly connected to what they deliver in the Discovery stage. In this stage you're motivating developers to continue the journey they’ve started by giving them what they need to truly understand the technology itself—not merely a name, logo, and mood.

  • The same blog posts that made you discoverable will do the trick for this stage as well. If you have a technology that is widely known about but not yet widely understood, it may work simply to blog about it in more detail, without thinking too hard about adjacent search terms. The same blog post that brings awareness can also impart understanding.
  • Conference talks and Meetups. Again, topics that are already of broad interest to your community may generate their own organic reach. In 2026, a talk about “agentic development” is likely to draw a crowd without having to align with a more popular topic. Even if you don’t have organic reach on your own, you’re still on the hook to provide a solid explanation of your technology once a developer is in the room.
  • Explainer videos remain a popular way of teaching the basics about a new technology. There should be one and only one “Introduction to X” video, which can be followed up by any number of explainers that go deeper into the technology, related subject areas, integrations, or architectural principles your community should master.
  • Product documentation (or project documentation, in the case of open source) must contain an introductory article, prominently featured on the docs landing page, that satisfies the requirements of the Understand stage. In my anecdotal experience, around half of developers prefer to read over watching a video.

PLAY

In the play stage, the developer has developed a robust mental model of your technology; now they need to see it in action. They don’t yet know enough to be able to start from a blank page, so they’ll need something to start with. The details depend on the nature of the technology, but traditionally they fall into two categories:

  • If the product is downloadable, either through a package manager, as a container, or as a direct file download, a traditional quickstart should contain a procedure to download it, install it, and put it through a basic “hello, world” process. This is often in the form of a GitHub repository with a detailed README, but format can vary.
  • If the product is cloud-first, the quickstart can take the form of in-product learning or some other kind of guided tour in the UI itself.

BUILD

If a developer’s experience with the quickstart ends in success, is relatively trouble-free, and is actually quick, they’re likely to pivot to solving real problems in their domain. Traditionally, this is when they move on from explainer videos and conference talks and lean into the documentation. They’ve left “hello world” and the happy path. Now they’re exploring edge cases, trying to find new corners of the API to solve unforeseen problems, and generally adapting the technology to their own unique circumstances. Advanced tutorials and blog posts can help, but the real key to this stage is the documentation.

Examples of details they need?

ADVOCATE

What pushes developers from building to advocacy are fundamentally human motivations: your technology has provided such an elegant solution to the problems they face, and has enabled them to build such valuable, successful systems that they truly want other people to experience their success. They want to recruit others to their team. This is the place where the journey of a developer merges with their journey as a growing, successful human being. It’s the place where a DevRel team can provide some of the most personal, relational, and valuable support for your growing community. Advocate-focused programs might look like this:

  • An MVP program should identify your most enthusiastic community members and recognize them formally as leaders in the space. This can be as simple as a box of branded swag and a picture and bio on your web site, or as elaborate as occasional, well-funded gatherings that resemble customer advisory boards. As the program grows, you should consider tiers that acknowledge your most prolific contributors while still allowing you to scale the program to larger numbers.
  • If you have a podcast, recruit your best-known builders as guests. Some advocates are born, and some are made.
  • Encourage developers to speak about your technology at conferences and meetups. The best way to do this is to fund their travel expenses if you’re able, but short of that, you can also provide mentoring on the presentation itself, or even just make interested community members aware of speaking opportunities.

In the age of AI, what changes?

An AI construct offers to mentor developers

When the standard expectation of AI’s impact on a field is that it changes everything, my early experience in DevRel is simply that it doesn’t, even as it imposes tremendous changes on the day-to-day work of being a software developer. The fundamentals of the developer journey are the same, and thus the fundamentals of what an effective DevRel team are as well. AI has real impact, though, and that impact is additive. The team has more work to do now. Let’s look at the stages again and see how our programs grow in a post-AI world.

DISCOVER

AI models themselves have become a critical new discovery mechanism.

  • When a developer is prompting new functionality in an agentic workflow, the AI is sometimes free to make architectural recommendations. You need to be at the top of its list. Your language, framework, API, service, or infrastructure component should be the one it suggests.
  • Sometimes a developer will simply ask an AI for architectural guidance, whether they begin a chat with that goal in mind, or end up there as a part of some exploratory process. Just like in the agentic coding case, you want your technology to be the answer the AI gives.

If this sounds like an SEO problem, you’re close: Generative Engine Optimization (GEO) is SEO for the AI era. It’s similar to SEO, except that it has only recently emerged as a discipline, so we’re missing the 20 years of experience and best practices that SEO brings with it. Its details are well beyond our scope, but at a minimum, we know that succeeding in the Discover phase in the AI era requires us to double down on publishing text that the models can ingest. This means more blog posts explaining how our technology fits into the world and what problems it solves, and more code samples showing how to use it.

UNDERSTAND

Of course, it’s commonplace now for developers to use AI for research: “Claude, can you help me understand the difference between Supabase and PlanetScale?” or “We rolled our own auth years ago, and want to migrate to a hosted solution now. What are my options?” If you want the models to give new users a trustworthy, accurate account of your technology, you again need to prioritize written content that is discoverable and ingestible by them. You are not just teaching humans—you are teaching the AIs that humans will use as their teachers.

  • Blog posts and documentation should have emerging GEO techniques applied alongside existing SEO methods, helping keep your content front and center in the model’s answers.
  • Video content shows up in contemporary AI results through ingested transcripts, so your explainers are still working for you.
  • Talks, whether at conferences or Meetups, will impact AI only if they are recorded and published in a place the models will use as an ingestion source. Favor venues that post talks to YouTube, or equip your Meetup speakers with a simple recording kit that will capture good audio and workable video.

PLAY

Quickstarts remain important post-AI. Many developers will still want to see a self-contained, authoritative example of how to use a new thing, vetted by the technology’s creators or sponsors. Now, though, it’s also viable simply to prompt a coding agent to produce a prototype. Developers may default to doing this independent of any resources you offer them—they’ll just run the agent of their choice and prompt out a prototype. This is very early on in the process, so you may not ever have a chance to ask a curious developer to do any setup steps at all (like installing skills or setting up an MCP server), so the best thing you can do is to help the AIs write good prototype code by providing them with lots and lots of sample code to ingest.

Public GitHub repos, blog posts with ample code samples, and tutorial pages on your developer site are all places a model’s pre-training pipeline may find code to learn from. There are two things to keep in mind here to optimize for AI ingestion:

  • When publishing code in a blog post or a tutorial page, keep fragments relatively complete. In the past, you might have elided unimportant sections of code to keep the reader’s focus on what you’re trying to teach, but now you’re also trying to show the AI a complete example of how to reach a particular goal.
  • Now is the time to express your opinions about how to use the technology. Not everything is Perl, but there’s still often more than one way to do it, and you should illustrate the one way you want developers to adopt. For example, if you believe no Kafka topic should ever exist without schema management, don’t publish any examples of unmanaged schemas. The AIs will repeat what they see you do.

In some cases, an MCP server or a custom skill may truly be critical to your getting-started process. If so, you’re going to have to provide developers with a solid Getting Started page on your web site. Make sure it’s easy to find and as simple as it can possibly be. It should contain a clear procedure for new users to install any relevant client-side software, connect to the MCP server, and install the necessary skills, followed by an example prompt to build a sample project.

BUILD

Even if developers have made minimal use of AI before the build stage, they will almost certainly be working with coding agents by the time they are truly building. There are several things you can do to give those agents, and the models behind them, the best chance for success:

  • If comprehensive documentation with complete code samples is helpful to human readers, it’s also essential to train AI models. Just like we saw in the play stage, you are now writing both for human understanding and for model ingestion. GEO (the new SEO) is again a priority.
  • You may find that the agents still need help writing code your way, which is where Agent Skills come in. Skills allow you to encode your internal knowledge and best practices in files you can easily distribute for your developers to install in their local coding agents, enabling the agents to generate code that is more correct, and often uses fewer tokens. Building effective skills can be a moderate product development investment in itself, but if your technology benefits from them, they are one of the best ways to support build-stage developers in the post-AI world.
  • If your technology has a cloud-based component (e.g., managed data infrastructure, a SaaS application with a significant API surface later), or requires a client-side application, your developers will likely benefit from an MCP server. MCP allows coding agents to access resources and call tools in a process outside of the agent itself. An MCP server can give the coding agent the ability to change schemas, perform CRUD operations on domain-specific entities, and initiate server-side processes that would normally be unavailable to it. This can give your building developers a much more fluent interface to your system through the prompting interface they have recently come to love.

ADVOCATE

AI makes minimal impact on the way you’ll execute the programs that support your community advocates. You’ll still sponsor them to speak for you; you’ll still run a robust MVP program to recognize your top contributors. AI doesn’t change any of that—what it does is make this phase vitally more important.

As you’ve seen in the four previous stages, you’re still on the hook to create a tremendous amount of content, but the reality is that content is cheap now. Your competitors can produce it at near-zero marginal cost. What now emerges as the most important differentiator for your program isn’t the mere presence of content, but trust.

In a world where anyone can prompt out credible-seeming blog posts and sample code, and increasingly even create instructional videos without a human subject setting foot in front of a camera, the trust between your community and the people who speak for your technology is paramount. Your team of professional developer advocates must build this trust themselves—they must always deliver technically credible, useful content that is free of hype—but even in the best case, they’ll always be susceptible to the criticism that they are merely speaking for the company, not truly advocating for the best technical solution. Your community members who have proceeded to the Advocate stage are free of this accusation. And as a bonus, there are more of them than you could possibly hire even in the most well-funded DevRel team. AI makes community advocates even more critical than they were before.

The mentors they need more than ever

The developers in your community are on a journey. It is, on the one hand, a journey to adopt and succeed with your technology. It’s also a journey for them to understand the shape their profession will take as it is being transformed by the advent of AI. Like Obi Wan, Gandalf, and Sgt. Powell, you are there to help them along their way. Your DevRel team must hold their success as their goal. It must provide scrupulously up-to-date AI tools to the community, without giving up any of the traditional tools of the trade. A DevRel team that earns trust and mentors developers through adoption, success, and growth is one that can help maintain your relevance and go-to-market success in a rapidly evolving world.