The idea that an AI agent can write code is well established. The harder problem is getting the agent to explain what it wrote, why it chose that approach, and how its decisions map to the original requirements. Whiteboard, an open-source desktop application from devdotfast, is built around that specific gap: it gives agents a canvas to visualize their reasoning and gives developers a way to trace those visualizations back to the underlying code.

Why Text Diffs Are Not Enough

When an AI coding agent completes a task, the developer's standard review process is to look at a diff. Raw diff views present every added and removed line without context about why those changes were made or how they relate to the original requirements. A function might be refactored, a test added, and a configuration file updated, all in the same pull request, but the diff view offers no indication of which change addressed which requirement or which decision was made autonomously by the agent versus directed by the developer.

The Whiteboard team's observation is practical rather than theoretical. They found it difficult to reason about what set of decisions their own agents made autonomously and how those decisions impacted a change. That friction is what the application was built to address.

How Whiteboard Works

Whiteboard is a desktop application that connects to existing coding agents like Claude Code and Codex. The connection process starts from the app's welcome screen. Once linked, a developer can ask the agent to review a branch against the latest main branch and have the results open directly inside Whiteboard rather than in a terminal or a web interface.

The agent is given an SDK that lets it draw on an in-app canvas. This means the agent can produce sequence diagrams, entity relationship diagrams, and annotated trace excerpts as part of its output rather than relying solely on text. When a developer clicks on one of those visualizations, they jump directly to the underlying code that generated it. This creates a two-way link between the agent's reasoning and the codebase, which is something neither a chat window nor a diff viewer can provide.

The application also includes a semantic diff viewer written in Rust. Unlike a raw git diff, which shows every change line by line, this viewer analyzes the abstract syntax tree of the code to surface only the changes that are meaningful to the current review. Large added functions are summarized as pseudocode. Unit tests and documentation changes are collapsed or hidden by default, reducing the noise that typically overwhelms a review.

Agent Traces as a Development Tool

One of the more distinctive features is the trace visualization system. Developers can query and link an agent's own execution traces on the Whiteboard canvas. This means you can see the requirements that were set, understand how the agent implemented them, and identify which decisions the agent made on its own. The intent is to turn the agent's reasoning from a black box into a visible, inspectable part of the development workflow.

The application also supports a feedback loop where a developer can highlight something they disagree with in their clipboard, hand it to the agent, and have the agent redraw its visualization on the Whiteboard to address the concern. This is a refinement process rather than a one-shot generation, which mirrors how human design reviews typically work.

The Codebase Behind It

Whiteboard is built on a vendored fork of Code OSS, the open-source version of VS Code. The team chose this approach rather than maintaining patches on top of a standard VS Code build, partly because coding agents struggle with patch-based workflows and partly because roughly 45 percent of the current VS Code codebase is Copilot-specific functionality that Whiteboard does not need. The team monitors upstream Code OSS and merges in security and feature patches as they are released.

The application runs against local checkouts and is MIT-licensed. Anonymous telemetry collects usage data but does not include code, diffs, Whiteboard text, prompts, or model output. A hosted product for teams is planned, though the team has stated that everything will always remain self-hostable.

Where It Is Still Immature

The application has explicit limitations that are worth noting. File editing is not currently supported within Whiteboard, which means it functions as a review and visualization tool rather than a full IDE. Working across multiple repositories in a single review is not well supported. And while reviews can be shared between machines using a share button, updates made after a review is shared do not appear for the recipient; the review would need to be shared again.

These gaps are the kind that emerge early in a product designed around a new interaction model. The core idea, connecting an agent's visual reasoning directly to code, is sound. Whether Whiteboard becomes the standard for that interaction or one of several competing approaches remains to be seen.