Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | design / review / agent interfaces

Make the agent draw before the diff gets loud.

A shared canvas can expose the shape of a change before review turns into file-by-file archaeology. The drawing earns trust only when it links to code, carries a failure path, and survives contact with the revision.

The take. Treat an agent-drawn diagram as a review instrument. Pin its scope, walk one real route, anchor claims to files, and draw the route that fails. Then ask reviewers to challenge the map before they inspect the patch.
Open the Canvas Alignment Table

The canvas moved into the coding loop.

Whiteboard is an open-source desktop app that connects to coding agents and gives them an in-app canvas. Its README shows an agent drawing a sequence diagram, expanding pseudocode, and opening a named implementation symbol while the developer asks follow-up questions.[1] Release 0.1.2 was published on September 24.[2]

This is a useful change in interface. Chat is good at turn-taking. A canvas is better at holding several relationships in view. The reviewer can point at a route, compare branches, and ask what the picture omitted.

A picture can still dodge the hard part.

An agent can draw a clean diagram that reflects its own guess. The boxes can have plausible names while the arrows skip retries, state changes, authorization checks, or error handling. Visual clarity does not verify the model.

The map becomes reviewable when every important arrow has a code anchor and every happy route has a named way to fail.

Start with one request or event. Follow it through real symbols at one revision. Mark the point where state changes. Add the branch that rejects, retries, times out, or rolls back. If the diagram cannot survive that walk, fix the diagram before asking the reviewer to trust its explanation.

Review automation needs a review object.

GitHub now lets users configure automatic Copilot reviews for pull requests, draft pull requests, and new pushes. It also exposes Lite and Balanced review effort, with enterprise defaults and repository overrides.[3] Those settings decide when a review runs and how much effort the service applies. They do not decide whether the author supplied a useful model of the change.

Attach a compact design packet to the pull request. Include the diagram, revision, route under review, code anchors, failure path, unresolved questions, and reviewer corrections. Automation can inspect the packet. Humans can dispute it. Later readers can recover the reason without replaying the whole agent session.

Navigation closes the gap.

Zed 1.21 added a language server command picker and support for language servers to open files and URLs through showDocument requests.[4] That release note describes editor behavior, not Whiteboard integration. The useful pattern is broader. Explanations should open the exact code they describe.

A review canvas should make each file, symbol, test, and issue link actionable. The diagram remains a guide. The repository remains the source. Fast navigation lets the reviewer cross the boundary without hunting.

Use the four-layer packet.

  1. Scope one change. Name what is inside the drawing and what is outside.
  2. Walk one real request or event through the current revision.
  3. Anchor every important node and arrow to a file, symbol, test, or issue.
  4. Challenge the happy route with a rejection, timeout, retry, rollback, or stale-state case.
Interactive makeover / layered design inspection

Canvas Alignment Table

Traditional purpose replaced: a static architecture picture that asks the reviewer to trust the boxes. Better version: switch four transparent inspection layers on and off. The shared table exposes what is present, what is missing, and which fields still need real evidence.

Stack the review layers

Select the layers that the change packet will contain. The glass table shows how each layer contributes to one review object. Selection defines the template. It does not fill the evidence.

Review packet layers
TEMPLATE EMPTY0 OF 4
Packet stateNo review layer is selected.

Choose the information the author must supply before review. Every field remains unverified until a person or tool checks it against the pinned revision.

Scope and revisionOPEN
End-to-end walkOPEN
Code and test anchorsOPEN
Failure and correction recordOPEN
Next move. Select at least one layer, then replace its required markers with links and facts from the current revision.

Print the canvas packet

Evidence still requiredThe generated packet contains required markers. Selection changes its structure and status. It never changes a marker to passed, verified, or ready.

Sources read, not vibes

Open the source log
  1. Whiteboard repository and README. Product scope, supported agent connections, in-app drawing SDK, example sequence diagram, pseudocode expansion, and code navigation.
  2. Whiteboard v0.1.2 release. Release identity and publication date.
  3. GitHub Changelog. Automatic review triggers, personal review settings, Lite and Balanced effort, enterprise defaults, and repository overrides.
  4. Zed 1.21 release notes. Language server command picker and showDocument support for opening files and URLs.
  5. Hacker News discussion for Whiteboard. Discovery and public discussion source. The discussion does not verify product behavior.

Source boundary. Whiteboard documents its own product and examples. GitHub documents its review settings. Zed documents editor navigation behavior. No source shows these products working together. This dispatch combines their published interaction patterns into a review method. The Canvas Alignment Table is a teaching tool.