Skip to content
Editing a 48-minute video with an AI

Keeping the AI aware of its own earlier cuts as it works through the film

ResultThe AI made 98 edits to a 48-minute video, more than double the 44 of the earlier pass, and none of them was rejected for pointing at a stale part of the timeline.

In plain words
The problem
A 48-minute video is too much for an AI to plan in one go, and every cut it makes moves the timestamps after it. A plan that was right when it was made can be wrong by the time it is applied.
What I did
The video is split into four-minute stretches that are views of one document, not separate copies. The AI decides the film-wide choices first, then edits one stretch at a time, re-reading the current timeline before each step.
What happened
On a 48-minute recording the AI applied 98 edits, up from 44 in the earlier version, and none was refused for referring to a part of the timeline that had moved.
My contribution

I set the limit on how much the AI sees at once and chose the order: film-wide decisions first, then local edits against the current document.

I designed HYVIRAL’s editing of long videos around two constraints: an AI call needs a task it can hold in view, and its plan must refer to the timeline as it is now. A cut moves later timestamps and a split creates new clip IDs, so a sensible plan can be invalid before it reaches the document.

One editable documentFilm-wide choices travel with every segment
Previous segmentAlready applied
Current segment4-minute target · 2–5-minute nominal bounds
10 sec
neighbor context
10 sec
neighbor context
Next segmentPlanned after this edit
1Read current state

Use current clip IDs and timing.

2Plan the local edit

Keep the film-wide choices fixed.

3Apply, then advance

The next plan sees this change.

Bound the agent’s task. Keep the film’s state shared.

Decision 1

Give the AI four minutes at a time, from one shared document

I kept one editable project document; the segments are views of it, not separate documents to merge later. Each local planning call receives its segment, ten seconds of context on either side, the film-wide outline and decisions, and what the pass has done so far.

Segments target four minutes, within two to five. They prefer a nearby sentence ending or scene change, fall back to a clock boundary and allow a short final segment, so the work stays bounded even when the footage does not divide neatly.

Separate documents would have needed merge logic and undo across segments; sending the whole transcript on every call kept the overload I was removing. The tradeoff is more planning calls and repeated shared context, in exchange for a smaller task per call that still serves one film.

SourceSpecification + implementation

How the video is split into four-minute segments, from the architecture spec and the planner code: a four-minute target, a clock fallback when no sentence or scene boundary fits, and a deliberately short final segment.

Read the source
Decision 2

Plan each segment against the video as it is now

I chose a server-controlled sequence: film-wide choices first, then local edits planned and applied in order, with the document re-read before each call for its current clip IDs and timing. Caption style, look, fades and music travel with each local prompt, and a film-wide operation proposed locally is removed and recorded.

Planning all segments at once from one copy of the timeline offered speed, but earlier edits could invalidate later plans. The model proposes edits while the server decides which step runs next, which keeps the workflow quotable, resumable and inspectable.

The cost is doing the steps one after another, which buys current references and a predictable order. Targeted segment tools let a small follow-up revision skip another full pass.

SourceDecision record + implementation

The locked decision to edit in order, and the planner’s input: the document is re-read before every segment, and the film-wide choices travel with each call.

Read the source

Results

In a September 2026 evaluation driven by an outside assistant, the revised workflow applied 98 edits across 12 segments of a 48-minute, 20-second recording, against 44 in the previous pass.

A dry run removed nine proposed edits before application. The remaining 98 applied with zero refusals from the editor and zero removals by the scope filter, the two checks that reject an edit pointing at a stale or out-of-bounds part of the timeline. Applied edits reached 2.03 per minute, above the comparison threshold of 1.57.

That measures applied work, not artistic quality: the cut still went through its own export and human review (see trusting the quality checks).