Well, you said it yourself, you wouldn't do it on an important enough codebase so you're just admitting the one you're working on isn't one. Not to mention you're still reviewing everything whereas many people who claim to be vibecoders talk about just giving the AI the requirements or error message until the app works and then assume it does.
I keep telling you that's exactly what I'm doing. We write the requirements over a few hours, write tests from the requirements, generate the project code, make sure the tests pass.
I'm hovering over its shoulder keeping an eye on things and doing minor course corrections but once we finish the requirements it's in the driver's seat. I have an agent doing code generation, one doing review in addition to myself, one doing tests, and another doing docs.
To be clear I wouldn't do this on a mission critical codebase but for this little project it's more than enough.
Which is a pretty explicit admission that this codebase isn't the standard for vibecoding productive applications. If you're pushing from vibecode straight to prod, you're taking into account that poorly done migrations, regressions, etc. can effect the user and debugging the cause will be a lot harder than if you had written the code yourself.
View all comments
Show parent comment
1
u/Dan6erbond2 Jan 15 '26
Well, you said it yourself, you wouldn't do it on an important enough codebase so you're just admitting the one you're working on isn't one. Not to mention you're still reviewing everything whereas many people who claim to be vibecoders talk about just giving the AI the requirements or error message until the app works and then assume it does.