Simon Willison built a video compressor with Claude Fable 5.1 and FFMPEG WASM in one session — here's what the stack actually looks like

Simon Willison recorded a demo video on his phone yesterday. He wanted to publish an optimized version on his blog. Instead of opening a terminal and writing FFMPEG flags, he had Claude Fable 5.1 build him a web tool that does the compression client-side using FFMPEG's WebAssembly build.

One session. Production-ready output. The tool is live at tools.simonwillison.net/video-compressor.

This is the stack pattern that's replacing the "write a script" workflow for a meaningful chunk of technical tasks in 2026. Not because the agent is smarter than the operator — Simon knows FFMPEG cold — but because the agent can wire up the UI, the file handling, the multiple export formats, and the WASM build all at once. The operator specs the job; the agent writes the glue.

What the tool actually does

The compressor takes a video file, runs it through FFMPEG compiled to WebAssembly, and outputs three versions: H.264 MP4, H.265 MP4, and WebM VP9. All client-side. No upload to a server. The WASM build of FFMPEG means the entire encoding pipeline runs in the browser.

This is the pattern we see repeatedly in Claude Code for web and ChatGPT Work sessions: the agent doesn't just write the core logic, it scaffolds the entire tool. File picker, progress indicator, download buttons, format selection. Simon didn't ask for those individually; the agent inferred the standard UX for a video tool and built it.

The WASM constraint is the interesting part. FFMPEG is a 20-year-old C codebase with hundreds of codec options and a notoriously dense CLI. The WebAssembly build exposes a subset of that surface. The agent has to know which flags are available in the WASM port, which aren't, and how to call the library through its JavaScript wrapper. That's not trivial lookup — it's multi-layer stack knowledge.

Fable 5.1 got it right in one pass.

Why this matters for internal tooling

We're seeing this pattern in client work too. Not video compression specifically, but the same shape: operator needs a one-off tool, agent builds the full stack, tool goes into production without refactoring.

Last month we had a client who needed a CSV transformation UI for their ops team. The transformation logic was 40 lines of JavaScript. The surrounding tool — file upload, preview table, error handling, export — was 400 lines. The agent wrote all of it. The client's engineer reviewed the logic, shipped the tool, and the ops team has been using it daily since.

The economics flip when the agent writes the glue. Before, you'd spec the tool, write the logic, realize you need error handling, realize you need preview, realize you need undo, realize you need batch mode. Each realization is another hour. With the agent, you describe the job and the agent scaffolds the standard UI in the first pass. Review time stays the same; build time drops by 3-5×.

This is why we're shipping more internal tools per client engagement in 2026 than we did in 2024. The constraint was never "we don't know what tools would help" — it was "we don't have time to build them." Agents removed that constraint.

The WASM build matters

The WebAssembly angle is worth calling out. FFMPEG compiled to WASM has been available since 2019 via ffmpeg.wasm, but adoption stayed niche because you had to learn a completely different API than the CLI. The mapping wasn't obvious.

LLMs trained on GitHub know both the CLI syntax and the WASM wrapper. They can translate between them. That's the unlock. Simon describes the job in FFMPEG CLI terms — "compress this video using H.264 with a target bitrate" — and the agent writes the WASM equivalent. The operator doesn't need to learn the WASM API at all.

This generalizes. Any C library with a WASM port becomes trivially usable through an agent that knows both the C API and the WASM JavaScript wrapper. SQLite WASM, ImageMagick WASM, Postgres WASM — they all follow the same pattern. The agent is the translation layer.

We built a client tool last quarter that uses sql.js (SQLite compiled to WASM) for client-side query execution over large CSVs. The client's team had never touched SQLite WASM before. The agent wrote the entire data loading pipeline, the query execution layer, and the result rendering. Shipped in 3 days. That's the WASM + agent pattern in production.

What this replaces

The old workflow for "I need to compress a video for the blog" was:

1. Open terminal
2. Look up FFMPEG flags (or retrieve them from shell history)
3. Run the command
4. Realize you wanted multiple formats
5. Run three commands
6. Rename the outputs

The new workflow is: describe the job to the agent, review the tool, use the tool every time you need it going forward.

The value isn't just the time saved on the first compress. It's that the tool is reusable. Simon will compress 50 more videos this year with that same UI. He didn't have to learn WASM. He didn't have to write the JavaScript. He reviewed 200 lines of code once and now he has a bookmarked tool.

This is the pattern that's quietly eating "script in a gist" workflows. The agent builds the full artifact, not just the core logic. The operator gets a tool, not a snippet.

The stack here is Claude Fable 5.1 running in Claude Code for web, calling FFMPEG via the ffmpeg.wasm library, rendering a React UI with file pickers and progress bars. One session, production output, live on the public internet. That's the 2026 tooling stack.