Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | code review / tools / agent workflow

Inspect before you wrench.

Agent-era review needs a place built for understanding. That does not mean every review surface should also change the code.

The take: Whiteboard turns diagrams, semantic diffs, source links, and agent decisions into one review workspace. Its current inability to edit files is a stated limitation, not a security guarantee. It also exposes a useful design question. Should inspection and repair share the same trigger?
Set the Review Isolation Clutch

The review job changed.

Whiteboard describes itself as a desktop canvas where people and coding agents can architect software together. Its agent can draw sequence diagrams, link visual elements to code, summarize large functions as pseudocode, and show decisions from an agent trace.[1]

That is a different job from placing a chat panel beside a raw diff. The tool is trying to reconstruct intent and structure before the reviewer reaches individual lines.

A faster diff is still a diff. A review tool should rebuild the model in your head.

Read-only can be a useful mode.

Whiteboard also says it cannot currently edit files.[1] Several people in the Hacker News discussion questioned whether a tool without editing should be called an IDE. Others worried that a generated diagram could drift away from the implementation.[4] Both objections are fair.

The missing editor is not presented as a deliberate safety boundary. Still, the separation has value. Review asks what changed, why it changed, where the evidence lives, and what remains uncertain. Repair asks for new authority over the worktree. Combining those tasks makes it easy to rewrite a confusing area before the reviewer can describe the confusion.

Understanding keeps you in the work.

Geoffrey Litt argues that people need to understand agent-written code to participate in the next design loop, not only to verify the last one. He uses structured explainers, quizzes, and interactive "micro-worlds" to build that understanding.[2] Whiteboard cites that essay as an influence.

A diagram is not proof. A semantic summary is not the raw source. A quiz can reveal a gap without certifying the implementation. Each representation helps with a different part of the review. The interface should keep the links between them visible.

Put a clutch between modes.

GitHub's review documentation separates context, file inspection, comments, viewed progress, and the final approve or request-changes decision. It also notes that an approval can be dismissed when a code-changing commit arrives if the repository enables that rule.[3] The revision matters because review evidence ages.

A review workspace should start in Inspect. Pin four things before opening Repair:

  1. The purpose and constraints of the change.
  2. The visual or narrative map used to explain it.
  3. The exact source revision behind that map.
  4. The named checks or runtime evidence available now.

Then make write access a separate, explicit action. The clutch below records that handoff. It does not enforce repository permissions or prove that the selected evidence is accurate.

Interactive makeover / review control

Review isolation clutch.

Traditional purpose replaced: one editor surface where reading and writing share the same controls. Better version: pin the review basis in Inspect, shift to Repair deliberately, then open a separate write interlock and copy the handoff.

Choose the operating mode

Native radio buttons own the mode. Inspect starts without a write route. Repair makes the write interlock available but does not turn it on.

Review operating mode
Pin the review basis
INSPECT LOCKED1 / 4 LAYERS PINNED

Build the review basis before repair.

Context is pinned. The map, source revision, and proof record remain open.

Operating modeInspect. No write route is available in this template.
Current basisContext pinned. Map, raw source, and proof open.
Handoff stateReview basis incomplete. Repair remains a separate decision.
This control writes a review contract. It does not change repository access, freeze a revision, run tests, or validate a generated diagram.

Copy the handoff card

Fill the blanks after copyingAdd the actual revision, source links, check commands, outputs, unresolved questions, and reviewer. Selected layers describe the template structure, not collected evidence.

Sources read, not vibes

Open the source log
  1. Whiteboard repository and README: current product description, Code OSS base, agent canvas, code-linked diagrams, semantic diff, decision log, local checkout model, known limitations, privacy notes, and MIT license.
  2. Geoffrey Litt, "Understanding is the new bottleneck": understanding for participation, structured explainers, quizzes as a speed regulator, micro-worlds, and shared spaces.
  3. GitHub Docs, "Reviewing proposed changes in a pull request": review context, file-by-file inspection, viewed state, comments, approval choices, and stale-approval behavior when configured.
  4. Hacker News item 49833867: exact discovery thread and reader questions about editing, naming, diagram accuracy, drift, and semantic diffs.

Source boundary: Whiteboard describes its own product. Geoffrey Litt describes his practice and argument. GitHub documents its review interface and configurable repository behavior. Hacker News comments are reader reactions, not product facts. The isolation clutch is our design pattern, not a Whiteboard feature or security assessment.