Comment by 2001zhaozhao | Hacker News Reader

Comment by 2001zhaozhao | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com