"Inline diff" is becoming an AI-editor table-stakes phrase. Cursor has it. Copilot has it. Pearl has it. The marketing pages all use the same words.
The implementations are not the same. Here's what we mean when we say it.
The "Apply" pattern
Most AI editors land changes by writing the file and then asking you to review what happened. The flow is:
- You ask for a change.
- The AI shows you a proposed diff in the chat panel.
- You click Apply.
- The file is rewritten. The diff disappears from chat.
- If you don't like what landed: undo per-hunk, file by file.
This is fine when the change is small and the AI is right. It is brutal when the AI touches twenty files and got one of them wrong. The undo state is fragmented across files. The chat panel doesn't tell you what's still pending. There's no "back out the whole response" button.
The inline-diff pattern
Pearl's flow is different. The Agent doesn't write the file — it stages changes as inline hunks in the editor:
- Green decorations on added lines, red ghost text on removed lines, right where the change is.
- A floating prev/next navigator jumps between hunks across the active file. Each hunk has compact Keep and Undo buttons inline.
- A lens widget above each hunk shows before/after at a glance.
- Yellow ChangeSet dots appear on every file the agent touched, in the file explorer and on editor tabs.
- The chat panel shows the same hunks as a list, with the same Keep/Undo buttons. Either surface works.
The difference: nothing has been written yet. The hunks live in editor state. You can scroll through twenty files, accept the ones you like, reject the ones you don't, and only the accepted changes touch the filesystem.
The undo grouping detail
Every Agent response shares a single UndoRedoGroup. One Ctrl+Z
reverts the entire response — every file, every hunk, all at once.
This is the thing that matters when the agent touches twenty files and you want out. The per-hunk undo is convenient when you're tuning. The whole-response undo is essential when you're not.
The yellow-dots detail
The yellow ChangeSet dots in the file tree do two jobs: they show you the blast radius of one response, and they auto-clear when the session resolves. We tested an earlier design that left the dots until you manually dismissed them; it produced orphaned markers when sessions ended through unusual paths (programmatic close, parallel responses, app reload).
So we built a single frontend contribution that listens for the session-close event and cleans up the dots regardless of which path triggered it. It's the kind of thing nobody notices until you forget to do it.
Why we did it this way
Because the cost of "the AI wrote something I didn't want" is higher than the cost of one extra click. Apply pattern saves you a click in the happy case. Inline-diff saves you a gnarly undo session in the unhappy case. We optimize for the unhappy case.
Try it: ask Agent mode to do something that will touch three files. Watch the yellow dots appear. Walk through the hunks. Reject the one you don't like. Ctrl+Z the rest. Notice that nothing has been written yet — and then the ones you kept are the only ones that land.