AI agents can execute more developer work, but people still decide which products to evaluate, learn, trust, and recommend. DevRel work aimed at those decisions depends on identifiable people with a public record of judgement.
The working argument
When agents write the code, developers still choose what to build, what to integrate, what to advocate for inside their teams, and whom to trust. Those choices depend partly on reputation and judgement. As agents handle more mechanical work, DevRel’s influence rests increasingly on whether people trust the humans representing a product.
The dual-audience split leaves these choices with people (see Humans and agents). Agents can carry out more of the work, while humans still decide why to do it, which approach to take, and whom to trust.
What “inspiration” means here
Here, “inspiration” means giving a developer a reason to choose to engage with your product. Specifically:
- A reason to evaluate. Why is this product worth two hours of evaluation time?
- A reason to advocate inside their organisation. Why should they put their reputation behind it in an architecture meeting?
- A reason to invest in learning it. Why is this technology worth becoming an expert in?
- A reason to care. Curiosity, excitement, identification with a community, aesthetic appreciation, or intellectual delight can all give someone a reason to keep going.
AI assistants can repeat these reasons from existing material. The original judgement still comes from a person or community willing to attach a name to it.
Where developers encounter these reasons in 2026
YouTube
YouTube is a major human-facing DevRel surface in 2026. The format has expanded beyond tutorial videos to include:
- Build-in-public vlogs. Founders or senior engineers narrating decisions over weeks.
- Live coding streams. Engineers work through implementation problems, including failed attempts and recovery.
- Conference talk recordings. Often the talk reaches more developers post-event than during.
- Sponsored content with established educators. Fireship’s Code Report, ThePrimeagen, Theo Browne, and similar channels reach large developer audiences. Viewers can assess the product through a creator whose judgement they already know.
- Founder-led explainer videos. Patrick Collison or Guillermo Rauch can explain product decisions with the authority of the person who made them.
AI assistants can also retrieve YouTube transcripts, as discussed in GEO and AEO for DevRel. The video therefore reaches people directly and can become source material for later AI answers.
Conferences and in-person events
In-person conferences remain useful as AI mediates more digital discovery:
- Attendees can ask follow-up questions and watch how speakers handle uncertainty.
- A live demo shows how the product behaves outside a prepared screenshot or edited recording.
- Attendees who meet the team can continue a product evaluation or ask follow-up questions later.
- Recorded conference talks remain searchable after the event.
The 2024 to 2026 recovery in conference attendance after the pandemic is consistent with this thesis. See Flagship developer conferences.
Live streaming (Twitch and YouTube Live)
Live streams let viewers watch an identifiable person work through a problem, including search queries, misreads, and the eventual fix. ThePrimeagen and Tsoding do this on Twitch, and Stripe engineers have used YouTube Live for similar sessions. The visible process and accountable speaker provide evidence that a polished generated demonstration does not.
Founders and senior engineers on X / Bluesky / LinkedIn
The “founder voice” pattern (see Founders as DevRel) is useful because the speaker is accountable for the product decisions being discussed. Examples include Patrick Collison on payments architecture, Mitchell Hashimoto on infrastructure tooling, and Guillermo Rauch demonstrating Next.js.
LinkedIn reaches engineering directors, VPs, and CTOs who participate in technology-procurement decisions.
Podcasts
Long interviews let listeners hear how a practitioner reasons beyond a prepared launch message. The Changelog, Latent Space, Syntax.fm, Acquired, Lex Fridman Podcast, Practical AI, and Community Pulse all carry product and industry discussions to established audiences.
Discord and named-community spaces
Named staff in Discord servers run by Vercel, Supabase, Cloudflare, Cursor, and Anthropic can answer ambiguous bugs, product-policy questions, and disputed recommendations for which a generic AI response is insufficient.
Some AI assistants retrieve Reddit threads heavily. For DevRel teams, the useful work remains substantive participation in communities such as r/programming, r/learnprogramming, r/MachineLearning, r/LocalLLaMA, and r/ExperiencedDevs.
What “inspiration” excludes
These formats provide little accountable technical judgement:
- Generic content marketing. Thin “five best practices” articles offer little beyond material an assistant can already summarise.
- Unowned AI-generated developer content. It tends towards generic claims and leaves no accountable author when a technical judgement is wrong.
- Case studies with no trade-offs. Developers recognise marketing copy that withholds constraints or failed attempts. Specific limits make the account more useful.
- Generic brand posts on social. A corporate account posting “Our team is excited to share…” gives the reader little reason to care. A named engineer can explain what changed and why.
Publishing founders, engineers, educators, and community members under their own names lets readers connect claims to the decisions and experience behind them.
What the inspiration audience trusts
Evidence developers can inspect includes:
- Founders writing honestly. Stripe Press essays, Mitchell Hashimoto on his blog after leaving HashiCorp, individual posts from senior engineers at Anthropic and OpenAI.
- In-public iteration. Supabase Launch Weeks, Vercel’s roadmap thread, Cloudflare’s Developer Week.
- Recognised voices. A recommendation from someone with a relevant public record gives readers a reason to investigate.
- Customer accounts in the customer’s own words. The engineer can explain the constraints, failures, and trade-offs that a vendor case study may omit.
- Conference talks that disclose limits or failures. They give the audience evidence unavailable in a polished product claim.
- Working live demos. An unedited demo shows how the product behaves outside a prepared recording.
The published record
Readers can inspect what a named person recommended, built, corrected, and defended over time. A prompt can help draft a post, but it cannot supply that history of decisions and public work.
How DevRel teams should staff for inspiration
Teams investing in this work in 2026:
- Assess technical ability and public communication together. An existing audience is relevant to distribution but does not substitute for product knowledge or judgement.
- Use long-form formats where the subject needs them. Conference talks, YouTube tutorials, podcasts, and build-in-public series allow detailed explanation.
- Compare external creators with internal production. Use audience fit, cost, referral, and activation data rather than assuming either route is superior.
- Give founder material a direct review path. Check claims and disclosure requirements without flattening the named author’s technical judgement.
- Define the purpose of conference work. Speaker placement, side events, and customer dinners support different relationships and need different measures.
- Maintain real community presence. Use named people in Discord, on Reddit, and in long-running threads rather than bots or generic accounts.
- Use an evaluation period appropriate to the format. A YouTube channel or podcast may need several releases before reach, referrals, or assisted conversions can be assessed.
Operating both sides
When customers use agents to carry out developer work, DevRel teams need accurate machine-readable material. People still decide what to build, adopt, and recommend, so those teams also need credible authors, speakers, educators, and community participants. The staffing and output plan should account for both kinds of work.