What to Focus On When Vibe Coding: Know When to Read the Code

A page loads. The button works. You ask an assistant to move the form, add search, and fix the error in the console. Within a short session, something that existed only as an idea becomes usable.

That experience explains the appeal of “vibe coding,” the phrase Andrej Karpathy introduced in February 2025 for a style of programming in which the person increasingly follows generated changes without closely reading the code.

The interesting boundary is not whether an assistant helped. Developers were using generated suggestions before this name existed. The boundary is how much understanding you need before you trust the result with something that matters.

A convincing demo leaves important questions unasked

Imagine a prototype for sharing project notes. You can create a note, open it, and edit it. A demo with one account goes well.

Now create a second account. Copy the first account’s note URL into the second account’s session. Does the server check ownership, or did the interface merely hide the link?

The browser cannot establish access control by looking correct. The relevant rule lives where the data is read and written. Someone must inspect that boundary and test it.

This is the point where I would stop accepting changes based only on the screen. The question has changed from “Can this interaction exist?” to “What prevents the wrong person from using it?”

Make understanding proportional to the consequence

A disposable local animation can tolerate experimentation that a shared account system cannot. Before extending the prototype, mark the parts where a mistake has consequences: authentication, authorization, stored data, external calls, billing, and destructive actions.

For each boundary, write down the rule in plain language. “Only a note’s owner can change its contents” is testable. “Make it secure” is not an acceptance condition.

Then trace the rule through the implementation. Ask the assistant to identify the relevant files and explain its proposal, but verify that explanation. A model can produce a coherent account of a check that is missing or placed too late.

Read the dependency changes too. Adding a package creates another thing to understand and maintain. A high download count is context, not proof that the specific use is correct.

Keep changes small enough to reject

When a prototype breaks, a broad request to “fix everything” can produce a patch that removes the symptom while changing unrelated behavior. The next request then tries to repair those changes, and the original intent gets harder to recover.

Save a known state before each substantial change. Ask for one behavior at a time. Inspect the difference and run the relevant checks before stacking more work on top.

For the notes app, the ownership test should fail against the insecure version and pass once access is enforced. It should also confirm that the owner can still perform the intended action. Blocking every request would make the first test pass for the wrong reason.

Let the prototype answer a limited question

A quick prototype can reveal that the proposed interaction is awkward, unnecessary, or worth developing. That is valuable even if the code is later replaced.

The mistake is treating the pleasure of seeing it work once as evidence that the hidden parts are ready. The more costly the consequence, the more the evidence needs to include the code, its tests, and its operating assumptions.

Use the fast feedback to discover what to build. When the prototype begins carrying responsibility, slow down enough to know what you have built.