What parts of a vibe-coded product should never be left to the vibe?
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?
Replies
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.
MonoCloud for Startups
@faysal_fateh 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?”
My line is whether a wrong call is quiet or loud. UI, copy, layout, even a fair bit of app logic, if the model gets it wrong I see it the first time I click through, so I let it decide freely there. Anything touching money, deletion, or a statutory deadline gets written as a fixed rule before any AI touches that file, because a wrong interpretation there does not surface as a bug, it surfaces as a customer finding out weeks later that something they were owed never happened. The tell for me now is asking whether a mistake would show up in testing or only in a support ticket three weeks on. If it is the second, I do not let the model infer the behaviour, I write it down first and treat the AI as implementing a spec rather than authoring one.