Fundamentals

How to Review Code You Didn't Write

The awkward secret of vibe coding is that you're accountable for code you didn't write and maybe couldn't have written. That sounds worse than it is. Reviewing code is a different (and more learnable) skill than writing it — closer to reading a contract than composing one. Here's how to do it without pretending to expertise you don't have.

Start at the entry point, not the top of the file

Find where things begin — the page that loads, the function that runs first, the button's click handler — and read outward from there. Code makes sense as a story of "user does X, then…", not as a stack of files read alphabetically.

Trace one action all the way through

Pick the app's most important action — submit, save, buy — and follow it end to end: what gets read, what gets computed, where the result goes. One completed trace teaches you more about the codebase than an hour of skimming. It's also exactly where the important bugs live.

Ask the AI to explain — then verify against reality

"Explain what this file does, in plain language, and list anything unusual" is a legitimate review tool. But treat the explanation as a claim, not a fact: models describe what code appears to do. Run the app and confirm the described behavior actually happens. Where explanation and behavior disagree, you've found either a bug or a lie — both worth knowing.

Let behavior be your ground truth

You may not be able to judge elegance, but you can absolutely judge behavior: what renders, what gets sent over the network, what's stored, what the console reports. Behavioral review catches the failures that matter — silent errors, unexpected requests, data going somewhere odd — without requiring you to evaluate style.

Know the red flags anyone can spot

  • Empty error handlers — catch blocks with nothing inside are failures being hidden.
  • The same logic twice — two near-identical functions means fixes will miss one of them.
  • Secrets in the source — anything that looks like a key or password.
  • Dead weight — imports and functions nothing uses, often left over from regenerations.
  • Comments that don't match the code — a sign of drift between versions.
Where Vibe Coder Playground fits: behavioral review needs a place to watch behavior. The Playground runs your own build and shows the rendered DOM, live network calls, and state — so "verify the explanation against reality" is a two-minute check instead of an act of faith.

You'll get faster than you expect

The first review is slow. The fifth isn't. Codebases repeat their patterns, and once you've traced a few actions, new code reads like variations on a theme. Accountability without authorship is a skill — and it's the defining one of this era of building.

Related: 10 mistakes new vibe coders make →

Related: how to manage vibe coding sessions so the next one starts informed →