You typed one sentence, an AI agent wrote two hundred lines across four files, the tests passed, and it felt done — so you merged it. A week later you’re staring at a null-pointer exception in a function you don’t remember existing, because you never actually read what got written. This is the exact failure mode that turns “vibe coding” from a superpower into a liability, and it has a simple fix: look at the diff before you look away.
Vibe coding is the increasingly common practice of describing what you want in plain English and letting an AI agent write the actual code, staying in the flow of the idea rather than the syntax. It’s fast and it’s fun — but “fast” and “reviewed” are not the same thing, and the gap between them is exactly where bugs, security issues, and quiet architectural drift get in. The fix isn’t to stop vibe coding. It’s to make reviewing the diff as automatic a step as writing the prompt.
Why Skipping Review Is Tempting — and Risky
When an agent reports “done, tests pass,” it’s easy to treat that as a green light. But passing tests only prove the existing tests still pass — they say nothing about:
- Code that technically works but doesn’t fit your codebase’s patterns (a new dependency for something you already had a utility for).
- Edge cases the tests don’t cover (empty arrays, network timeouts, race conditions).
- Security-relevant changes (a new SQL query built with string concatenation instead of your usual parameterized helper).
- Scope creep (the agent “helpfully” refactored a neighboring function you didn’t ask it to touch).
None of that shows up in a green checkmark. It shows up in the diff — which is exactly why the diff, not the test output, needs to be the thing you actually read.
A Practical Review Workflow
Treat every agent-produced change like a pull request from a new contractor: promising, probably fine, but worth five minutes of your attention before it goes anywhere near main.
Step 1: Isolate the change before you even look at it
Make sure the agent worked in its own branch (ideally its own git worktree) rather than directly on top of your working copy. This guarantees the diff you’re about to review is only the agent’s change — not tangled up with whatever you happened to have half-edited.
Step 2: Read the diff top to bottom, not just the summary
# See exactly what changed, file by file
git diff main...agent-branch
# Or, file names only, if you want the lay of the land first
git diff --stat main...agent-branch
Resist the urge to skim the agent’s own explanation of what it did and call that the review. The explanation is the agent’s claim; the diff is the evidence. Read the evidence.
Step 3: Flag anything that touches trust boundaries
Some categories of change deserve extra scrutiny no matter how confident the agent sounded:
| Category | Why it needs a closer look |
|---|---|
| Auth / permissions logic | A subtle off-by-one here is a security hole, not a bug |
| Database queries | Watch for string-built SQL, missing indexes, N+1 patterns |
| Error handling | Agents sometimes swallow exceptions to “make tests pass” |
| Dependencies added | New packages are a new supply-chain surface |
| Anything outside the requested scope | If you asked for A and got A + B, review B just as hard |
Step 4: Reference specific lines when you push back
The fastest way to correct an agent is with exact file:line references instead of vague descriptions — “the error handling in checkout.ts:142 swallows the exception, log it before returning” gets fixed correctly on the first try far more often than “can you improve the error handling.”
Step 5: Only merge what you’ve actually read
If a change is too large to review comfortably in one sitting, that’s useful information too — it usually means the original task was too broad, and splitting it into smaller, independently reviewable pieces will serve you better next time.
Why a Visual Diff Panel Beats the Terminal for This
git diff in a terminal works, but a side-by-side diff view — the kind you’d get in a pull request on GitHub — makes the kind of scanning described above dramatically faster: additions and deletions are color-coded, you can jump file to file, and it’s far easier to spot an unrelated change buried in a large diff.
This is the whole idea behind the diff panel in Agents: a right-side, Cursor-style git diff view sits next to every session in the sidebar, so you can see exactly what an agent changed — file by file — before it goes anywhere near your main branch. You can select any line and copy an exact file:line reference straight into your next prompt, which closes the loop between “I found a problem in the diff” and “I told the agent precisely where to fix it.”
Common Vibe Coding Review Mistakes
Even developers who know they should review agent output tend to fall into the same handful of traps:
- Treating a green test suite as a review. Tests confirm the code doesn’t break what’s already covered — they say nothing about code quality, security, or scope creep. Read the diff anyway.
- Reviewing the agent’s summary instead of the diff. A confident “I fixed the bug and added a test” is a claim, not evidence. The diff is the evidence.
- Reviewing everything in one giant diff. If an agent’s change spans a dozen files and you can’t hold the whole thing in your head, that’s a sign the task should have been split smaller — not a sign to skim faster.
- Giving vague corrections. “This doesn’t look right” produces a worse fix than “the null check on
orders.ts:58needs to happen before the discount is applied.” Specific file:line feedback closes the loop faster. - Merging straight to
main. Even a quick agent task benefits from landing on its own branch first, so a bad diff is onegit branch -Daway from gone instead of already baked into your history.
What Good Review Habits Feel Like Once They’re Automatic
The goal isn’t to slow vibe coding down — it’s to make the review step so lightweight that skipping it stops being tempting. In practice that means: isolate every task in its own branch or worktree by default, pull up the diff as the very next action after “agent says done,” and keep a habit of pointing at specific lines rather than describing problems in the abstract. None of that takes more than a couple of minutes per task once it’s a habit, and it’s the difference between a codebase you trust and one you’re quietly worried about.
Getting Started
- Next time an agent finishes a task, resist merging on the test-pass alone — pull up the diff first.
- Practice giving corrections as file:line references instead of general descriptions; notice how much more precisely the agent responds.
- If a diff feels too big to review comfortably, treat that as a signal to break the next task into smaller pieces.
- If you’re running agents on macOS, download Agents and try its built-in diff panel — reviewing every session’s changes in place, before merging, becomes a habit rather than a chore.
Vibe coding doesn’t have to mean skipping review — it just means moving the review to where it belongs: after the agent writes the code, before it becomes part of your history. Read the diff, and the “vibe” part stays fun instead of becoming a liability.