Vibecoding
Build for the vibe, debug later
Start new thread

What parts of a vibe-coded product should never be left to the vibe?

by
•

I’ve been building more with AI lately, and I’ve realised I am comfortable letting it write a lot of the code, but much less comfortable letting it decide the rules the product runs on. If I already know how something should behave, I usually define that first. What inputs are valid, what should happen, what should never happen, edge cases, fallback behaviour. AI can help me build it, but I don’t want an important product rule to exist only because the model happened to infer it correctly in that conversation. The line gets blurry pretty quickly though.


I am fine giving AI much more freedom with something like UI implementation. Billing feels very different. So do permissions, data deletion, security checks, or anything where one slightly different interpretation can have an actual consequence. And once you start defining enough rules yourself, I am not even sure where “vibe coding” ends and AI-assisted development begins.

For people shipping real products this way, what do you still let the AI decide?

And what have you decided should always be deterministic, no matter how good the model gets?

35 views

Add a comment

Replies

Best

I’m with you on this. For me, auth, permissions, billing, data deletion and anything that changes state should never be left to AI to “figure out.”

I’m happy letting AI handle most of the frontend and even draft a lot of the logic, but the rules themselves need to be explicit and tested. One small interpretation drift in permissions isn’t a UI bug, it can become a data leak pretty quickly.

The tricky part is figuring out where that line is as the product gets more complex.

 I think “anything that changes state” is where I would probably draw the line a little differently. Some state changes are cheap to undo. Others have real blast radius. I am much more comfortable letting AI create a draft, rename something, or update a reversible setting than letting it change permissions, move money, delete data, or touch production access. So maybe the boundary is less “can it change state?” and more “how reversible is the mistake, and how bad is the consequence if it gets it wrong?”

I’m comfortable letting AI handle a lot of the UI work, but my boundaries are much stricter around anything involving money or user data.

 I am similar, but I think “user data” gets complicated pretty quickly because not every data action carries the same risk. I would be fine letting AI update something reversible like a preference or draft, but exporting data, changing permissions, or deleting anything would need a much harder boundary.

Do you separate those actions too, or treat anything touching user data as one category?