How AI Is Changing the Way We Build Video

"What did you do with AI this week?"

We kicked things off asking each panelist what they'd actually been doing with AI that week. Simple question — but the answers went in completely different directions, which kind of said everything.

Christian Pillsbury (Staff Engineer & Tech Lead, MUX) admitted he'd clocked about 15 unplanned hours the day before. He's been building documentation for video.js with Claude — and not just any docs, but docs that Claude itself will later use as context to generate code. It's a bit of a mind-bender: writing for an AI that will write for you.

Casey Occhialini (Principal Software Engineer, Paramount) told a story that got a few reactions in the chat. He had a bug that only showed up on a physical device in a lab — no remote access, no dev tools, nothing. So he grabbed his phone, took photos of his TV, described what he was seeing on screen, and worked through it with Claude. It worked.

"I've barely had any luck debugging video players with Claude until recently. Now I'm thinking about entire micro frameworks we could build for this." 

Nico Caballero (Technical Manager, Qualabs) went in a completely different direction. He'd spent time with Qualabs' operations manager helping her automate something she did manually every week — pulling the staffing meeting transcript from Drive, running it through a custom template, and dropping a draft into her Slack DM before it goes to the team. Small thing, real impact, already running every Monday.

Alex Leschinsky (Co-Founder & CEO, G&L Systemhaus) had two things going at once that couldn't be more different. On one side, the not-so-fun part: trying to write an AI policy that stays ISO 27001-compliant when the technology changes faster than any sentence can keep up with. On the other, something he's genuinely into — a project he's been building since November where he feeds video specs (H.264, DASH, AV1, and more) into a dual-LLM framework that converts normative statements into Prolog for deterministic bitstream validation.

What is spec-driven development with AI, and why does it matter?

One thread that came up independently from multiple panelists was spec-driven development — the practice of writing a specification before generating any code, and treating both the spec and the implementation as living, iterative documents rather than a one-shot handoff to the model.

It's not a formal methodology. It's more like a discipline that emerged from experience: the engineers who stay most meaningfully in the loop are the ones who don't skip the planning step.

Christian's version: write docs, generate code against them, clear the context, test whether the output actually works, give feedback, iterate — then go back and refine the docs based on what you learned. Not write-spec-then-ship. A loop.

Casey's version is lighter, but same idea: write a spec, ask for an implementation plan, push back on it until it makes sense, then execute. The thing he noticed most? The planning step — the one that always got skipped before — now actually happens.

What spec-driven development with AI looks like in practice

• Write a spec before prompting for code, even a rough one
• Ask for an implementation plan first and review it before any code gets written
• Write tests upfront — it forces you to define what "correct" actually means
• Clear context regularly — long sessions drift from the original intent
• Treat the review as the real work, not a formality at the end

The cognitive shift nobody warned developers about

Nico Caballero said something mid-session that landed hard and sparked the longest conversation of the day. The work hasn't gotten easier. It's shifted. Before AI, there was a clear rhythm: understand the problem, sketch the architecture, implement. With AI, that boundary is gone. Design now happens while you're reviewing what Claude generated. You're not writing code anymore — you're making hundreds of micro-decisions, fast, without pausing.

"The work didn't get easier — it became fully cognitive. There's a kind of fatigue I'm starting to notice that didn't exist before." — Nicolás Caballero, Technical Manager @ Qualabs

Christian connected this to what it's like managing junior developers — except the AI responds instantly to every change request, which creates its own psychological pressure. There's no natural pause in the loop.

Alex described hitting a ceiling around 20 parallel agent sessions and settling back to 10. The real challenge, he said, isn't the parallelism — it's that agents fully adopt your personal style. Rolling that out to a team of 20 or 30 developers without losing alignment is a harder problem than it first appears.

Adrian Roe (CEO, Id3as) added something that resonated with the room: a lot of developers chose this profession because they love the craft. The artisan part of it. And that's quietly changing. You're suddenly a manager of very fast processes, context-switching constantly, rarely going deep on one thing the way you used to. That shift deserves more honest conversation than it's getting.

How AI is changing open source maintenance

Casey and Christian both maintain widely-used open-source video libraries, Common Media Library and video.js respectively. AI hits differently when you're a maintainer with a day job.

Casey described how reviewing the C2PA implementation that Qualabs contributed, eight interlocking specs, heavy cryptography, became possible in a reasonable timeframe because he had an assistant that could research and summarize as he went. Documentation and tests that used to get skipped now get written. The work is more thorough than it was before.

The concern: AI-generated pull requests that look correct at a glance but weren't really thought through. Casey has heard from other maintainers that it's starting to happen. Nobody on the panel had a clean answer for how to handle it at scale.

Adrian Roe (CEO, Id3as) brought up Tailwind CSS as a concrete case. Usage has exploded over the past year because AI is extremely good at generating Tailwind. Revenue has fallen because fewer people need the paid product when the AI handles it. The market behaving rationally at the local level, while quietly eating the ecosystem that makes the whole thing possible.

How Qualabs is building AI into its engineering culture

Nico Caballero shared what Qualabs has been building internally — and the core bet is on organic adoption rather than centralizing AI expertise in a small group.

The idea: engineers should learn from the engineers sitting next to them, not from a dedicated AI team they have to go ask for help. To make that real, Qualabs launched an internal AI lab and an ambassador program — one person per team whose role is to surface use cases, share patterns, bring guardrails, unblock teammates, and translate new capabilities into something immediately useful for the current sprint.

One thing worth saying plainly: the review bar for AI-generated code should be higher than for human-generated code, not lower. It looks correct by default. That's exactly why it needs more scrutiny. And accountability stays with the person who commits — our name is on that commit regardless of what wrote the code.

What Qualabs' ambassador program looks like

• One AI ambassador per team — not a centralized group everyone depends on
• Ambassadors surface use cases and translate cutting-edge concepts into sprint-level actions
• Higher review bar for AI-generated code, not a pass because the model wrote it
• Smaller commits, tighter feedback loops
• Organic adoption over top-down mandates

Five things that stuck with us

1. AI amplifies what you already bring to it. Everyone has access to the same tools. The quality of the output depends on the knowledge and craft behind the prompt. As Alex put it: it's like giving a knife and a piece of wood to someone who can carve — and to someone who can't. Same tools, very different results.
2. Spec-driven development is worth the upfront time. Writing a spec before coding keeps you in the loop, surfaces problems earlier, and produces output that actually matches what you meant to build. It also makes the planning step — which used to get skipped constantly — finally happen.
3. The cognitive shift is real and underappreciated. The fatigue of constant review at high speed is different from the fatigue of writing code. The loop never pauses. That's something the industry needs to start talking about more honestly.
4. Organic AI adoption scales better than centralized expertise. Engineers learning from engineers creates more durable fluency across a team than a small group of specialists everyone has to go through.
5. Think about how AI will consume your code, not just write it. If you work on libraries, LLMs are increasingly a user persona. That changes how you should think about documentation, naming conventions, and structure — not just how you write code today.

We started with a simple question and ended up somewhere more honest than panels usually go. That's exactly what we were hoping for.

Thank you to Alexander, Casey, Christian, and Nicolás for bringing real takes, not polished ones. And to everyone who joined, raised their hand, and made this the kind of conversation that actually moves things forward. 💚

See you at the next one. 🇺🇾