How much of a spec do you write before letting the AI vibe-code the rest?
by•
I keep going back and forth on this. Write out a tight spec first (user story, edge cases, acceptance criteria) and the AI output gets a lot more predictable, but it also kills a chunk of the speed that made vibe coding appealing in the first place. Skip the spec and just describe the vibe, and I end up rewriting prompts three or four times to fix things a spec would've caught upfront. Where do people here actually land? Full spec, loose bullet points, or just winging it and iterating in the chat?
21 views
Replies
let an agent fix edge case and write the test. Test passed, but I reverted the fix to check and test still passed. Was testing wrong assertion. So now spec always includes failing reproduction test written manually before any code generated
I used to justify specs by saying the structured version is cheaper. I was wrong, publicly. At the same scope JSON runs longer than the prose that says it, and providers bill the schema as input on top.
What a spec actually buys is a smaller answer space. In one of my recipes the blocking decision reads six short enum values instead of the 2,439 character source, 42x smaller at the point where something branches. Which means the tax is real. It just buys something that is not speed.
I’ve found the sweet spot is somewhere in between. For example, if I’m vibe coding a signup flow, I’ll just say “simple signup, Google or email, then take them to the dashboard” and let the AI handle the first version. But if there are edge cases around existing users, validation, password resets, etc., I’ll spell those out. Otherwise I end up spending more time correcting the AI than I saved by skipping the spec.