Whiteboard Turns AI Code Review Into a Visual Design Session

A coding agent can open a pull request before you have finished forming a mental picture of what changed. The diff may be technically correct, yet the important questions remain fuzzy: Which component owns this behavior? What tradeoff did the agent make? What could break six weeks from now?

Whiteboard, an open-source project from /dev/fast’s YC Winter 2026 batch, is built around that uncomfortable gap. It is a desktop canvas where a human and a coding agent can look at the same change through diagrams, code links, structured diffs, and a record of the agent’s decisions. The launch title called it an IDE, an integrated development environment, but the current project description uses a more precise word: canvas.

The problem is not writing code fast

Modern coding agents are very good at moving from an issue to a working branch. They can inspect a repository, change several files, run tests, and explain the result in a terminal session. The trouble begins when the change is large enough that a short summary no longer gives a human enough confidence to approve it.

A raw diff shows what moved, but not always why the system needed to change. A design document may explain the original intention, but it can drift away from the implementation. The agent’s chat history contains useful clues, yet important decisions can disappear inside hundreds of lines of tool output.

How do you review AI-generated code without reading every line? Whiteboard’s answer is not to remove human judgment. It tries to give that judgment a better surface.

A canvas, not another editor

Whiteboard connects to coding tools such as Claude Code and Codex instead of asking you to abandon them. Its software development kit, or SDK, gives an agent a way to draw on an in-app canvas and connect visual explanations to the local codebase.

A useful mental model looks like this:

coding agent
 │
 ├── reads the local checkout and current change
 ├── draws diagrams through Whiteboard’s SDK
 └── links claims back to code, diffs, and traces
 ↓
 human review canvas

A local checkout is the copy of a Git repository on your computer. Whiteboard works against that checkout, so the review begins with the code you actually have rather than a detached screenshot or a generic explanation generated from a prompt.

The practical workflow starts with an instruction such as:

Review my current branch against main.
Draw the new data flow and the components that changed.
For each major design choice, link to the relevant files.
Call out assumptions, risks, and decisions the agent made autonomously.

The result is meant to be explored. A box in a diagram can lead to the implementation behind it. A statement from the agent’s explanation can point toward a diff or a related trace. Instead of switching between a terminal, a pull request, a diagram editor, and a chat window, you get a connected review of the same change.

Three details make the idea more than a diagram tool

Diagrams that point back to implementation

Whiteboard supports visualizations such as sequence diagrams, which show how messages move between parts of a system, and entity-relationship diagrams, which show how data objects relate to one another. Their value is not the picture by itself. The useful part is the path from a visual element to the code that gives it meaning.

The code view keeps familiar editor features, including keybindings and LSP support. LSP, or Language Server Protocol, is the standard that powers features such as jump-to-definition, symbol lookup, and context-aware navigation. That connection makes the canvas feel less like a presentation board and more like a map of a living codebase.

A diff that follows syntax

Most code review tools compare files as lines of text. Whiteboard adds a semantic diff viewer, meaning it tries to compare the structure and meaning of a program rather than treating every changed line as equally important.

The viewer uses an abstract syntax tree, or AST. An AST is a structured representation of code that separates functions, calls, conditions, and other language elements from their spelling on the page. That makes it possible to recognize that a function gained a new authorization branch, even when surrounding formatting changed too.

The project says its diff engine is written in Rust, a programming language known for speed and strong memory-safety guarantees. Large added functions can be reduced to pseudocode, while tests and documentation changes can be collapsed by default. A WebAssembly, or Wasm, plugin system provides a way to customize those rules without rebuilding the entire application.

A record of what the agent decided

The third layer is the decision log. Here, an agent trace means a record of the tools, files, outputs, and actions involved in a coding run. It is not a magic explanation of everything inside a model; it is evidence about how the change was produced.

Whiteboard lets agents link those traces to requirements and code. That creates a more useful review question than whether the final diff looks tidy: Which requirements did the agent act on, which choices were left to its judgment, and where should a human look more closely?

Local by design, open under the hood

Whiteboard is MIT-licensed and designed to run on local repositories. Its README says anonymous telemetry does not include source code, diffs, canvas text, prompts, or model output, and that telemetry can be disabled. For teams that cannot send private code to a hosted review service, that local-first approach is a meaningful part of the product rather than a footnote.

The repository also reveals that this is more than a drawing surface. It is a monorepo, a single repository containing several related packages. The desktop app and vendored Code OSS editor foundation live under apps/review-desktop; the packages/review area contains the command-line interface, embedded server, and canvas; other packages handle agent traces, protocols, local version-control helpers, and agent plugins.

Contributors currently work with Node.js 24 and pnpm 11. The documented starting point is compact:

pnpm install
pnpm dev

That structure explains the project’s ambition. Whiteboard is trying to connect the desktop shell, the review model, the agent bridge, and the code navigation layer instead of shipping another isolated AI feature.

The rough edges matter

Whiteboard does not currently edit files inside the app. Working across multiple repositories in one review is limited, and a shared review does not automatically show updates made after it was shared. Those constraints make its role clear: this is a companion to an editor, terminal, and coding agent, not a replacement for them.

There is also a deeper risk. Any design canvas can become another source of truth that slowly drifts away from the code. Whiteboard’s strongest defense is the direct connection between diagrams, diffs, traces, and files. Whether that connection stays useful as projects evolve will matter more than how polished the first canvas looks.

Whiteboard’s interesting bet is that faster code generation creates a new bottleneck: understanding. By giving AI coding agents a visual, navigable place to describe their work, it makes software design and open-source code review feel less like archaeology and more like a shared investigation. The project calls itself a canvas now, and that distinction fits. It is not where the agent writes everything. It is where humans regain enough context to decide what should happen next.