Friday demos
Finding out what your AI team has really been building
Years ago I led a large development team. Every second Friday we’d get together for a retrospective; a quick whizz through plans for the coming sprint before we got to the best bit of the week - demos.
This was the chance for people to show what they’d been up to - what new features they’d implemented. Or bugs fixed. These were invariably live demos. Which added to the fun - would the feature work? Or would it crash?
As the lead these demos were an important part of helping me understand if the project was on track - were we delivering what was needed to hit the schedule. Where were the quality problems? Where should I focus my attention? What stones should I be looking under?
The lead of a large team doesn’t have time to review every design, never mind every line of code. So they need to develop proxies. Ways to understand the state of their project when they don’t - can’t - understand all the detail. For me, these demos were one of my proxies.
AI team reporting
These days I lead a large team of AI agents. And face the same problem - how do I know what has happened in the codebase? How do I know if it is any good? Could I get an AI to produce a demo for me? Could I get it to make a little video to show me what it had been up to? Only one way to find out :).
Over the past month, I’ve had some agents building a replica of Minecraft in Rust. I’ve happy memories of playing Minecraft with my kids when they were younger. But I disliked the fact it wasn’t written in Java - having to wrangle JVM versions and manage memory made it feel more like work than play. So it seemed obvious to have a go at reimplementing in Rust. No more JVM. No more garbage collection.
I asked Claude to produce a little video to demo what it had built. And it was only too happy to oblige. Here’s what I got:
Clearly Claude needs to work on selling. And explore more of the world. But the basic concept works - I got a demo video with text-to-speech.
And the video did its job - it got me concerned. What has Claude been doing? I want - need - to know more. This project isn’t going as well as I hoped.
As AI becomes more autonomous, getting it to report on activity and progress becomes increasingly important. We’ll need to develop all sorts of ways to get insights into what our AI teams are up to.
As an another example, Claude now creates a weekly report of what it and Codex have been up to. It mines my github, the Claude Code & Codex tracking files, journals, designs, uncommitted local work. It’s just like the weekly status reports my team used to send me. Except - and I hate to admit this - it’s better quality. The analysis is crisper, there’s more detail, the ordering is right. I would have loved my team to produce reports like this.
And so?
I’m an IC who spends their days managing. Reviewing reports. Watching demos. Prioritising what to look at next. Developing proxies to understand work I haven’t done myself.
These aren’t coding skills. They’re the skills I developed over 25 years as a team lead and engineering director - the ones I thought I was leaving behind when I went back to being a developer. Turns out they’re exactly what I need now.
Right now, getting the most from AI coding tools requires management skills. Learning what the models can do well - and what they can’t. Knowing how to brief. Knowing what done is. Knowing how to check on progress. The technical know-how matters less than it used to. The "spidey" senses matter more.
Last week Kimi released V2.5 with built-in swarm support - one agent orchestrating others. Claude Sonnet V5 is imminent. And rumoured to have the same. The AI is moving into first-line management, which pushes us further up the stack.
I spent years learning to be a better coder. Maybe I should have been learning to be a better manager.