TL;DR
Whiteboard (devdotfast/whiteboard) is an MIT-licensed desktop app from the YC W26 startup dev.fast. It is not a coding agent and, despite the Show HN title, it is not really an IDE either: you cannot edit files in it. It is a canvas that your existing agent (Claude Code, Codex, Cursor, OpenCode, Pi) draws on through an MCP server, so that a large agent-written change arrives as a structured “whiteboard session” instead of a 40-file diff.
Three things make it more than a Mermaid renderer:
- Diagrams are attached to code. Every node in a sequence diagram, flow diagram or call-stack diff links to a pinned line range (
review-source:head/src/file.ts#L10-L24). Click it, and a vendored Code OSS editor opens those lines with LSP intact. - A semantic, AST-aware diff viewer written in Rust. Large added functions collapse into pseudocode; tests and docs fold away by default. Customisable with WASM plugins.
- A decision log. Agents can query and link their own session traces, so the whiteboard records which decisions were your requirements and which the agent made alone.
Key facts as of 2026-09-27:
- Stars: 1,721; repo created 2026-08-18; v0.1.0 tagged 2026-09-24, v0.1.3 on 2026-09-26
- Launch: Show HN on 2026-09-24, 412 points and ~140 comments
- Platforms: macOS, Windows, Ubuntu, Fedora; the macOS build is roughly 736 MB
- Price: free and local-only. A hosted multiplayer product is planned; everything stays self-hostable
- Requires: Node 24 for the headless
reviewCLI; the desktop app bundles its runtime
Verdict: the most polished attempt yet at the “explain the change before I approve it” workflow. Worth installing if you review agent-written PRs weekly. Not worth it if you already work comfortably in a TUI and a plain-text plan file.
Quick reference
| Repo | github.com/devdotfast/whiteboard |
| Stars / forks | 1,721 / 77 (2026-09-27) |
| License | MIT (vendored Code OSS keeps Microsoft’s MIT licence and third-party notices) |
| Language | TypeScript (Electron/Code OSS shell), Rust (semantic diff engine, compiled to WASM) |
| Install | install.dev.fast (macOS), /windows, /linux/ubuntu, /linux (Fedora) |
| Agents supported | Claude Code, Codex, Cursor, OpenCode, Pi; Copilot CLI tracked in issue #593 |
| Agent integration | stdio MCP server: ~/.local/bin/whiteboard mcp |
| Data home | ~/.dev (DEV_REVIEW_HOME), SQLite review-api.db |
| Website / community | dev.fast · Discord · Show HN thread |
| Maintainers | Sid Menon, Alex, Ketan, Milan (dev.fast, YC W26) |
What Whiteboard is
The founders describe Whiteboard as “an open-source canvas for thoughtful software design”. The premise: agentic coding makes code cheap to produce and expensive to understand. Their MVP was agent-generated HTML artifacts, and three walls shaped the product.
Diagrams that lead to code. HTML artifacts cannot connect a box to the function it represents. Whiteboard vendors Code OSS (the open-source core of VS Code) so that clicking a diagram node, a code peek or a trace quote jumps into a real editor with go-to-definition and LSP. They vendor rather than patch because “coding agents have a hard time with patches”, and because roughly 45% of stock VS Code is Copilot code they do not need.
Semantic diff viewer. A Rust engine parses both sides of a change. Large new functions render as pseudocode, tests and docs collapse, renames are tracked. A WASM plugin system changes those rules. The founders admit this engine alone is 138 MB of the download.
Decision log. Experimental trace capture hooks each agent’s session lifecycle (Claude Code and Codex via hook settings, Pi via an extension, OpenCode via a plugin) and stores transcripts in your S3/R2 bucket or dev.fast’s hosted store. The agent can then search its own past sessions through the fff MCP server and link “why this exists” evidence into the whiteboard.
Why it is trending now
The Show HN on 2026-09-24 landed at 412 points, high for a local-only developer tool. The first comment, from user bbor, called the streaming pen-drawing diagrams “a technique that’ll be everywhere in 12 months.” Several commenters said they had built something similar for themselves: a skill that generates a flow-map website, an interactive “explainer” per feature, a TUI for narrative reviews (mtford90/revue). Simon Willison’s showboat came up too. Whiteboard is the first of these to ship as a packaged product with a YC label.
It also arrived in the same month as Archify, the 61K-star agent skill that renders validated architecture diagrams from a typed JSON IR. They overlap on “agent draws architecture” but differ on scope: Archify is a diagram skill, Whiteboard is a review workflow with diagrams inside it.
How a whiteboard session works
The app serves its own agent instructions rather than shipping a long system prompt. A Pi skill in the repo is five lines long and boils down to one command:
whiteboard api session_get_instructions '{}'
# or, for the two other modes:
whiteboard api session_get_instructions '{"topic":"scratchpad"}'
whiteboard api session_get_instructions '{"topic":"trace-archaeology"}'
The instructions returned (packages/review/instructions/authoring.md) tell the agent to write “an interactive RFC-style whiteboard, for consumption by a staff engineer”:
- Register the repository; create a whiteboard pinned to the commits or PR
- Spawn a subagent to group changed files into “file lenses”
- Read the diff with
session_diff - Write What/Why, then Requirements (in the user’s own words), Design, Implementation
- Read the whole whiteboard back and fix contradictions before finishing
The Design section picks one diagram type based on the shape of the change:
| Component | Use when |
|---|---|
sequence | Participants interact over time (who calls whom, async handoffs) |
flow_diagram | The interesting part is branches, retries or state transitions |
database_lens | A schema change, and who reads/writes the tables |
code_peek | A new or changed contract: show the key types inline |
call_stack_diff | Old vs new path through a user flow, rooted at the entry point |
Every claim that describes real code must hyperlink it with a repository-relative path and verified line numbers, base for old code and head for new. That rule is what makes hallucinated architecture less likely than in a Mermaid block: the canvas can tell when a linked range no longer exists.
The JSON review API
The desktop app and the headless review server share one SQLite store and the same token-protected HTTP routes under /reviews-api: register a repository (POST /repositories), pin base and head commits (POST /pins), read the diff (GET /:id/diff?format=patch), and apply edits (POST /commands). An edit inserts a Markdown block or a diagram component:
{
"commandId": "8575b264-9ef4-46c9-af3c-8185545aeebd",
"operation": {
"type": "edit",
"reviewId": "<returned by create>",
"edit": {
"type": "insert",
"content": { "type": "markdown", "markdown": "# Summary\n\nWhat changed." }
}
}
}
Writes go through an authoring lease per review, so two agents cannot silently overwrite each other, and every saved version keeps the command inputs as receipts. GET /:id?version=2&full=true returns a historical snapshot.
The review_diff tool deserves a mention: it prefixes both base and head line numbers on every hunk line, drops the noisy index/---/+++ headers, and enforces a 40,000-byte budget with a closing line naming the files it cut. Small decision, big difference in how well an agent reads a diff.
Getting started
- Download the app from install.dev.fast for your platform. On first launch it detects installed agents (Claude Code, Codex, Cursor, Pi, OpenCode), offers to install the CLI and skills, and writes a
whiteboardshim to~/.local/bin. - The Claude Code plugin is a plain
.mcp.json:
{
"mcpServers": {
"whiteboard": {
"command": "sh",
"args": ["-c", "exec \"$HOME/.local/bin/whiteboard\" mcp"]
}
}
}
Codex uses an equivalent wrapper script in packages/agent-plugins/codex/bin/whiteboard-mcp. Cursor gets a mcp.json; Pi gets a skill.
-
In your agent, ask for a session. The README’s example: “this stack of commits is set up so i can get an [api] to do [objective]. i’d like to see: proposed api, examples, motivations… use whiteboard.”
-
Optional guidance:
~/.dev/DEV-REVIEW.mdfor user preferences,DEV-REVIEW.mdat a repo root for project rules (repo wins). Headless:review server start --state-dir <dir>runs the API without the desktop;review info --alllists active reviews per worktree.
The README recommends GPT-6 Sol and Claude Opus 5.5 “for their intelligence, cost, and speed tradeoff”. Cheaper models work but produce thinner whiteboards, because the instructions ask the model to verify line ranges and read the result back.
Community reaction
The Show HN thread is unusually substantive. By theme:
“Is this a feature or a product?” The most common pushback. User 2001zhaozhao asked how much better it is than “some simple custom Mermaid format”; nnevatie asked why Markdown plus Mermaid would not do. Sid Menon’s answer: Markdown editors do not give you go-to-definition, a diff viewer, or a way to tie a spec to a code range from one interface. He also said Whiteboard will be exposed as an MCP UI so it can render inside Codex Desktop, Superset, Conductor or Emdash without the standalone app.
The N+1 source of truth. User asdev argued a design artifact inherently drifts, and that an agent keeping it updated would degrade it into “unintelligible slop”. Co-founder Milan agreed the concern is real and pointed to the hosted product. Ketan was blunter: the artifacts are ephemeral; the lasting outputs are better-understood code and an updated mental model.
Accuracy. User 8organicbits spotted a “wait for release” transition in the demo GIF that did not match the diff. The founders admitted the GIF was a design mock they forgot to replace and said real diagrams are linked to code, so that mismatch cannot happen silently. Credit for the honesty; still a reminder to check.
Size and naming. factorialboy: “736mb on macOS /facepalm”. Sid compared it to Cursor at ~1 GB and Zed at ~400 MB and said a native rewrite is planned. Several commenters noted a tool that cannot edit files is an odd IDE (“I Don’t Edit”, per altmanaltman); the team renamed it “canvas” in PR #587 within two days. Windows and Ubuntu builds shipped the day after launch.
Privacy scare, resolved. satwikhebbar reported Codex warning that Whiteboard “requires uploading/exposing repository data to its authoring server”. A maintainer clarified the “authoring server” is the stdio MCP process on your own machine; repository data leaves the box only for opt-in bug reports or shared sessions.
Alternatives named: LikeC4 and erode.dev (C4 architecture-as-code), PlantUML’s C4 stdlib, whiteboard-mcp.com, revue and showboat.
Honest limitations
- No editing. Whiteboard is a review surface; you still fix things in your agent or editor.
- Single-repo reviews. Multi-repository sessions are not well supported, per the README.
- Sharing is a snapshot. Later updates do not sync to people you shared with; you re-share.
- Download size. ~736 MB on macOS: a full Code OSS build plus a 138 MB diff engine.
- Early. The first tagged release was three days before this review. Expect schema churn (
REVIEW_SCHEMA_VERSIONis already 5; areview migrate applycommand moves legacy MDX reviews). - Trace capture is experimental: a second MCP server (
fff), git hook dispatchers, and your own S3/R2 bucket or the hosted store. Off by default. - Telemetry is on by default. Anonymous, via PostHog, excluding code, diffs, whiteboard text, prompts and model output. Event list in
docs/telemetry.md; switch it off in Settings. - Model-dependent quality. On weaker models you get pretty diagrams with fewer verified links.
Who should use Whiteboard
Good fit: tech leads reviewing agent-written PRs who want a design-level pass before the line-level one; teams running an automated reviewer (the founders mention Greptile) that need an escalation path for changes requiring human judgement; anyone who asked Claude Code for “a diagram of this change” and got a Mermaid block that did not match the code.
Poor fit: terminal-native developers happy with git diff and a plan file who do not want a 736 MB Electron app; teams needing a web-based or multiplayer review surface today; changes spanning several repositories.
Comparison with alternatives
| Tool | What it produces | Linked to code? | Runs where | License |
|---|---|---|---|---|
| Whiteboard | RFC-style session: prose, sequence/flow/DB diagrams, semantic diff, decision log | Yes, pinned line ranges into a Code OSS editor | Local desktop app + MCP | MIT |
| Archify | Validated interactive architecture diagrams from a typed JSON IR | Partly (validated against codebase, no editor jump) | Agent skill, browser render | Open source |
| Mermaid in Markdown | Static diagrams inside a plan or PR description | No | Anywhere | N/A |
| Greptile / CodeRabbit / Open Code Review | Automated line-level review comments | Yes, on the PR | CI / GitHub app | Mixed |
| revue / showboat | Narrative “guided tour” of a change | Yes, sequential | TUI / static | Open source |
The distinct position is the combination: agent-authored, diagram-first, every box resolvable to a verified line range. Nothing else in the table does all three.
FAQ
Is Whiteboard free? Yes. MIT-licensed, local-only, no account required. A paid hosted product for teams (multiplayer, PR-triggered reviews) is planned; the founders say the local app stays self-hostable.
Which coding agents does it support?
Claude Code, Codex, Cursor, OpenCode and Pi have first-party plugins in packages/agent-plugins/. Copilot CLI is tracked in issue #593. Any agent that can run a stdio MCP server can use whiteboard mcp directly.
Does my code get uploaded anywhere? Not by default. The MCP “authoring server” runs on your machine and anonymous telemetry excludes code and prompts. Content leaves only if you share a session, opt into a bug report, or enable trace capture with the hosted store.
Can I edit code in Whiteboard? No. It is a review canvas built on Code OSS for navigation, not editing. The team renamed it from “IDE” to “canvas” after launch feedback.
How is this different from asking Claude Code for a Mermaid diagram?
Whiteboard diagrams carry pinned review-source: links, so each node opens the exact code and the canvas can detect drift. The Rust semantic diff hides tests and docs and summarises large additions as pseudocode. Mermaid gives you a picture; Whiteboard gives you a navigable one.
Does it work on Linux and Windows? Yes. macOS shipped first; Windows, Ubuntu and Fedora builds landed on 2026-09-25 after Show HN requests.
What is the “decision log”?
With experimental trace capture enabled, the agent can search its own session history (trace-archaeology mode) and cite which decisions were your requirements and which it made autonomously.
Bottom line
Whiteboard is a well-built answer to a question everyone using coding agents now has: how do I understand a change I did not write before I approve it? The linked diagrams and the Rust semantic diff are genuinely new, the Code OSS base makes navigation feel normal, and the founders answered a tough HN thread by shipping Windows, Linux and the “canvas” rename within 48 hours.
The open questions are the thread’s: artifacts drift, the app is heavy, and much of the value may eventually arrive as an MCP UI inside the harness you already use. For now, if you review agent-written code weekly, install it and run one session on your next large PR. You will know in fifteen minutes whether the “whiteboard with a colleague” feeling is real.
Sources
- devdotfast/whiteboard on GitHub (README,
packages/review/README.md,packages/review/src/review-api/README.md,packages/review/instructions/authoring.md,packages/agent-plugins/, releases v0.1.0–v0.1.3) - Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design (2026-09-24, 412 points)
- dev.fast and install.dev.fast
- Whiteboard demo video