Whiteboard reached 277 points and 110 comments in this story's Hacker News snapshot, but the revealing moment was a correction. A commenter traced a label in the demo diagram back to the diff on screen and found that the two did not match. The team replied that the GIF was a notional design asset left on the page by mistake and said it would replace it with output from the app. That small public stumble frames the job Whiteboard has chosen: making agent-generated explanations trustworthy enough to review code through them.
The new MIT-licensed desktop app connects to coding agents such as Claude Code and Codex, then gives them a canvas for explaining a branch. The launch focuses on the human side of the loop after the model has produced code. Agents can produce a large patch quickly. The developer still has to work out what changed and why the agent chose that implementation. Then comes the harder check: does the result match the request? Whiteboard puts those questions in the interface instead of leaving them buried in a transcript.
The diagram has a route back to the code
A normal diagram generated by a model is easy to admire and hard to audit. Whiteboard's answer is to make each useful object a navigation point. According to the project repository, clicking a sequence diagram, entity relationship diagram, or excerpt from an agent trace can take the reviewer to the underlying code. The app is built on Code OSS, so that jump lands in an editor surface with familiar keyboard controls and language-server support.
The starting workflow is deliberately narrow. You open the desktop app and connect an existing coding agent. Then you ask it to compare the current branch with an updated main branch. The agent can draw its explanation through Whiteboard's SDK. The resulting canvas can map the system and link code to the decisions behind it. If a reviewer selects something that looks wrong, the project suggests sending that selection back to the agent so it can redraw the explanation.
The agent redraws its explanation while file editing stays in the coding tool. Whiteboard's published limitations say the app cannot currently change files. It is a review environment beside the coding agent, rather than a replacement editor that also writes the patch. Multi-repository review is poorly supported, and a shared review does not update after the sender changes it. The sender has to share a fresh copy.
The decision log is the more unusual part. Whiteboard lets an agent link its trace to requirements and code, giving the reviewer a way to inspect which choices came from the developer and which were made autonomously. The product demo shows a storage change tied to a specific instruction about using one transaction, followed by the files and agent activity that implemented it. A line-by-line diff can tell you that two writes now share a transaction. The linked trace can tell you why that constraint existed.
The diff is opinionated about attention
Whiteboard also tries to reduce the amount of code a reviewer must scan. Its semantic diff viewer uses diffr, a Rust library that parses code into syntax trees. Large added functions can appear as pseudocode, while tests and documentation are collapsed by default. Function signatures remain visible. Reviewers can expand the original code when the summary is too thin, and a WebAssembly plugin system can change the presentation rules.
Those defaults amount to an editorial judgment about a patch. Tests may be repetitive, yet a changed assertion can expose behavior that the implementation summary missed. Pseudocode can make control flow legible, while also smoothing over an error in a condition or return type. That tension remains. It gives the reviewer a faster route through a large change and leaves the underlying code available for inspection. Teams will have to decide which files deserve expansion every time.
Diffr's own README calls the library experimental and alpha. Its API may break, and semantic summarization currently supports only Gemini-class models. The plugin API is due for a major simplification. Those limits put useful boundaries around Whiteboard's launch pitch. The structural folding exists today, but its model-written summaries and extension interface are still early.
The mistaken launch GIF offers a blunt preview of the failure mode. A polished diagram can look authoritative even when one label is unsupported by the code beside it. In the Hacker News exchange, the team said real diagrams are linked to code and acknowledged that the published example was a placeholder. The link back to a source line is part of the product's safety model. Reviewers still need to click it.
Local checkouts have network edges
Whiteboard runs against local repositories and stores authored boards in a SQLite file under ~/.dev by default. Several paths still send data off the machine. The project's privacy documentation says anonymous telemetry is enabled unless the user turns it off. Passive events may include feature usage, durations, versions, operating-system categories, and cleaned error data. The project says those events exclude source code, diffs, paths, repository names, Whiteboard text, prompts, and model output.
Crash handling deserves a closer read. Electron crash dumps can contain process memory, including source text that was open at the time. On the next launch, Whiteboard says, the app uploads a dump to its bug-report service. The service retains it for 30 days, and the local copy is removed after upload. Turning telemetry off deletes those dumps without uploading them. Developers who work on private code can disable collection in settings or use the documented environment variable for a command:
DO_NOT_TRACK=1 whiteboard info
Manual bug reports follow different rules. The dialog can attach the saved Whiteboard record and changed diff lines. It can also include a screenshot. The session and diff attachments are selected by default, though the user can clear them before sending. Sharing is also explicit: the whiteboard share command uploads an immutable board containing its text, images, software maps, pinned commits, the user's GitHub login, and the repository clone URL. Recipients fetch the pinned source commits through their own GitHub access.
The same document describes an optional hosted trace store with a much wider payload. Per-repository consent is required, and capture starts off. Once enabled for a repository, a complete agent transcript may include prompts, model output, code, file paths, URLs, and email addresses. Access is limited to GitHub users who currently have push permission or higher, but the service uses server-controlled encryption keys. For a tool built around sensitive development history, these distinctions are worth checking before a team enables sharing or hosted traces.
The product is still early
The app is available for macOS and Linux, and the repository carries an MIT license. The team has also said it plans a paid hosted product for session creation and multiplayer review, including stored trajectories, while keeping the software self-hostable. That commercial direction explains why the local desktop app already sits beside explicit sharing and a hosted trace service in the documentation.
For now, the rough edges define who should try it. A developer reviewing a large agent-authored change in one repository fits the current workflow. A team expecting live collaborative editing, automatic updates to shared boards, or a complete multi-repo map will run into the stated limits. The app also inherits the maintenance burden of a vendored Code OSS fork, which the project says it monitors for upstream security and feature patches.
The next evidence to watch is concrete: whether diagrams stay tied to the current revision and whether diffr's summaries cover more model providers without concealing important edits. Live shared reviews are the other promised step. Whiteboard's 277-point debut shows that developers recognize the review problem. Its harder measure will be what happens after someone clicks a box on the canvas: do they reach the exact decision and code that justify it, or another explanation they must take on faith?