Reviewing AI-Generated Code

The fastest way for vibe coding to go wrong is treating AI output as finished, rather than as a draft that still needs your review, exactly like you'd review a pull request from a teammate.

What to check every time

• Does it actually do what you asked? Re-read the diff against your original goal, not just "does it run."
• Logic errors, off-by-one mistakes, wrong comparison operators, edge cases (empty lists, zero, null) that were never tested.
• Security, this is where blind trust is most dangerous: SQL/command injection, missing input validation, secrets hardcoded into source, authentication or authorization checks that got weakened or removed.
• Scope creep, did it change more than you asked for? Unrelated refactors hidden inside a "simple fix" are easy to miss if you don't read the whole diff.

Test before you trust

1. Run the change locally.
2. Exercise the exact scenario you asked for.
3. Try at least one edge case or invalid input.
4. Check existing tests still pass, and add a new one if the change deserves it.

You still have to understand it

If a bug shows up in production next month, you're the one debugging it, whether or not you personally typed the original code. Reading and understanding why an approach works, not just confirming that it appears to work, is what turns vibe coding into a sustainable practice instead of a liability.