Agents Writing Video: `@scenerok/sdk` vs VidScript

A developer behind the Scenerok video tooling outlined when AI agents should author videos in VidScript, a declarative DSL, versus TypeScript via the public @scenerok/sdk, arguing both compile to the same intermediate timeline so preview and render semantics stay identical. The guidance recommends VidScript for short promos and templates and the SDK for loops, branches, computed timing and agent-driven work, with validation and render checks wired into the agent loop. The author warns against using the SDK for everything, hand-copied pretend-loops in VidScript, and unpinned generative calls that re-resolve assets on every pass.

People ask a practical question once the demo lands: should my agent write VidScript or TypeScript? The honest answer is the one on the public @scenerok/sdk README, expanded into engineering judgment: | Use | Language | |---|---| | Short promos, human edits, templates | VidScript .vid | | Loops, branches, computed timing, agents | TypeScript + @scenerok/sdk | Both emit the same intermediate timeline for preview and render. That sameness is the feature. This essay is how to choose without cargo-culting either side. VidScript is for when the video wants to look like a script. Imports pull generative providers. Inputs declare footage you already have. Time ranges place layers on a clock. Compile-time slots resolve model calls before composition. Output sets container and destination. Why humans like it: Why agents like it sometimes : If the job is "15s reel, hero clip, VO, end card," start in VidScript. Do not open with a framework. @scenerok/sdk exists because some videos are data . Examples that outgrow a tidy .vid : In TypeScript you get real control flow, real tests, real module imports, and the same toIR exit. Public surface includes timeline construction, loadVideo / loadAudio probing helpers, text/audio factories, grid areas, transitions — see the npm README for the current API. Stay on that surface in articles; do not invent private methods for blog flair. Agents already live in TypeScript. Giving them a first-class authoring SDK is how "write the launch video too" stops being a metaphor. If VidScript and the SDK drifted into different semantics, you would fork the product: preview lies depending on path; templates refuse to migrate; agents and humans cannot hand off. So the rule is strict: authoring is plural; timeline meaning is singular. Operational consequences: scenerok validate style checks apply to both public CLI behavior . .vid .ts folders; forks should not surprise you at render. This is the same lesson compilers learned decades ago: multiple languages, one machine model — here the "machine" is the timeline + render contract. Use VidScript when: Use @scenerok/sdk when: Use both in one shop when: Pitfall: SDK for everything. You get enterprise-shaped code for a six-second bumper. Prefer the DSL until it hurts. Pitfall: VidScript with pretend-loops. Copy-pasting twenty near-identical blocks is a smell. Migrate that scene to TS. Pitfall: Generative calls without pins. Either language will burn money if every agent pass re-resolves assets. Make pinning part of the workflow, not an afterthought. Pitfall: Teaching agents only prompts, not validate/render. The loop is edit → validate → preview → maybe final. Wire MCP/CLI skills to that loop; do not stop at "emit text." From the SDK README, the flavor is intentional: build a timeline, assign clips to ranges, return toIR . From the site, VidScript shows timed ranges and compile-time generative functions side by side with brand inputs. Cloneable showcase material lives in the public GitHub showcase — fork, change a string, re-render. That loop is the pedagogy. A good agent skill does not always emit TypeScript because TypeScript is familiar. It classifies the job: If your skill always scaffolds the SDK, you will get correct-but-heavy programs. If it always scaffolds VidScript, you will get unmaintainable copy-paste. The classifier is the product. The sweet spot we see: When the template outgrows declarative form, a human or agent with a migration brief ports the skeleton to @scenerok/sdk once — then the campaign scales in TS. Migration is a deliberate event, not a surprise rewrite mid-flight. You cannot unit-test taste. You can test structure: Keep tests on the IR/validate layer so VidScript and SDK share them. That reinforces the peace treaty: two frontends, one meaning. Everything above stays within what you can learn from scenerok.com https://scenerok.com , the npm README for @scenerok/sdk , and the public showcase. If an API is not documented there, do not teach it in GTM essays. Longevity beats insider flex. Agents should not "prompt a video." They should author a program that compiles into one. Pick VidScript when clarity wins. Pick @scenerok/sdk when computation wins. Refuse a world where those choices fork your renderer. Install the SDK from npm, open the editor or CLI path on scenerok.com https://scenerok.com , and let the IR be the peace treaty between humans and agents.