The Smart Editor Mode Diffs As A Transient Interaction Mode
[DEVELOPING]- Planted
- 2026-07-07
- Tended
- 2026-07-08
- State
- [DEVELOPING]
- Topics
- topic/engineering topic/ai
- Links out
- 6
The smart-editor mode — diffs as a transient interaction mode
Current harnesses make the human a passive reviewer because the diff arrives after the agent’s work and gets read like email: top to bottom, out of context, decision at the end. Invert the asymmetry: a diff’s arrival should put the editor into a transient mode where everything relevant to judging it is one keystroke away. The diff becomes a focused editing surface, not an inbox.
Parent discussions
- Agent-Editor Protocol — the spec gestures at this (“files open in editor buffers, harpoon preloaded”); this note claims the gesture should be the whole UX
Connected concepts
- The hidden tax of agentic coding is context switching — the cost this mode is designed to cut: not the number of decisions but the price of each
- Delegation is not collaboration — reject-and-reshape only becomes cheap if the editor makes the evidence cheap
- AI Pair Programming Workflow — this is the implement phase given an actual interaction design
The point
Cursor’s diff-review panel is a modal document you scroll. Claude Code prints the diff into the terminal and waits for confirmation. Aider skips the reading and commits. All three treat the diff as a text to be read. But a diff is not a text; it is a set of claims about a codebase. “This function now does X.” “Its callers are unaffected.” “The tests still describe its behavior.” Evaluating claims means visiting evidence, and today every visit is manual navigation: find the callers, find the tests, find your way back, paying the switching tax at each hop. No wonder reviewers degenerate into rubber-stampers; the interface prices diligence out of the market.
Invert it. When an edit_proposal lands, the editor enters a transient mode in which the evidence is pre-mapped: <leader>1 jumps to the changed function, <leader>2 to its callers, <leader>3 to its tests, <leader>a accepts, <leader>r sends the proposal back with a revised prompt. Vim users already know this shape; it is operator-pending mode writ large: a temporary grammar that exists only while a question is open and dissolves the moment you answer it. The mode ends when the decision is made. Nothing lingers.
The design principle underneath: every harness on the market optimizes for the agent doing more (more files, more autonomy, longer runs). The right target is the human doing less per decision, but deciding more decisively. Reviewer throughput was never reading speed. It is evidence-access speed, and evidence access is an editor problem, not a model problem.
Needs
- Evidence-access speed as a sibling primitive to throughput — what would reviewer-throughput metrics look like if they measured evidence access instead of lines reviewed?
- Navigate-by-claim as a navigation primitive — the LSP call graph gives callers and tests and callees for free; the editor mode that surfaces them on demand is a research question, not a feature request
Referenced by
notes that reference this one
Needs
dead links from this note that are not yet planted
- Agent-Editor Protocol
- Evidence-access speed as a sibling primitive to throughput
- Navigate-by-claim as a navigation primitive