Developer Relations in the Era of AI

Developer relations is the practice of building and nurturing relationships with developers through community engagement, technical support, education, and advocacy, and it is the discipline that turns developer adoption into business value. AI has changed who that work serves. From here on, DevRel serves two audiences at once: the human developer evaluating your product, and the AI agent consuming your documentation to write code on their behalf, and that single change ripples through every surface, metric, and function DevRel owns.

What is developer relations?

The DevRel Foundation (Linux Foundation, 2025) offers the working definition: “Developer Relations (DevRel) is the practice of building and nurturing relationships with external and internal teams through community engagement, technical support, education, and advocacy to enable the successful adoption of an organization’s developer products and drive business value.”

The shorter version: DevRel is how a company with a developer product keeps the people who build on it moving forward. Bear Douglas, formerly of Slack Engineering, frames the role as “an interdisciplinary role that sits in a border space between product, engineering, and marketing.” That border space is the whole argument. DevRel is not a sub-function of marketing, and it is not a sub-function of engineering. It sits between them and pulls from both, and it translates between them when they stop talking to each other.

Seth Juarez, in the DevRel Handbook (2026), made the case that matters most at budget time: “Developer Relations is not a squishy collection of nice-to-have activities. It is a structured business function that creates content, refines technology, grows community, measures success, and organizes people around developer impact.”

The composition data agrees. Four pillars make up the practice, measured by team makeup: Developer Advocacy (82.2% of DevRel teams), Community Management (52.7%), Technical Writing (42.7%), and Developer Experience. Each of those is a real discipline with its own tooling and its own metrics, and they all sit under the same roof. I’ve worked in this space long enough to say the roof is the hard part, not the individual rooms. Advocacy runs the demos and the talks, community keeps the Discord alive and the forum answered, and technical writing owns the docs and the migration guides. Developer Experience owns the parts of the product that make developers feel smart, or the opposite. Get the mix wrong and you have a content machine with no community, or a community with nothing fresh to talk about.

Each pillar produces something measurable. Advocacy produces demos that get copied, talks that get replayed, and reference integrations that get forked. Community produces threads that get answered and relationships that survive staff changes. Technical writing produces docs that get cited and migration guides that get followed. Developer Experience produces a product surface that needs less support. When executives ask what DevRel does, these outputs are the answer in plain words.

Where that roof hangs varies a lot. 33.1% of DevRel teams report to Marketing, 21.7% to Product, 20.3% to the CEO, and 19.9% to Engineering. Forrester put a warning sign on that spread in May 2026: “Developer relations (DevRel) is a strategic capability for any organization whose growth depends on developers. Too many companies mistake it for marketing, but when they do, their products drift from developer needs, developer trust erodes, and buying influence quietly disappears.”

The reporting line matters because it decides what DevRel can influence. Under Marketing the incentive is campaign volume. Under Engineering the incentive is API quality and feedback loops. Under the CEO the incentive is ecosystem health and revenue influence. None of those choices is wrong, but each one shapes what the team prioritizes when the roadmap turns.

And that leads to the problem that has dogged the discipline for a decade. 60.7% of DevRel practitioners say proving impact with data is their number one challenge. Only 17.5% can link revenue influence directly to their metrics. 61% have no defined career path. These numbers moved slowly for years, and AI is the first thing with a real chance of moving them.

How does developer relations operate inside a company?

DevRel sits on a web of five relationships, and every one of them carries information in two directions.

DevRel and Engineering. DevRel hands Engineering developer-sourced bug reports, friction logs, usability issues, and integration patterns that never appear in internal testing. Engineering hands back roadmap context, technical accuracy review, and API stability commitments. Break this loop and DevRel writes about features that are about to change while Engineering builds on assumptions that do not match reality. The strongest versions of this relationship I have seen run a regular joint triage: engineering gets the raw developer complaints, DevRel gets the roadmap dates it is not supposed to leak.

DevRel and Product. The grassroots feedback, competitive intelligence, and usage pattern data flow from DevRel to Product. Feature announcements, use cases, and beta access flow back. The best DevRel teams sit in product planning meetings as the voice for the developer nobody in the room has talked to this quarter. That is not an honorary seat. Developers tell DevRel things they will never put in a bug report, usually because they are not sure whether what they hit is a bug or a misunderstanding.

DevRel and Marketing. DevRel provides the authentic developer voice, the technical credibility, and the event ROI data. Marketing provides budget, brand guidelines, and distribution. The tension is structural. Marketing is measured on volume, and DevRel is measured on depth, and the two do not reconcile themselves. A team that names that tension early spends less time arguing about it later. The healthy pattern is marketing owning the reach and DevRel owning the message, with both agreeing in writing on which is which.

DevRel and Sales. This is the most underused relationship in most companies. DevRel can hand sales developer-qualified leads, technical validation during evaluations, and churn risk signals from developers who are struggling. Sales can hand back customer pain points and revenue attribution. Rarely do the two pipelines meet, which is a waste on both sides. An integration story that someone at a mid-market company wrote about in their own words is worth more to sales than any spec sheet, and DevRel is where those stories are found.

DevRel and the executive team. DevRel provides ecosystem health metrics, market signals, and the link between developer engagement and revenue. The executive team provides strategic direction and budget authority. When DevRel cannot make that link, its future is decided at the next budget review. That is the loop the measurement problem keeps jamming, and it is the loop AI is finally starting to unblock.

The web only works when all five relationships stay live. I’ve seen DevRel teams that ran four of them well and silently dropped Sales, and the gap showed up as a revenue question at the next forecast. I have seen teams that never gave Engineering a seat and then wrote launch content for a breaking change nobody had warned them about. Every one of those dropouts, the missing Sales link or the missing Engineering seat, showed up as a support ticket or a forecast question three quarters later.

How is AI changing developer relations?

Chris Chabot, in the DevRel Almanac (2026), made the strongest claim on record: “The 2023-2026 wave of LLMs, AI coding agents, and agent-mediated discovery has changed what Developer Relations does, who its audience is, and how it is measured, more than any shift since the 2008 emergence of GitHub and Stack Overflow.”

That claim holds up. The mechanism is the dual audience. DevRel now serves two publics at once: AI agents (Cursor, Claude Code, Copilot, ChatGPT) that consume docs, schemas, and llms.txt files to produce code, and human developers who evaluate, adopt, and recommend products. The agent reads your docs before the human does. It decides, from those docs, whether your product is worth calling.

That does not make the human reader secondary. The human is still the one who approves the budget, signs the purchase order, and ships the integration. What changes is the order of operations: the agent does the first pass and the human does the second, and the second pass is where trust gets built or burned. A developer who was burned by a product that looked good in the agent summary will remember it. The human-facing work stays: demos, benchmarks, honest error messages, references a developer can check by hand.

AngelHack summarized the shift in September 2026 with three observations. Discovery moved to AI: developers start product research on ChatGPT, not Google. The LLM is the first-touch user of documentation, which means the first read of your getting-started guide is very often not a human read at all. And measurement expectations moved, because executives are no longer satisfied with blog views.

The survey numbers back this up. 51% of B2B software buyers start research with AI chatbots more often than Google (G2, 2026), and 69% of B2B buyers say they chose a different vendor because of AI chatbot guidance. 84% of developers use or plan to use AI tools. 65% of senior developers expect their role to be redefined by AI in 2026 (BairesDev). When that many buyers let a chatbot pick the shortlist, the thing the chatbot reads becomes your storefront.

There is a name for tuning content for this new reader, and it follows SEO by a decade. GEO, Generative Engine Optimization. It works too. The Princeton KDD 2024 study found a “Cite Sources” strategy lifted visibility by +115% in generative engine responses, and Reddit and Wikipedia remain ChatGPT’s two most-cited domains. Your product does not need to be Wikipedia, and it doesn’t need to be Reddit-sized either. It needs to be in the pool of sources a chatbot quotes when a developer asks “what SDK should I use for streaming audio,” and if you are not in that pool, you have no visibility where discovery now happens.

The surfaces are new as well. There is llms.txt, the machine-readable entry point for your docs. There are MCP servers, which turn an API into a service an agent can call directly. There are agent skills, which function as evolved demos, and there are .cursorrules and CLAUDE.md files sitting in repos that shape how coding agents behave. All of these are now part of the developer experience, which means all of them are DevRel’s problem.

What does AI do for DevRel today?

The gap between the hype and the tooling is real, but the tooling that exists is already proving itself function by function.

Documentation. This is where AI has landed hardest. 64% of software development professionals use AI for writing documentation (DORA 2025), and Stack Overflow’s 2025 survey puts it near 52% using AI at least partially for docs. Teams are using AI to draft reference material, auto-update docs from pull requests, and keep llms.txt and MCP server definitions in sync with the code. The docs treadmill, the one where every API change means five rewrites across five guides, is the best AI use case I have seen in production. It does not write the migration guide for you. It stops the reference doc from rotting in the week between the PR and the release.

The other half of the docs job is watching how agents read them. Log the questions agents actually ask your docs, the way you would log search terms on a website. Teams that do this find the same pattern every time: the agent drifts on setup steps and authentication, the two places where docs usually assume context a reader already has. That feedback loop is new, and it is the fastest route from unstructured docs to docs an agent can actually act on.

Community management. Vercel’s Community Guardian is the named example. Its AI agents triage community posts, detect duplicates at over 95% confidence, and revive ghosted threads, roughly 1 in 8 of them. In 23 days the tool produced 4,716 first responses. The human community manager still does the work machines cannot, but the triage layer is now automated. CMX’s 2026 data says 93.1% of community professionals use AI tools, up from 81% a year earlier. The remaining 6.9% are not a holdout, they are a workflow in transition.

Content creation. 42% of DevRel practitioners already use AI for content generation (State of DevRel 2024), and 21.8% do not use AI at all. That spread is the current market. The teams in the 42% use AI for drafting, repurposing talks into posts, and scaling technical content across channels. The teams in the 21.8% are about to be priced out on velocity alone. I still draft by hand when the piece is opinion, a post on writing technical content at speed but the pipeline work, the changelog summaries and the “what changed this release” notes, is exactly the job AI should do.

Developer experience. AI-powered support is the fastest-moving part of DX. Chatbots that answer from your docs, onboarding flows that generate a starter project from one sentence, error messages that explain themselves in plain language. These used to be engineering projects. Now they are configuration, and the question is which team owns them. Most companies have not answered that yet, and the teams that leave them unowned are shipping a worse first-run experience than the SDK alone deserves. what AI does to the developer experience

Metrics. This is the quiet revolution. AI-first DevRel teams report that 10-30%+ of new signups cite AI mediation as the path they took, which is a measurable surface that did not exist two years ago. The untapped part is enormous: Reo.Dev found 83.6% of accounts with developer activity are not in the CRM. The tooling to attribute agent-led discovery to accounts is maturing, and it is the first attribution story DevRel has ever had that an executive can read without a translator.

Two measurement layers are emerging. Surface metrics count the agent’s direct interactions: llms.txt fetches, MCP calls, agent-mediated signups. Cross-surface metrics compare the same developer across agent and human paths: did the account that started in a chatbot also attend a webinar, open a trial, or run a benchmark? The first layer shows whether agents can find you; the second shows whether what they found turns into adoption.

Events and outreach. The audience changed before the events did. Developer conferences still matter, but the people who will never attend one are reachable where their agents read. Sponsoring a conference talk is one thing. Being the vendor an MCP server recommends when the model weighs options is another, and the second costs a fraction of the first.

What does this mean for DevRel teams?

The measurement gap that has haunted DevRel for a decade starts closing now that agents leave traces. Every llms.txt fetch, every MCP call, every agent-mediated signup is a data point that ties developer-facing work to outcomes in a way blog views never could. Only 17.5% of teams currently link revenue influence to metrics. The teams that instrument the agent surfaces are the ones that will double that number, and the CFO will hear about it before the DevRel conference circuit does.

The new surfaces are the new portfolio. If you own llms.txt, MCP server definitions, and the agent-readable layer of your docs, you own discovery. If nobody on your team owns them, your product is invisible to the agents 69% of B2B buyers say steer their vendor choice. That is not a content strategy question anymore. It is an infrastructure question, and it needs an owner with a budget.

Owning the agent surface is an organizational question before it is a technical one. The budget for llms.txt and MCP servers is not going to fall out of the marketing line by itself. Some companies will bolt it onto DevRel, which is the natural home because DevRel already owns docs and community. Some will let engineering claim it, which produces technically clean but commercially silent interfaces. How fast a company sorts that out depends on whether agent-readable output is treated as a product surface with a roadmap or as a side project.

The risk of not adapting is concrete. The two audiences are diverging: humans increasingly ask agents to do the work, and agents trust whatever documentation they can parse cleanly. A team that targets only the human reader is doing half the job and will eventually be measured on the half it ignored. The 61% of DevRel teams with no defined career path have a second problem now: the career paths that are emerging point at agent surfaces, and the people who can speak both languages are rare.

The alternative future is easy to sketch. Your docs are still written for a reader who evaluated a vendor in 2023, your llms.txt returns a 404, and the agent that 69% of buyers consult recommends your competitor. The competitor did not out-market you. It wrote docs an agent could parse, shipped an MCP server, and let the citations land.

This means DevRel hiring changes first. The profile shifts from “can give a talk and write a guide” to “can structure information so an agent and a human both trust it.” It means the function finally has a measurement story. And it means the discipline stops being judged on impressions and starts being judged on whether the agents that steer buying decisions recommend the thing you build. a post on how DevRel teams prove impact

Frequently asked questions

What is DevRel, and why does AI change it?

DevRel builds and nurtures relationships with developers through community, support, education, and advocacy to drive adoption. AI changes it because agents now consume documentation before humans do. Discovery, first-touch reading, and even purchase influence have moved into LLMs, so DevRel must serve both audiences or lose half its reach.

What are the four pillars of DevRel?

Developer Advocacy, Community Management, Technical Writing, and Developer Experience. Advocacy appears in 82.2% of DevRel teams, Community Management in 52.7%, and Technical Writing in 42.7%. The pillars share tooling and reporting, and most teams blend them rather than staff them as separate roles.

How do AI agents affect documentation?

Agents read docs as their first touch with a product. llms.txt gives them a structured entry point, and MCP servers let them call the API directly. Docs that parse cleanly get cited by coding agents, and docs that do not get ignored. That is why AI-assisted and AI-kept-current docs are the fastest-growing DevRel function.

Does AI replace community managers?

No, it replaces the triage layer. Tools like Vercel’s Community Guardian detect duplicates, route questions, and revive stale threads while humans handle the judgment calls. CMX finds 93.1% of community professionals use AI tools, and the ones who do not are spending their time on work the machine now does.

How do DevRel teams measure AI-era success?

They measure the agent surface. Signups citing AI mediation, llms.txt fetch rates, MCP call volume, and vendor selections driven by chatbot guidance. Some AI-first teams already see 10-30%+ of new signups arrive through AI mediation, and that number is becoming the new proof of impact.

The teams that treat agents as first-class DevRel customers will define what this discipline is worth, and the teams that do not will find out from their quarterly numbers.