1 min lesson
Streaming edits and the review surface
Rebuild the parts of "Streaming edits and the review surface", then say why each one matters.
Step 1 of 2
Streaming edits and the review surface
Multi-file edits raise a UX problem before a systems one: the user has to stay in control of changes they didn't type. The answer is to stream edits into a diff the user reviews, not silently overwrite the buffer.
- Stream, don't batch
- Render edits as they generate so the user sees progress and can stop a run that's going wrong, instead of waiting for a wall of changes.
- Diff as the unit of trust
- Every change lands as a reviewable diff - accept, reject or accept-per-hunk - so AI output is a proposal, not a fait accompli.
- Keep the buffer authoritative
- Apply against the live document with conflict checks; if the user typed since generation started, reconcile rather than clobber.
- Per-file granularity
- A five-file edit shouldn't be all-or-nothing. Let the user keep the three good files and redo the two that missed.
Learn more
Full explanation
Guardrails: scope, confirmation, rollback
Guardrails: scope, confirmation, rollback
An agent that can edit anything is a liability. Constrain its blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. up front and make every action reversible.
Bound what the agent can touch: the workspace, an allowlist of paths, no writes outside the repo.
Gate destructive tools (shell, delete) behind explicit permission.
Cheap, reversible edits can apply optimistically into a diff.
Side effects that leave the editor - running commands, network - ask first.
Checkpoint before a multi-step run so one click undoes the whole turn.
Treat the agent's changes as a transaction, not scattered keystrokes.