By Sagar Dey, founder of MirrorCut
Most AI features ship with an all-or-nothing contract. The model does a thing, and you either keep the result or throw it away.
That works for a one-line autocomplete. It falls apart for a video edit, where a single "AI pass" might contain dozens of independent decisions: cut this pause, drop that filler word, keep the second take, caption this line.
When I built MirrorCut, an AI video editor that runs in the browser, I made one rule early: every AI change is a patch on the timeline, and every patch can be accepted or reverted on its own.
This post is about why, and the design constraints that rule creates. It's written for developers building any kind of AI-assisted editor: video, docs, code or design.
Note: the code below is a simplified illustration of the pattern, written for this post. It is not MirrorCut's production code.
The problem with "re-render and replace"
The simplest way to add AI to an editor looks like this:
- Send the current state to the model.
- Get back a new state.
- Replace the old state.
It's easy to build. It's also hostile to the user, for three reasons:
- No granularity. If the model made ten good decisions and one bad one, the user can't separate them.
- Lost work. Anything the user did by hand can get silently overwritten.
- No explanation. The user sees a different result, not what changed or why.
In video, there's a fourth problem: re-rendering is slow and expensive. Throwing away a whole pass because of one bad cut costs real time.
The alternative: edits as small, named patches
Instead of returning a new timeline, the agent proposes a list of small changes against the existing one. Conceptually, each patch carries:
// Illustrative only
type EditPatch = {
id: string;
kind: "cut" | "caption" | "reframe" | "graphic";
range: { start: number; end: number }; // seconds on the timeline
summary: string; // one human-readable line
status: "pending" | "accepted" | "reverted";
};
The summary matters more than it looks. In MirrorCut, every AI change is explained in one line, for example "Removing a 0.6 s pause at 0:54". If you can't describe a change in one line, it's probably several changes and should be split.
Rule 1: Show every patch where it happens
Each pending change is outlined on the timeline itself, not buried in a side panel. The user's eyes are already on the timeline, so that's where the review should happen.
This also forces a useful discipline on the agent: every change has to map to a visible location. "Improved the pacing" isn't a patch. "Removed 2.1 s of dead air at 3:12" is.
Rule 2: Accept and Revert are per patch
The whole point is granularity. A pass with ten patches gives the user ten decisions, not one.
// Illustrative only
function revert(patchId: string) {
const patch = timeline.patches.get(patchId);
timeline.apply(inverse(patch));
patch.status = "reverted";
}
The hard part isn't the button. It's making sure patches are independent enough that reverting one doesn't break the others. Cutting 0.6 s at 0:54 shifts everything after it, so later patches need to be expressed in a way that survives earlier ones being reverted.
Rule 3: One undo history for humans and AI
This is the rule people find most surprising.
In MirrorCut, AI edits and manual edits share one undo history. There's no separate "AI layer" or "AI mode." If you trim a clip by hand, then the agent removes a pause, then you press undo, you undo the pause removal, exactly like you'd expect.
Why not keep them separate? Because two histories create two mental models. Users end up asking "which undo do I need?" And they lose trust when the AI's changes behave differently from their own.
A cut is a cut, whoever made it.
Rule 4: Follow-ups patch, they don't restart
When the user asks for a follow-up, like "make the intro faster and add captions", the agent edits the existing timeline instead of regenerating from scratch.
This protects everything the user already accepted or adjusted by hand. A restart would quietly throw that away.
It also keeps responses small and reviewable. The site shows this flow: "Done. Intro trimmed from 4s to 2s and captions added." That's two patches, not a new video.
Rule 5: Expensive operations ask first
Some patches are cheap to preview. Others, like a full-resolution render, take real compute.
In MirrorCut, expensive steps ask before running. The general pattern: separate proposing a change from paying for it. Let the user review the plan before the costly part kicks off.
There's a pricing angle too. On MirrorCut's plans, each request to the agent uses AI credits based on the work it takes, while editing by hand on the timeline uses no credits. That makes "do it yourself" a real, free option for small fixes, and it keeps the agent honest about when it's worth calling.
Where this pattern applies beyond video
Strip out the video specifics and you get a reusable checklist for any AI-assisted editor:
- Return patches, not replacement states.
- Give each patch a one-line explanation and a visible location.
- Make accept/revert granular, and design patches to survive each other's reversal.
- Use one undo history for human and AI changes.
- Patch on follow-up; never silently restart.
- Ask before expensive work.
Try it on your own footage
MirrorCut, AI video editor (mirrorcut.ai), runs in the browser. It cuts dead air, filler words and retakes, adds word-timed captions, reframes to 16:9, 9:16, 1:1 and 4:5, finds Shorts, and adds motion graphics, all as reviewable patches on a real timeline. Exports are MP4 up to 4K, plus SRT and VTT captions.
Every account starts with 7 days of the Creator plan free (card required). After that, it's Creator $10, Pro $30 or Studio $60 a month. MirrorCut launches publicly in November 2026: https://www.mirrorcut.ai
I'd love to hear how you handle review flows for AI output in your own tools. Drop it in the comments.
Top comments (0)