Seven arguments recur in discussions of AI-era DevRel. Each catches a real problem, but several overstate what follows from it. This page separates the evidence from the larger claim.
Critical take 1: “DevRel is dead because AI can do it”
Strong-form version: AI can generate documentation, answer community questions, produce tutorial content, and explain products to developers. So why pay for DevRel?
Where this take is right
- A substantial fraction of pre-2023 DevRel work was producing tutorial-style content, FAQ answers, and “X for beginners” posts. AI assistants now generate this kind of content competently. Teams that built their value around this work are in genuine trouble.
- First-line community support for “How do I X?” questions is increasingly handled by AI before reaching humans. Community managers whose value was answering basic questions need to redefine their role.
- Anyone whose DevRel work is volume-of-content-produced is competing directly with AI’s near-zero marginal cost.
Where this take is wrong
- A community manager who shows up reliably for years earns trust through conduct and memory.
- A founder who writes thoughtfully across a decade builds a reputation attached to their decisions.
- Human judgement determines which controversial position to take, which engineering trade-off to discuss honestly, and which design pattern to recommend.
- Conflict resolution, code-of-conduct enforcement, and support for emerging contributors require accountable human judgement.
- Representing developers inside a company requires technical credibility and enough internal access to change decisions.
AI can take on some production work. DevRel teams still need people who earn community trust, make editorial decisions, resolve conflict, and carry developer evidence into the company. A team measured only by the volume of material it publishes has a weak case for its budget.
Critical take 2: “Most AI-era DevRel advice is unvalidated”
This critique concerns the evidence behind current advice:
llms.txtis widely adopted but two 2026 studies found no measurable AI-citation lift correlated with publishing it. Server logs from real production sites report essentially zero AI bot fetches ofllms.txtfiles.- The 2024 to 2026 GEO/AEO tooling category (Profound, AthenaHQ, Otterly.AI, etc.) reports wildly different numbers using different methodologies. Their absolute claims should be treated cautiously.
- Single-anecdote “we tripled our AI citations by doing X” posts are almost always unreproducible and often retroactive.
- Sentiment about AI tools systematically overstates measured productivity (Faros AI, JetBrains HAX, Anthropic skill-formation research).
Where this take is right
- Much of the 2024 to 2026 AI-DevRel advice is performative. People are doing things that look like AI optimisation without evidence they actually work.
- Tooling in this category is young and immature. The measurements are noisy.
- DevRel teams that bet heavily on
llms.txtas their primary AI strategy are likely overinvesting.
Where this take is wrong
llms.txtis cheap to produce, and the work can improve documentation hygiene even when its effect on AI citations remains unvalidated.- Absence of measurable effect in 2026 may just mean the measurement methods are bad. Several decades of SEO research had this same problem.
- Some AI-era practices do show measurable effects (clean OpenAPI specs, runnable code samples, schema markup, consistent canonical naming, dated content). The critique applies more strongly to specific tools and conventions than to the broad direction.
The evidence supports caution. Developers do research through AI assistants, but the effect of particular optimisation tactics remains uncertain. Teams should instrument the tactics they can measure and label the rest as experiments.
Critical take 3: “Developer-experience surveys are no longer reliable”
A specific empirical critique from operational engineering teams.
Argument:
- Developer-sentiment surveys are widely used to assess AI-tool effectiveness.
- Telemetry consistently shows that the sentiment overstates the reality. Code churn rises, edit frequency rises, errors rise, but developers report feeling more productive.
- Several research efforts (Faros AI, JetBrains HAX study with 800 developers across two years, Anthropic skill-formation research) all confirm this gap.
Where this take is right
- Surveys are insufficient on their own.
- DevRel teams that rely on “we asked developers and 80% love it” are probably overstating their impact.
- The post-launch NPS that gets reported up to executives is often misleading.
Where this take is wrong
- Surveys need telemetry and behavioural data alongside them. Each method catches evidence the others miss.
- Developer perception remains useful because felt productivity affects retention, advocacy, and product loyalty. It should be read alongside behavioural data.
Use surveys and telemetry together, and state what each measure can support.
Critical take 4: “AI-generated DevRel content fails”
A point most working practitioners agree with but worth stating explicitly.
Argument:
- DevRel teams have experimented with using LLMs to scale content production. Most attempts have failed.
- AI-generated technical content is detectable, anodyne, and often subtly wrong.
- Developer audiences are sophisticated and notice. Engagement collapses.
- Trying to scale DevRel through AI-generated content has been a consistent failure mode in 2024 to 2026.
Where this take is right
- Empirically true. Most pure-AI-generated content marketing produces worse outcomes than less-of-it-but-real-voice content.
- The temptation to use AI to “scale” DevRel work is widespread and usually wrong.
Where this take is wrong
- AI can help with drafting, editing, and signal detection. The public surface still needs an accountable human author.
Practical response: use AI for drafting, editing, and signal detection while keeping an accountable human author on the public surface.
Critical take 5: “DevRel is being absorbed into other functions, not surviving as its own thing”
A structural critique. Some patterns:
- Many companies are merging DevRel into Product Marketing, Developer Experience Engineering, or Customer Engineering.
- Job titles like “Developer Advocate” are sometimes being replaced with “DX Engineer” or “Developer Experience Engineer” reporting through Product.
- Pure DevRel functions have been contracting; adjacent functions have absorbed parts of the responsibility.
Where this take is right
- At some companies, especially later-stage developer-product companies, DevRel-as-such is being unbundled into specialist roles: DX Engineer, Documentation Engineer, Community Manager, and similar positions reporting through different leaders.
- The dual-audience thesis (see
./the-dual-audience-thesis.md) accelerates the trend because the work split increasingly justifies specialist hiring.
Where this take is wrong
- Much of the work continues under narrower titles. People who might have been called DevRel in 2018 now work as DX engineers, documentation engineers, educators, or community managers.
- At earlier-stage companies, the integrated DevRel function is still typical and effective. Specialisation is a scale-stage choice.
The work is splitting into specialties rather than disappearing. DevRel practitioners can prepare by developing depth in community, education, documentation, advocacy, marketing, or AX engineering.
Critical take 6: “AI is hollowing out junior developer skill formation”
A specific concern that applies to DevRel-adjacent products.
Argument:
- AI tools accelerate productivity on tasks developers already know.
- They may hinder skill formation on tasks developers don’t yet know: the developer accepts AI output, the work gets done, but no skill is acquired.
- For junior developers in particular, this risks producing a cohort that can’t operate without AI assistance.
Where this take is right
- Empirical evidence, including Anthropic’s 2026 skill-formation research and anecdotal evidence from senior engineering managers across many companies, supports the concern.
- DevRel teams in education-adjacent products face a real strategic question.
Where this take is wrong
- Every previous developer-tool generation faced this critique. Calculators, IDEs, search engines, Stack Overflow: each was accused of hollowing out skill. Each was assimilated; the next generation of developers became more productive and developed different (sometimes deeper) skills.
- Plausibly the same will be true of AI. The senior developer of 2035 will have skills the senior developer of 2025 doesn’t.
DevRel teams working on education should teach first principles alongside AI use and test whether learners can explain and debug the resulting code.
Critical take 7: “The 2026 AI-DevRel hype cycle will look embarrassing in 2030”
A meta-critique sometimes made by senior practitioners.
Argument:
- Every wave of developer-relations transformation (cloud, mobile, OSS, microservices, DevOps, blockchain, AI) generates a wave of certain-sounding advice. Most of the advice doesn’t survive the cycle.
- Much of the 2024 to 2026 AI-DevRel writing, including this section, will look quaint or wrong in 2030.
- “AI Engineer,” “Agent Experience,”
llms.txt, even MCP itself may turn out to be names for things that were temporarily prominent.
Where this take is right
- Probably true at the level of specific tools and terms. MCP may not be the protocol name in 2030; specific tools that look central now may be footnotes.
Where this take is wrong
- Underlying directions such as agents reading docs, AI mediating developer discovery, the dual-audience structural split, and AX as a discipline are probably durable even if their names change.
- Some current advice will age badly without making every underlying change imaginary. The practical response is to act on well-supported changes, measure the rest, and revise when the evidence changes.
Treat every 2024 to 2026 convention as revisable. Invest first in changes with independent value, measure the newer tactics, and drop the ones that fail.
Working position
Taken together, the seven critiques support a narrower position than much AI-era DevRel marketing. AI changes how developers discover products and how some support and content work gets done. Community work, editorial decisions, and internal representation still need accountable owners.
The claims about particular tactics are less secure. Evidence for llms.txt, GEO tools, and AI-citation optimisation is inconsistent, while clean documentation, runnable examples, stable schemas, and observable product behaviour remain useful whether a human or an agent reads them. Teams can adopt the latter without pretending the former are settled.
The organisational picture is mixed. Some larger companies are splitting a general DevRel role into DX, AX, documentation, community, education, and customer-engineering specialties. Earlier-stage companies still often need one person or team to cover several of those jobs. Titles alone do not show whether the underlying work has disappeared.
Measurement needs the same caution. Sentiment surveys record a real part of developer experience, but they cannot establish productivity or adoption on their own. Use telemetry where it exists, keep the survey data, and state what each measure cannot prove. Several of the conventions discussed in this section will change; the evidence should decide which ones survive.