Vibe coding is fast, but can you still explain what you built?
I think one of the interesting things about vibe coding is how quickly you can end up with something that works.
As a product designer, I used to spend more time figuring out how something should work before seeing it in action.
Now I can build a working version with AI much earlier in the process.
But there’s something I’ve started paying more attention to.
Just because the product works doesn’t always mean I fully understand how everything works underneath.
And that becomes a problem when I need to change something, explain a decision, or figure out why a particular interaction behaves the way it does.
I’m not saying everyone needs to understand every line of code.
But I do wonder how much understanding is enough when AI is doing most of the implementation.
For people who vibe code, how do you make sure you actually understand what you’ve built?
Replies
My bar is being able to explain the decisions, not every line. I don't read every function, but for each feature I want to know three things: where the data lives, who is allowed to change it, and what happens when the outside service it depends on fails. Those three answers cover most of the moments you describe, changing something or explaining why it behaves the way it does. The other thing that helps is asking the agent to write down the why of every decision that isn't obvious from the code, so a month later I'm reading my own reasoning instead of guessing. As a designer, do you find the flows easier to hold in your head than the code?
Test what you built, thoroughly. You don't have to do it all yourself though. I have AI write the E2E test scenarios and run the tests too. After working with agents long enough you get a feel for where they tend to slip. Anything that just reads data I hand off without much worry, but anything that updates data I test carefully.