# The project file is the interface: letting AI agents drive a video editor > Source: > Published: 2026-07-09 15:54:17+00:00 Last week I open sourced [FableCut](https://github.com/ronak-create/FableCut), a Premiere-style video editor that runs in the browser and that AI agents can operate. It hit the front page of Hacker News ([thread](https://news.ycombinator.com/item?id=48845422)), and the questions there made me realize the interesting part isn't the editor. It's one design decision: **the project file is the interface.** Most AI video tools hide the edit behind an API. You call `addClip()` , `applyFilter()` , and the tool owns the state. If you want a human to touch the result, you build a whole collaboration layer. FableCut does the opposite. The entire timeline lives in one JSON document, `project.json` : media, clips, tracks, keyframes, transitions, markers. The editor UI reads it. The export renders it. And anything that can write JSON can edit video: Claude Code through MCP, a Python script, `jq` , or you with a text editor. ``` { "id": "c_title", "kind": "text", "track": "V3", "start": 0, "duration": 2.2, "props": { "text": "HANDMADE", "font": "Bebas Neue", "glow": 45, "textAnim": "letter-pop" } } ``` That clip is a glowing kinetic caption. There is no API call that creates it. Writing it into the file IS creating it. The first question on HN was "what's the benefit of SSE here?" Fair question, because the SSE channel does almost nothing, and that's the point. The server watches the project file with `fs.watch` , debounces 150ms, and pushes the literal string `change` to the browser. No payload. The browser re-fetches the project and re-renders. The whole mechanism is about 15 lines on a bare `node:http` server. Why not WebSockets? Because the data only flows one way. Everything that writes (the UI, an agent, a shell script) goes through REST or the filesystem. The browser only ever needs to hear "something changed, go look." An event with no payload can't arrive out of order, and a missed event costs nothing because the next fetch has the latest state anyway. The file carries an integer revision. Every write must bump it. If a write arrives with a `revision` that isn't newer than what's on disk, the server rejects it with a 409. This one integer is the entire concurrency model. If I drag a clip in the UI while an agent is mid-edit, the agent's stale write bounces, it re-reads, re-applies its change on top of mine, and writes again. No operational transforms, no CRDTs, no lock files. It works because edits are coarse (a whole document) and rare (human speed), so last-writer-wins with a staleness check is enough. FableCut has animated SVG overlays (lower thirds, confetti, sparkles) that are plain `.svg` files animated with CSS `@keyframes` . The problem: a video compositor needs to render the animation state at an exact time, and export isn't realtime. You can't just let the animation play. The solution: pause every animation and drive time by hand. The compositor sets `animation-delay: calc(var(--d, 0s) - t)` where `t` is the clip's local time. A negative delay means "you started in the past," so a paused animation with delay `-1.3s` displays exactly its 1.3 second frame. Deterministic, scrubbable, identical in preview and export. The only rule for SVG authors is to never hardcode `animation-delay` and use the `--d` custom property for staggering instead. Someone said this on HN and it deserves a straight answer. For trims, concats, and batch transcodes: yes, absolutely, do that. The difference is the creative loop. ffmpeg is write-only. The agent builds a filter graph, renders for minutes, and cannot see what it made. You give feedback, everything re-renders. In FableCut an edit is a JSON diff, the open browser updates in 150ms, and the timeline stays editable instead of being baked into a filter string. It's not a replacement for ffmpeg anyway: the export pipeline renders frames in the browser and pipes them to ffmpeg for encoding. FableCut is the state and preview layer between the agent and ffmpeg. The compositor is the browser, so export needs a browser open (headless export is not there yet). It's Chromium-first. And an AI can misjudge a cut just fine, which is why the human-in-the-loop part matters more than the AI part: the agent does the labor, you do the taste. Full disclosure since HN asked: Claude helped write the README, and large parts of the editor were built in collaboration with it. That felt fitting for a tool whose primary user is an AI agent, but the architecture decisions above are the ones I'd defend in person. Repo: [https://github.com/ronak-create/FableCut](https://github.com/ronak-create/FableCut). It's MIT, zero dependencies, one `node server.js` . If you build something weird with it, I want to see it.