Reflections On DevRel Uni Cohort 7 - My Takeaways from 5x Sessions with Industry Gurus
I came into Cohort 7 thinking I had a decent mental model of where DevRel was heading. I left with three of those assumptions broken. This was a great six week excercise.
DevRel Uni is a six-week cohort for developer relations practitioners. Not a course you watch and forget. A structured sequence of live sessions with practitioners actively doing the job, running in parallel with a project you ship publicly by the end. Cohort 7 had five speakers across six weeks: Bianca Buzea, Nader Dabit, Patrick Skinner, Hassan El Mghari, and Francesco Andreoli.
I enrolled because I wanted a forcing function. I was already doing DevRel at AccuKnox, already thinking about how AI was reshaping the job, already building tools to reduce how much of my workflow was manual. But thinking about something in the background while doing other work is not the same as sitting with it directly and building something real from it. The cohort gave me a reason to do the second thing.
The format: one session per week, one project built in parallel, one public deliverable at the end. This is that deliverable.
Here’s a recap of my notes, takeaways and learnings from each of the final session to take away from the DevRel Uni Cohort 7 that ran for 6 weeks.
Session 1: The Scope of the Job Changed
Bianca Buzea opened the cohort with a deceptively simple framing: four things define DevRel across any era. Sense-making (what matters), storytelling (why it matters), distribution (who hears it), and feedback loops (what’s working). Those stay. Everything around them is moving.
The part that landed hardest for me was the audience expansion. DevRel has always served developers. Now it has to serve developers and AI agents simultaneously. Those aren’t the same job.
When a developer reads your docs, they read for intent. When an LLM reads your docs, it reads for pattern. A page that explains a concept well for a human can still be useless to a coding agent if the API examples are ambiguous, the parameter descriptions are vague, or the page is prose-heavy with no machine-readable anchors. An agent running in a coding environment doesn’t infer gaps. It either has the information or it hallucinates a plausible answer.
LLM-friendly documentation isn’t a style preference. It’s a different technical spec. Clean OpenAPI accuracy, explicit input/output schemas, deterministic code examples with exact commands, zero ambiguous pronouns. The docs need to answer the question before the question is asked, in a form that a retrieval system can lift without filling in blanks.
Bianca’s quiet point that “more people can build now, which means more people need guidance” is the one I keep returning to. The barrier to entry dropped. The demand for DevRel didn’t shrink. It widened.
Session 2: Career Architecture, Not Career Path
Nader Dabit’s session hit harder than I expected, partly because he’s watched enough of these cycles play out to speak with authority rather than anxiety.
The line that stuck: don’t optimize for a title, become a technologist.
Lock yourself into a job title and you’ve already lost. Think like a technologist, not a role. The people who last are the ones who can read shifts and move with them.
Career paths are rarely straight lines. Fast pivots beat slow, careful plans, and speed matters more now than it used to.
Nader’s learning system was the thing I kept thinking about after the session. He monitors GitHub Trending and Hacker News daily, runs AI agents on topics he tracks, and routes everything into custom feeds. His information advantage isn’t luck. It’s infrastructure.
Learning by itself doesn’t compound. The loop that actually builds something is: learn, build, share, get feedback, improve. The “share” step is the one most people skip.
Social media is a job board you get ahead of, not one you react to. Showing what you know publicly and helping people openly gets you on a company’s radar before a role ever posts.
“Every day is an opportunity to reinvent yourself. Small daily changes compound into a different person over time.”
In practice that means building in three layers that compound at very different rates. Tools change every few months. Fundamentals (systems thinking, communication, product sense) compound over years. Judgment, knowing what to ignore, when to move, and what actually matters, is the layer AI can’t replace. The sequence matters: tools are tactics, fundamentals are strategy, judgment is what lets you know which strategy applies right now.
The learning loop Nader gave is specific: learn something, build something, share something, get feedback, integrate. The key word is “share.” Output makes learning stick. A GitHub repo, a video, a post, a talk. Proof of work is the new resume, and proof of work is specific where a resume is generic.
One thing I applied directly from this session: treating every project as a forcing function for public output. The DevRel Workbench is the primary example. Every week, something shipped and something got posted. The posting wasn’t just distribution. It was a test of whether I could explain what I built clearly enough for someone who hadn’t been staring at the code all week. If I couldn’t write a clear LinkedIn post about what shipped, something was wrong with how I understood what I built.
The other thing Nader said that I flagged immediately: readiness usually comes after movement, not before it. You don’t need all the answers before the next step. You need enough signal. The window opens whether you’re ready or not.
Session 3: Speed Without System Is Just Queue
Patrick Skinner’s session had the line that I keep repeating to myself when I catch myself rushing without a system.
“Speed without system doesn’t create progress. It creates queues.”
Start research from data, not from a hypothesis. Feed AI a bias and it confirms the bias. The prompt is upstream of everything.
Snipers shoot with both eyes open: dominant eye locked on the target, the other keeping peripheral awareness. The dominant eye trap is what kills focused startups. Too zoomed in on the roadmap, too slow to catch competitors or new tools moving around them.
Carving out time to learn every day feels impossible until you realize the cost of skipping it. The compounding works in both directions.
Passion is your distribution strategy. Patrick posted an article on EdTech, something he actually cares about, and it brought in investors, collaborators, and hires. The content wasn’t a growth hack. It was proof of genuine interest.
The sniper’s fourth eye scope metaphor was specific enough to be useful. When you close one eye to aim, you get precision but lose peripheral vision. In a fast-moving AI ecosystem, losing that peripheral awareness is dangerous because the thing that shifts everything might not be inside your current focus window.
Patrick’s example about Framework, a project trying to teach kids engineering through building things, illustrated the problem with brutal clarity. The team wasn’t bad at execution. The team had a dominant-eye problem: so focused on their product roadmap that they missed the ecosystem shift happening around them. They were building something real while the ground moved.
What I pulled from this: I now block 45 minutes every week specifically for ecosystem scanning. Not consuming content passively. Deliberately tasting new tools, documenting what changes in my workflow, updating a personal changelog of what I’ve tested and what I’ve replaced. Patrick calls this “brain lifting.” Intentional learning, not reactive scrolling.
The Orbit model (Gravity, Love, Reach) has a layer most people skip in the AI context. Gravity brings developers into your ecosystem. Love keeps them loyal. Reach grows the community outward. But coding agents now operate inside your ecosystem too. They pull from your docs, your SDK, your changelogs. You need to gravity them in with the same structural clarity you’d use to onboard a developer who reads carefully and expects exactness.
Session 4: Your Docs Are a Product Decision
Hassan El Mghari from Together AI turned something I had been doing half-consciously into an explicit principle.
Developer experience is the floor. Agent experience is the problem already sitting above it.
When a new model drops, figure out what it’s uniquely good at and build something around that specific capability fast. Hassan did this with RoomGPT (room interior redesigns) and BlinkShot (real-time image generation). Timing and simplicity beat complexity.
Develop taste. AI speeds up execution but doesn’t supply judgment. Good writing, thoughtful UX, interactive demos built with care, people can tell the difference between that and something generated without intention.
Consistency is the unfair advantage almost nobody uses. One article a week for six months is 24 articles. Most people never hit that. The same math applies to demos, videos, and open-source contributions.
DevRel now serves two audiences: developers and agents. That means MCP servers, agent-friendly docs, and SDKs built for coding agents, not just humans reading reference pages.
Hassan keeps a running idea journal with hundreds of prioritized app ideas. When he’s ready to build, he never starts from zero. The setup cost is low. The return is that he can move the moment he has capacity.
Here’s the concrete problem. When a developer asks ChatGPT how to use your API, one of two things happens: the model answers correctly from training data or retrieval, or it hallucinates a plausible but wrong answer. The difference is whether your technical content was clear, authoritative, and structured well enough to get pulled into the response accurately.
This is not about Google ranking anymore. It’s about being in the answer when someone never visits your site. Your changelog entries, SDK method docs, and getting-started guides are now answering questions in conversations you’re not present for.
The implications are specific. Changelogs need semantic structure, not narrative bullet points. SDK method signatures need inline examples with typed inputs and explicit outputs. Getting-started guides need to be written for a system that will execute steps literally, not read them for general intent. A human reads “run the install command” and infers the context. An agent in a coding environment needs the exact command, the exact flag, the exact expected output.
Hassan’s own workflow was worth noting. He uses coding agents to build demo apps, generate documentation stubs, and scaffold internal tools. But he was direct that pace still matters and good ideas and strong UX are still human decisions. The agent accelerates execution of a direction you’ve already chosen. It doesn’t choose the direction.
Session 5: The Operations Grid I Didn’t Know I Needed
Francesco Andreoli from Consensys closed the cohort with the most operationally useful framing I heard across all five sessions.
The DevRel Operations Grid asks three questions per task: should this be human-led, AI-assisted, or agent-led? That’s not a philosophical question. It’s a workflow design question with a concrete answer for most of what DevRel teams actually do.
Francesco’s Pyramid of Builder Needs is a Maslow-style hierarchy adapted for developers. The bottom layer is docs. If your docs are broken, nothing above it (grants, events, hackathons) lands. You can’t skip levels.
The developer funnel separates value-driven onboarding from product conversion. His Builder Nights series worked because it covered the whole ecosystem (L2s, ZK, EIPs, different chains) without pushing a single product. Product-specific conversion only comes after that value-first stage.
The DevRel Operations Grid maps the gradual shift from human-led to AI-assisted to agent-native across content, community, support, and education. The key word is gradual. This is onboarding a new way of working, not flipping a switch.
Docs are top-of-funnel now. Agents crawl them to answer developer questions in conversations you’re not part of. GEO (Generative Engine Optimization) replaces SEO as the mental model. Well-structured docs beat marketing sites as agent sources.
You serve two audiences: humans and agents. That means llms.txt, MCP servers, agent skills, and guides written for systems that reason over them rather than skim them.
Community at scale still runs through a small, trusted core. Find your top 50 contributors and amplify their wins. The community grows around what you celebrate.
Here’s how it maps across common work:
Docs: AI-assisted draft, human judgment on accuracy and voice.
Tutorial production: AI-assisted structure, human judgment on what’s actually hard.
Support triage: agent-led classification, human-led response on anything complex or nuanced.
Hackathon outreach: agent-led prospecting and first contact, human-led relationship building.
Community moderation: agent-led flagging, human-led final calls.
Content distribution: agent-led scheduling and formatting, human-led strategy on what to amplify.
The “Geo is the new SEO” point extended Hassan’s session into a direct strategy. Francesco called it GEO, Generative Engine Optimization. The docs that get cited in AI responses are the ones that are clear, authoritative, and structured so a retrieval system can grab them cleanly. You’re no longer just optimizing for search bots. You’re optimizing for language model retrieval.
The permissionless community angle was specific to Consensys’s web3 context, but the design logic holds anywhere. If your community can contribute without asking permission, you get faster growth and higher-quality submissions because contributors are self-selecting on actual investment. The system needs clear standards and a moderation layer, not a bottleneck at the front door.
My Capstone Project for the DevRel Uni Cohort 7 - DevRel Workbench (Giving Back to the Community)
Six weeks and a major tools shipped. The DevRel Workbench is live at https://10xdevrel.atharvashah.com
The four tools: Launch Checklist Generator (paste a changelog, get a DRI-mapped checklist with pre-launch, launch day, and post-launch tasks and priority levels), Demo Run of Show Builder (describe a demo brief, get a timed agenda with speaking notes and a fallback matrix for common failure modes), Content Repurposing Planner (one source asset becomes six content briefs across channels), and Demo to Distribution Planner (one product change generates a connected demo flow, launch checklist, and two-week content calendar).
The playbook library ships 15 playbooks covering the major DevRel motions. Community members can submit best practices, vote on submissions, and get approved contributions added to the library with contributor attribution.
The biggest technical lesson from building it: scoped tools beat general assistants. Every time. I built a general AI assistant early on for the workbench. It underperformed the four scoped tools by a meaningful margin. The scoped tools have clear, testable success criteria. “Did this generate a valid launch checklist with DRI assignments, priority levels, and correct task categorization?” is a question you can answer objectively. “Was this conversation helpful?” is not.
That pattern held everywhere I looked during the cohort. The best-performing agent demos I saw, including Devin’s Nubank case study, were agents with narrow scopes and explicit success criteria, not general-purpose assistants given vague goals.
What I’m Taking Forward
Three concrete things that changed my actual workflow:
Agent experience is now part of my documentation process. When I write a getting-started guide or update an API reference, I run through it from the perspective of a coding agent executing the steps literally. If it would fail at any step, the doc needs to be fixed.
The learning loop is now scheduled, not reactive. Forty-five minutes a week of ecosystem scanning: taste new tools, document what changes, update the workflow list. Not background noise. Blocked time.
The DevRel Operations Grid is how I plan my week. Three columns: human-led, AI-assisted, agent-led. Anything that belongs in the third column and isn’t there yet is a backlog item, not a nice-to-have.
Thanks
Bianca built a cohort structure that gave people permission to ship imperfect things publicly and learn from them in real time. That’s harder to design than it sounds, and the format held up across six weeks.
Manik, the YouTube walkthrough we recorded together was the best QA test the workbench could get. You were the first person to use it cold in real time, and some parts held up and some parts got cut on camera. Both outcomes were useful.
Daniel Pisu, the conversations throughout the cohort were some of the most direct feedback I got on whether the workbench was actually landing for a working DevRel practitioner. That’s the signal that matters.
To my team at AccuKnox: everything I built here was shaped by the real problems I run into every week. The launch checklist tool was a direct export of the actual checklist we use. The demo run-of-show builder came from watching what breaks when you don’t have one. The workbench is a product built from doing the job, not imagining it.
The cohort ends on June 9. The workbench keeps shipping. Go try it out.
