Reading diffs critically
A diff is the list of exactly what changed: red lines removed, green lines added. Reading diffs is the highest-leverage habit in vibe coding, because it's where you catch the AI doing something you didn't ask for.
You don't have to understand every line. Scan for these red flags:
- Files you didn't expect to change. Why did a config file get touched?
- Deleted code. Did it remove a validation check, an error handler, or a test "to make it pass"?
- Secrets or hardcoded values. (Application Programming Interface) keys, passwords, or URLs (Uniform Resource Locators — web addresses) that shouldn't be in the code.
- Disabled checks. A skipped test, a commented-out guard, a
// @ts-ignore, or a loosened permission. - Scope creep. Changes far from what you asked for.
If anything looks off, ask: "Explain why you changed X — I didn't ask for that." Make the AI justify deletions especially. "It was causing an error" is a reason to understand the error, not to delete the check.
A practical way to build the habit: read the diff before you accept the change, never after. Once code is merged and the app seems to work, you'll never go back and read it — there's no friction forcing you to. The moment of review has to be the moment of decision. Tools help here: git diff --stat gives you a one-line-per-file summary so an unexpected file jumps out immediately, and reviewing on a page surfaces the whole change in one scrollable view instead of scattered across your editor.