FitWhen to use it — and when not
Use it when
- AI editing existing text or code the user owns
- Contracts, policies, specs — anything with accountability
- Bulk edits where some changes are good and some are not
Skip it when
- Generating something new from scratch — there is nothing to diff
- Changes so large that a side-by-side or regenerate is clearer
AnatomyThe parts of the pattern
- HunksDeleted and inserted text shown inline, colour plus strike/underline.
- Per-hunk controlsAccept or reject each change.
- ReasonWhy the AI suggested it, on demand.
- Bulk actionsAccept all / reject all with a running count.
GuidelinesDo & don’t
Do
- Keep hunks small — one idea per change.
- Use colour and a second cue (strike, underline) for colour-blind users.
- Make reject as easy as accept, and both undoable.
Don’t
- Replace the document and show "Done".
- Auto-accept after a timeout.
- Lose the user's cursor and scroll position after applying.
In the wildReal-world examples
CursorGitHub Copilot editsGrammarlyGoogle Docs suggestions
Products named for reference only — no affiliation, and the demo above is an original illustration, not a copy of their UI.
For engineersImplementation notes
- Ask the model for edits as structured operations (find/replace with anchors), not a full rewrite — cheaper and diffable.
- Re-anchor hunks with a fuzzy match if the user edits while suggestions are pending.
- Apply accepted hunks as one undo step in your editor's history.