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.
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.
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.
It may be even simpler: plain markdown files that explain architecture including C4 diagrams generated from text using plantuml (automated via invoke/fabric/whatever). Plantuml includes C4 in stdlib https://github.com/plantuml-stdlib/C4-PlantUML
Yeah, haha funnily enough I'm a huge fan of both C4 and plantuml. We actually do have an experimental 'software map' feature, turned off in settings by default, which draws a hierarchical / C4-based architecture diagram of your codebase (even highlighting the nodes which changed in the PR!) Warning, it is a little rough around the edges at the moment.
As far as plantuml/graphviz/mermaid/similar UML tools, it's really cool stuff, I agree. My issue is that those tools are mainly built to render static diagrams (output to svg, png, etc.) Some eg mermaid are perhaps extensible for interactivity, but it's a little wonky. I think a lot of the value of whiteboard comes from the interactivity -- being able to click on a node to see the underlying code, being able to go through a guided walkthrough of a given flow, etc.
But using their UML authoring format is certainly worth looking into, since the LLMs are already so well-versed in it. i'll put some thought into this!
more than anything it's valid enough as a frame of reference for what many people want to do. if they went and invented a new term for it i'd reckon a lot of people just wouldn't even click on it
yes, this is tricky and something we’ve struggled with too. We chose IDE because the closest comp is probably VSCode - lots of folks seem to just use it for code browsing / review these days!
regardless, we ended up renaming “ide” -> “canvas” in on gh + website. hope that’s less confusing. will mull it over in the meantime.
This is really cool! I'm pumped for anything that makes it easier to review generated code. I, like many people these days, am searching for ways to stay close to the code whilst not being overwhelmed... and as a visual personal i like your idea to semantically link code to diagrams
I've been working on a (semi-)similar thing, a TUI for narrative code reviews - https://github.com/mtford90/revue - the idea being to generate "guided tours" of a change as opposed to a big wall of files.
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 emit 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.
> how people mostly use whiteboard today is:
plan -> approve -> agent codes -> use whiteboard to explain the code.
I guess it's interesting and useful for now, but I don't think people are going to work at the code level much longer.
In my opinion current coding agents + automatic review systems are already at superhuman reliability during the implementation phase (as in they will not fail something in the plan during implementation and not tell you about it, so there's no need to look at the actual code beyond maybe a cursory glance). I literally just use plan mode + CC's /code-review in each task so it's not like I'm doing anything special. So I think the main human interaction surfaces to target in the future will be in the planning process.
Without going through the following flow I very quickly end up with nitty recurring micro bugs or interaction "gunk" and 10's of thousands of lines of pointless code that bloats out the code-base and agent's context.
plan -> approve -> agent codes -> review code -> cleanup and pointing to specific skills/agents depending on what the issues are and some manual instructions pointing to specific lines of code-> agent codes -> review code -> final cleanup -> ship.
Working on a 3d sims-like video game I cannot get away with much less than that flow outside of very small features.
I have (like all of us I assume) tried moving forward over weeks of not code reviewing and only plan reviewing, and it's amazing how badly things fell apart, I ended up having to reset weeks of work and ended up knocking out like 50K loc for the exact same features and zero bugs instead of constant bug (or just interaction/latency gunk cropping up everywhere) cleanup slowly escalating and agents needing to take hours to build anything.
> So I think the main human interaction surfaces to target in the future will be in the planning process.
yes, agreed. we're working on more stuff in that direction (a plan / scratchpad mode), but what i personally like the most is eliminating / shrinking the plan/review gap.
i think reviewing a plan without an implementation doesn't feel that useful anymore, at least to me, because key tradeoffs often only surface during implementation that effect the top-level spec.
in some sense, the code writing process is just a cheap effort which makes the spec better and more thorough?
Is that really true? I feel even with Fable and the likes, once the LLM has locked down an implementation any reworks I try to do gets it really tunnelvisioned on the current implementation, treating it like the truth even though it JUST wrote it, and any attempts to make it reframe the problem just makes it dig down further. In these cases I always get way better results throwing the whole thing away and rewinding the conversation rather than trying to evolve it.
An easy upgrade (ime) is to be intentional about a process, move the planning artifact to a file, use multiple research/propose/review sessions to dial it in. Still tuning my vibes for when to add in some actual exploratory implementation elements, because there's always something you didn't foresee when getting to the actual implementation, while also not having them implement the solution as a "plan" in markdown
> be intentional about a process, move the planning artifact to a file, use multiple research/propose/review sessions to dial it in
Yeah, I think we need something like that as well. I am actually working on an virtual artifact filesystem in my orchestrator to enable this. So agents can create a persistent, versioned plan artifact separate from the codebase (maybe a HTML) and iterate it alongside the user, much like what ChatGPT/claude.ai can already do but for a coding agent. Then you'd need to define a process and get the agent to follow it, but that's much easier and mostly a mix of prompt and orchestration primitives.
> exploratory implementation elements
This is a good point, I've ran into a lot of instances as well where my agents in plan mode would like to explore something but can't because of permissions. I wonder if there should be some kind of system like a "experiment subagent" to handle it.
Commit it to git, it's not far off from an llm-wiki
I have no orchestration primitives, just a skill tied to a .design/*.md
Unless we consider opencode sometimes using a subagent as a primitive? Maybe the problem is leaving the clankers to their own devices for too long/much
I intentionally block almost every tool for the design/review agents, letting them "do" things is a distraction. I will use the build agent and tell it what to do if I need that experiment. I don't want to have to read through the wasted tokens a bunch of dumb bots burned through to create walls of markdown. They go on way too many side quests
Thanks! The project looks great and I am definitely interested in this approach. I hope it will help me with my usual issue - I review a lot of code these days and it's really hard to understand what changes about and why they even needed usually, without deep analysis and AI sessions. It's always good to have such a visual method to check briefly what's there on architecture and design level - these mistakes are hardest to find in other people's code, as it is for me.
I especially like your way to connect agents - I'm basically using what I wish to use, without limitations or pay walls. At my work, all AI tools should be reviewed and approved before usage but here I just use my coding agent and this is "plugin" for visualisation, so I guess it will be approved in no time. Thanks to not keeping a forced data collection, it will really help to promote your tool in corporate environments.
No reasons to not try it for me! I am looking closely at what will come next and will try to share my feedback, if there will be some.
For now, I just feel that it will be good to have a way to trigger review creation from the app itself, not to create a new agent session for this. Kinda a bit counterintuitive but I understand why it works this way and it's not a real issue.
yeah, i think there's definitely a lot to improve about the ux still. thanks for the feedback, hope you enjoy using it. open to feature requests, bug reports, and anything in between!
the authoring server is referring to the stdio mcp server running on your machine! so its all still local and private, we should clarify that nomenclature though.
all of the facets we track are in the repo's TELEMETRY.md! for errors and crashes, any specifics about your machine+repo are redacted. We only collect repository information when you submit a bug report and opt into it, or share a whiteboard session, also totally optional.
yeah, ack that IDE is confusing. mentioned this elsewhere, but 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 ended up changing "ide" -> "canvas" on the website + github, but can't edit the post above.
btw, we're also strongly considering adding an editing feature, but not sure how opinionated we want to be on how agentic it should be, so decided to go in favor of not shipping it (yet)
windows is on our roadmap (fingers crossed launching tomorrow!). and as far as the web-based affordances, we are working on it! wanted to start with the local dev experience before trying to build multiplayer features.
One concern about accuracy of the diagrams. In the example, there is a transition back to the session service labelled "wait for release" after the "no" decision. I'm not seeing that in the shown diff.
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?
I think we need less software with AI features. Less stuff chasing the hype train and more "slow" software that encourages thoughtfulness and less reliance on the machine.
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.
Okay great timing because I was having the exact same idea, but mine was just a skill that was building a website with the flow mapped out and the relevant code, which seems that you are doing as well, definitely going to follow this, good luck guys!
Nice. I didn't build a skill but I noticed that for a few complicated features that I built recently, I asked the model to build an interactive "explainer" for it
Such an explainer would contain for example a simulation of the feature, where it shows how data flows between components and allows the reviewer to tweak parameters and see how it affects things. The explainer can visually show edge cases or introduce faults.
Basically my problem is that agents can write a lot. They can write a lot of code and also a lot of natural language design/spec which ultimately becomes hard to review (sloppificarion of design documents)
Sometimes you can tame this by focusing on very high level, human curated specs, but since often the devil is in the details, you need a way to see these details.
I found that interactive visual exploration tools are a very good way to both iterate on your problems and to share it with your colleagues.
Haha yeah and I’ve been building one for myself as a side project. I think there are many people experimenting in this space. Going to be interesting to see how it develops.
I can see the value of having the agent and the human looking at the same design. The thing I'd worry about is the diagram becoming another thing that slowly diverges from the code. Would be interesting to see how you handle that once the implementation starts moving.
yeah, i think this is a real concern. the diagrams are all attached to code by design so we can tell if something has drifted (e.g. can model a diagram node in a sense as a code forge "comment"; building upon some great work from e.g. gitlab here!).
there's a separate problem here re: multiple sources of truth (e.g. Linear for a spec) that you're also getting at. in my own experience, whiteboard is still quite helpful when it's important to understand the change going in (which isn't every single one!).
in the future, we plan to deliver (1) affordances to capture the spec planning process in the whiteboard so you can iterate more flexibly / in more ways, and (2) will also ship a hosted product so this can be multiplayer - which will help resolve that source-of-truth issue, we hope.
yeah, for sure. i think the diagrams/artifacts are definitely more ephemeral, since they fall out of date. in my experience, the more lasting artifacts from the whiteboarding session have been
1) making the code that ships higher quality because i understand it, and
2) getting my own mental model aligned with the current state of the codebase.
we're dreaming up some features in a hosted version of the product which could maintain an up-to-date 'software map' of your codebase, and that is the backbone which would power all diagrams/visualizations
Is a new IDE really required for this? Wouldn't Markdown already cover a shared "canvas" for documentation/planning, when accompanied by something like Mermaid?
I think some of the presented ideas are pretty cool, but am thinking that you'll get slown down by the IDE approach.
i think the really tricky thing w markdown is (1) tying the actual spec to the code / diffs and (2) then smoothly navigating those artifacts from one interface. markdown editors don't quite give you "go-to-definition" and nice diff viewers / code viewing affordances.
we'll be building a hosted product as well that will be web-based and I don't think that will be a full IDE, really. we really only need the ability to view code + diffs at this point, but we figured that starting from the most popular code editor in the world would be a good place to start / help things "feel natural".
also, we're not sure yet about the edit/write capability yet and how much of that should flow through here. so much work flows through the terminal these days and it's really nice to have a complementary, focused tool to that.
at the same time, i find myself missing edits + autocomplete occasionally; this is particularly valuable for specification authoring / editing, and is something that is definitely on our roadmap.
The UX seems nice, but the scope is way too narrow.
I would be actually lazier for me to to just rebuild it inside my own harness (exactly as i want it) than start looking at yours.
very cool. Congrats on the launch. first half of 2026 was the year when every one made such internal tools one way or another. I am happy you guys could build a product out of it.
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.
> end only a small % of the traces really are important to the final changes, because concise changes are typically very small and self contained.
yes, totally. i think this is mostly 1 piece of the broader puzzle. we found that, esp. for complex changes where i need to spend my brainpower anyways:
> A challenge then is can i understand just enough about a new proposed change to approve it?
whiteboard has been a powerful tool for us! i think much more of this needs to be instrumented as part of a larger system, as you said (we are thinking the same way btw: https://dev.fast/about/)
Yeah.. that's something that I thought about for a few years now. I think making sense of code bases and software design will soon be a completely new industry. I had expected that companies like Jetbrains would be in a prime position to offer solutions for that, but it takes longer than I expected.
Interesting idea for sure. But as a software engineer, I’m struggling to map out what this would replace today. I use Cursor pretty heavily, but it’s not entirely clear what would make me jump to a new IDE based on what you’ve built so far.
sorry, yeah the word IDE is a misnomer - we will fix, looking for something better. It's really a canvas that your agent can use to help you understand an implementation, what tradeoffs were made, etc.
Whiteboard is meant to be used in conjunction with tools like Cursor / an ADE.
Edit: just updated the GitHub + marketing site to reflect this!
> the word IDE is a misnomer ... looking for something better
YAT (Yet Another Tool) is something I use (sometimes pejoratively, sometimes as a reality), arising from the general trend and burnout in the developer tools space
One of the nice things about Ai is that it can deal with all that and I don't have to go through YAT docs and code to figure out how to use it
Echoing the wish for a Windows version. This is the first piece of software I've attempted to download in my ~2 years on this site. 90% of the software engineers I know are on Windows :-)
that’s so nice! windows is definitely coming and on our roadmap soon. Will you let know when it’s ready - feel free to ping me at sid@dev.fast and will send you an email when it’s ready!!
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.
I see this fitting into my workflow more ephemerally. That, or I will use screenshots in some of my existing documentation so it can all rot in one place.
When using an agent for development, I find that I REALLY miss being able to "see" the shape of the code in my head while I work, and I find that I get bombarded with so much information that I cannot keep track of what the code looks like. This has led to me having to get back to people async on questions they have on a call, etc., because I can't remember exactly how i made something work in the end!
I will be using this to make sure I understand my own output at a depth I can remember, and I will be using it to do the same for reviewing complex PRs or diving into new parts of the codebase.
I think you’re on the money with the problem of maintaining (another) source of truth.
Speaking from personal experience, I still find myself reaching for Whiteboard. It’s helpful when it’s critical for me as a developer to understand the implementation, which is certainly not every change!
In the future, we want to deliver a hosted product that addresses the N+1 concern you raised. The problem with the existing tools is that plans don’t stay up to date with what the agent decided to implement, and the back-and-forth that happens after the initial prompt isn’t captured. We believe a single whiteboard canvas can be used to capture not only a plan at design time, but what happens after.
not no-code at all (a big part of this project has been our semantic diffing engine)! check out the demo - in fact if anything it's meant you bring more into touch with the code, rather than less. :)
(1) right now, i think this is a better tool for the tech lead / senior engineer. they can enter a loop like:
start brainstorming with their agent -> agent writes code -> agent writes Whiteboard session (connected to the underlying code) for them to iterate on.
(eliminates the middle plan mode phase)
(2) i don't think every piece of work fits in that way, so we're working on a "scratchpad" mode your agent can use for planning via versioned artifacts for architecture + behavioral specifications. Then it can update that plan when the implementation is complete! when this feature rolls out I think an "architect" would be using that feature more in collaboration with an engineer.
(the boundary b/w architect and engineer does seem a bit fuzzy to me, esp. these days, so hopefully we share a similar mental model)
https://install.dev.fast/linux ! we just have a fedora build right now, but if you're looking for another distro let me know and i can put it on our roadmap.
for sure, we're thinking of doing something along those lines for our hosted product-- auto-trigger reviews upon opening PR, link to them from gh, etc. feel free to shoot me a message (ketan at dev dot fast) if you're interested in that!
If you make it hosted only, my guess is you will lose out on a number of users who cannot convince their corporate overlords to authorize yet another GitHub app. Charge the user and use their local gh access to make it work!
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 :)
So are we just letting go and having clankers write everything now while we have other clankers "explain" it to us? Just collectively, "fuck it" ?
The software I use day to day is just getting worse and worse, and I can only guess that AI is accelerating that problem. Like I can barely convince spotify to play a full album anymore without it "failing to play a song", crashing, or play without audio underruns. We're so screwed if we can't even play audio smoothly in 2026.
Sorry, just ranting. But I see tools like this that are basically encouraging people to "let go" of understanding what exactly your code is doing, and continue to let the robot pile more and more code on top of the bad abstractions we already have.
I'm asking about terminals in the IDE, I have many of them, really multiple panes, each pane is agent(s) in terminals and the associated files/diff for their work. VS Code looks more like a dashboard for agents these days. (50" 4k)
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? What I'm seeing here would/could be better/replicated as a VS Code extension
I'm only interested in an "Integrated Developer Experience", winner takes all kind of thing, tool sprawl is out of hand
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)
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
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.
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)
I'd recommend AppImage as distro independent package format
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.
I like and adopted the term "agent multiplexer" for these.
Just can't warm up to "ADE" (never even liked "IDE") and "agent orchestrator" and "control plane" are just not specific enough to stick.
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
I was describing T3/Superset which help you manage context switching. Whiteboard is obviously different.
Or control planes
How do you compare to https://likec4.dev/ and https://erode.dev/ , which are currently fully open-source and community driven?
C4 gives the text-based representation needed for LLMs to generate and maintain large architecture diagrams - why not build off that heritage?
It may be even simpler: plain markdown files that explain architecture including C4 diagrams generated from text using plantuml (automated via invoke/fabric/whatever). Plantuml includes C4 in stdlib https://github.com/plantuml-stdlib/C4-PlantUML
Yeah, haha funnily enough I'm a huge fan of both C4 and plantuml. We actually do have an experimental 'software map' feature, turned off in settings by default, which draws a hierarchical / C4-based architecture diagram of your codebase (even highlighting the nodes which changed in the PR!) Warning, it is a little rough around the edges at the moment.
As far as plantuml/graphviz/mermaid/similar UML tools, it's really cool stuff, I agree. My issue is that those tools are mainly built to render static diagrams (output to svg, png, etc.) Some eg mermaid are perhaps extensible for interactivity, but it's a little wonky. I think a lot of the value of whiteboard comes from the interactivity -- being able to click on a node to see the underlying code, being able to go through a guided walkthrough of a given flow, etc.
But using their UML authoring format is certainly worth looking into, since the LLMs are already so well-versed in it. i'll put some thought into this!
more than anything it's valid enough as a frame of reference for what many people want to do. if they went and invented a new term for it i'd reckon a lot of people just wouldn't even click on it
yes, this is tricky and something we’ve struggled with too. We chose IDE because the closest comp is probably VSCode - lots of folks seem to just use it for code browsing / review these days!
regardless, we ended up renaming “ide” -> “canvas” in on gh + website. hope that’s less confusing. will mull it over in the meantime.
> VSCode - lots of folks seem to just use it for code browsing / review these days!
Truth to be told. Yezzir.
This is really cool! I'm pumped for anything that makes it easier to review generated code. I, like many people these days, am searching for ways to stay close to the code whilst not being overwhelmed... and as a visual personal i like your idea to semantically link code to diagrams
I've been working on a (semi-)similar thing, a TUI for narrative code reviews - https://github.com/mtford90/revue - the idea being to generate "guided tours" of a change as opposed to a big wall of files.
You might want to look at Simon Willison's showboat [0] tool, which generates walkthroughs of code to explain changes.
[0]: https://simonwillison.net/guides/agentic-engineering-pattern...
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 emit 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)
> how people mostly use whiteboard today is: plan -> approve -> agent codes -> use whiteboard to explain the code.
I guess it's interesting and useful for now, but I don't think people are going to work at the code level much longer.
In my opinion current coding agents + automatic review systems are already at superhuman reliability during the implementation phase (as in they will not fail something in the plan during implementation and not tell you about it, so there's no need to look at the actual code beyond maybe a cursory glance). I literally just use plan mode + CC's /code-review in each task so it's not like I'm doing anything special. So I think the main human interaction surfaces to target in the future will be in the planning process.
Without going through the following flow I very quickly end up with nitty recurring micro bugs or interaction "gunk" and 10's of thousands of lines of pointless code that bloats out the code-base and agent's context.
plan -> approve -> agent codes -> review code -> cleanup and pointing to specific skills/agents depending on what the issues are and some manual instructions pointing to specific lines of code-> agent codes -> review code -> final cleanup -> ship.
Working on a 3d sims-like video game I cannot get away with much less than that flow outside of very small features. I have (like all of us I assume) tried moving forward over weeks of not code reviewing and only plan reviewing, and it's amazing how badly things fell apart, I ended up having to reset weeks of work and ended up knocking out like 50K loc for the exact same features and zero bugs instead of constant bug (or just interaction/latency gunk cropping up everywhere) cleanup slowly escalating and agents needing to take hours to build anything.
Might find this interesting: https://earendil.com/posts/measuring-code-sloppiness/
> So I think the main human interaction surfaces to target in the future will be in the planning process.
yes, agreed. we're working on more stuff in that direction (a plan / scratchpad mode), but what i personally like the most is eliminating / shrinking the plan/review gap.
i think reviewing a plan without an implementation doesn't feel that useful anymore, at least to me, because key tradeoffs often only surface during implementation that effect the top-level spec.
in some sense, the code writing process is just a cheap effort which makes the spec better and more thorough?
Is that really true? I feel even with Fable and the likes, once the LLM has locked down an implementation any reworks I try to do gets it really tunnelvisioned on the current implementation, treating it like the truth even though it JUST wrote it, and any attempts to make it reframe the problem just makes it dig down further. In these cases I always get way better results throwing the whole thing away and rewinding the conversation rather than trying to evolve it.
> a better alternative to the current Plan Mode
An easy upgrade (ime) is to be intentional about a process, move the planning artifact to a file, use multiple research/propose/review sessions to dial it in. Still tuning my vibes for when to add in some actual exploratory implementation elements, because there's always something you didn't foresee when getting to the actual implementation, while also not having them implement the solution as a "plan" in markdown
> be intentional about a process, move the planning artifact to a file, use multiple research/propose/review sessions to dial it in
Yeah, I think we need something like that as well. I am actually working on an virtual artifact filesystem in my orchestrator to enable this. So agents can create a persistent, versioned plan artifact separate from the codebase (maybe a HTML) and iterate it alongside the user, much like what ChatGPT/claude.ai can already do but for a coding agent. Then you'd need to define a process and get the agent to follow it, but that's much easier and mostly a mix of prompt and orchestration primitives.
> exploratory implementation elements
This is a good point, I've ran into a lot of instances as well where my agents in plan mode would like to explore something but can't because of permissions. I wonder if there should be some kind of system like a "experiment subagent" to handle it.
> separate from the codebase
Commit it to git, it's not far off from an llm-wiki
I have no orchestration primitives, just a skill tied to a .design/*.md
Unless we consider opencode sometimes using a subagent as a primitive? Maybe the problem is leaving the clankers to their own devices for too long/much
I intentionally block almost every tool for the design/review agents, letting them "do" things is a distraction. I will use the build agent and tell it what to do if I need that experiment. I don't want to have to read through the wasted tokens a bunch of dumb bots burned through to create walls of markdown. They go on way too many side quests
Thanks! The project looks great and I am definitely interested in this approach. I hope it will help me with my usual issue - I review a lot of code these days and it's really hard to understand what changes about and why they even needed usually, without deep analysis and AI sessions. It's always good to have such a visual method to check briefly what's there on architecture and design level - these mistakes are hardest to find in other people's code, as it is for me.
I especially like your way to connect agents - I'm basically using what I wish to use, without limitations or pay walls. At my work, all AI tools should be reviewed and approved before usage but here I just use my coding agent and this is "plugin" for visualisation, so I guess it will be approved in no time. Thanks to not keeping a forced data collection, it will really help to promote your tool in corporate environments.
No reasons to not try it for me! I am looking closely at what will come next and will try to share my feedback, if there will be some.
For now, I just feel that it will be good to have a way to trigger review creation from the app itself, not to create a new agent session for this. Kinda a bit counterintuitive but I understand why it works this way and it's not a real issue.
yeah, i think there's definitely a lot to improve about the ux still. thanks for the feedback, hope you enjoy using it. open to feature requests, bug reports, and anything in between!
Codex warns me - "Whiteboard requires uploading/exposing repository data to its authoring server".
Is this expected? I had a different take on "local" and "works as a plugin with your existing harness". What might I be missing?
the authoring server is referring to the stdio mcp server running on your machine! so its all still local and private, we should clarify that nomenclature though.
all of the facets we track are in the repo's TELEMETRY.md! for errors and crashes, any specifics about your machine+repo are redacted. We only collect repository information when you submit a bug report and opt into it, or share a whiteboard session, also totally optional.
Thanks for that clarification!
"Known limitations You cannot currently edit files in Whiteboard. If this is something that you find yourself wanting to do, please file an issue!"
Seems like a big limitation for an "IDE"
Seems more like IDE is "I Don't Edit" in this case
yeah, ack that IDE is confusing. mentioned this elsewhere, but 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 ended up changing "ide" -> "canvas" on the website + github, but can't edit the post above.
btw, we're also strongly considering adding an editing feature, but not sure how opinionated we want to be on how agentic it should be, so decided to go in favor of not shipping it (yet)
So it's an electron app but you don't support editing or even viewing on the web? And no windows client?
windows is on our roadmap (fingers crossed launching tomorrow!). and as far as the web-based affordances, we are working on it! wanted to start with the local dev experience before trying to build multiplayer features.
One concern about accuracy of the diagrams. In the example, there is a transition back to the session service labelled "wait for release" after the "no" decision. I'm not seeing that in the shown diff.
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?
Hey! oops, that gif is a notional one we were using for design, and we forgot to update it.
Real diagrams are all linked to code, so hallucinations don’t really happen in practice (hallucinated architecture really bothers me too!)
Will update shortly with an actual gif of the app. Sorry about that!
update: fixed - grabbed an actual whiteboard session that I had previously set up. thanks again!
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...
I think we need less software with AI features. Less stuff chasing the hype train and more "slow" software that encourages thoughtfulness and less reliance on the machine.
I wrote some thoughts on this a while ago. They're not cleanly organized (sorry!) but it's my raw thinking on AI: https://nonograph.com/some-disorganized-thoughts-about-artif...
Also wrote this on the state of VC if interested: https://nonograph.com/write-some-software-give-it-away-for-f...
Ha, nervous enthusiasm seeing this, as I’m building something similar. Guess I should put a demo somewhere public. Very cool space.
The point about semantic diff viewer sounds very interesting. I think many coding harnesses are not doing this well enough.
I use https://whiteboard-mcp.com in a similar way to this - it gives me a drawing canvas claude can access and read
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.
Okay great timing because I was having the exact same idea, but mine was just a skill that was building a website with the flow mapped out and the relevant code, which seems that you are doing as well, definitely going to follow this, good luck guys!
Nice. I didn't build a skill but I noticed that for a few complicated features that I built recently, I asked the model to build an interactive "explainer" for it
Such an explainer would contain for example a simulation of the feature, where it shows how data flows between components and allows the reviewer to tweak parameters and see how it affects things. The explainer can visually show edge cases or introduce faults.
Basically my problem is that agents can write a lot. They can write a lot of code and also a lot of natural language design/spec which ultimately becomes hard to review (sloppificarion of design documents)
Sometimes you can tame this by focusing on very high level, human curated specs, but since often the devil is in the details, you need a way to see these details.
I found that interactive visual exploration tools are a very good way to both iterate on your problems and to share it with your colleagues.
Inspirations:
* https://ciechanow.ski/
* https://www.3blue1brown.com/
Haha yeah and I’ve been building one for myself as a side project. I think there are many people experimenting in this space. Going to be interesting to see how it develops.
I can see the value of having the agent and the human looking at the same design. The thing I'd worry about is the diagram becoming another thing that slowly diverges from the code. Would be interesting to see how you handle that once the implementation starts moving.
yeah, i think this is a real concern. the diagrams are all attached to code by design so we can tell if something has drifted (e.g. can model a diagram node in a sense as a code forge "comment"; building upon some great work from e.g. gitlab here!).
there's a separate problem here re: multiple sources of truth (e.g. Linear for a spec) that you're also getting at. in my own experience, whiteboard is still quite helpful when it's important to understand the change going in (which isn't every single one!).
in the future, we plan to deliver (1) affordances to capture the spec planning process in the whiteboard so you can iterate more flexibly / in more ways, and (2) will also ship a hosted product so this can be multiplayer - which will help resolve that source-of-truth issue, we hope.
yeah, for sure. i think the diagrams/artifacts are definitely more ephemeral, since they fall out of date. in my experience, the more lasting artifacts from the whiteboarding session have been 1) making the code that ships higher quality because i understand it, and 2) getting my own mental model aligned with the current state of the codebase.
we're dreaming up some features in a hosted version of the product which could maintain an up-to-date 'software map' of your codebase, and that is the backbone which would power all diagrams/visualizations
Is a new IDE really required for this? Wouldn't Markdown already cover a shared "canvas" for documentation/planning, when accompanied by something like Mermaid?
I think some of the presented ideas are pretty cool, but am thinking that you'll get slown down by the IDE approach.
i think the really tricky thing w markdown is (1) tying the actual spec to the code / diffs and (2) then smoothly navigating those artifacts from one interface. markdown editors don't quite give you "go-to-definition" and nice diff viewers / code viewing affordances.
we'll be building a hosted product as well that will be web-based and I don't think that will be a full IDE, really. we really only need the ability to view code + diffs at this point, but we figured that starting from the most popular code editor in the world would be a good place to start / help things "feel natural".
also, we're not sure yet about the edit/write capability yet and how much of that should flow through here. so much work flows through the terminal these days and it's really nice to have a complementary, focused tool to that.
at the same time, i find myself missing edits + autocomplete occasionally; this is particularly valuable for specification authoring / editing, and is something that is definitely on our roadmap.
This is a good development in terms of processing information for people.
Visual memory comes the easiest to people and it’s the quickest way to understand and convey information to most people.
Other forms of memory that I expect to see having better tools to address them are auditory and kinesthetic.
The UX seems nice, but the scope is way too narrow. I would be actually lazier for me to to just rebuild it inside my own harness (exactly as i want it) than start looking at yours.
For that there's Python: with30 lines you can automate this task. If you want I can send you the script I use. DM me if interested.
careful! you'll lose your chance to pitch it to YC!
If you’re interested in IDEs and want to see a completely different take, look no further
[0] - https://github.com/con-dog/slices-demo#slice-ide---an-experi...
To me these show HN posts all build things that are a bit too obvious
very cool. Congrats on the launch. first half of 2026 was the year when every one made such internal tools one way or another. I am happy you guys could build a product out of it.
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.
> end only a small % of the traces really are important to the final changes, because concise changes are typically very small and self contained.
yes, totally. i think this is mostly 1 piece of the broader puzzle. we found that, esp. for complex changes where i need to spend my brainpower anyways:
> A challenge then is can i understand just enough about a new proposed change to approve it?
whiteboard has been a powerful tool for us! i think much more of this needs to be instrumented as part of a larger system, as you said (we are thinking the same way btw: https://dev.fast/about/)
Semantic diffs in Rust enhance code understanding significantly.
Oh I like this!
This approach clearly seems like the way to go with agentic coding.
I’ll be downloading it and checking it out! Great idea!
Yeah.. that's something that I thought about for a few years now. I think making sense of code bases and software design will soon be a completely new industry. I had expected that companies like Jetbrains would be in a prime position to offer solutions for that, but it takes longer than I expected.
this is really cool, claude artifacts often fails to visualize/explain system's layout and flows
Interesting idea for sure. But as a software engineer, I’m struggling to map out what this would replace today. I use Cursor pretty heavily, but it’s not entirely clear what would make me jump to a new IDE based on what you’ve built so far.
Maybe I’m missing something.
sorry, yeah the word IDE is a misnomer - we will fix, looking for something better. It's really a canvas that your agent can use to help you understand an implementation, what tradeoffs were made, etc. Whiteboard is meant to be used in conjunction with tools like Cursor / an ADE.
Edit: just updated the GitHub + marketing site to reflect this!
> the word IDE is a misnomer ... looking for something better
YAT (Yet Another Tool) is something I use (sometimes pejoratively, sometimes as a reality), arising from the general trend and burnout in the developer tools space
One of the nice things about Ai is that it can deal with all that and I don't have to go through YAT docs and code to figure out how to use it
Echoing the wish for a Windows version. This is the first piece of software I've attempted to download in my ~2 years on this site. 90% of the software engineers I know are on Windows :-)
that’s so nice! windows is definitely coming and on our roadmap soon. Will you let know when it’s ready - feel free to ping me at sid@dev.fast and will send you an email when it’s ready!!
The 'thoughtful design' angle is intriguing. Always looking for ways to capture early architectural ideas better than just diagrams.
Was excited to try this, but my company moved from Claude to Copilot CLI. Any plans for Copilot support?
oh absolutely - i see https://github.com/devdotfast/whiteboard/issues/593 has already been filed for tracking.
Will probably be in the release tomorrow!
Looks interesting! Side question: how do you plan to make money out of it?
we plan to launch a complementary hosted, multiplayer product as well; here's some of the ideas we're thinking about: https://dev.fast/about/
but that's all a bit far in the future; lots to iterate on here right now to get the ux right.
Any thoughts on if or how it might make sense to integrate Product/Business folk into the workflow?
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.
Awesome, keen to see where this goes. Can we have light mode for the whiteboard and dark mode for the code?
definitely down to expand the theme set! could you file an issue for tracking ? Thanks!
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.
I see this fitting into my workflow more ephemerally. That, or I will use screenshots in some of my existing documentation so it can all rot in one place.
When using an agent for development, I find that I REALLY miss being able to "see" the shape of the code in my head while I work, and I find that I get bombarded with so much information that I cannot keep track of what the code looks like. This has led to me having to get back to people async on questions they have on a call, etc., because I can't remember exactly how i made something work in the end!
I will be using this to make sure I understand my own output at a depth I can remember, and I will be using it to do the same for reviewing complex PRs or diving into new parts of the codebase.
I think you’re on the money with the problem of maintaining (another) source of truth.
Speaking from personal experience, I still find myself reaching for Whiteboard. It’s helpful when it’s critical for me as a developer to understand the implementation, which is certainly not every change!
In the future, we want to deliver a hosted product that addresses the N+1 concern you raised. The problem with the existing tools is that plans don’t stay up to date with what the agent decided to implement, and the back-and-forth that happens after the initial prompt isn’t captured. We believe a single whiteboard canvas can be used to capture not only a plan at design time, but what happens after.
It’s like CS101 and drawing UML diagrams. Cool.
Cool open-source project. Vut why are we trying to build so many no code tools?
not no-code at all (a big part of this project has been our semantic diffing engine)! check out the demo - in fact if anything it's meant you bring more into touch with the code, rather than less. :)
Ill check it out
Plans for Windows version?
yes of course! It’s on our roadmap to land soon. Feel free to email me at sid@dev.fast, and I’ll shoot you an update when it’s landed !
As an architect, how do you envision me using this?
(1) right now, i think this is a better tool for the tech lead / senior engineer. they can enter a loop like:
start brainstorming with their agent -> agent writes code -> agent writes Whiteboard session (connected to the underlying code) for them to iterate on.
(eliminates the middle plan mode phase)
(2) i don't think every piece of work fits in that way, so we're working on a "scratchpad" mode your agent can use for planning via versioned artifacts for architecture + behavioral specifications. Then it can update that plan when the implementation is complete! when this feature rolls out I think an "architect" would be using that feature more in collaboration with an engineer.
(the boundary b/w architect and engineer does seem a bit fuzzy to me, esp. these days, so hopefully we share a similar mental model)
Looks cool :-)Linux wen plz so I can play with it?
https://install.dev.fast/linux ! we just have a fedora build right now, but if you're looking for another distro let me know and i can put it on our roadmap.
Thanks! Sorry if I missed it. I had clicked ok the download on the page and it only pointed me at Mac.
If you can create an aur it'd be awesome for the arch crowd :-)
ok i will get cranking on it, also got a request for nixOS too so im churning through them. watch the repo to get notified when the aur is released!
A .deb install for Debian and Ubuntu would be good please. I also know people will ask for flatpak's too.
make it possible to link to and comment on github PRs - this would be a sweet reviewing tool
for sure, we're thinking of doing something along those lines for our hosted product-- auto-trigger reviews upon opening PR, link to them from gh, etc. feel free to shoot me a message (ketan at dev dot fast) if you're interested in that!
If you make it hosted only, my guess is you will lose out on a number of users who cannot convince their corporate overlords to authorize yet another GitHub app. Charge the user and use their local gh access to make it work!
See tuicr for a cool tui tool in this space
Loved that zed-inspired landing pages.
thanks, appreciate it! we also took inspiration from paper.design. the tmux bits are just for fun though :)
looks great! personally for me, system design is quite imporatn and cognitive debt is shooting up
No Windows?!
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.
great to hear! project looks interesting and I'm excited to see where you guys go with it.
Excited to try this out!
Congrats! Looks tight.
So are we just letting go and having clankers write everything now while we have other clankers "explain" it to us? Just collectively, "fuck it" ?
The software I use day to day is just getting worse and worse, and I can only guess that AI is accelerating that problem. Like I can barely convince spotify to play a full album anymore without it "failing to play a song", crashing, or play without audio underruns. We're so screwed if we can't even play audio smoothly in 2026.
Sorry, just ranting. But I see tools like this that are basically encouraging people to "let go" of understanding what exactly your code is doing, and continue to let the robot pile more and more code on top of the bad abstractions we already have.
this is exactly what I was looking for!
Throw in some tla+, eventb, p and modp for formal guarantees
haha, we're thinking the same way: https://dev.fast/about/
I was confused for a moment by the name "Sid" in new coding tools.
Sid of GitLab raised for Kilo, and GitLab is also of YC
https://capwolf.com/former-gitlab-ceo-launches-kilo-in-ai-co...
haha, different sid, also YC!
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, each pane is agent(s) in terminals and the associated files/diff for their work. VS Code looks more like a dashboard for agents these days. (50" 4k)
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? What I'm seeing here would/could be better/replicated as a VS Code extension
I'm only interested in an "Integrated Developer Experience", winner takes all kind of thing, tool sprawl is out of hand
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)
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
ok, it's vibecoded, but for once you don't have
- fucking sepia background and italic font
- "content" fading in while you scroll
you can't deny there was some actual thought in the design