After Effects Is Still Rendering, Opus 5.5 Has Already Delivered the Video—but the Next One Is the Hard Part

After Effects' timeline is still spinning, while Opus 5.5 has already finished rendering. rari posted a video on X: the screen shows video editing software, the timeline is filled with multiple colored tracks, an orange block character sits on the left, and a tripod light and a cup are nearby. The video itself has already been exported.

There have been many similar shares recently. People are using Claude Opus 5.5 to make videos; a few are very good, but most look like the same demo: a big headline in the center, a gradient behind it, everything fading in, and finally the logo appears. After seeing enough of them, you realize the difference is not some secret prompt; it is the system outside the model.

Anthropic released Opus 5.5 on September 22. rari's assessment is that its coding ability and visual judgment make this workflow usable, but the model is only part of it. The more accurate pipeline is: the model writes a program, the program draws frames, the renderer encodes the frames into video, and the review loop decides whether the piece can be shown to people.

This brings a practical change: edits become local. If the title appears too early, change one timing value; if a shape overshoots too far, change one motion curve; if the product UI is wrong, swap the asset and re-render. You don't have to ask a video model to regenerate the entire shot and hope it remembers the previous version. Code-driven motion does not solve every visual problem—live-action-feeling scenes, complex characters, and organic motion may still need footage or generated video—but for product films, UI motion, data stories, typography, charts, and launch explainers, controllable frame functions have a clear advantage.

rari breaks the process into 10 stages. Asking Opus to spit out an MP4 directly from a one-line description skips the intermediate decisions. A more reliable approach is to turn each decision into an artifact, then move to the next step. The model fills missing decisions with the safest visual defaults, and that is how generic demos happen.

Start with a director's brief, not a mood prompt. What is the product, what is the one thing the audience should remember, which films are allowed as references, which elements must come from the real product, and what outcomes are unacceptable. The brief separates product facts from film choices. The model can invent camera moves, but it cannot invent your dashboard; it can propose a stronger opening, but it cannot quietly replace the logo. This boundary is more useful than a long string of adjectives.

Give the model references it can inspect. Without a visual grammar, it will use its own. Give it a frame, a short film, or an old project folder, and have it write out the style guide it learned instead of outputting a collage of borrowed shots. For product films, also have it capture the interfaces from the real site that are ready to animate, and review the asset list first. If assets are missing, make the agent stop and ask; do not draw a fake interface that looks real.

Turn the story into states and beats. A string of effects is not a storyboard. 'Push in first, then morph, then add particles' describes actions, not meaning. Every beat needs an entry state, an exit state, and a reason to exist. For UI motion, write the state table first, then draw the transitions. A component can change size, color, content, and position in the film, but it still has to look like the same object. The shot list is also a contract. If the agent cannot explain why the fourth shot exists, the fourth shot should not go into the render.

Choose the renderer by purpose. Opus can write lightweight Canvas or SVG films inside a project, which suits small, self-contained pieces. For repeatable series, a video framework saves more maintenance: Remotion treats video as React components and renders at a known frame number; HyperFrames uses editable HTML composition with explicit time and a seekable animation runtime. Neither is automatically better; use the smallest system that can support your repeated production. The hard requirement is seekability: no hidden clock, no unseeded randomness, no animation that only takes effect after the browser has been running for eight seconds. Every frame should be a deterministic query. That is how revisions stay local and testable.

Motion needs weight. Basic motion goes from A to B on a fixed curve. Good motion conveys mass, hierarchy, and intent. Small controls can snap, large panels can settle, the camera can be slow without destroying the sense of direction, and titles can enter fast and then hold long enough to be read. Springs are useful because they describe these behaviors more naturally than generic ease-in-out, but do not turn every object into a spring. If everything overshoots, nothing feels precise. Write motion rules for each object category. At every step, does the audience still know where to look? If not, the animation is decoration and is competing with the information for attention.

Put sound on the same timeline. Many AI films look finished on mute, but when you turn on the sound, nothing connects: clicks land after the button, cuts miss the beat, and the logo arrives before the music resolves. Put sound back into the timeline inputs; do not treat it as a file dragged in at the end. If you have a licensed or original track, measure the beats and cut to them; if you are synthesizing sound, place every cue at the same timestamps that drive the visuals. Listen once with your eyes closed. If the sound has no shape without the picture, the sound design is probably not finished.

Check frames before export. The first render looks a lot like progress, which is why this step is the easiest to skip. Do not watch the 60-second cut ten times in a row first. Have the renderer produce a contact sheet: one frame per major beat, and short strips around the fastest transitions. Hand the contact sheet and a specific critique task to Opus. This step separates 'the agent made a video' from 'the agent directed a video.' The former stops when the file exists; the latter stops only when there is evidence that the piece works.

Export variants from the source project, not from crops. A 16:9 launch film and a 9:16 social cut are different compositions. Vertical may need larger type, fewer simultaneous elements, a different camera path, and a tighter story. Do not make a beautiful widescreen piece and let software crop the middle. Keep the same assets, timeline, and narrative states, and define layout behavior for each format. Produce a contact sheet for every variant. The encoder finishing does not mean the export is correct; it counts only if the composition still holds after the format changes.

Finally, package a studio, not a chat. If the only record of the piece is a conversation, you just have one lucky session, not a production system. Put important decisions into files that another run can read. The next video starts from a real base: swap the product brief and assets, keep the render contract, checklist, and delivery structure. Long tasks need gates, not unlimited freedom. The agent can work for hours between gates, but it should not make irreversible brand decisions for you. If the brief says 'use the real interface,' a missing screenshot is a blocker; the model should not fill in one that looks right. If the reference is unclear, the correct output is a question or a test frame, not 900 polished wrong frames. Autonomy is useful only if each stage leaves evidence for the next. A loop needs a goal, observations, bounded fixes, and a way to stop.

Thariq from the Claude Code team joked about 'one-shot success': the so-called one-shot has a 10,000-character prompt and comes with skills, examples, and an API key. That detail explains why long prompts look like one-shot success.

A one-prompt video is exciting because the first version arrives fast. Motion engineering is valuable because the tenth version can be better than the first. The model gives speed, the brief gives direction, the renderer gives control, the contact sheet gives evidence, and the loop turns evidence into improvement. The gap is here: generating a demo versus running a studio.

Original: https://x.com/0xwhrrari/status/2115473687466201208

Long article: https://x.com/i/article/2105626165704572928