Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | code review / agents / human understanding

A faster queue is not a clearer system.

Agent sessions are getting easier to launch, sort, and resume. That does not mean the person approving the work understands the machine that came out.

The take: VS Code is making large agent-session lists faster. Whiteboard is building a review space where diagrams and decisions link back to code. The important split is now visible. Session throughput moves work. Comprehension tools let a person steer the next lap.
Build the review plan

The queue is becoming infrastructure.

VS Code 1.139 stores lightweight session and chat metadata in a central catalog. It no longer needs to open every conversation database to build the session list. Microsoft measured about a fourfold improvement in initial load and about an eightfold improvement in refresh with roughly 645 sessions on one development machine. The release notes warn that smaller collections will see less gain.[1]

The same release adds compact rows, in-place renaming, nested chat presentation choices, and remote Dev Container sessions over SSH, Tunnel, and WSL hosts. These are useful controls for a shop with a lot of parallel work.[1]

A session catalog tells you where the work is. It does not tell you whether the reviewer can explain the result.

The review tool is changing shape.

Whiteboard describes itself as a local desktop app where people and coding agents share a canvas. Its agent can draw diagrams, connect a review to code, and record decisions. Selecting a sequence diagram, entity relationship diagram, or quoted trace can take the reviewer to the related code. The editor side uses a vendored Code OSS fork for language services and code navigation.[2]

The interesting part is not the canvas. It is the route between an explanation and the implementation. A diagram without code links can become theater. A diff without a system model forces every reviewer to reconstruct the design alone.

Whiteboard also lists real limits. It cannot edit files today. Multi-repository review is not well supported. Shared reviews do not update after sharing unless somebody shares them again.[2] Those limits matter because a review surface should state what it cannot witness.

Understanding is a control input.

Geoffrey Litt argues that understanding is needed for participation, not only verification. His examples include an explainer that teaches background before code, a quiz that slows the handoff, and small interactive worlds that let a person operate the system.[3]

That changes the merge question. "Did the agent pass its checks?" is one question. "Can the maintainer form the next useful idea and recover when the design bends?" is another.

Give every large change four probes.

  1. Background: What system existed before this change?
  2. Route: Which request, decision, code path, and test belong together?
  3. Decision: What did the agent choose without explicit instruction?
  4. Teach-back: Can the accountable reviewer explain one failure path and the next safe edit?

The wind tunnel below writes a review-plan template. It does not inspect code, test a reviewer, validate a diagram, or approve a merge.

Interactive makeover / review planning

Review wind tunnel.

Traditional purpose replaced: one flat diff checklist. Better version: choose the review goal, clamp four comprehension probes into the change, and copy a plan that keeps selected structure separate from real evidence.

Set the review goal

Native radios and checkboxes own the state. Every selected probe names evidence the reviewer still has to produce.

Review goal
Comprehension probes
DRAFT REVIEW PLAN2 / 4 PROBES SELECTED

Verify review. The decision log and teach-back are still open.

Background model and change route are selected. Decision log and teach-back lap remain open.

Review questionDoes the implementation match the stated requirement and its tests?
Completion claim2 of 4 review-plan probes selected. No code or reviewer has been tested.
This teaching control writes review structure. It does not read the repository, verify code links, inspect agent traces, score human understanding, run tests, or authorize a merge.

Copy the tunnel card

Fill after copyingAdd the real requirement, base revision, changed revision, code links, test output, autonomous decisions, failure path, reviewer, and merge decision.

Sources read, not vibes

Open the source log
  1. Visual Studio Code 1.139 release notes: central metadata catalog, measured session-list results, compact rows, session naming, chat presentation, remote Dev Container sessions, and rollout limits.
  2. Whiteboard repository and README: local canvas, coding-agent connection, code-linked diagrams, decision log, Code OSS base, privacy summary, and current product limits.
  3. Geoffrey Litt, "Understanding is the new bottleneck": understanding for participation, background-first explainers, quizzes as speed regulators, interactive micro-worlds, and shared mental models.
  4. Hacker News discussion for Whiteboard: exact discussion route used for discovery. The thread does not verify the product claims above.

Source boundary: Microsoft reports measurements from one development machine and says gains vary with session count. Whiteboard describes its own design and limitations. Litt's piece is an argument backed by his working methods, not a controlled study. The four-probe review plan is our synthesis.