sidharthkmenon

hmm - I think we care about the same problems you do ("software I use day to day is just getting worse and worse"). and pandora's box is already open with getting AI to write code - it's just so much faster than us.

but i think being a "good software engineer" was never really about the writing code part though - it was in the craft of designing systems, making sure that they were designed thoughtfully and are extensible etc.

fwiw Whiteboard is our stab at helping to fix this problem. we put a lot of effort into the diff viewer, tying the diagrams into the actual code, etc. so you can make sure you're not shipping slop. the point is to not have the agent "explain" it to you with a wall of slop, but instead to give you the tools so the diffs themselves feel approachable. the Whiteboard surface is meant as a springboard into the code underneath.

At least spiritually, this tool is definitely NOT meant for folks to let go of understanding the code. It's meant at tackling precisely the opposite problem - understanding the code still while still working with your agents.

edit:support for windows + ubuntu released as well (among many other improvements and fixes)!

thanks for the feature requests!!

update: fixed - grabbed an actual whiteboard session that I had previously set up. thanks again!

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.

oh absolutely - i see https://github.com/devdotfast/whiteboard/issues/593 has already been filed for tracking.

Will probably be in the release tomorrow!

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!

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.

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.

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.

haha, we're thinking the same way: https://dev.fast/about/

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)

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 !

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.

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!!

definitely down to expand the theme set! could you file an issue for tracking ? Thanks!

> 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/)

(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)

> 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?

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!

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!

haha, different sid, also YC!

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 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

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...

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)

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)

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

thanks, appreciate it! we also took inspiration from paper.design. the tmux bits are just for fun though :)

Yeah i think empirically you've hit the nail on the head (and there are some ties here to computability theory, e.g. Rice's thm).

sometimes the specification is easier to write than the code (sorting algo vs. quicksort impl) and sometimes the spec is much harder (what's "a good user experience"? what does "high availability" in a distributed system mean, precisely?)

i think it's just not true that it's easy to formally verify everything, it's often much easier to just write the code lol (e.g. sel4 is 200k+ lines of proof, ~50k lines of code iirc).