Every time I shipped a side project, the same wall showed up at the end: the demo video. The thing people actually watch before they read a word. And the normal way to make one is miserable.

You open a screen recorder, rehearse the clicks, fluff a take, redo it. You drop the clip into an editor, trim, add a caption, render. The export looks soft because a video codec compressed your crisp UI into smears. You spot a typo in the third second, and now you re-record the whole thing. A two minute clip eats an afternoon.

So I stopped recording my screen. Here is what I do instead.

The demo is a webpage

The trick is to stop treating the screen as the source of truth. The screen is a lossy copy of something. Make that something a file you control.

I write the demo as a single HTML page. CSS animations for the motion, a tiny JavaScript timeline for the choreography. A dashboard fades in, a chart draws itself, a row slams into place, a number counts up. None of it is a recording of a real app. It is a reconstruction of the app’s interface in its own colors and fonts, built to play on a clock.

Two things make this page recordable rather than just pretty.

First, one knob controls all the timing. Every duration in the CSS reads calc(var(--d) * 0.6s) instead of a hard 0.6s. Set --d to 1 and it plays at normal speed in the browser. Set it to 7 and the whole demo crawls, uniformly, every transition stretched by the same factor. That single variable is what lets me slow the motion down later without re-timing anything by hand.

Second, the page reports where it is. A small script schedules each beat with at(ms, fn), exposes the current animation time on window.__t, and flips window.__demoDone to true at the end. So a script driving this page always knows the exact frame it is looking at and when the show is over.

Claude Code drives the browser

This is where the Playwright MCP comes in. I ask Claude Code to open the page in Chrome, crank --d up so everything plays in slow motion, and then sit in a loop: grab a frame, check the animation clock, grab the next frame, until the page says it is done.

The frames come out through Chrome’s DevTools protocol as plain JPEGs, not through a video encoder. That is the whole point. There is no codec in the capture loop, so there is no compression smear. Each frame is stamped with the window.__t value it was taken at, so I know its real position on the timeline rather than guessing from a frame count.

The slow motion is not for looks. The capture runs at about eleven frames a second, which would be a stutter at real speed. But the page is playing at fifteen percent of normal, so those eleven real captures cover a sliver of actual motion. Stretch them back out and you get more than seventy distinct frames for every second of final video. You are sampling the animation far denser than the output needs.

ffmpeg puts it back together

Now I have a folder of JPEGs and a timestamp for each one. I hand ffmpeg the list with each frame’s real duration and ask for a constant sixty frames a second, H.264, high quality.

Because the captured frame rate is higher than sixty, ffmpeg picks real frames to land on each output slot instead of duplicating one or inventing a blurry in-between. The result is genuine sixty frames a second of motion, built entirely from frames that actually existed, so the interface stays sharp and nothing smears.

If I want sound, ffmpeg muxes a CC0 track underneath, trimmed to length with gentle fades and normalized so the music sits under the visuals instead of fighting them. A few seconds of the best beat get pulled out as a looping GIF for social.

What this buys you

Here are three reels made this exact way. Each one reconstructs a product’s real interface and plays it on a timeline, captured frame by frame, never recorded.

The reason I will never go back: it is code, so it is repeatable. A stat is wrong? Change a number and rerun. A beat feels rushed? Nudge one timestamp. Want the same demo for four different products? Loop over four pages and render them all while you make coffee. There is no take to redo and no quality lost to another export.

The studio is a browser. The editor is a script. The footage never touches a codec until the last step, so it stays sharp the whole way through.

Next

I am writing one of these a week: how I actually work with AI as a senior engineer, and the small mechanical tricks that turn out to matter. If that sounds useful, subscribe and the next one lands in your inbox.

One question back to you, because it shapes what I write next: what is the last thing you made that took an afternoon and should have taken ten minutes? Reply and tell me. I read every one.

Ten years in, mostly at startups, I write less code by hand than at any point in my career. Not because I stopped caring about the craft. Because I found a better seat: the one where I decide what gets built and whether it is good enough to ship.

I work with AI every day now. Not as a magic box I type wishes into, and not as autocomplete. I work with it the way I would manage a sharp, fast, slightly overconfident junior engineer. That one shift changed how much I can build, and it is what this newsletter is about.

Here is what it looks like in practice.

I hand over goals, not keystrokes

A junior does their best work when you give them a clear outcome and the constraints around it, then get out of the way. “Build the admin dashboard for my projects. Here is the data model. Make it boring and reliable.” Not “create a file called route.ts and add a GET handler.”

So I delegate at the level of intent. I say what done looks like, what it must not break, where the edges are. Then I let it run. The good ones surprise you with how far they get from one good sentence.

I review like it is my name on the commit

Delegation without review is just hoping. The first pass, from a junior or a model, is often wrong in a way you only catch when you look at the actual result. A loader that never appears. A layout that breaks at the one width you forgot. A feature that is “done” but quietly half-wired.

So I stay close as the quality gate. I read the diff. I run the thing. I look at the rendered screen, not the description of it. When it takes a wrong turn, I catch it early and redirect in a sentence, instead of letting it pour another hour into the wrong idea. A confident wrong move I can correct beats ten minutes of hedging.

I make it prove the work

The highest-leverage instruction I give is simple: do not tell me it works, show me. Take the screenshot. Run the test. Open the page and click the thing. A junior stops saying “should be fine” once you ask for proof every time. A model is no different. “Verify it end to end before you call it done” turns a confident guess into a checked result.

I write the context down once

What makes a junior fast by month three is not raw talent. It is that they stopped needing the same explanation twice. The conventions, where things live, the things we never do: written down once, referenced forever.

I treat the model the same way. The standing instructions, the repeatable routines, the access to check real state instead of guessing, I put them in place once so I never re-explain. It is onboarding, and the payoff compounds.

What that buys

Working this way, in a month I shipped more finished things than I used to ship in a quarter. An admin dashboard for my whole project portfolio, with its own tool layer so the model can act on real data. A markdown-to-everywhere publishing tool. A keyboard-first database client. A mobile app. I usually have two or three of them running at once, each delegated, each reviewed.

None of it is magic. It is the same management I would give a person, pointed at something that types faster and never gets tired, and that still needs someone with taste deciding what good means.

What this is

I am going to write here, once a week, about how I actually work: the delegation, the reviewing, the small systems I build so the machine stays useful instead of just impressive. I will write about where I think tech is going, with opinions I am willing to be wrong about in public. And I will build my projects in the open, the parts that work and the parts that break.

If any of that sounds useful, subscribe. And tell me one thing to get us started: what is the last task you handed to AI that fell apart on you? Hit reply and tell me. That is what I want to write about next.

Florent