A headline crossed my feed: “Opus 5.5 Replaced After Effects.” Twelve seconds of a mascot building a title inside a fake After Effects screen.
My first reaction was the same one I have when a vendor says “zero-downtime migration.” Okay, show me the logs.
So I tested it. Not on a studio machine with a fancy GPU. On my ordinary laptop: Intel i7, integrated graphics, no gaming card. If a trick only works on a studio rig, it is a hardware advertisement, not a workflow.
What the viral clip actually is
The post is by Monokern AI, and to their credit, they explain the route. One 390-word prompt went into Claude Code running Opus 5.5. The fake After Effects interface was built as HTML (a web page) and screenshotted. The 3D scene was written as Blender Python, meaning a script that tells Blender what to build. Then it was rendered in Cycles on a GPU. Render means turning code into finished pictures; Cycles is Blender’s realistic renderer.
Output: 360 frames at 30 fps, 1920x1080. Finished after three follow-up prompts.
Here is the part the headline skips. The model did not output a video. It wrote code. The code made pictures. Other tools stitched those pictures into a video. It is code all the way down. That is the whole trick.
My test: one brief, ninety frames
My laptop did not even have Blender, ffmpeg or Node installed. Fine. Constraints make good tests.
I wrote one brief for a 6-second title card for my blog brand, 3AM FILES: black background, orange accent. I gave it to Claude Code on the laptop. Claude wrote ONE self-contained HTML file where the whole animation is a pure function of time. You pass ?t=2.80 in the URL and you get exactly what the frame looks like at 2.8 seconds. Pure function means same input, same output, every time, so any frame renders exactly.
The finished card: the last frame of the 6-second clip.
Then frames. I used headless Chrome, which is the browser running without a visible window, to take screenshots: 90 frames at 15 fps, 960x540. ffmpeg was not there, so GStreamer (another media toolkit, already on the machine) encoded the frames into MP4 using x264enc.
claude -p “Read brief.md and build the animation file”
google-chrome --headless=new --screenshot=f042.png “file:///.../index.html?t=2.80”
gst-launch-1.0 multifilesrc ! pngdec ! x264enc ! mp4mux ! filesink clip.mp4
The middle line is one example from the per-frame loop.
The brief itself was written like a deployment plan. Not “make it cool.” Actual beats with timings:
A terminal types a deploy. A CI to K8S to LIVE line draws. The title staggers in. The subtitle fades and the final card holds. All written down before a single frame existed.
Round one was ugly. Round two was a sentence.
Round one worked. Technically. The composition sat in the left half of the frame and the final frame looked unbalanced, like a slide where someone forgot to click “center.”
In the old world, this is where you open the timeline and start dragging keyframes. A keyframe is a saved position an animator sets by hand. Move one, re-preview, repeat until chai goes cold.
I wrote one follow-up prompt instead: fix the centering and scale the final composition up. Done. Re-render.
Total human prompts: two. The brief and the fix. No timeline editor opened. No manual keyframes.
That is the lesson, and it is bigger than video. You edit words, not keyframes.
The timeline did not die. It became a text file.
What this replaces, and what it does not
Manual timeline editing vs this code route:
Making a change — Manual: drag keyframes, re-preview, repeat. This code route: change a sentence, re-render.
Repeatability — Manual: saving a project file and hoping the app opens it next year. This code route: a text file, re-render any time.
Best at — Manual: footage, fine hand-tuned motion. This code route: titles, diagrams, cards, explainers.
Hardware — Manual: wants a strong GPU. This code route: a normal laptop coped.
Now the honest limits. 15 fps at 960x540 is a proof, not production quality. This route makes motion graphics: titles, diagrams, cards. It does not edit real camera footage. And the GPU/Blender route from the viral post would be slow on integrated graphics, so do not expect that on a laptop like mine.
Most important: quality comes from how precise the brief is. Timings, positions, easing (how motion speeds up or slows down). The model is not guessing your taste. If your brief is vague, your video will be vague, just faster.
Steal this: the checklist
Write timings in the brief. Beats, seconds, positions.
Make the animation a function of time. One
tparameter in, one exact frame out.Approve still frames before rendering all frames.
Render cheap first. Low fps, small size. Go big only after it looks right.
Fix with words, one change at a time. Same discipline as one change per deploy.
Keep the text file as the source of truth. Version it like code, because it is code.
The basics did not change
Story, timing and taste still decide whether a video is good. That was true before any of this, and it is true now. What changed is the tool that applies them.
I used to think motion graphics needed a subscription and a weekend. Now it needs a clear paragraph and a laptop that was never meant for this. Honestly, the clear paragraph is the harder part.
Disclaimer
This post reflects my personal experience and opinions only.
It is not affiliated with, sponsored by, or endorsed by any company named in it.
All product names and trademarks belong to their respective owners.
Facts about other creators’ work are summarized from their public posts, linked in the article.
This is not professional advice; validate everything in your own environment before production use.
© 2026 Honey Kiran. All rights reserved.
Honey Kiran · DevOps & Platform Engineering
Writing on DevOps, platform engineering, and agents that do the boring work — follow along if 3 AM pages are your love language too.
Examples are illustrative — validate in your own environment before running in production.
Top comments (0)