DevRel Uni is a six-week cohort for developer relations practitioners. You do not watch it and forget it. It runs live sessions with practitioners who do the job now. A project runs beside those sessions, and you ship it publicly at 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 already did DevRel at AccuKnox, and I already thought about how AI reshaped the job. I already built tools to cut the manual part of my workflow. Background thought during other work is a weak version of the real thing. Direct focus, and a real build from it, is the strong version. The cohort gave me a reason to do the second thing.
The format is simple. Each week has one session. One project runs beside the sessions, and one public deliverable lands at the end. This is that deliverable.
Below is a recap of my notes and takeaways from each session. DevRel Uni Cohort 7 ran for 6 weeks.
Session 1. The Scope of the Job Changed
Bianca Buzea opened the cohort with a simple framing. Four things define DevRel in any era. Those four are sense-making (what matters), storytelling (why it matters), distribution (who hears it), and feedback loops (what works). Those four stay. Everything around them moves.
The part that landed hardest for me was the audience expansion. DevRel always served developers. Now it must serve developers and AI agents at the same time. Those aren't the same job.
When a developer reads your docs, they read for intent. When a large language model (LLM) reads your docs, it reads for pattern. A page can explain a concept well for a human and still fail a coding agent. That happens when the API examples are ambiguous or the parameter descriptions are vague. It also happens when the page is prose-heavy with no machine-readable anchors.
An agent in a coding environment does not infer gaps. It has the information, or it hallucinates a plausible answer.
LLM-friendly documentation is a technical spec, not a style choice. That spec wants OpenAPI accuracy and deterministic code examples with exact commands, with explicit input and output schemas and no ambiguous pronouns anywhere. The docs answer the question before anyone asks it, in a form a retrieval system lifts whole.
Bianca made one quiet point that I keep returning to. "More people can build now, which means more people need guidance." The barrier to entry dropped. The demand for DevRel didn't shrink. It widened.
Session 2. Career Architecture, Not Career Path
Nader Dabit tracks GitHub Trending and Hacker News every day, and runs his own AI agents against the topics he follows. That habit alone told me his advice on career timing came from data, not from instinct.
Don't optimize for a title. Become a technologist.
Lock yourself into a job title and you've already lost, Nader said. Think like a technologist rather than a role, because the people who last are the ones who read the shifts and move with them. Career paths rarely run in a straight line, and a fast pivot beats a slow, careful plan now that speed matters more than it used to.
Nader's own edge is infrastructure, not luck. The daily GitHub Trending and Hacker News habit feeds his agents, and the agents route everything into custom feeds that keep working whether he checks the news that day or not. None of that compounds by itself. His loop is learn, build, share, get feedback, improve, and the "share" step is the one most people skip. Treat social media as a job board you get ahead of rather than one you react to. Show what you know in public, help people for free, and you land on a company's radar before the role ever gets posted.
"Every day is an opportunity to reinvent yourself. Small daily changes compound into a different person over time."
In practice you build three layers, and they compound at different rates. Tools change every few months. Fundamentals, systems thinking, communication, product sense, compound over years. Judgment is the layer AI can't replace, and it covers what to ignore, when to move, and what matters right now. The sequence matters: tools are tactics, fundamentals are strategy, and judgment tells you which strategy applies now.
Output makes learning stick. A GitHub repo, a video, a post, or a talk all count as output. Proof of work is the new resume, and proof of work is specific where a resume is generic.
I applied one thing directly from this session. I treat 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 tested whether I could explain the build clearly. The reader had not looked at the code all week. A LinkedIn post that I could not write clearly meant I did not understand my own build.
Nader said one more thing that I flagged immediately. Readiness usually comes after movement rather than 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 opened with a question nobody in the room answered right away: how many eyes does a sniper keep open when aiming?
"Speed without system doesn't create progress. It creates queues."
Snipers shoot with both eyes open. The dominant eye locks onto the target, and the other eye keeps watch on everything around it. Close that second eye and you gain precision but lose peripheral vision, and in a fast-moving AI ecosystem, that lost awareness gets expensive. The thing that changes everything for you often sits outside the window you're currently staring through.
Patrick's example was Framework, a project that teaches kids engineering by having them build real things. The team executed cleanly and still ran into a dominant-eye problem. They fixed their gaze on the product roadmap and missed an ecosystem shift moving around them. They built something real while the ground under it moved.
The rest of the session was about research discipline. Start from data, not from a hypothesis, because feeding a bias into an AI system just gets the bias confirmed back to you. The prompt is upstream of everything that follows it. Carving out time to learn every day feels impossible right up until you calculate the cost of skipping it, and the compounding runs in both directions.
Passion is a distribution strategy in its own right. Patrick posted an article about EdTech, a subject he genuinely cares about, and it brought him investors, collaborators, and hires, because readers could tell the interest was real.
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.
Coding agents now operate inside that ecosystem too. They pull from your docs, your SDK, your changelogs. Pull them in with the same structural clarity you use for a careful developer, one who reads closely and expects exactness.
Session 4. Your Docs Are a Product Decision
Hassan El Mghari from Together AI turned a half-conscious habit of mine into an explicit principle.
Developer experience is the floor. Agent experience is the problem already sitting above it.
When a new model drops, find what it's uniquely good at and build around that capability fast. Hassan did this with RoomGPT (room interior redesigns) and BlinkShot (real-time image generation). Timing and simplicity beat complexity.
Develop taste, because AI speeds up execution but supplies no judgment of its own. People can tell the difference between careful work and generated work, in the writing and in the demo.
Consistency is the advantage almost nobody uses. One article a week for six months adds up to 24 articles, and few people actually hold that pace. The same math applies to demos and to open-source contributions.
Hassan's specific read: build MCP servers and agent-friendly docs for coding agents, since a growing share of your readers are no longer human.
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, and the payoff is that he can move the moment he has capacity.
A developer asks ChatGPT how to use your API, and one of two things happens: the model answers correctly from training data or retrieval, or it hallucinates a plausible but wrong answer. Your technical content decides which. Clear, well-structured content is what gets pulled into the response accurately.
Being in the answer someone reads without ever clicking through to your site now matters more than a spot in Google's ranking. Your changelog entries and getting-started guides already answer questions in conversations you never join.
The implications are specific. Changelogs need semantic structure instead of narrative bullet points. SDK method signatures need inline examples with typed inputs and explicit outputs. Write getting-started guides for a system that executes each step literally. That system does not read 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, and 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. He was direct that pace still matters. Good ideas and strong UX are still human decisions. The agent speeds up execution of a direction you already chose. It doesn't choose the direction.
Session 5. The Operations Grid I Didn't Know I Needed
Francesco Andreoli, from Consensys, closed the cohort by borrowing a framework from psychology: a Pyramid of Builder Needs, adapted from Maslow's hierarchy.
The bottom layer of that pyramid is docs. If that layer breaks, nothing above it (grants, events, hackathons) lands. You can't skip a level in a hierarchy. His developer funnel separates value-driven onboarding from product conversion, and his Builder Nights series proved the split works. That series covered the whole ecosystem, from L2s to ZK to EIPs across different chains, without pushing a single product. Product-specific conversion only arrived after that value-first stage had earned it.
The DevRel Operations Grid asks one question per task: is this work human-led, AI-assisted, or agent-led? That is a workflow design question rather than a philosophical one, and most DevRel work has a concrete answer. The grid maps a gradual shift, human-led to AI-assisted to agent-native, across content, community, support, and education. The key word is gradual. You onboard a new way of working, you don't flip a switch.
Docs sit at the top of the funnel now, because agents crawl them to answer developer questions in conversations you never join. Generative Engine Optimization, or GEO, replaces SEO as the mental model here, and well-structured docs beat a polished marketing site as a source agents actually cite. Francesco's specific addition to that idea: publish an llms.txt file and design real agent skills, then write every guide for a system that reasons over it rather than one that just skims it.
Applied to daily work, the grid looks like this:
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.
Even at scale, community still runs through a small, trusted core. Find your top 50 contributors and amplify their wins in public, because the rest of the community grows around whatever you choose to celebrate. The permissionless community angle was specific to Consensys's web3 context, but the design logic holds anywhere. A community that contributes without permission grows faster and produces better work, because the contributors select themselves through real investment. The system still needs clear standards and a moderation layer near the edges, instead of a bottleneck at the front door.
The DevRel Workbench Was My Capstone Project
Six weeks passed and the major tools shipped. The DevRel Workbench is live at https://10xdevrel.atharvashah.com.
The Launch Checklist Generator takes a changelog and returns a DRI-mapped checklist covering pre-launch, launch day, and post-launch tasks with priority levels. The Demo Run of Show Builder takes a demo brief and returns a timed agenda, one that carries speaking notes and a fallback matrix for common failure modes.
The Content Repurposing Planner turns one source asset into six content briefs across channels. The Demo to Distribution Planner turns one product change into a connected demo flow, plus a launch checklist and a 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 the build is that scoped tools beat general assistants. That holds every time. I built a general AI assistant early for the workbench.
It underperformed the four scoped tools by a meaningful margin. The scoped tools have clear, testable success criteria. Here is a question you answer objectively. "Did this generate a valid launch checklist with DRI assignments, priority levels, and correct task categorization?" The question "Was this conversation helpful?" has no objective answer.
That pattern held everywhere I looked during the cohort. The best agent demos I saw had narrow scopes and explicit success criteria. Devin's Nubank case study is one of them. None of them were general-purpose assistants with vague goals.
The Habits That Actually Changed After the Cohort
Three habits changed after the cohort, and all three came directly from a session.
Agent experience is now baked into my documentation process. When I write a getting-started guide or update an API reference, I run through it as if I were a coding agent. That agent executes every step literally, and a failure at any step sends me back to fix the doc.
The learning loop is scheduled now instead of reactive. Forty-five minutes a week goes to ecosystem scanning, where I taste new tools on purpose, document what changes, and update my own workflow list. That block sits on the calendar like any other meeting.
The DevRel Operations Grid is how I plan my week, across three columns: human-led, AI-assisted, and agent-led. Work that belongs in the third column and still sits in the first becomes a backlog item.
Thanks
Bianca built a cohort structure that gave people permission to ship imperfect work in public. They then learned from it 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. Some parts held up and some parts got cut on camera. Both outcomes were useful.
Daniel Pisu, your conversations across the cohort gave me the most direct feedback. They told me whether the workbench landed for a working DevRel practitioner. That's the signal that matters.
To my team at AccuKnox, the real problems I meet every week shaped everything I built here. The launch checklist tool was a direct export of the actual checklist we use. The demo run-of-show builder came from what breaks when you have no run of show. The workbench is a product built from the job itself rather than from imagination.
The cohort ends on June 9. The workbench keeps shipping. Go try it out.
Related reading: The Future of Leadership Is Fluid and Meritocratic and AI-First DevRel: 15+ Playbooks for Content and GTM.
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.
