6.1CORE PATH

Reading Code You Didn't Write

The single highest-leverage skill for vibe coders. Most of the difference between people who ship and people who don't is whether they can read their agent's output and tell when it's wrong.

You don't have to be able to write the code yourself. You have to be able to read it well enough to spot:

  1. WHAT THE CODE CLAIMS TO DO. Read the function names, the comments, the variable names. Does the code's vocabulary match what you asked for?

  2. WHETHER THE CONTROL FLOW MAKES SENSE. Where do if statements branch? What loops run? Read the code top to bottom and ask "what happens in this scenario, and this one, and this one?"

  3. WHETHER THE EDGE CASES ARE HANDLED. What if the input is empty? Null? Negative? Too big? Look for explicit checks. The absence of a check is a bug, not a feature.

  4. WHETHER THE DATABASE OPERATIONS ARE WHAT YOU EXPECTED. Look for SELECT, INSERT, UPDATE, DELETE. Read the WHERE clauses. Does the code touch the tables you expected? Only those tables?

  5. WHETHER ERRORS ARE HANDLED. What happens when a function fails? Is the error caught? Logged? Returned to the user? Or silently swallowed?

The discipline: don't accept a single line of agent output without reading it. Even if it works. Even if you're tired. Even if it's "just" a small change. The bug you don't notice today is the production incident next month.

A practical workflow:

Step 1: Read the diff. Most coding agents show you a diff (a side-by- side or before/after view) of what they're changing. Read every line. Don't skim.

Step 2: Run it. After accepting changes, run the code. Hit the new endpoint. Click the new button. Verify the actual behavior matches what the code claims to do.

Step 3: Test edge cases. Submit an empty form. Submit a form with unicode characters. Submit a form twice in rapid succession. Try the edge cases the agent didn't think of, because that's where the bugs are.

Step 4: Check the logs. After the run, look at the logs (or the console output). Are there any errors or warnings you didn't expect? Investigate them.

If you can't do these four steps for a piece of code, you should not have asked for that code yet. Either lower the scope (ask for less) or learn more (return to v1).

Curriculum last updated 2026-04-30