Stephanie Jarmak of Sourcegraph argues that developer relations is not dead but its audience has changed: AI agents now read documentation, call APIs, and recommend tools. She shares an experiment showing assistants mention Sourcegraph 65% of the time for generic tool comparisons but 0% when real pain points are described, and presents a benchmark of hundreds of lifecycle tasks run with and without Sourcegraph's code navigation tool, including trace analysis of agent failures such as a wasted turn caused by an unclear tool description. The talk also covers generative engine optimization, listing tools in MCP registries, keeping content fresh, reducing friction to adoption, and a "curb cut" analogy — building for agents clears the path for everyone. Includes a personal note on Jarmak's transition from astronomer to "agent advocate." # Channel Identity Observations: "The Death of Developer Advocates — Stephanie Jarmak, Sourcegraph" ## Explicit Self-Description - **Speaker role & employer**: The speaker identifies herself as a **research scientist** at **Sourcegraph** ("I'm a research scientist. So last year I was an astronomer"), presenting under the emerging role of **"agent advocate."** - **Employer's product context stated**: She says, "I work at Sourcegraph and we have a code navigation MCP tool," and references an older product ("it kept pitching Cody, which was like one of our older products"). - **Talk origin**: She describes the title as pitched by her manager, a developer advocate: "my manager, who is a developer advocate, he put in... the death of developer advocates, which is, you know, appropriately buzzworthy and hypey." - **Format**: A **conference talk** ("we made it to the end of this track... Thank you everybody for sticking it out this long"), delivered live to an in-person audience at the close of a multi-speaker track. ## Intended Audience - **Developer relations professionals and developer advocates**, addressed directly: "are there any developer advocates or devrel people in the audience? Raise your hand." - **Practitioners on GTM/DevRel strategy sides**, evidenced by the closing call to action: "if you're more on the GTM side, start like developing some of these experiments with the GEO." - Attendees of a technical conference covering **agents, MCP, and AI-era workflows**, implied by cross-references to prior talks ("as we had heard like in some of the previous talks"). ## Claimed Scope of the Channel/Content - **DevRel history and evolution**: From "software evangelism" in the '80s through 2010s developer advocacy to a proposed 2026 "agent advocacy" model. - **AI agents as a new user class**: "an agent is somewhat unique, right? In the sense that it is both the user of your tool... But then it's also a recommender of your tools." - **Measurement and evaluation methods**: Concrete projects presented — **CodeScaleBench** ("I developed hundreds of tasks that were reflective of the software development life cycle") and a **GEO pilot study** testing how chatbots recommend products. - **Hands-on enablement**: Templates and repos offered to the audience ("a couple different toy repos that have some templates for you to get started" via QR code). ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Data-driven, first-person case studies** from her own work at Sourcegraph (thousands of agent traces, read-tool failure example, GEO experiment results). - **Self-deprecating, humorous tone**: jokes about "throw tomatoes," a discarded robot-attack stage bit, and "Claude's slop." - **Credibility markers through background**: emphasizes her scientist-to-engineer trajectory ("I had like zero commits on GitHub last year, and now I have 12,000"). - **Actionable, prescriptive advice** ("point a coding agent at your docs... start developing your agent experience report"). - **Provocative framing with a conciliatory conclusion**: "I know I said the death of developer advocates. But the core right of DevRel still holds." ## Summary Identity Signal This video demonstrates a channel/event presence focused on **forward-looking DevRel and AI-agent strategy content for developer-relations and go-to-market practitioners**, delivered by a named industry practitioner (Sourcegraph) using **original research, benchmarks, and experiments** as evidence — with the talk being an end-of-track conference keynote-style session rather than standalone educational content. # Delivery Observations: Stephanie Jarmak — "The Death of Developer Advocates" ## Overall Tone - **Conversational and self-deprecating humor**: opens with jokes about the audience and the talk title — *"...did you come to like throw tomatoes at me cuz I'm talking about the dead now"* - **Casual, filler-heavy speech style**: heavy use of "like," "um," "you know," "right?" — e.g., *"It's like yeah, yes, yes. It's all of those things."* - **Playful framing devices**: describes an abandoned bit — *"maybe I would dress up as like a robot and like a maul him and attack him on the stage"* — establishing an informal, comedic register early. ## Vocabulary & Jargon Use - Dense industry vocabulary delivered without much scaffolding: **GTM, ICP, DevRel, GEO, MCP, evals, pipe gen** — e.g., *"I didn't know what GTM was or any of that."* - Coinages/phrase-building: **"agent advocate," "go to agent market,"** *"it's the uh GEO instead of SEO"* — explicitly teaching new terms by contrast. - Metaphors drawn from analogies: **"kingsmakers," "curb cut,"** *"babysitters and whatnot of these things."* ## Recurring Linguistic Habits (stable patterns) - **Rhetorical "right?" as a connective tag** — appears constantly: *"Um and then these developers, right?"*, *"So that we can then go in and actually fix that... And this is really important, right"* - **"Sort of / kind of" hedging** throughout: *"just sort of talk about what what this thing is"*, *"I'm just kind of talking about the other users, right?"* - **"Like" as a universal filler/quotative**, even inside technical explanation: *"if the agent realizes your tool requires like three different demos"* - **"You know" as a pacing marker**: *"But his title is developer advocate, so it didn't really necessarily make as much sense"*, *"you know, there's a bias, right"* ## Teaching Habits - **Historical framing before argument**: grounds the topic in a timeline — *"back in the '80s, right? It was called like software evangelism"* → 2010s → "now in 2026." - **Concrete data/examples over abstractions**: describes her **CodeScaleBench** benchmark and a specific failure case (*"it tried to use like read line instead of start line"*), plus a GEO experiment with numbers (*"recommended like 65% of the time"* vs. *"zero mentions"*). - **Quoting hypothetical dialogue**: *"It's like, 'Hey user, like here's what you should do, but FYI, you're going to have to do all this other stuff.'"* - **Actionable closing checklist**: rapid-fire "you want to / make sure" imperatives near the end — *"give the agent something to quote," "go to agent market," "reduce as much friction as possible."* - **Audience-interaction opener**: hand-raising question — *"are there any developer advocates or devrel people in the audience?"* - **Logistics reassurance**: *"there's like a QR code with a link... don't worry about like taking screenshots."* ## Structure & Communication Patterns - **Signposting transitions**: *"zooming out a little bit," "So let's talk about now this whole new user," "the other side of it."* - **Subversion-reversal rhetorical move**: provocative title, then explicit softening — *"I know it's late for numbers"* and *"I know I you know said the death of developer advocates. But the core right of DevRel still holds."* - **Taxonomy breakdown as an organizing device**: splits agent advocacy into *"the engineering flavor... the product flavor... the marketing flavor."* - **Self-identified persona**: *"I am a data science scientist nerd person"* — leaning on her research-scientist background as credibility for the measurement-heavy sections. ## Isolated Moments (insufficient repetition) - The exact-figures experiment (65% vs. zero mentions) is a single instance; whether number-heavy evidence is a stable habit can't be confirmed from one talk. - The "curb cut" metaphor appears once — an effective single-use analogy, not an established pattern. # Position Record: "The Death of Developer Advocates" — Stephanie Jarmak, Sourcegraph ## Speaker & Framing - **Stephanie Jarmak** (self-identified research scientist; former astronomer; now "agent advocate" at Sourcegraph) delivered the talk. The title was proposed by her manager, a developer advocate; she jokes the title is "appropriately buzzworthy and hypey" and clarifies the talk is **not doom and gloom**. - **Core thesis**: The developer advocate role is not dying but must change because the audience — developers — is fundamentally changing, and a new user (the **agent**) has entered the room. ## Historical Narrative of DevRel - **1980s**: "Software evangelism" — one-way communication spreading the product's word. - **2010s**: Developer advocacy emerged as a **two-way feedback loop** with deep developer empathy feeding back to product. - Since then, developers gained internal influence ("kingsmakers") and developer experience became central to go-to-market. - **2026 (her framing)**: Developers no longer work alone; "what it means to be a developer is completely changing," so the advocate role must change too. ## Other Changing Personas (Beyond the Agent) - Engineers are becoming **orchestrators/babysitters of agent fleets**; job postings increasingly demand **AI fluency**. - **Non-engineers** can now use dev tools via agents — she cites herself: zero GitHub commits a year ago, now 12,000 and an open-source maintainer of a multi-agent orchestration framework. This creates a new persona/ICP for DevRel. ## The Agent as User and Recommender - Agents are **both users and recommenders** of tools, analogous to developers but machine-mediated: reading docs differently, calling APIs, hitting and recovering from errors. - Bottom-up adoption — the basis of DevRel — is now partly **driven by agents themselves** (via Q&A in ChatGPT/Claude, or installing libraries directly, as a previous talk's audience poll showed). ## Concrete Measurements (Her Own Work) ### CodeScaleBench - She built a benchmark of hundreds of software-development-lifecycle tasks, running agents **with and without** Sourcegraph's code navigation MCP tool, generating thousands of traces for tight feedback loops. - **Example finding**: A model used `read line` instead of `start line` due to training-data bias; the tool description didn't disambiguate. The agent self-corrected via the error, but **burned an entire turn failing** — fixable in the tool's interaction design. - **Claim**: Organizations will evaluate tools not just by correctness but by **token cost and speed** for agents. ### GEO (Generative Engine Optimization) Pilot - Comparative-shopping prompts surfaced the product ~**65%** of the time. - A pain-point prompt ("we keep breaking downstream services… can't see all the consumers") got **zero mentions** — the agent suggested "make a wiki page." - **Inference (hers)**: messaging doesn't attribute pains/use cases clearly enough; a content campaign is underway to test measurable lift via how agents interpret web-search tool calls. - **Staleness/staleness-compounding**: rerunning with Claude Sonnet 4.6 (same day as the talk) produced *more* pitching of Cody (an older product) than Sonnet 4 did, because old model output compounds on the internet — one must "bury the noise with true signal." ## Prescriptions for Agent Advocacy - Authoritative sources (e.g., **LLMs.txt**), plus real-time tool use and provenance. - Give agents something to **quote**: current examples, updated content, charts, FAQs — even for unchanged products (relevance algorithms favor freshness). - Be present where agents are: **MCP registries, marketplaces**. - **Minimize friction**: agents won't recommend tools requiring multiple demos or emailing sales. - Cover pain-point content so agents can connect users at their moment of need. ## Where Agent Advocacy Sits - To "is it engineering, product, or marketing?" — **"yeah, yes, yes"**; roles have gotten fuzzier, which she says helps. Flavors: - **Engineering**: MCP interfaces, evals, instrumentation. - **Product**: end-to-end agentic experience, translating evals, experience rubrics. - **Marketing**: pipeline generation, how agents enter the funnel and surface recommendations. ## What Still Holds in DevRel (Change of Audience, Not Core) - **Enablement**: educate orchestrator-developers and produce machine-readable, agent-friendly content. - **Community**: human-to-human connection matters more than ever; new concerns arise (e.g., privacy if users' Claude instances record Discord conversations). - **Feedback loop**: voice of the developer still matters; plus one can run experiments on thousands of agents that developers wouldn't tolerate. - **Credibility**: humans dislike "Claude slop" (she says tell AEs to stop sending it); agents, however, "love their own slop" — a **different credibility landscape** with structured, agent-facing content. ## Closing Argument: The Curb Cut - Curb cuts were built for wheelchairs but benefit everyone; she argues **serving agents clears the human path too** — "one more user in the room," still ultimately serving the human. - **Immediate actions**: point a coding agent at your docs and build an agent experience report; on GTM, run GEO experiments tracking mentions vs. recommendations. She says talk materials, QR code, and toy repos with templates are available (all data "will be released"). ## Qualifications & Tensions Preserved - She explicitly walks back the title's premise: the core of DevRel still holds; only the audience changes. - Her GEO finding is a single small pilot; the 4.6 rerun contradicted her expectation of improvement ("surely it's going to be better" — it got worse). - The role-boundary question ("where does it fit?") is left unresolved rather than settled. # Speaker & Role Attribution Record ## Video - **Title:** The Death of Developer Advocates — Stephanie Jarmak, Sourcegraph - **Video ID:** 01a15ca7-c09e-7c71-8f6a-228d00013d98 ## Identified Speakers | Speaker | Role | Notes | |---|---|---| | Stephanie Jarmak | **Primary/sole speaker** — research scientist at Sourcegraph, self-described "agent advocate" | Former astronomer; presents the full talk | ### Referenced (non-speaking) persons - **Her manager** — identified as a **developer advocate** at Sourcegraph; credited with submitting the talk title "the death of developer advocates"; was "on vacation" rather than presenting. No name given. - **Unnamed prior/previous speakers at the same conference** — referenced twice (agent library installation question; LLMs.TXT pages); no names given. ## Audience - Live conference audience, end-of-track session. Speaker asks for show of hands from developer advocates / DevRel people; interactive moments noted. ## Provenance Facts & Referenced Sources - **Employer / product affiliation:** Speaker works at **Sourcegraph**; references Sourcegraph's **code navigation MCP tool** and **Cody** (an "older product"). - **Benchmarks / projects (speaker's own work):** - **CodeScaleBench** — benchmark with "hundreds of tasks" reflective of the software development life cycle; agents run with and without Sourcegraph tooling. - **GEO (Generative Engine Optimization) pilot study** — experiment testing how chatbots/agents recommend/mention the Sourcegraph product; states it used **Claude Sonnet 4** ("very old") and was re-run with **4.6** "today, this afternoon." - **Two toy projects / GitHub repos** — templates referenced; access via a **QR code at the end of the talk**; "all of the data will be released to you." - **Third-party products/tools mentioned:** ChatGPT, Claude, GitHub (open-source maintainer status), MCP registries/marketplaces, Discord (community/privacy discussion), LLMs.TXT-style pages (attributed to "other people"). - **Claims about third parties:** None verifiable; all statistics (e.g., "65% of the time," "zero mentions," "12,000 commits") are speaker-reported and unverified. ## Promotional Segments - **Flagged:** Substantial portions promote the speaker's employer's product and role: - Sourcegraph code navigation MCP tool and its benefits for agents. - Product observability layer ("see across all the repos") as solution to the cited pain prompt. - "We have a content campaign in the works to make changes to our website" — explicitly promotional/marketing intent. - Cody references (noting agents "pitch Cody" in GEO tests). ## Comment Availability - **Not specified** in the source material. ## Uncertainty Notes - Speaker's manager is unnamed; role (developer advocate) is speaker-asserted. - No transcript timestamps available. - Referenced prior talks and speakers at the conference are not identified. \>\> Hi everyone. Sorry for the start with technical difficulties and all of that. Uh, we made it to the end of this track. Super exciting. Thank you everybody for sticking it out this long. Um, are there any developer advocates or devrel people in the audience? Raise your hand. Yeah, okay. So did you come to like throw tomatoes at me cuz I'm talking about the dead now. Okay, so it's not going to be all doom and gloom like that. Um, a bit of like backstory in this. Um, I'm a research scientist. So last year I was an astronomer. Um, and I just sort of like wound up. I didn't know what GTM was or any of that. I just sort of wound up in this. Um, and I submitted like a bunch of boring sciency eval talks that were unceremoniously I I assumed thrown into the trash uh, for this conference. But my manager, who is a developer advocate, he put in, you know, the death the death of developer advocates, which is, you know, appropriately buzzworthy and hypey. And so so that was great. But his title is developer advocate, so it didn't really necessarily make as much sense for him to be coming up here and giving his eulogy. So we brainstormed like maybe I would dress up as like a robot and like a maul him and attack him on the stage or something like that. Um, but then it just like logistically it was going to be hard to do that. Uh, so he just went on vacation. Uh, so I'm here uh, as the agent advocate uh, to talk about this sort of like new role and uh, try to advocate for it and uh, convince all of you that we should all be agent advocates to help uh, in this new era. So uh, zooming out a little bit and going back uh, in time a bit because uh, I was trying to talk about developer advocates to somebody at the conference yesterday and their eyes like glazed over they had no idea what I was talking about. So just to sort of talk about what what this thing is that I'm saying is dead. Uh so back in the '80s, right? It was called like software evangelism where one would go forth and speak the good word of the product and bring it out there. But then fast forward to the 2010s or so, that's when developer advocacy advocacy started to become a thing where now instead of having this single trajectory of the communication pathway, now it's a feedback loop and a two-way street where you have these people with very deep empathy for developers who understand them and speak their language and could understand um what their needs were um and then bring that back to the product. And then um these developers, right? Fast forward even more, they have so much influence within their company and basically become these like kingsmakers. Uh and so the developer experience became a very important aspect of the go-to-market sort of strategy. Um but now in 2026, uh developers are no longer working alone and what it means to be a developer is completely changing. Um and so our role, right, as developer advocates um developer in developer relations, we're relating to developers. And so as the role of developers fundamentally changing, so must then does the role of the developer advocate. Um so in this slide I'm just kind of talking about the other users, right? So what's happening uh with DevRel uh outside of the agent. So most of the talk is going to be talking about the agent as a user. But I also did did want to bring up, right, that engineers they're becoming like these orchestrators of these fleets of agents, um babysitters and whatnot of these things. Um and their job, like all of the job postings and whatnot, there's language is continuously changing, right? They're um expected to have this AI fluency. Um and at the same time, there's also, you know, people like me, like uh non-engineers, right? I was a research scientist. I had like zero commits on GitHub last year, and now I have 12,000, and I'm like an open source maintainer for multi-agent orchestration framework. Like, we have so much like capability now with all of these agents, and now anybody with these agents can use dev tools, essentially. So, you have this whole other persona and ICP uh to potentially be relating to and um having empathy with when you're there using your product. So, let's talk about now this whole new user that we have in the form of an agent. Um so, an agent is somewhat unique, right? In the sense that it is both the user of your tool in a very similar way to the developer. It's going out reading your docs, but it's just reading them differently cuz it's a machine. Um you know, it's calling the API. It's encount- it's ha- has its own frustrations with how it's encountering errors and recovering from them, right? But then it's also a recommender of your tools. Um but somewhat similar, right? To developers in the way that they are also recommenders of your tools in a more organic, bottom-up way. Um so, the whole, you know, basis for DevRel, right? Is to encourage that bottom-up adoption. But now the adoption and the recommendation system, a lot of it's being driven by the agent itself. That is either, you know, maybe servicing your product directly through like ChatGPT or Claude, like directly in a Q&A sort of environment, or it's, as we had heard like in some of the previous talks where the speaker asked folks like, "How many of you have just let your agent install a library for you?" And like, there were many hands went up, right? So, there's this like recommender of tools where basically it's just installing these like frameworks and things um directly and embedding them into the workflow um and sort of working with the developer um in that taste. So, I know it's late for numbers. You don't have to read them or anything like that. Um so, I have a couple different concrete examples for measuring these seats, right? Cuz I am a data science scientist nerd person. Um so one of my first projects when I was uh working on this um uh when I became an agent advocate was to build um a benchmark called CodeScaleBench. And so I developed hundreds of tasks that were reflective of the software development life cycle. And I basically unleashed these agents with and without um our product tooling. So I work at Sourcegraph and we have a code navigation MCP tool. Um and the point of that was to understand, okay, how is our tool helping the agent do the work that it's, you know, going to be doing. Um and when it isn't working well, why isn't it working well? So that we can then go in and actually fix that. Um so I have thousands and thousands of these traces. And I I as we have heard in like the previous talks, like now we have these amazing logs of data for like these really tight feedback loops where you can see exactly where it's breaking down and then go in and fix it. Uh so this one specific example here was um when I was looking at how it was like using a read tool. Um and the model had the these expectations based off of its like biases from how it from its training data of what it expected for a particular um command um that would be available within the tool. And there's nothing in our description uh that would have like led it to believe otherwise. So it tried to use like read line instead of start line or something like that. And then it ended up failing, but then at least the error told it why it failed. So it was like, okay, that that was a good part of it. So it was able to fix itself. But then it's burning right an entire turn just failing. And you could just go in and fix that um aspect of like how it's interacting with the tool. And this is really important, right, to gather that feedback um and understand the friction that like now your new agent user is having with your tool because it's the way that um different organizations are going to be evaluating your tool, right? In terms of not just is it working well, but like how many tokens is the agent dealing with to work with your tool? And how fast is it? Um so this is, you know, really an important aspect of the role is measure um, how these users are using it. The other side of it um, is like the recommendation layer, right? So, the uh, GEO instead of SEO. So, the generative engine optimization. Um, and I didn't mention it before, but in the previous slide um, I had a GitHub repo. Like, there's two different toy projects that I put together. At the end of the talk, there's like a QR code with a link that you can send your agent to to like have access to all this. So, don't worry about like taking screenshots All of all of the data will be released to you. Um, so anyway, back to this. Um, I set up a little experiment, right? To see how uh, these different chatbots and agents and whatnot were recommending our product or like mentioning it at all. Um, and so there's a, you know, process to that cuz you have you want to understand like, what is your ICP actually doing when you would want your product to be surfaced? So, there was a bit of a gap that I found. Um, if I had designed some of these prompts around somebody who like was actively shopping for this sort of code intelligence sort of tooling and doing a comparative sort of thing, then our product was ending up being recommended like 65% of the time. Um, but what I found was the arguably like the more typical use case and where we'd want to be showing up for people when they're encountering a specific pain or have a specific need where our product could serve them better, uh, zero mentions, right? So, in this particular instance, um, I put in a prompt that was like, we keep breaking downstream services when we change shared libraries because we can't see all the consumers. And you know, our one uh, part of our product is being able to have this observability layer to like see across all the repos. So, we'd want uh, some level of like attribution or recognition from um, an agent to say, "Hey, you could use something like this." But instead it said, uh, "You could just have your developers make a wiki page or something. Um but with this, you know, we wouldn't know that without running these sorts of experiments um and getting this sort of data. So, what this leads to is like then you can have a hypothesis of okay, maybe the messaging that we're putting out there isn't uh attributing some of these pains and use cases clearly enough for the agents to be picking it up. So, we have uh like a content campaign in the works to um make changes to our website and then we can directly measure whether that has like an actual lift and not necessarily in the form of like anything that was baked into the training data, but then how uh the agents that are using those like web search tool calls, how they are then interpreting um the information about your product. So, you know, there are just some um different ways that you could think about guiding the agents um to help support like the servicing, the discoverability of your product and this user finding it um at their moment of need, right? Um so, for example, um this whole field is moving so fast. Uh so, I mean, training data is always going to be stale. Actually, in the um GEO pilot study that I did, the data that I was showing there, that was using Claude Sonnet 4. It's very old um obviously and I just today, this afternoon, ran it with 4.6 thinking that okay, surely it's going to it's going to be better. It's going to know like improved information about our product, but uh so, in the previous model, it kept pitching Cody, which was like one of our older products. Um but if I when I uh ran it again, it it pitched Cody even more, right? Cuz like now you have all of these like old models like uh outputting content that then is like compounding in the internet. So, you have to figure out like how to bury all of that uh noise with your true signal. Um and the way that some folks are working on that is as we've heard from other people like these LLMs at TXT uh sort of pages, right? So, you have more authoritative sources of truth that you're hoping to direct the agent to. But, they still need to be using the tools and using real-time information and provenance to be able to give accurate answers about your product. You also want to give like the agent something to quote, right? They they they want to bring something that they can really sell to the to the user, right? So, you want current examples and keep everything up-to-date. Like, even if your stuff hasn't changed in 2 years, which would be shocking. Even if it hasn't, like keep everything up-to-date and fresh because that, you know, part of that is how they have their relevance algorithm. And they also really really like charts and FAQs and things like that. And you also want to make sure your product is where the agents are, right? You're going to market. So, go go to agent market, right? So, make sure you're in the marketplace in the MCP registries, everywhere that you would expect an agent to be able to easily find you. And also make sure that you know, that whole you reduce as much friction as possible for an agent or and developer to go from finding out about your tool to embedding it in their workflow. Because if an agent realizes your tool requires like three different demos and emailing sales reps and stuff, they're never going to say, "Hey user, like here's what you should do, but FYI, you're going to have to do all this other stuff." It's like not going to happen. And then also make sure that you are covering that those pains, right? Because that's how a user is going to be most like in their time of need, right? That's going to be the best opportunity for your product and your service, right, to be surfaced to them. And so, you want to make sure that there's enough content out there on the internet for the agent to like be aware of that and make those connections for you. And so, right, there's this like ongoing question of what even the heck is DevRel and advocacy and now now this agent advocacy thing, right? So like where does it fit? Where does it go? Like is it engineering? Is it product? Is it marketing? It's like yeah, yes, yes. It's all of those things. And and with the rise of agents it hasn't gotten any clearer, right? Those seams haven't gotten any clearer. If anything though, everybody's role with across the organization has gotten fuzzier. So that actually helps in a lot of ways. Um and but you can sort of split it up and think about it in terms of like these different flavors, right? And you can mix and match depending on whatever skills and abilities various employees have within your organization and whatever the product needs at a given time. So you have like the engineering flavor, right? And those are folks that are partnering directly with the engineering team to make these interfaces for how the agent is talking to your product like through the MCP server and building out these evals and the instrumentation. Then you have the product flavor. So those are folks that are going to own the end-to-end agentic experience, right? And so translating these evals to bring it to the product team and like having the agent experience rubrics how they're encountering all of that content. And then you have the marketing flavor, right? And that should be the folks that are really owning that pipe gen and how the agents are like entering the funnel and finding out about your product and then bringing the developers along with them by surfacing those recommendations. So I know I you know said the death of developer advocates. But the core right of DevRel still holds. It's just you have a change in your audience. So it's still extremely important to do enablement, right? It's just the type of enablement is a bit different. You're educating developers now who are have a completely different type of job where they're orchestrating these fleets of agents. And you're also educating agents, right? So you're having to put out content that is machine readable, has like agent friendly APIs, all of these things to make it as easy as possible to use your product both for human developers and for the agents that they're using. And community is also more important than ever, right? Um having that human-to-human connection um where developers can come um and uh bring their agents also into the loop, right? So that's another component um that needs to be considered uh when you're building these different communities because there's all these questions, right, of privacy and like data concern as well. If people are like bringing their Claude's and whatnot like into the Discord and they're like uh recording all of the conversations and everything like this. It's just like a new thing they have to think of as a community builder. And then there's the feedback loop, so you're still uh responsible for bringing the voice of the developer who's using the agents back to the organization, but then you can also uh basically spin up like thousands of these agents to perform experiments on them and experiments that you can't really like do as easily with the developers who don't want to maybe talk to you that much. Um and then credibility, right? So you need to be earning credibility both from human developers. Um so like don't like not using Claude's slop at them, right? Then tell your AEs to stop that as well. Nobody Everybody knows what it is and nobody likes it. Um and but then credibility like actually Claude loves its own slop uh for whatever reason. So there's a bias, right, from agents of their own content. So whenever you're making like agent-facing content, as long as it's structured, you can have as many m dashes and whatever as as it wants. Um but it's just a completely different sort of uh credibility landscape, humans versus agents. So what I'm advocating for here, right, is like building out a curb cut. So curb cuts were built for wheelchairs, like built for a specific user to use them. Um but now everybody, you know, benefits from that, right? Anybody with wheels, right, strollers and um suitcases and all of those things. So my argument is that by serving the uh agents, uh the human path gets cleared, too. There's just, you know, there's just one more user in the room now, but they are still serving the human on the other end, and we're all working together on this. So, for, you know, DevRel, one quick thing that you could do like right away is point a coding agent at your docs, and then looking through that transcript and start developing your agent experience report. And then if you're more on the GTM side, start like developing some of these experiments with the GEO, putting together those prompts, and looking at the mentions versus recommendations. And I made this whole talk agent legible, right? So, there's a QR code there, as well as a couple different toy repos that have some templates for you to get started. And that's it. \>\> \[music\]