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.
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.
free, oss, and local-only right now! we are working on a hosted solution but honestly aren't sure yet; we mostly made this for ourselves to fix our own gripes with agentic coding :)
Oh WOW, cool to see a technique that'll be everywhere in 12 months (the fake pen drawing animations + streaming diagrams as they're produced) first be announced. Do we still do "First!" comments, y'all?
~~[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.
There are a lot of emerging tools like this for which we will need a name. A similar one I randomly came across (https://github.com/Maksim-Burtsev/merl) calls itself a "Code Navigator."
Along similar lines, I also don't know what we're calling tools like T3 or Superset. They're basically harnesses for harnesses.
hmm - those tools are great, but I don't think orchestrator / ADE is quite right either, since this is explicitly not opinionated about where your coding agent is living.
Whiteboard is targeted at almost the opposite problem of the ADE (which is targeted to context switching) - having a dedicated tool to help you understand & participate in the development process in places where humans are high leverage.
1. Yeah, we've thought about this too - at the minimum, we're going to implement a vibe-codeable extension system so that you can add your own diagram types without rebuilding the app. definitely hopeful for some sort of common schema or lsp-shaped thing in the future
2. this is a good point and is something we've considered and struggled with. we ultimately settled on the term 'IDE' because we've found that most people use vscode to review code nowadays, almost exclusively (so it makes it a bit easier to draw the comp in your mind). we're also strongly considering adding an editing feature, but not sure what the exact shape of it is, so decided to go in favor of not shipping it yet - editing tends towards a conductor / superset shape of product. maybe we could try "canvas" instead of "ide" or something? will mull it over more.
4. Yeah, this is definitely tricky. This is why we didn't end up shipping edits as part of this release. Part of the solution here, we think, is tighter integration with the "spec" part of the lifecycle - where whiteboard makes it easier to understand if a spec (like a formal proof) is extensible, generalizable, etc. will mull on this more.
5. yes that's a typo! we're fixing right now - we meant "GPT 6 Sol" (basically, fast TPS, don't need the limits of intelligence really).
Edit: we do have a Fedora Linux build out if that's what you use! releasing stuff on every distro requires some care, so please let us know what you'd want to see it on (re: appimage lol)
Edit 2: (5) is fixed! thank you
I don't have much to say, other than these were interesting & helpful responses to understand what you've learned and where you're going. So thanks!
I'll be honest that my initial belief it was for OSX exclusively left me feeling indignant, so knowing I was just mistaken (based on the link up top, tbf) turns me around completly. I do in fact run Fedora, so I'll be trying this ASAP!
I feel Fedora+Debian+Ubuntu+Arch covers all but the long tail of devs, based on vibes alone? You might get bullied if you don't support Nix, but you'll probably be bullied by them anyway lol so no advice on navigating those waters.
I did, for what it's worth, spend a painfully long amount of time designing this website, but unfortunately none of us are great frontend devs, so we lean on the models here for sure (definitely am working on getting better at frontend dev).
we've put in a lot of time and attention into the app especially and hope it shows in the details - e.g. the diff viewer, the rendering animations - we want development to feel human again while still enjoying the speed boost of agents
This is definitely getting at least some things right about how we work with agents today, specifically that we often work at the architecture level, and we need a better alternative to the current Plan Mode offered by coding agents to efficiently architect software at a high level, which is more visual and offers better back-and-forth incrementation with the agent than simply "reject final plan with X message".
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.
1. "is this a feature" - it could be! in fact, we will expose this as an MCP UI next so that you can view the info directly in Codex Desktop or Superset/Conductor/Emdash for example. that aside, we found that the big things that matter for us are: (1) good code navigation (diagram/spec -> code), (2) beautiful diff viewing, and (3) visualizing agent traces as they connect to code. we found that these problems were hard enough, and enough folks that were using platforms that didn't easily map to these requirements - e.g. TUIs like claude code - that a dedicated product that was just focused on these problems exclusively makes sense.
2. "using whiteboard for plan mode": hmm, i think our wires are crossed a bit here. how people mostly use whiteboard today is:
plan -> approve -> agent codes -> use whiteboard to explain the code.
(or just omit the plan phase as a formal artifact -> just omit a plan + code together, like a golang design draft [A]).
we are exploring an explicit "put the plan in whiteboard first" mode (there's a scratchpad feature that's experimental right now), but it's definitely not ready for prime time yet.
yes, totally, this is a legitimate concern and i hate this too as a dev. we made the choice to build on top of vscode for the mvp so that the code navigation experience would be normal / seamless (and hopefully, devoid of slop).
as a comparison, vanilla cursor / vscode is ~1GB and zed is ~400Mb.
in the future we will definitely rewrite this app as fully native and get it way, way down. in the meantime, we're working to get the size down in other ways (e.g. our diff viewer can definitely be optimized - it's 138Mb, yikes)
If only this tool came out before I discovered the ballerina programming language (https://ballerina.io/). Otherwise I am inline with the language <-> uml like definition ballerina statically provides without llm usage.
I'm asking about terminals in the IDE, I have many of them, really multiple panes, my VS Code looks more like a dashboard for agents these days. Each pane is agent(s) in terminals and the associated files/diff for their work.
The headline says "IDE", but what you wrote here does not sound like an IDE, why would I want my agent calling an MCP / API to do the things your feature list suggests? I'm only interested in an "Integrated Developer Experience", winner takes all kind of thing, tool sprawl is out of hand
I think the issue with this type of product is it creates an N+1 source of truth for teams alongside their other tools. Inherently, this will get out of date as a project progresses. You could have an agent update based on changes, but that would likely degrade the design doc/artifact into unintelligible slop which wouldn't be useful in the future. This is a behavioral/structural problem of software design in general, which I don't think can be solved by software. Perhaps if this is mainly focused on collaboration at design time, but then that begs the question if teams will really want this tool versus using Notion, Linear, Google Docs.
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...
Loved that zed-inspired landing pages.
thanks, appreciate it! we also took inspiration from paper.design. the tmux bits are just for fun though :)
Cool idea will give this a try!
What does pricing look like?
free, oss, and local-only right now! we are working on a hosted solution but honestly aren't sure yet; we mostly made this for ourselves to fix our own gripes with agentic coding :)
How does that fit the YC W26?
You building something else and this scratches an itch?
That aside. I actually love this. Anything that helps with the "wtf did you just do?".
If I can still learn I will. If an agent can't reason about the changes made, then they are not good changes.
Oh WOW, cool to see a technique that'll be everywhere in 12 months (the fake pen drawing animations + streaming diagrams as they're produced) first be announced. Do we still do "First!" comments, y'all?
~~[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.
There are a lot of emerging tools like this for which we will need a name. A similar one I randomly came across (https://github.com/Maksim-Burtsev/merl) calls itself a "Code Navigator."
Along similar lines, I also don't know what we're calling tools like T3 or Superset. They're basically harnesses for harnesses.
They are usually called orchestrators, sometimes Agentic Development Environments (i.e. IDE for agents) if they are complex enough
hmm - those tools are great, but I don't think orchestrator / ADE is quite right either, since this is explicitly not opinionated about where your coding agent is living.
Whiteboard is targeted at almost the opposite problem of the ADE (which is targeted to context switching) - having a dedicated tool to help you understand & participate in the development process in places where humans are high leverage.
maybe also useful: https://x.com/ThePrimeagen/status/2101869827266596973?s=20
thank you! really appreciate it.
1. Yeah, we've thought about this too - at the minimum, we're going to implement a vibe-codeable extension system so that you can add your own diagram types without rebuilding the app. definitely hopeful for some sort of common schema or lsp-shaped thing in the future
2. this is a good point and is something we've considered and struggled with. we ultimately settled on the term 'IDE' because we've found that most people use vscode to review code nowadays, almost exclusively (so it makes it a bit easier to draw the comp in your mind). we're also strongly considering adding an editing feature, but not sure what the exact shape of it is, so decided to go in favor of not shipping it yet - editing tends towards a conductor / superset shape of product. maybe we could try "canvas" instead of "ide" or something? will mull it over more.
4. Yeah, this is definitely tricky. This is why we didn't end up shipping edits as part of this release. Part of the solution here, we think, is tighter integration with the "spec" part of the lifecycle - where whiteboard makes it easier to understand if a spec (like a formal proof) is extensible, generalizable, etc. will mull on this more.
5. yes that's a typo! we're fixing right now - we meant "GPT 6 Sol" (basically, fast TPS, don't need the limits of intelligence really).
Edit: we do have a Fedora Linux build out if that's what you use! releasing stuff on every distro requires some care, so please let us know what you'd want to see it on (re: appimage lol) Edit 2: (5) is fixed! thank you
I don't have much to say, other than these were interesting & helpful responses to understand what you've learned and where you're going. So thanks!
I'll be honest that my initial belief it was for OSX exclusively left me feeling indignant, so knowing I was just mistaken (based on the link up top, tbf) turns me around completly. I do in fact run Fedora, so I'll be trying this ASAP!
I feel Fedora+Debian+Ubuntu+Arch covers all but the long tail of devs, based on vibes alone? You might get bullied if you don't support Nix, but you'll probably be bullied by them anyway lol so no advice on navigating those waters.
https://install.dev.fast/linux ! we added the fedora build because one of our friends swears by it! (was hoping you wouldnt say omarchy lol)
Vibe-coded landing pages are an instant “no thanks” for me.
I did, for what it's worth, spend a painfully long amount of time designing this website, but unfortunately none of us are great frontend devs, so we lean on the models here for sure (definitely am working on getting better at frontend dev).
we've put in a lot of time and attention into the app especially and hope it shows in the details - e.g. the diff viewer, the rendering animations - we want development to feel human again while still enjoying the speed boost of agents
The animation carries it, don't worry.
So many launches don't show what they are. This on the other hand - got it straight away from the animation.
Great job
This is definitely getting at least some things right about how we work with agents today, specifically that we often work at the architecture level, and we need a better alternative to the current Plan Mode offered by coding agents to efficiently architect software at a high level, which is more visual and offers better back-and-forth incrementation with the agent than simply "reject final plan with X message".
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.
thanks for the feedback! two points:
1. "is this a feature" - it could be! in fact, we will expose this as an MCP UI next so that you can view the info directly in Codex Desktop or Superset/Conductor/Emdash for example. that aside, we found that the big things that matter for us are: (1) good code navigation (diagram/spec -> code), (2) beautiful diff viewing, and (3) visualizing agent traces as they connect to code. we found that these problems were hard enough, and enough folks that were using platforms that didn't easily map to these requirements - e.g. TUIs like claude code - that a dedicated product that was just focused on these problems exclusively makes sense.
2. "using whiteboard for plan mode": hmm, i think our wires are crossed a bit here. how people mostly use whiteboard today is:
plan -> approve -> agent codes -> use whiteboard to explain the code.
(or just omit the plan phase as a formal artifact -> just omit a plan + code together, like a golang design draft [A]).
we are exploring an explicit "put the plan in whiteboard first" mode (there's a scratchpad feature that's experimental right now), but it's definitely not ready for prime time yet.
[A] we were heavily influenced by golang's practice of "design drafts" as a way of scaling engineering velocity, e.g.: https://go.googlesource.com/proposal/+/master/design/draft-i... (thanks to Russ Cox, the legend)
We need LESS of AI and more HUMAN thinking. The process of thought and the increased difficulty with increased complexity is a feature not a bug.
AI note taking is a scourge on society and needs to go.
i am not sure to be honest if you're agreeing with us or not! but we do think that human thinking is both necessary and important in the future.
wrote a blog about this if you're interested! https://dev.fast/blog/youre-still-going-to-have-a-job-in-5-y...
736mb on macOS
/facepalm
yes, totally, this is a legitimate concern and i hate this too as a dev. we made the choice to build on top of vscode for the mvp so that the code navigation experience would be normal / seamless (and hopefully, devoid of slop).
as a comparison, vanilla cursor / vscode is ~1GB and zed is ~400Mb.
in the future we will definitely rewrite this app as fully native and get it way, way down. in the meantime, we're working to get the size down in other ways (e.g. our diff viewer can definitely be optimized - it's 138Mb, yikes)
Excited to try this out!
looks great! personally for me, system design is quite imporatn and cognitive debt is shooting up
Very happy to see a product like this. UML-style diagramming is still a part of my workflow when designing any architecture. Excited to try it out.
If only this tool came out before I discovered the ballerina programming language (https://ballerina.io/). Otherwise I am inline with the language <-> uml like definition ballerina statically provides without llm usage.
Does it have a terminal and panes? These are things I do not ever see giving up
it's meant to be used as a complement to your existing terminal! your agent uses the mcp or api from the terminal to draw on the Whiteboard
I'm asking about terminals in the IDE, I have many of them, really multiple panes, my VS Code looks more like a dashboard for agents these days. Each pane is agent(s) in terminals and the associated files/diff for their work.
The headline says "IDE", but what you wrote here does not sound like an IDE, why would I want my agent calling an MCP / API to do the things your feature list suggests? I'm only interested in an "Integrated Developer Experience", winner takes all kind of thing, tool sprawl is out of hand
Congrats! Looks tight.
Looks cool :-)Linux wen plz so I can play with it?
I think the issue with this type of product is it creates an N+1 source of truth for teams alongside their other tools. Inherently, this will get out of date as a project progresses. You could have an agent update based on changes, but that would likely degrade the design doc/artifact into unintelligible slop which wouldn't be useful in the future. This is a behavioral/structural problem of software design in general, which I don't think can be solved by software. Perhaps if this is mainly focused on collaboration at design time, but then that begs the question if teams will really want this tool versus using Notion, Linear, Google Docs.