Yesterday an open-source project called Motion Lab showed up on r/PromptEngineering. Step 2 is the twist.
What’s new
The author wanted to see how far a lightweight model (Gemini 3.8 Flash, per the post) could go at writing code-driven motion graphics. Raw prompting with small models usually falls apart. They take lazy shortcuts, invent animation properties that don’t exist, and wreck timing curves. You ask for a smooth ease-out and get a linear slide. You ask for a staggered entrance and every element lands on the same frame. The usual fix is to reach for a bigger model and pay more per call. This build goes the other way and puts the model inside a tight box instead. The stack is React 19, Remotion and GSAP 3. That is a solid choice, because all three have strict, well-documented behavior the checks can lean on.
The twist
The model never writes free-form code from a blank page. Production is split into three stages: a direction file (direction.md), a structured contract (spec.json), and then the deterministic code (Scene.tsx). By the time the model writes code, most of the creative guessing is already settled in the contract. Think of it like a film crew. The director decides the feel, the planner locks the shot list, and only then does anyone touch the camera. A small model is much better at following a shot list than at inventing one while it codes.
The second surprise is that the checks run before anything renders. Static AST rules and audits catch layout-property reflows (width, height, top), bad palettes, dead holds, and drift from the spec. The model gets caught on paper, not on screen. That matters more than it sounds. Animating layout properties forces the browser to recalculate layout on every frame, which is exactly the kind of mistake that looks fine in a quick preview and then stutters in the final export. Catching it in the syntax tree means you never even see the stutter.
The mini-workflow
- 🎬 Write the direction. Mood, pacing, what the scene should feel like. Plain words, no code. Be specific about energy (“snappy, confident, nothing lingers longer than half a second”) because that is what the contract will be built from.
- 📋 Turn it into
spec.json. This is the contract. Timing, elements and palette get pinned down so nothing is left open to interpretation. If a value isn’t in the spec, the model has no business inventing it later. - 🧩 Generate
Scene.tsxfrom the contract. The repo ships 23 declarative template kits and 28 reusable primitives, so the model doesn’t invent coordinate math or layout from scratch. It assembles known parts instead of improvising geometry. - 🔍 Run the static gates. If it animates
widthortop, leaves a dead hold, or strays from the spec, it fails before you spend time rendering. Feed the failure message back to the model and let it fix its own mistake. Short, specific errors work far better than “try again.”
The repo also includes 20 studio workflow skills in .agent/skills. They split direction, engineering and auditing apart, so one context window isn’t doing everything. A model that has to be director, developer and QA in a single pass tends to blur the three jobs together. Separate roles keep each task small enough for a lightweight model to hold in its head.
Pro tips
- Steal the pattern even if you never touch Remotion. Put a structured contract between the idea and the code, and let a cheap checker enforce it. That works for any code generation task where a small model keeps going off the rails, whether it’s chart code, CSS animations, or SVG generation.
- Give the model ground truth to copy from. Templates and primitives beat “please get the math right” every time. If you catch yourself writing a long prompt about how to calculate positions, that is a sign you should hand over a helper function instead.
- Check the things you can check with rules (property names, palettes, timing gaps) and save human eyes for taste. Every rule you automate is one less thing you have to squint at in a render.
- Start with one failure you keep seeing, such as a hallucinated property name, and write a single rule for it. A checker with three sharp rules beats a sprawling one you never finish.
Fair warning
This is an early pre-release (0.8.0), and the author says there are rough edges. The post has just one upvote and no comments yet, so nobody has stress-tested the claims in public. Rules also only catch what someone thought to write a rule for. A scene can pass every gate and still look bland, so taste still has to come from you. Treat it as an interesting design to poke at, not a proven recipe.
Your move
The author is asking for feedback from anyone who has done contract-driven code generation or run smaller LLMs on creative work. If that’s you, go find where this approach breaks! Odd aspect ratios, long scenes with many elements, and specs that contradict themselves are all good places to push.
Repo: https://github.com/m2rtyaman/motion-lab
Grab it, run one scene through the whole pipeline, and tell the author what fell apart. 🚀
Experimenting with Gemini 3.8 Flash for motion graphics: Using structured contracts and static checks to stop hallucinations (Motion Lab)
by u/Bitter-Theme4433 in PromptEngineering