Seven arguments recur in discussions of AI-era DevRel. Each identifies a real problem, but the evidence often supports a narrower conclusion than the slogan.
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 rarely provide enough method or baseline data for reproduction.
- 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 recommends visible optimisation work without evidence of effect.
- 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 reflect limitations in current measurement. Early SEO research faced a similar attribution 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”
Operational engineering teams make this empirical 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.
- Research from Faros AI, the two-year JetBrains HAX study of 800 developers, and Anthropic’s skill-formation work each reports a gap between some self-reported and observed outcomes, using different methods.
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”
The argument:
- DevRel teams have experimented with using LLMs to scale content production. Most attempts have failed.
- AI-generated technical content is often generic or subtly wrong.
- Readers may disengage when the material lacks accountable technical judgement.
- Teams report poor results when they use generation volume as a substitute for review and authorship.
Where this take is right
- Practitioner accounts associate unreviewed AI-generated content with lower trust and engagement, although comparative data remains limited.
- AI can increase drafting volume without increasing the amount of accurate, useful material a team can review.
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 rather than surviving independently”
The structural argument cites these 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 Humans and agents) 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”
The argument for DevRel-adjacent products:
- 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
- Anthropic’s 2026 skill-formation research and accounts from senior engineering managers support the concern, with different evidential weight.
- Education teams need to test whether learners can explain, modify, and debug code produced with AI assistance.
Where this take is wrong
- Similar concerns accompanied calculators, IDEs, search engines, and Stack Overflow. Developers adopted those tools while the skills expected of them changed.
- 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”
The argument:
- Previous shifts including cloud, mobile, open source, microservices, DevOps, and blockchain produced confident advice whose relevance later narrowed or disappeared.
- 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
- Specific tools and terms are likely to change. MCP may not be the protocol name in 2030, and currently prominent tools may lose relevance.
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 prove wrong even if the underlying changes persist. 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.