Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design
Unofficial Hacker News client; not affiliated with Y Combinator.
2001zhaozhao · · focus · HN ↗
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.
sidharthkmenon · · focus · HN ↗
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.: <a href="https://go.googlesource.com/proposal/+/master/design/draft-iofs.md" rel="nofollow">https://go.googlesource.com/proposal/+/master/design/draft-i... (thanks to Russ Cox, the legend)
2001zhaozhao · · focus · HN ↗
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.
sidharthkmenon · · focus · HN ↗
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?
sippeangelo · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]