Films made in code

I was sent a brief for an AI "motion director": an agent that designs, animates, scores and checks a finished film entirely in code. It's one of the better prompts I've read, and not really because of the film part. It's a complete recipe for getting work you'd show a client out of an agent, and almost every rule in it maps onto how we already try to build software.

The brief was shared as a screenshot and I don't know its author. What follows is my reading and summary of it, plus how I'd run it here. None of this has been built yet.

1. The bar: finished, not bug-free

The brief opens with the line that sets everything else up: a film with no bugs isn't finished; it's finished when it holds up next to the best work in its genre. That's a higher bar than most agent prompts set, and it's the right one. "It runs" is the floor. An agent that stops at the floor hands you something you then have to finish yourself, which is most of the work.

The same idea is in our testing standards: a 200 alone proves little. For a film, a clean render alone proves little.

2. Decide the brief before touching pixels

Every project starts by filling in a short form: mode, subject, viewer, end state, length, frame rate, brand, facts, assets, style, sound, autonomy, toolchain and sign-off. Any blank the agent fills itself, writing down the choice and a one-line reason. That's section 1 of AGENTS.md ("state your assumptions out loud") turned into a form.

Two fields stand out. End state asks what the viewer should feel, know or do in the last second, which is the film's acceptance test. Autonomy is either unattended or gated, with gates after the storyboard, the style frames and the audio mix: the three points where a person's taste is cheap to apply and expensive to apply later.

It names four modes, each with its own pacing:

3. Facts and assets come from the source

Every claim on screen or in the voice-over goes into facts.json with its exact source sentence and URL. No fake clients, logos or metrics. Anything generated is labelled as concept. This is the film version of our rule that every claim in a proposal links to its source.

Assets follow the same honesty. Capture the real product at 2x, take the logo as SVG from the source, sample the real colours and fonts, and never redraw a logo. The rule I like most: never show a raw screenshot. Rebuild the panels, icons and text as live HTML or SVG so each part can move. A screenshot is a dead slab; a rebuilt UI is something the camera can fly into. Reference films are for study only, through frame-difference passes and contact sheets, never for copying footage, layouts or music.

4. Craft, in eleven rules

The craft list reads like notes from a good motion designer. Condensed:

1. Frame one is a finished picture that works as a still on a busy feed. The hook lands in the first second.
2. One object, shape or word carries the film and lands on the same pixels on both sides of every handoff.
3. Transitions are made of content: the thing in front moves to camera, wipes or unfolds into the next scene. Hard cuts only when size, direction and subject match, and only on a beat.
4. One lead movement with overlapping secondary ones. Nothing starts or stops all at once.
5. Speed always changes. No linear easing; use anticipation, follow-through, squash and stretch, springs and arcs.
6. Every action has a visible result.
7. Type is motion, not captions, kept on screen about 0.3 s per word, and never over a busy picture without a plate. If the picture says it, cut the word.
8. Vary scale and layout. Never repeat one.
9. Holds breathe with micro-motion; nothing freezes.
10. 3D only where it explains something spatial.
11. Every effect earns its place. No decorative particles, generic gradients or stock glitches.

Rule 11 is section 2 of AGENTS.md in a different medium: no features nobody asked for. An effect that doesn't explain anything is speculative code.

5. Sound first, picture cut to it

Audio comes before animation. Music sits low and matches the energy; beats, the drop, voice in and out, and key actions are detected and written to timing.json, and every animation reads its timing from that file. Effects only mark real on-screen events: one soft whoosh per scene change, clicks and impacts on real actions. The mix lands around −14 LUFS with true peak at or below −1 dBTP, and a music-only version is exported too.

Making the timing a file rather than numbers scattered through scenes is the data-structures-first idea from section 7: get the data right and the code mostly writes itself. Change the track and every scene re-syncs.

6. Why "every value is a function of the frame number" matters

This is the technical heart of the brief. Everything lives on one timeline in code, with pinned local fonts and assets, rendered frame by frame and encoded with ffmpeg. No timers, no unseeded randomness. Each scene is a pure function: give it a frame number, get back exactly one picture.

That one constraint buys a lot:

• Reproducible. Render frame 412 twice, on two machines, a month apart, and get the same pixels. A bug report can name a frame.
• Parallel. Frames don't depend on each other, so a two-minute film splits across as many processes as the box has cores (twelve-factor rule 8: scale out with processes).
• Inspectable. A critic can ask for any frame, or every fifth of a second, without playing the film. Contact sheets and frame-difference passes are just loops.
• Diffable. The film is source code in git. A change to one ease curve is a one-line diff, and a re-render proves it.

The drawing itself has to happen in a browser engine, since that's where HTML, SVG, CSS and fonts render well, so the scenes are JavaScript (Remotion, or plain HTML with GSAP, are the toolchains the brief names). The orchestration around it is plain Ruby: read the brief and timing, drive a headless browser one frame at a time, and pipe the frames to ffmpeg.

// scene.js: a frame number in, one picture out
export function title(frame, t) {
  const p = spring(frame - t.beats[0], { stiffness: 180, damping: 14 });
  return { y: lerp(40, 0, p), opacity: p, scale: lerp(0.96, 1, p) };
}

# bin/render: frames from the browser, straight into ffmpeg
Open3.popen2("ffmpeg", "-y", "-f", "image2pipe", "-framerate", fps.to_s, "-i", "-",
             "-i", "mix.wav", "-c:v", "libx264", "-pix_fmt", "yuv420p", "-shortest", out) do |stdin, _|
  (0...frame_count).each { |frame| stdin.write(browser.screenshot_at(frame)) }
end

Sketches, not working code. The brief also asks for a 3 to 5 second test rendered end to end before any real work, which is the cheapest way to find out the pipeline breaks.

7. The builder never judges its own work

The part that makes this more than a style guide is the critic loop. After the storyboard, after each scene and after each full render, a fresh critic agent that has seen none of the building pulls its own frames (every 0.2 s, denser around transitions), measures them, and returns ranked problems with timestamps, ending in "ship" or "one more pass". Every full render also gets:

• A sound-off read. A critic sees only a silent 2 fps contact sheet and retells the story. If it can't, the picture isn't doing its job.
• A sync check. Every hit and line within one frame of timing.json.
• A fact check. Every word traced to facts.json.
• A director's review. A brutal critique of what feels assembled, slow or generic.

The builder fixes the biggest problem first, re-renders, and a new critic rechecks every earlier item. Each round goes in ledger.md with before and after numbers.

This is the rule from our testing standards, applied to taste: the same generation is never the only judge of its own correctness. A builder that has stared at a scene for an hour can't see it any more. A critic with no context sees what a viewer sees. Starting a fresh one each round matters too; a critic that watched the last round starts grading on effort.

8. A quality bar you can measure

The brief ends with a release gate, and most of it is numbers a script can check:

And one judged item: a critic would put it beside the references without it looking weaker. The measured checks keep the judgment honest; the judgment keeps the measured checks from becoming the goal.

9. Where it fits our platform

The threads workspace we're building for Claude Code, Codex, Kimi and local models is a good home for this, because the brief is already shaped like our threads:

• A film is a thread. It owns a task, runs for hours, and ends with a result: the render, a music-only mix, and the ledger.
• Builder and critic are different agents, ideally different providers. If Claude Code builds, Codex or Kimi critiques, and next time they swap. Different models miss different things, and it's the two-providers rule from Own your stack earning its keep.
• The workflow steps are the status checklist. Facts, references, concept, storyboard, style frames, audio, build and critic rounds, deliver. The brief's eight steps are exactly what a person skims.
• Gates are approvals. "Gated" autonomy stops after the storyboard, style frames and audio mix and waits for a yes, the same way a feature proposal waits.
• The ledger is telemetry. Rounds, problems found and fixed, render time and token cost per provider go to observability, so we can see which critic catches the most and what a finished minute of film costs.

The bigger lesson isn't about video. Any job we hand to an agent gets better with the same five pieces: a written brief with decisions recorded, sources locked before work starts, output that's deterministic and inspectable, a critic that didn't do the building, and a bar with numbers on it. The brief also suggests saving the whole pipeline as a reusable skill once it works, and that's how I'd want every one of these to end.

Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.

Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.