devdotfast/whiteboard

Worth trying if you already hand long tasks to a coding agent and regularly lose the plot of what it decided. Treat it as a review and explanation surface rather than a replacement editor.

The problem

When an agent finishes a multi-commit change, the usual output is a wall of diff plus a prose summary. You want to understand the shape of the change first — the proposed API, the data model, the call sequence — and only then look at lines. Today that means asking the agent for a Mermaid diagram in a file, pasting it elsewhere, and then hunting through the repo to find the code each box refers to. In Whiteboard the agent draws into an in-app canvas and you click a diagram node or a quoted trace step to jump to the underlying code, so the explanation and the implementation stay in one place.

What's different

The mechanism is an SDK and plugin surface that lets an agent (Claude Code, Codex, or another connected coding agent) write visualizations into a shared workspace. Clicking a sequence diagram, entity-relationship diagram or trace excerpt opens the relevant source, and the embedded editor — a vendored Code OSS build — supplies VSCode keybindings and LSP support for navigation. A Rust-written AST-aware diff viewer sits alongside: it summarizes large added functions as pseudocode and collapses test and documentation changes by default, with WASM plugins to change that behavior. Agents can also query and link their own traces, which is aimed at reconstructing which decisions were made autonomously and why.

The main trade-off is that this is a second app beside your editor and agent terminal. The visual output exists because your agent chose to use the SDK, so prompt discipline still matters; the README offers example prompts and says good defaults are still being baked into the system prompt. Vendoring Code OSS instead of patching also means the project carries upstream merges itself — the README says security and feature patches are merged regularly, but that is a maintenance commitment to watch, not a guarantee.

Who should try it

Good fit: a developer who reviews agent-generated branches and mainly needs architecture-level understanding — API shape, schema, telemetry additions, request flow — before line-level review. A commenter's framing of the gap fits that use case: existing plan modes make it awkward to iterate visually on an architecture with an agent comment by 2001zhaozhao. Poor fit: someone who wants to edit code in the same window, or who reviews changes spanning several repositories. The README lists no file editing yet and says cross-repo review is not well supported, so the editing gap pushes you back to another editor and the multi-repo gap limits monorepo-adjacent workflows. The 1-minute demo is the fastest way to judge whether the output style suits you.

Requirements and limitations

It is a desktop app for macOS, Windows and Linux, distributed through the download page or a Homebrew cask; there is no browser version described. You need a connected coding agent that can drive the SDK, plus local checkouts, since Whiteboard runs against your machine rather than a hosted copy of the code. Anonymous telemetry is described as excluding code, diffs, prompts and model output, and can be turned off.

Three documented limits matter in practice: files cannot be edited in Whiteboard; sharing a review is a snapshot, so later updates do not appear for recipients and you must re-share; and browsing files across multiple repos in one review is poorly supported. Budget for upkeep too: because the editor is a vendored fork rather than a patch set, staying current depends on the maintainers' upstream merge cadence.

HotRepo's take

On 2026-10-25 the project appeared on HotRepo's monthly TypeScript board at #10 with +2,476 stars that month, at 67 days old; the stored sample covers only that single date, so persistence cannot be judged from it. The Show HN thread drew 424 points and 143 comments on 2026-09-24, which indicates discussion volume, not consensus. Before committing, verify the agent-connection and plugin documentation covers the agent you actually use — the canvas is only as useful as the SDK integration behind it.