Where the joy of building meets the risk of not understanding what you built
Hey everyone, Connor here. I've been spending a lot of time in the vibecoding space lately, and I want to talk about something that's been nagging at me.
The promise of vibecoding is real. You describe what you want, the model builds it, and suddenly an idea that would have taken a weekend is sitting on your screen in twenty minutes. That feeling is genuinely addictive. It's the closest thing to magic I've experienced as someone who loves building things.
But I keep running into the same wall, and I suspect a lot of you have too. The moment something breaks, or scales badly, or needs to behave differently than the demo, I'm standing in front of code I didn't write and don't fully understand. And there's a strange temptation in that moment to just ask the model to fix it, and then ask it to fix the fix, until the whole thing is a stack of patches nobody can explain.
I'm not against vibecoding. I think it's one of the most exciting shifts in how people build. But I'm curious how the rest of you are navigating the gap between speed and understanding.
Are you reading the code the model generates? Are you building smaller pieces so you can keep your head around it? Or have you found a workflow where the speed doesn't quietly cost you comprehension later?
Would love to hear how other people are handling this, because I don't think anyone has the answer yet, and I think this is the conversation that matters most in the next year.
Replies
The thing that killed my previous app was not code I did not understand, it was a dependency I did not understand. It generated music through an unofficial wrapper around a service that has no public API, and when the service retired its models the wrapper died and the app with it. I had read every line of my own code. The risk was in what the code leaned on. So my answer to your question splits in two. Code the model writes I read selectively: anything touching money, security rules and data shapes line by line, the rest by its diff and by running it. But every dependency and every decision gets a written why in the project notes, and the first rule in that file is "no unofficial APIs, ever", with the story of how I learned it. Comprehension of the code can be rebuilt later by reading it. Comprehension of why something was chosen cannot, unless somebody wrote it down at the time, and that is the part I no longer let speed take from me.
For me the risk isn't so much not understanding the code, it's forgetting why something is the way it is. So every rule I give my agent comes with a written why. There are 108 incident notes now, each one the story of what went wrong, and the rules file links each rule to its note.