The most useful moment in a technical video is often a small one: the viewer sees a request become a result and understands how to try it themselves.
That moment is the focus of my work in developer relations. I have produced 1,600+ videos across my career, and my background is in software engineering. Software development and video production are both hands-on technical disciplines; creative judgment connects them in my DevRel work. I can work through the implementation, then decide how to explain it through a script, a screen recording, and an edit. Today, as a Senior DevRel Lead at GMI Cloud, I bring those skills together in AI infrastructure, developer education, and community work. My specialty is making complex technical ideas easy to understand while keeping the engineering detail useful.
A camera angle, a readable code example, and a well-timed explanation can help someone follow a system. The next step is giving that person the documentation and practical exercise to build with it.
For DevRel leads and technical educators, here is how I would turn that production experience into a repeatable lesson format.
What video contributes to developer relations
Developer relations connects a technical product with the people building on it. Developer education, documentation, community conversations, and product feedback all contribute to that relationship.
Video adds something particularly useful: sequence. A developer can see the input, follow the action, watch the response arrive, and hear why a particular choice matters. For AI products, that sequence might include a model request, a tool call, an inference result, or a generated media asset.
My video background gives me a way to direct attention through that sequence. I think about what a developer needs to see at each point, how much context belongs on screen, and which decision deserves an explanation.
The technical question and the editorial question become closely related. Which parameter changes the behavior? Which part of the interface should fill the frame while I explain it?
My NVIDIA Nemotron 3.5 Super VL demonstration. Read how I built and tested the desktop agent on GMI Cloud. Image supplied by Roan Weigert.
Developers learn through video and documentation together
The 2026 Stack Overflow Developer Survey shows the resources respondents selected for learning. Among 14,530 respondents to its learning-resources question, 58.9% selected technical documentation and 41.1% selected videos outside a course or certification. Respondents could choose several resources.
Those figures describe reported resource use. My practical takeaway is to design the video and written guide as parts of the same learning experience.
A video shows the order of operations. A guide can give the developer exact commands, configuration details, and a place to return to later. The same example should appear in both, with matching names and outputs.
Diátaxis offers a helpful way to organize that material. It separates tutorials, how-to guides, reference, and explanation. I would use those distinctions to decide what each asset should accomplish: a guided first build, a specific task, precise parameter information, or an explanation of how the system works.
For a developer watching an AI demo, the next link should fit the question the demo creates.
How I would storyboard an AI developer tutorial
Here is the structure I recommend for turning a complex workflow into a practical lesson. It combines an editor’s attention to sequence with an engineer’s attention to reproducibility.
Start with a visible result
Show what the developer will build. A short screen recording of the completed workflow gives the setup steps a purpose.
For a voice-controlled assistant, that might be a spoken request followed by an observable action on screen. For a multimodal workflow, it might be the finished media asset and the input that produced it.
Name the audience and prerequisites immediately after that preview. A developer who already has an API key can move directly to the example; someone setting up an account can follow a clearly marked setup section.
Explain one meaningful decision at a time
A screen recording becomes a lesson when the viewer understands why an action matters.
For an inference example, explain the selected model, the input format, and the response the application expects. For an agent demo, show where the model proposes an action and where application code executes it. That distinction helps the viewer understand the implementation.
Keep the cursor, crop, and narration focused on the same decision. When a parameter matters, make it large enough to read. When the response arrives, leave it visible long enough for the viewer to inspect it.
Preserve the timing of the system
Editing helps a viewer follow a sequence. Labels keep that sequence technically meaningful.
If a generation takes time, label the wait before shortening it in the edit. If the demo uses prepared assets, identify them. Put the model version and recording date in the companion guide so a developer can relate the example to the current product.
Those details make a polished video useful as a technical reference.
End with a small variation the developer can try
Give the viewer one change to make: a different input, a parameter adjustment, or an additional tool. Describe what they should observe after the change.
That exercise connects watching with understanding. It also produces a useful community question: what happened when you tried your variation?
A proposed shot plan for a voice-assistant tutorial
For the NVIDIA Nemotron use case linked below, this is the editorial outline I would recommend. It is a proposed teaching sequence.
| Segment | What the viewer sees | What the narration explains |
|---|---|---|
| Result | A spoken request followed by an action on screen | The task the assistant completes |
| Input | The screenshot and request sent to the model | What information the model receives |
| Decision | The proposed tool call | How the application interprets the response |
| Execution | The application carrying out the action | Which part is ordinary application code |
| Verification | The resulting screen | How the developer checks the outcome |
For the editor, the practical instruction is to hold each view through its explanation. For the technical reviewer, it is to confirm that the visible sequence matches the implementation. Both reviews protect the same thing: the viewer’s understanding of what happens next.
What research suggests about tutorial production
Philip Guo, Juho Kim, and Rob Rubin analyzed 6.9 million viewing sessions across four edX courses in their 2014 study of educational video engagement. They found stronger engagement with shorter videos and offered recommendations about presentation style and segmentation.
The study measured engagement in a particular online-course setting. I use it as a reason to give each segment a clear learning purpose, with duration guided by the task. A brief setup lesson and a longer implementation walkthrough can serve different needs.
Accessibility belongs in that planning. The W3C media accessibility guidance covers captions, transcripts, and descriptions of relevant visual information. In a technical tutorial, that means speaking the important action aloud, making code readable, and providing a text route through the same lesson.
Putting technical storytelling to work at GMI Cloud
At GMI Cloud, I lead editors, technical writers, junior DevRel professionals, and community developers. My responsibilities also include community events and customer support across our channels.
That scope lets me connect the explanation across several formats. A video introduces a workflow. Documentation provides the implementation detail. An event gives developers room to try it. Questions from the community show where an example or explanation can become clearer.
My work includes NVIDIA Nemotron content, GMI MCP tutorials, AgentBox documentation and demonstrations, webinars, and AI filmmaking education. Each subject calls for a specific teaching decision.
For NVIDIA Nemotron, the voice-assistant video and companion article give readers a concrete application to inspect. The article describes the prototype and its evaluation. The measured results belong to that prototype and its test conditions.
For GMI MCP, the walkthrough video and developer article connect Model Context Protocol to practical work with media and developer tools.
As a team lead, I see value in giving each contributor a clear part of the lesson. The technical writer can make prerequisites precise. The editor can make the relevant action easy to see. A junior DevRel colleague can help test the walkthrough from a fresh starting point. Community and support colleagues can bring recurring questions into the next revision. This is the review process I recommend around a shared example.
My flagship AI filmmaking masterclass and hackathon
My flagship AI Filmmaking Masterclass + Hackathon in San Francisco, supported by GMI Cloud as a sponsor. Photo published in GMI Cloud’s event recap.
The AI Filmmaking Masterclass + Hackathon is my flagship event for video and AI. I led the three-hour masterclass; teams then had four hours to create the 23 films we screened. GMI Cloud participated as a sponsor. My event recap documents the work and credits our co-hosts, production team, and partners.
I reviewed 195 applications before the event and adjusted the curriculum around what people wanted to learn. The room brought filmmakers and engineers together. That combination matters to my approach to developer education: teach the technical workflow in the context of something the participant wants to make.
The finished films gave participants a tangible result. Participants make choices about tools, references, generation, and editing, then show what those choices produced. My production experience is useful in explaining those decisions as part of a complete workflow.
Earlier, at APARAVI, I built technical demos and reusable demo kits, supported tutorials and onboarding, and helped grow a Discord community to 500+ builders. Those experiences connect the teaching work with an ongoing relationship: people return with another question, another use case, or an example of their own.
How I would measure a DevRel video program
My career total of 1,600+ videos describes production experience. For a developer education program, I would track a separate set of outcomes tied to the intended task.
| Question | Useful measure | What to define |
|---|---|---|
| Did the right audience find the lesson? | Qualified views and relevant search queries | Audience, channel, and reporting period |
| Did viewers reach the practical step? | Retention around the implementation section | Timestamp and video version |
| Did they start building? | Visits to the matching guide or sample | Tagged links and consent-aware analytics |
| Did they complete the exercise? | Successful first run or workshop submission | Starting point and completion criteria |
| Did they continue using the product? | Return usage among the learning cohort | Cohort, timeframe, and product event |
| What should the team explain next? | Recurring questions and documentation updates | Topic, source, owner, and resolution |
For a new program, I would choose the measures that match the learning goal and define the reporting window before publishing. Each measure answers a different question. Together, they can help a team decide which lessons to expand and which examples deserve a refresh.
Questions about video and AI developer education
What makes a technical video useful for developer relations?
A specific task, readable implementation detail, an observable result, and a clear next step. The developer should be able to connect what happens on screen with an example they can run or adapt.
How should video and documentation work together?
Use the same example and terminology in both. Let the video explain the sequence and decisions, and let the written guide provide setup, commands, parameters, and reference links.
How can a DevRel lead bring video expertise to a team?
Translate the technical objective into an editorial plan. Define what the viewer should understand, assign technical and production reviews, and bring community questions into the next version. Give editors enough technical context to preserve the meaning of each step.
Where can I see examples of this work?
Start with my NVIDIA Nemotron demonstration, GMI MCP walkthrough, or selected work. Choose a workflow you want to explain, then write down the exact moment where your audience should be ready to try it.
About the author: Roan Weigert is a Senior DevRel Lead at GMI Cloud, video specialist, and host of AI Insights San Francisco. His software engineering background and 1,600+ videos inform his work in AI infrastructure, developer education, and technical storytelling. He leads his flagship AI Filmmaking Masterclass + Hackathon, supported by sponsors including GMI Cloud. Connect with Roan on LinkedIn.
