Mistake one: describing the destination in the wrong units
Most wasted rounds in the build chat come from aiming at the wrong altitude, and it happens in two opposite directions. Some people ask for less than they mean — "improve the design," "make it better," "this doesn't feel right yet." Each of those is a diagnosis with no target, so the next version is a guess: it might darken the header, might swap the font, might reorganize the nav, and you won't know why until you're staring at the result wondering what happened. Other people overcorrect and ask for more than they should — they name session cookies, or CSS grid, or a loading skeleton component, because they know a little and want to be helpful. That failure is quieter but just as costly. The moment you specify implementation, you've usually specified it wrong, or at best narrowed the solution space down to whatever you personally already know — which, unless you're a working developer, is narrower than what the builder would have tried on its own. And if the library or pattern you named turns out to be the wrong call, that's now a bug you introduced, one the builder would never have made working from the outcome instead.
The fix lives between those two failure modes: name the thing you're looking at and the change you want to see, not the mechanism that produces it. "Visitors should be able to book without creating an account" beats a paragraph about session cookies, because what you actually want is the friction gone, and there are probably three ways to get there you haven't thought of. "The pricing table is confusing" is still too thin on its own — confusing how? — but "people can't tell the annual plan saves money, put the discount next to the price instead of burying it in the fine print" gives the builder something concrete to work against. If you don't know what the fix should look like, that's fine too; say what's wrong and let it propose the shape. What doesn't work is vague dissatisfaction with no anchor, because that turns every following version into a guessing game.
| Instead of… | Say… |
|---|---|
| "Improve it" | "The hero text is hard to read on the photo — give it contrast" |
| "Fix the game feel" | "The jump floats too long; make it snappier" |
| "Add auth somehow" | "Players need accounts so scores persist" |
| "Make it faster" | "The gallery page takes a beat to load images — show a placeholder instead of blank white" |
| "This section is bad" | "The testimonials look like an afterthought — give them the same weight as the pricing section" |
Mistake two: reacting to a version instead of looking at it
The second way people trip themselves up is answering the chat's summary of a change rather than the change. Someone reads "moved the schedule to its own page and darkened the header," forms a mental picture, and writes feedback against that picture instead of the actual site. Most "it got this wrong" complaints turn out to be "I hadn't opened the preview yet" — the result was fine, or close to fine, and the objection was really about an assumption. It costs maybe thirty seconds to click through before typing, and skipping that step is the single biggest source of rounds that shouldn't have existed. Even reviewing from a phone in a meeting, glance at the preview first — feedback on a description of a description compounds error fast.
The related mistake is bundling unrelated requests into one message and losing the ability to tell what caused what. You can absolutely stack several asks and get them all in one new version — a build that fixes the header, moves the schedule, and tightens mobile nav in a single pass is easier to review than three separate diffs, because you're judging one coherent state of the site rather than three deltas against a moving target. The trouble starts when the requests aren't related. Bundle a schedule-page overhaul with a global color change, and if something about the result feels off, you genuinely can't tell which change caused it — was the page hard to read because of the new layout, or the new palette? Untangling that costs a follow-up message and another full round just to isolate the variable. Keep "everything about the schedule page" in one message and "the color direction" in the next, even though nothing stops you from combining them; each version stays a clean comparison, and you can revert or adjust the one thing that needs it instead of throwing out an otherwise-good version because one piece missed.
Mistake three: treating each version as disposable
The third mistake is forgetting that a version card isn't a receipt, it's a working object, and skipping past what it actually offers. Every completed round produces a card with a live Preview — an actual running instance, not a screenshot, so clicking a button in it does what clicking it does in production. There's a Code tab for browsing every changed file, which matters if you're technical enough to spot-check something specific (does this form actually post to the right endpoint?) without waiting on a chat reply to confirm it. Download gets you the raw files. And the actions menu is where a version stops being a draft: publish it live, build native installers if it's an app, ship it to a store, save the whole thing as a template for future builds, or deploy it standalone.
People who skip all this end up trying to remember whether the button was blue in the old version instead of just opening the old version and looking — because the wreckage of treating cards as disposable is exactly that: relying on memory for something that's still sitting one click away. Version 4 doesn't get archived or frozen when version 7 ships. Its preview still runs, its code tab still browses, its actions menu still works, forever. Comparing two versions isn't a diff-reading exercise, it's opening both previews side by side and clicking around each one. The card also carries the build's verification record — the automated pass confirming it actually works before it's handed to you as done — scoped to that specific version, which is another reason old cards staying live matters: if version 6 verified clean and version 7 didn't, you have both to compare instead of a chat message saying "fixed it" that you have to take on faith.
The same instinct — treat the workflow as something to skim past rather than use — shows up in ignoring the follow-up suggestions the chat proposes after each build. They aren't generic filler; they're drawn from the build itself, so they tend to catch things you'd miss on your own pass: an empty state nobody designed, a form that doesn't confirm submission, a page that's fine on desktop and cramped on mobile. Taking them isn't required, but skimming them costs nothing, and they're a reasonable substitute for a QA pass if you don't have time to click through every page yourself.
