I don't open a video editor any more. I ask Claude instead.

Jeet Adeshara — Sat, 12 Sep 2026 18:11:29 +0000

I always wanted to make content. What stopped me was never the ideas — it was the four hours in a timeline afterwards.

So I started automating bits of the editing with AI. Then more bits. About six months later it had turned into a product, and somewhere in there I stopped opening a video editor entirely. Everything on my channels now — 100+ videos on a YouTube channel that posts daily, plus two Instagram accounts — is made end to end with the thing I built.

This is the part I think is worth writing about, because the architecture is strange and I haven't seen it done quite this way.

The wall every AI video tool hits

Every AI video tool I tried is a prompt box. You describe a video, you wait, you get a finished clip back.

That works right up until scene 3 is wrong. And then you have nothing. There's no handle on scene 3. Your only move is to re-roll the whole video and hope the dice land better — which also re-rolls the two scenes that were fine.

The reason is that the output is pixels. Once a model has rendered a video, the video is the artifact, and you can't ask a file to be less busy.

The inversion

What if the artifact were code?

If each scene is a React component, "scene 3 is too busy" isn't a re-roll. It's an edit to one file. The other scenes don't move, because nothing regenerated them.

That's the whole idea. Remotion already lets you write videos as React, so the animation layer was solved. The question was who writes the code.

The answer I landed on: your AI client does, and my server never calls a model at all.

It's an MCP server, and that constraint shaped everything

Idea to Motion is an MCP server. You connect it to Claude, Cursor, VS Code, Windsurf — whatever you already use — and your assistant does the creative work: it writes the script, directs each scene, and writes the actual Remotion components.

My server does the deterministic half: text-to-speech with word-level timestamps, working out where scenes start and end from those timestamps, assembly, and rendering.

Here's the flow, roughly:

your client's LLM          my server
──────────────────         ───────────────────────
create_job          ──▶    creates the job, returns a brief
   ◀── "here's the contract, the theme, the canvas size"
submit_plan         ──▶    validates against the same schema
                            a server-side agent would face
approve             ──▶    TTS + word timestamps + scene boundaries
   ◀── "scene 1 runs 0.0–4.2s, here's its brief"
submit_scene_code   ──▶    static validation → sandboxed smoke render
                            → layout audit → accepted
   ◀── [rendered frames, so the model can see what it made]

Because no server-side model makes a creative decision, a tool result can't be a conversation. It has to be a work order. Every tool returns a brief assembled from the same prompt sources a server-side agent would have used, and every submission is validated against the same schemas. If the model gets it wrong, the error comes back in-band and it corrects itself, instead of the job dying in a queue somewhere the user can't see.

Two gates that make this survivable

Letting a remote model write code that my renderer will execute needs guardrails. Two have earned their keep.

A sandboxed smoke render. Static validation catches syntax, not runtime. So every submission gets esbuild-transformed and executed at 3 frames in a worker thread with mocked Remotion globals and a 5-second timeout to kill runaway loops. If it throws, the model gets the stack trace back immediately and fixes it. This is the MCP equivalent of the preview → autofix loop the web app has.

A layout audit. This one surprised me. I render a still and walk the pixels, measuring vertical occupancy — how much of each third of the canvas has content in it.

The reason is that "all the text is clustered in the top third with a huge empty gap below" is something a model reliably does not notice about its own output. It reads its code, the code looks balanced, and the frame is lopsided. You cannot catch this by reading the source. You have to look at the pixels.

When the audit rejects a scene it hands back the frames it measured, so the model rewrites with the evidence in front of it rather than guessing.

What this buys, and what it costs

Editing is the payoff. "Scene 3 is too busy" rewrites one component. So does making a scene shorter, re-framing the speaker, changing captions, or adjusting the audio mix. You can also hand it a recording of yourself instead of a script — it transcribes, cuts the dead air and the retakes, and builds graphics around you, and you edit that the same way.

It also made pricing fall out oddly. Your client's tokens do the thinking and your own ElevenLabs or Cartesia key does the voice, so creating and previewing cost me nothing and are unlimited and free. The only thing I actually pay for is render compute, so that's the only thing priced.

Honest limitations, because I'd want to know:

You need an MCP client. If you don't already live in one, this isn't for you yet.
Rendering a 30–60s video takes a few minutes. It's Chrome plus ffmpeg, not a GPU model.
Scene code sometimes needs two passes. The gates catch failures, but it costs a round trip.
Aspect is 9:16 or 16:9. A portrait system diagram is a different composition and I haven't built it.

The test I actually care about

Not a demo reel. A posting schedule.

"Is the output good enough to publish on a schedule?" is the objection I'd raise about any AI video tool, and I don't think a hand-picked showreel can answer it — of course the showreel looks good, it was picked. So the answer I have is that I ship on it daily and haven't opened an editor in months.

It's at ideatomotion.com if you want to try it. Happy to go deeper in the comments on any of this — the word-timestamp-to-scene-boundary mapping and the render cost model both have more in them than I've written here.