Why does the motion design everyone makes with Opus 5.5 end up looking the same?
Big centered text, a gradient background, everything fading in, a logo slapped on at the end.
Only after reading @N01ennn’s long post did it click for me: the prompt is just a small part. Whether the final video is any good depends on the layer around the model: rules, checks, loops. The motion design, harness engineering and loop engineering everyone’s been talking about lately are really the same thing.
Quoted post: https://x.com/i/status/2107826459804840072
Let me break it down.
-
Where the motion comes from
What Opus writes is code: a draw(t) function that, given any point in time, draws that exact, deterministic frame. A headless browser screenshots it frame by frame, and ffmpeg stitches the frames into a video.
Each frame depends only on time, and rendering the same frame twice gives exactly the same result, so it can be checked automatically.
This also means you need an environment that can run commands, like Claude Code. If the code is only written out in a chat box, it can’t render or review the frames. -
Harness: the rules and checks wrapped around the model
It comes from Birgitta Böckeler’s framework on http://martinfowler.com, and it has two halves:
- guide: constraints before it starts. Rule files, style guides, storyboards, brand assets
- sensor: checks after it’s done. Deterministic checks run by scripts (frame hashes, loop seams, tests), plus inferential checks judged by a model (having Opus look at thumbnails of the frames it rendered and score them)
Every time you hit a pitfall, the rule file gains another banned item, so it gets more reliable the more you use it.
-
Loop: let it keep running until it passes
The term only showed up this June. One paper has a spot-on analogy: the harness is the engine, the loop is the driver.
Depending on how much you hand over, loops come in four levels: a human reviews every round → hand over the stopping condition → hand over when it triggers → hand over even the prompt.
Claude Code’s /goal is the second level: at the end of each round, a small model checks whether the completion condition has been met; if not, it keeps going, and you can also cap the number of rounds. -
Four steps you can copy directly
① Write a CLAUDE.md or AGENTS.md: conventions, banned default habits, definition of done
② Add two checks: a script that runs on every change, and a model check with its own separate review instructions
③ Wrap it in a goal: a stopping condition a machine can judge + a cap on rounds + abort when there’s no progress
④ When the same problem shows up twice, fix the rules and checks, don’t just patch this version
A common pitfall:
Just letting the model revise over and over based on its own gut feeling brings almost no improvement. The gains only become obvious once you hook up hard checks like tests and schemas. Any metric that can be written as a script, write it as a script.
-
Why Opus 5.5
Official numbers: it reaches Fable 5.1 level on most tasks, at an overall cost 40% lower than Opus 5. Because it’s cheap, you can afford to let it run over and over; because it can see images, it can check its own frames. -
What it’s good for
UI demos, kinetic text, data visualization and product feature explainers all work well. If you’re in e-commerce, you can use it directly for animated selling points on product pages and feature demo videos.
For realistic videos of people, still leave that to video models.
What would be the first banned item in your CLAUDE.md?
