When do you stop prompting and just fix the UI yourself?
by•
One thing I keep noticing with vibe coding is that small UI changes can sometimes take more prompting than expected.
You ask AI to adjust the spacing. It changes something else. You explain it again. The result gets closer, but now another detail is off.
At some point, opening the code and fixing it yourself feels faster than writing another prompt.
As a product designer, I find that line interesting because vibe coding is supposed to reduce how much implementation knowledge you need. But knowing when to stop prompting can still require understanding what’s happening underneath.
For people who vibe code, when do you stop trying to get AI to fix something and take over manually?
34 views
Replies
@abdullah_javaid3 "Rejected before I look at spacing" — that ordering is the whole trick, and most people get it backwards. They review the visual result first, and by then the invented component is already in the tree and it's three more prompts to undo.
I hand it a component set too, but I made one change that helped more than the rule itself: any new component has to be added to an allow-list file first, in a separate commit. If it can't be committed there, it can't exist. Turns a "please don't" into a "can't."
An agent made a failing test pass by weakening the assertion instead of fixing the code. The suite stayed green for days while the screen was broken. The second it starts quietly rewriting checks just to say it finished, you take the keyboard.
I stop prompting when I notice it inventing a new component. After a redesign I set one rule: it only composes from a prebuilt component set and a single icon library, and anything it invents gets rejected before I look at spacing.
Do you hand your model a component set, or does it start from scratch each time?
@michael_hurley Component level, almost always. The reason: CSS-level edits are the ones the agent "helpfully" re-breaks on the next turn, because it doesn't know your tweak was intentional. If I fix at the component level — give the thing a real prop or variant — the next generation builds on it instead of fighting it.
Your "second prompt rule" is a good tripwire. I'd add one more: if I catch myself describing where it is instead of what it should be, I've already lost and just open the file.
A rule of thumb that tends to work: if the second prompt for the same visual tweak doesn't land, stop and open the file. Small spacing or alignment changes are usually one or two lines once you find them, and describing them in words often takes longer than the fix. It also helps to tell the AI exactly which component and property to touch, so it doesn't rewrite neighbors. Do you find it easier to take over at the CSS level or the component level?
@skldk Yours is stronger than mine. Mine lives in a design doc plus a checklist I run before merging, so it is still a "please don't" that I enforce by reading.
The case I worry about is the restyled copy: the same button under a new name instead of a variant on the existing one. Would your allowlist catch that, or only a genuinely new name?
@chanil-92 For me the line isn't about complexity, it's about whether the prompt is still specifying *what* or has drifted into describing *where*. The moment I catch myself saying "no, the one above the header, the second one" — I've stopped specifying intent and started directing by pixel. That's when I open the code.
Reason: a prompt that describes a location encodes *my current screen state*, not the feature. The agent can't generalize from it, so the next change breaks it again. A manual edit at the component level becomes something the agent can build on.
So: stay in the prompt while it's cheap and general; take the keyboard the moment you're describing symptoms instead of outcomes.