How many parts of your "vibe-coded" app do you really read before sending it off?
For months now, I've been working on a side-project that I have mostly created via prompting, and I can see myself falling into bad habits that are kind of worrying me. When I started out, I was reading all the lines of the AI-created code. Now, after three weeks, I basically just skim through looking for any apparent mistakes and trust everything else.
It works. Users have never complained. And yet, honestly speaking, there is much of my authentication process that I do not understand anymore, which is a scary thought when it comes to code that is already in production use.
I'm not trying to sound alarmist here, but many bits of manually written code share the same problem once the codebase gets big enough. Still, I would be curious to know where other vibecoders draw the line. Is there something that you always read thoroughly and never let slip?
Replies
Agent lost context mid task, rebuilt helper function that already existed two files away under different name. Caught duplication only later debugging edge cases ) Now I read every diff specifically to verify it used existing utilities.
Same drift here. What helped me was splitting the code in two. UI and glue code I skim. Auth, payments and database permissions I read line by line, and I ask the agent to write tests for them before touching anything. On my project the database has row-level security, so even if the app code has a bug, the database still blocks the wrong reads. That's what lets me sleep.
omadesign
Agreed—the diff is where a “working” app can hide a lot of future debugging. On native desktop work I look first for new files versus edits to existing helpers, then run the changed path once before I ship; a duplicate helper or quiet API mismatch can cost hours. Thanks for the reminder to keep the craft in the loop.