ComfyUI Prototyping Environment

The visible symptom was slow iteration. The actual problem was upstream of that: the cost of asking a question had risen high enough that people stopped asking. Nobody decides to stop exploring — they just quietly route around the expensive path, and the exploration disappears from the process without anyone noticing it left.

The usual fallback is to move exploration into Figma, and for most products that works. It does not work for a node editor. A graph interface is almost entirely behaviour under load: what happens at forty nodes, how edges route when they cross, whether a panel that reads well beside three parameters still reads well beside thirty, how selection and pan and zoom interact when a user is moving fast. A static frame answers none of that. It shows you a tidy graph, which is the one case you already know works.

So the choice was not between prototyping in Figma and prototyping in code. It was between prototyping in code and not really prototyping at all.

The replica started as a straightforward rebuild of the interface in Vue, and the interesting part turned out to be the decomposition rather than the visuals. The production surface had to come apart into named pieces with clear edges — a canvas, a node card, a port row, an edge layer, an inspector, a toolbar — each one owning its own state and taking its configuration as props.

That is ordinary component hygiene, and I would not put it in a case study except for what it enabled. Once the interface was a set of named parts, changing it stopped requiring you to understand it. You did not have to read the file to move a panel; you had to know which part was the panel. A layout experiment became one line someone could write without a briefing.

The same property is what makes a codebase safe to hand to a model. An LLM cannot reliably edit a long component where markup, state and side effects are interleaved — there is no seam to cut along, and it will confidently break something three concerns away. It can very reliably swap a well-named prop. The refactor that made the environment legible to a designer is the same refactor that made it legible to a model, and that equivalence is not a coincidence: both are constrained by how much context you have to hold in order to make a safe change. We called the result vibe-code infrastructure, which makes it sound like it was about the tooling. It was about the naming.

It was built for designers and did not stay theirs. Design used it to check whether a layout survived a real graph rather than a tidy mock. Product used it to show a tradeoff instead of describing one — two versions running side by side settles an argument that two screenshots only extends. Engineering used it to try an interaction before committing to the architecture that would support it.

Those are three different jobs, and the environment did not need to be adapted for any of them. What they had in common was wanting to be wrong cheaply. Nothing built in the replica shipped, which is the feature and not a limitation — the cost of a bad idea was a discarded branch, so bad ideas could be tried on purpose.

The change I would point to is not the speed. It is that the awkward questions started getting asked — the ones where you suspect the answer is inconvenient and the cost of finding out used to be high enough to justify not looking.

Rebuilding a production interface to prototype against is an expensive decision and it deserves an honest accounting. It is real engineering time spent on something that ships nothing. It creates a second codebase. And it carries a specific failure mode: a replica that drifts from the product stops being evidence. Once the two diverge, every result it produces has an asterisk on it, and a prototyping environment nobody trusts is worse than none, because people still use it and then argue about whether the finding counts.

The mitigation was to keep it deliberately shallow. The replica tracked the production interface closely and implemented almost nothing behind it — no real backend, no execution, only enough state to make interactions behave truthfully. Shallow is what kept it cheap to resync, and staying cheap to resync is what kept it honest. A richer sandbox would have been more impressive and would have drifted within a quarter.

The tradeoff I would make again: a prototyping environment should be judged on how quickly it can be made to match reality again, not on how much of reality it contains.

Product exploration stopped depending on engineering availability. A designer with a question could answer it the same day, in the real interface, without asking anyone for time — and the answer came back as something running rather than something described.

Downstream of that, arguments changed shape. A disagreement about a Figma frame is a disagreement about taste, and it is resolved by whoever is more senior or more persistent. A disagreement about something running is a disagreement about the product, and it is resolved by using it. Moving that conversation onto working software took a whole category of decision out of the realm of opinion.

The narrower lesson, and the one I have carried into every project since: when a team stops exploring, the cause is usually not curiosity or talent. It is that someone, at some point, made exploration expensive — and that is a structural problem with a structural fix.