The critic loop: how to make Claude review its own video frames

If you read enough of the long posts creators wrote about making video with Claude in late 2026, one habit shows up in every account that explains a good result: the model watched its own output. Not the code. The frames. The first render was never the final one.

That habit is the subject of this tutorial. It is the step most people skip, because the first render arrives quickly and feels like progress, and it is the step that turns a "bit mid" clip into something people bookmark. Here is how to set it up so Claude does most of the reviewing and you only make the calls that need taste.

Why the model needs to see its own frames

When Claude writes a video as code, it has an idea of the film in mind, and the code is its attempt to express it. The two drift apart. Text wraps onto a third line. A card lands behind a label. One frame of a rotating part turns into a black disc because of a sign error at one angle. The model cannot know any of this from the code alone, any more than you could proofread a page by reading its HTML.

Claude reads images, and Claude Code can run ffmpeg and a browser. Put those together and the model can look at exactly what the viewer will see, compare it with what it meant, and fix the difference. seeco (@seeconvm), who took dozens of the viral clips apart, put it plainly: this one habit was what the clips that blew up had in common.

Rule zero: frames must be reproducible

A review loop only works if the frame you review is the frame you ship. That means the film must be a pure function of time: a seek(t) or render(t) that paints frame t with no timers, no CSS transitions, no state carried between frames, and no unseeded randomness. Several creators include a determinism test in their checks: render frame 300 twice and confirm the image hashes match. If they do not, fix that before anything else, because every later comparison is meaningless.

A determinism check

const a = await shotAt(10.0);   // seek(10) then screenshot
const b = await shotAt(10.0);
const h = (buf) => crypto.createHash("sha1").update(buf).digest("hex");
if (h(a) !== h(b)) throw new Error("frame 10.0s is not deterministic");

The evidence pack: what to render for review

Do not ask Claude, or yourself, to watch a full export ten times. Have ffmpeg build a small pack of images that each answer one question. Between them, the published methods converge on five.

Building the pack with ffmpeg

# contact sheet, 2 fps, 6 across
ffmpeg -i out/film.mp4 -vf "fps=2,scale=320:-1,tile=6x8" -frames:v 1 review/contact.png
# phone test, every 3 s at 360 px wide
ffmpeg -i out/film.mp4 -vf "fps=1/3,scale=360:-1,tile=6x4" -frames:v 1 review/phone.png
# 12 consecutive frames around the fastest move (starting at 6.2 s)
ffmpeg -ss 6.2 -i out/film.mp4 -frames:v 12 -vf "scale=360:-1,tile=6x2" review/strip.png

• A contact sheet: two frames per second (or one per beat), tiled six across. Answers: does something new happen every few seconds, and does the whole film hang together?
• A motion strip: twelve consecutive frames around the fastest move. Answers: does the move ease, overshoot or ghost?
• A phone test: frames scaled to 360 pixels wide. Answers: can a viewer read every word on a phone?
• A loop check: the clip played twice back to back, or the last and first frames compared. Answers: does it stutter at the seam?
• A pixel-difference scan over every frame of every move. Answers: is there a single frame that jumps?

The pixel-difference scan

Some faults are invisible in stills and obvious in motion: a single frame where an element blinks to the wrong place. The cleanest detector comes from Elvar's anatomy method: count how many pixels change between each pair of consecutive frames, and flag any frame that changes about three times more than its neighbours. He reports a lever that, for one frame at one angle, changed over 95,000 pixels when its neighbours changed around a thousand. zero (@twoclipping) builds the same scan into his launch film prompts as a check for single-frame pops.

Flag frames that jump

import numpy as np, imageio.v3 as iio
prev, diffs = None, []
for f in iio.imiter("out/film.mp4"):
    f = f.astype(np.int16)
    if prev is not None:
        diffs.append(int((np.abs(f - prev).sum(-1) > 24).sum()))
    prev = f
for i in range(1, len(diffs) - 1):
    local = max(1, (diffs[i - 1] + diffs[i + 1]) / 2)
    if diffs[i] > 3 * local and diffs[i] > 2000:
        print(f"possible pop at frame {i + 1}: {diffs[i]} px")

Expect false positives at hard cuts, where a large change is intended. Pass the cut list to the scanner and skip those frames.

The critique prompt: scores, three worst, local fixes

Hand the pack to Claude with a prompt that has teeth. The pattern that recurs across Raphael Aubry, Movez and seeco is the same: judge only the rendered frames, ignore what you meant; score on a fixed set of criteria; list the three worst defects with timestamps and evidence; fix them locally; re-render only the affected seconds; repeat until every score clears a bar. Raphael's line for the tone is "Be a harsh motion director, not a proud author."

Critique prompt shape (our wording)

Open review/contact.png, review/strip.png and review/phone.png.
Judge only what is rendered. Ignore what the code intended.

Score 1-10, one line of evidence each:
  hook in the first 2 s
  readability at phone width
  motion quality (eases, overshoot, ghosting)
  variety (something new every 2-4 s)
  composition (nothing cropped, nothing overlapping)
  accuracy (every number and claim is real or labelled)
  sound sync (cuts and hits on their beats)

List the 3 worst defects: timestamp, what you see, a local fix.
Fix those, re-render only the affected seconds, rebuild the pack.
Stop when every score is 8 or higher, and tell me what changed.

Things this loop catches, from the published accounts: letters overlapping in an intro, a headline clipped by a shape, chips stacked on top of each other, text blurring during a handoff, a colour flood so fast it reads as a flash, a gauge hidden behind another part, a long purple shadow nobody asked for.

Use a reviewer that did not make the film

An author reviewing their own work sees what they meant. Two creators address this directly. The huashu-art-motion skill described by Vox sends a subagent that took no part in making the film to watch only the finished film and write findings to a review folder, after its own QA script. And beamnxw's launch video method suggests opening another session with only the brief, the images and the extracted frames, having it propose up to five frame-specific corrections, and passing the accepted ones back to the builder.

In Claude Code you can do this with a subagent or simply a second terminal. The important part is that the reviewer gets the brief and the evidence, not the code or the author's reasoning.

Automatic blockers before a human looks

Some faults are so common that they deserve a hard check rather than a judgement. The same skill blocks delivery when a film has stretches where almost nothing moves, when there are 0.3 seconds or more of blank frames in the middle, and when a blue-purple background fills more than 30 percent of the film, a palette it treats as a giveaway of default AI styling. You can write your own blockers in a few lines: frames with near-zero difference for too long, captions outside the safe area, text smaller than a minimum size at phone width, audio silence over a threshold.

Scoped corrections: where, what, change, keep

When you or the reviewer find a problem, phrase the fix so the agent cannot wander. Both Dumble's 2.5D course and beamnxw use the same four fields: where (the frame range), what is wrong (observed, with evidence), what changes (only this), and what must stay fixed. Then ask for stills at the key frames and a short preview of the range, and a report of what changed. A scoped edit stops a fix in shot 18 from quietly breaking the camera in shot 19.

A scoped correction

WHERE    frames 204-222
PROBLEM  the cursor overlaps the result label at frame 210
CHANGE   only the cursor's path after the press: rest 24 px
         clear of the label by frame 210
KEEP     press at 195, reveal at 210, card geometry, copy, audio
THEN     stills at 195, 210, 222; preview 180-249; list the
         changed coordinates and output files

Fix in the right order

The order matters because later fixes are wasted if an earlier class of problem forces a rebuild. The sequence both methods recommend: first anything wrong or missing (a false claim, a missing screen, a broken frame), then readability, then timing, then visual detail. Polishing an easing curve on a shot whose copy is about to change is the most common way to lose an afternoon.

Stills before renders, animatics before full passes

The cheapest review is the one that happens before animation. Ask for a handful of stills at key moments before writing the full film, and for longer pieces an animatic at reduced resolution with placeholder audio. Raphael Aubry's stills caught a blur bug in two minutes that would have cost a ten minute re-render; at high subframe counts a full render can take a minute or more per second of film by his measurement. Seeco's gate list for overnight runs puts stills and an animatic as separate approvals before the full pass.

Do not forget to listen

Most review loops are visual. Sound needs one too. Seeco's "blindfold test" is simply to listen with your eyes closed: if the audio has no shape without the picture, the sound design is unfinished. Dumble recommends earshot, an open-source tool that lets an agent listen to and review its own mix. At minimum, check that the voice is always on top, that hits land on their frames, that no effect repeats so often it becomes wallpaper, and that the music resolves on the last frame. Our post on beat sync and sound design covers the measuring side.

How many rounds to expect

The honest accounts are consistent: more than one. Raphael Aubry's own launch video took five versions. Mickey Friedman, whose animated JavaScript illustration drew wide attention, said in replies that she used hundreds of prompts and placed every object herself. Movez cites a watercolour short that took 163 model calls and nearly seven hours as the honest counterweight to one-prompt captions. A simple film with a good brief may need two or three review rounds; an ambitious one many more.

Pitfalls

• Reviewing the code instead of the frames.
• Letting the author grade itself without a fixed rubric.
• Asking for "make it better". You will get random changes.
• Re-rendering the whole film for a local fix.
• Fixing detail before content: polishing a shot whose copy will change.
• A non-deterministic render, so the frame you reviewed is not the one you ship.
• Never checking at phone size, where most viewers will see it.

Cost and time

The checks themselves are nearly free: ffmpeg and a few lines of Python. The cost is Claude usage on each critique round and the re-renders. It is cheaper than it sounds, because a scoped re-render of two seconds costs a fraction of a full pass, and because stills catch most problems before any motion is rendered. Our measured token costs for agentic Claude Code sessions are in what a Claude video costs.

Doing it in about 3 minutes with WhatToUpload Video Studio

Video Studio is built on the same deterministic idea, packaged so you do not run the loop yourself. You write one sentence; Claude writes the script and storyboard; our renderer draws every frame as code from tested style templates; ElevenLabs voices it; captions and sound are timed. A video takes about three minutes, and a failed render refunds its credits automatically.

The styles live today are Kinetic type, Ink stickman and Diagram explainer, with more being added. A 30 second video is 26 to 30 credits, and plans are $19, $49 and $99 a month.