Show HN: Whiteboard (YC W26) ā An open-source IDE for thoughtful software design
127 points - today at 5:21 PM
Hello! Weāre Sid, Alex, Ketan, and Milan. Weāre building Whiteboard, an open-source desktop app where humans and agents can architect software together in a common workspace. Hereās our repo: https://github.com/devdotfast/whiteboard and our homepage: https://whiteboard.dev.fast/
We were missing the feeling of a āwhiteboard sessionā with another dev where you leave with a deep understanding of a system, so we built this app for ourselves. Whiteboard plugs into the tools you already use - e.g. Claude Code, Codex, etc. ā and gives your agent an SDK to draw on an in-app canvas to describe its work. We began with an MVP based on HTML artifacts and started rethinking the app as we ran into limitations:
1. Built on top of CodeOSS: We found that in pure HTML tools it was hard to connect a spec or diagram to code. In Whiteboard, when you click on visualizations like a sequence diagram, an entity relationship diagram, or a quote from the agentās trace, you can jump to the underlying code directly. When navigating code, you get keybindings and LSP support from VSCode out of the box. Weāve found this is especially valuable because tradeoffs are often only discovered after a first pass at implementation (re: slop)
2. Semantic diff viewer: we wrote a semantic, AST-aware diff viewer in Rust so you can only view the code changes which are relevant to you [1]. Weāve set up some sane defaults: large added functions are summarized as pseudocode, and things like unit tests and large documentation changes are collapsed / hidden. This is all customizable with a WASM-based plugin system.
3. Decision Log: We found it difficult to reason about what set of decisions our agents made autonomously. So we built tools for agents to query and link their own traces to the Whiteboard, so you can understand how the requirements that you set were implemented, and understand what decisions your agent made autonomously.
Hereās a quick demo video explaining more: https://www.youtube.com/watch?v=ChPn3ftULWE
Folks at companies like Salesforce and Modal are using Whiteboard today as a review tool for architecture or spec-level changes ā really any change where they want to be involved:
1. Reviewing your own coding agentās work: because Whiteboard makes it easier to review large amounts of code, folks will typically have their AI agents create a prototype and a corresponding Whiteboard session so they can iterate on the design.
2. Reviewing other peopleās changes: Weāve found that Whiteboard is particularly helpful when composed with tools like Greptile. For example, you can run an automated code reviewer on small changes and escalate to a Whiteboard session for the changes that require human judgement.
Why we built this: weāre four buddies from college who quit our jobs as tech leads right before agentic coding became industry standard. As we iterated towards an MVP for a previous idea, we struggled to maintain a comprehensible codebase while reaping all the velocity benefits of agentic coding. As more PRs were merged without our understanding, we felt a ācognitive debtā begin to seep in, until it became difficult for us to even contribute to the system [2].
Weāre releasing our desktop app under an MIT license. Please poke through and feel free to contribute! Eventually weāll charge companies for a hosted web version that manages whiteboard session creation alongside features like trajectory storage and multiplayer reviews. Everything will always remain self-hostable.
Thanks for reading, and we hope you try it out! We would love to hear any feedback and to learn from your expertise.
Hereās are the project links again: https://github.com/devdotfast/whiteboard, and you can install (for MacOS + Linux) at https://install.dev.fast
[1] diffs library: https://github.com/devdotfast/diffr [2] Credit for the term ācognitive debtā goes to https://www.geoffreylitt.com/2026/07/02/understanding-is-the...
Comments
Looking at the code the "no" seems to relate to the context expiring, so you wouldn't want to wait more if the context already expired, you'd want to stop. Is there a reason that label exists?
I'm pretty wary of LLM development tools hallucinating and wasting my time, is that whats happening in the lease broker example?
~~[EDIT: you need to put "only for macOS" in way more prominent places, all over -- that offends my soul greatly and may Linus frown upon you all]~~ [EDIT2: I was mistaken!]
This all looks really solid. That said, two remarks:
1. The integration with OS LSPs is quite fun and commendable. Is it possible that the diagrams might get their own LSP, someday? Or is better just staying as direct TS callsites?
2. The choice of the word "IDE" seems like it might get you in trouble, given the small "cannot edit files" detail. Any comments on the decision there, as opposed to, say... "brainstorming tool"? Or hell, "[architectonic] harness"?
3. The psuedocode "semantic diff" thing is an incredible idea, wow. Props there.
4. This language kinda concerns me: "how the requirements that you set were implemented". In my highly-arbitrary development flow, it ideally goes `idea -> spec/reqs -> plan -> test -> impl -> eval -> land -> review`, and this kind of tool seems explicitly targeted towards just the second and third with some partial coverage of their neighbors on either side. More concretely: by adding implementation, don't you lose a powerful specificity selling point and now have to compete with all full harnesses?
5. Suggesting "GPT-6 Luna and Claude Opus 5.5" is presumably a typo? Cause the equivelant of Opus 5.5 is Astra, and even then not really.
The cool thing is even though this tool addresses a few, use case for reducing cognitive load, they happen so frequently that they add up.
I think they key with cognitive load is that the agents often produce a lot of trace/docs etc, in the end only a small % of the traces really are important to the final changes, because concise changes are typically very small and self contained.
One thing i see this becoming important with is maintaining internal tooling built using this. I maintain an internal docs system that helps me do designing before i build code, that docs system is completely vibe coded and i can add features to it very fast, but now its all grown up. A challenge then is can i understand just enough about a new proposed change to approve it? That is key to the doc system not becoming a burden in of itself, while maintaining a tight core feature set.
From the website demos i definitely think this is a clean interface, although I don't know how much better this is compared to some simple custom Mermaid format, which the agent can write as artifact files and present to users. Zooming out, this app seems like 1 feature (a MCP with a GUI attached to it) rather than an entire product.
Also, I don't know if asking the agent to write specific code changes into the plan is a good idea. I think maybe that a "plan -> approve -> write code" would let the agent write higher quality code than "plan which contains code -> approve". But maybe you can make it work when combined with some specific prompting marking the code as clearly work-in-progress and subject to change, and that the agent should surface any parts implemented differently relative to the plan to the user, etc.
Maybe Iām missing something.
AI note taking is a scourge on society and needs to go.
Sid of GitLab raised for Kilo, and GitLab is also of YC
https://capwolf.com/former-gitlab-ceo-launches-kilo-in-ai-co...
/facepalm