AI Inline Diff Viewer
Problem statement
Cursor, GitHub Copilot, Codeium, and Sourcegraph all share one core view: a diff with hunk-level accept and reject controls. The user reads what the AI wants to change, accepts the parts they like, rejects the rest, and ships. The UI looks like a regular git diff but is operating on a different mental model — proposals, not commits.
Build a diff viewer that renders multiple hunks across files, supports per-hunk Accept/Reject toggles (idempotent — clicking Accept twice un-accepts), surfaces an Accept All / Reject All shortcut, shows correct line numbers including the +N gap between hunks, and renders a live count of the current decisions.
The architectural challenge is keeping per-hunk state independently editable while computing summaries derived from the whole. The data model is "hunk = unit of decision, line = unit of display, file = grouping label." Conflate any of those layers and the UI either becomes uneditable or breaks when you add a fifth hunk.
Requirements & constraints
- Render multiple hunks across one or more files
- Each hunk has an Accept and Reject button independently togglable
- Clicking the active state again returns the hunk to pending
- Accept All / Reject All applies to every hunk
- Added lines have green background with '+' marker; removed lines red with '-' marker
- Line numbers show the destination line (or original for context lines)
- Live summary at the bottom: N accepted · N rejected · N pending
- Rejected hunks appear visually muted
How to approach AI Inline Diff Viewer
The strategy an interviewer expects you to reach for.
How I'd Think About This Problem This UI is the heart of every AI code editor — Cursor, Copilot Chat, Codeium, Sourcegraph Cody. The user reads what the AI wants to change, accepts the parts they trust, rejects the rest, and ships. It looks like git diff, but the mental model is fundamentally different. Git diff is a view of past commits; this is a view of pending proposals. Each hunk is a decision the user hasn't made yet, and the UI's job is to make that decision frictionless without making it accidental. The clarifying question I ask before I write a line: what is the unit of decision? If the answer is "the whole patch" you're building a one-button confirm dialog. If it's "the line" you're building a different (and harder) UI with sub-line interactions.
The full solution is part of HelloFrontend Pro
The question above is free to read in full. Upgrade to unlock the interactive workspace and the senior-level walkthrough that go with it.
- Live React sandbox pre-wired for this component
- Time-boxed checkpoints that mirror a real 45-minute round
- Interviewer scoring criteria and a full reference implementation
Already a member? Log in to open the workspace.