Unpopular opinion: the best vibe coders write specs, not prompts
by•
The vibe coding aesthetic online is all 'just describe what you want and ship.' The actual best ones I know do something different.
What I keep noticing:
- They write longer specs and shorter prompts
- They check the agent's plan before letting it execute
- They commit small, review often, and roll back without ego
- They treat the agent as a fast intern who needs clear briefs
The 'just vibe it' framing makes for good Twitter content. The people actually shipping production code with AI look more like senior engineers running a tight async team.
Maybe vibe coding scales when it stops being vibey?
65 views
Replies
the "check the agent's plan before letting it execute" part is the one people skip most, in my experience. it feels slower in the moment, you're reading a plan instead of watching code appear, but it's the step that actually prevents the expensive kind of mistake - the agent confidently building the wrong thing for 20 minutes because nobody caught the misunderstanding at step one. the intern analogy is right too, a good intern brief also saves you from re-explaining the same context five times over the day
@galdayan the 20-minutes-confidently-wrong failure mode is exactly why we stopped letting agents touch anything model-facing without a plan review first. cheapest fix we found: make the agent state its assumptions before the plan, half the misunderstandings show up right there before it writes a line.
@galdayan @sabber_ahamed Stating assumptions before the plan is such a smart cheap fix, stealing that. Feels like most of these failures aren't really an AI problem, they're a "nobody forced the model to show its thinking early" problem, and that one extra step catches so much before any code gets written.
@galdayan @nolan_vu that reframe is right, it's a review habit gap not a model limitation. curious if the "show thinking early" step stays sticky once you trust an agent more, or does it get skipped first?
@galdayan @sabber_ahamed Good question, and honestly for me it fades a bit once trust builds up, which is probably the risky part. First few weeks I made the agent show assumptions on almost everything, now I catch myself skipping it on stuff that "should" be fine, and that's usually exactly when it bites me.
@galdayan This is so real, the plan review step is the first thing that gets skipped when you're in a rush, and it's exactly when you need it most. Watched an agent burn through a whole afternoon confidently building the wrong feature once because nobody stopped to sanity check the plan at minute one.
The intern brief comparison lands hard too, good context up front really does save you from repeating yourself five times over.
@nolan_vu I take a lot of time to align with the coding agent. Directly telling agent what to do leads to unexpected results and rollbacks. I follow what you mentioned, except I commit big.
Vibe coding gets overwhelming, though. If the product is complex, I have to track multiple things, and often just describing does not cut it.
@roopesh_donde Thanks Roopesh, really appreciate you calling this out. I've started feeling the same thing recently. The more AI coding tools improve, the less time I spend tweaking prompts and the more time I spend clarifying requirements upfront. A vague prompt can still produce something impressive, but a good spec usually produces something usable.
What surprised me is how often "bad AI output" turns out to be a requirements problem rather than a model problem. Once I started writing clearer constraints, edge cases, and expected outcomes, the number of rework cycles dropped dramatically. Feels less like prompting and more like product thinking now.
MonoCloud for Startups
the brief quality thing is underrated. you can tell within 5 minutes of watching someone vibe code whether they've actually thought through what they want or they're just hoping the agent figures it out.
@riya_pariyar This is such a good way to put it, you really can tell in the first few minutes. The ones who've thought it through ask the agent narrow questions, the ones just hoping it works out throw a vague prompt and pray. Kind of a tell on its own honestly, no need to even see the output yet.
the 'check the plan before letting it execute' one is underrated — most of my bad diffs trace back to skipping that step because the task looked simple. do you write the spec first every time, or only past some complexity threshold?
@sabber_ahamed Honestly for me it's mostly threshold based, if it's a one-file tweak I'll just wing it, but anything touching more than one system or anything customer facing gets a real spec first. Learned that the hard way after a "simple" task turned into an hour of cleanup because I skipped the spec on something that looked easy but wasn't.
@nolan_vu makes sense, that's basically our rule too. do you have a gut check for the ones that look like a one-file tweak but aren't, or is it always hindsight?
@sabber_ahamed Honestly it's mostly hindsight early on, then it becomes gut check once you've been burned a couple times. The pattern I've noticed is anything that touches a shared config or an API contract looks small but almost never is, those are the ones that fool me even now.
Absolutely. I would implore every vibe coder to use a skill like OpenSpec to actually explore their features before implementing. This will allow you to truly understand what you are building by asking the important questions and give you a breakdown of the steps required to implement such a feature.
The LLM can code, but it can't think. That's our job.