Verifying AI Output

The intro made a promise: you own correctness and security. This lesson is where that promise gets cashed out. In 2026, generating code is cheap and fast — verifying it is the bottleneck. The engineers who thrive are the ones who verify well.

Why AI code needs different verification

Human bugs and AI bugs don't look alike:

• A junior human who doesn't understand something usually writes code that looks broken — it won't compile, or it's obviously incomplete.
• An AI writes code that looks perfect — clean, idiomatic, well-named — and is semantically wrong. It calls a plausible-but-nonexistent method, handles the happy path and silently drops the edge case, or subtly misreads the requirement.

⚠️ AI failures are syntactically fine and semantically wrong. You cannot catch them by skimming for ugliness — the code is beautiful. You catch them by checking behavior against intent.

This is also why AI-assisted code ships ~2× the critical vulnerabilities of hand-written code (see Security): reviewers rubber-stamp code that reads correct.

Review the diff and the spec — not the prose

Three levels of review, weakest to strongest:

1. ❌ Read the AI's explanation and trust it. The explanation is also AI-generated; it can be confidently wrong about its own code. Lowest signal.
2. ✅ Review the diff. Read what actually changed, line by line, as you would a colleague's PR.
3. ✅✅ Review against the spec. Ask "does this satisfy each acceptance criterion?" — not just "does this line look okay?" This catches the semantic errors that line-by-line review misses. (This is why Spec-Driven Development pays off.)

🎯 As changes get larger, shift from line-by-line reading to specification review — verify the what, backed by tests, rather than exhaustively eyeballing every line of a 500-line diff (which nobody does well anyway).

Close the loop: make the agent verify itself

The highest-leverage move is to give the agent a way to check its own work automatically, so errors surface before they reach you:

• 🧪 Tests — the single best AI verifier. A passing test suite is objective proof the behavior is right. Consider TDD-with-AI: write (or have the AI write, then you review) the tests first, then let it implement until they pass. The tests become the spec.
• 🔬 Static checks — types, linters, mypy/tsc, security scanners. Free, fast, catch whole classes of errors.
• 🏃 Dynamic checks — actually run it. Start the app, hit the endpoint, look at the output. "It compiles" ≠ "it works."
• 🔁 Feed failures back in. When a check fails, hand the error to the agent and let it fix — a tight generate → verify → correct loop. An agent that can run your tests can self-correct most of its own mistakes.

💡 The dream isn't "AI that never errs" — it's a closed loop where the agent's errors are caught by checks and fixed automatically, so only genuinely-verified work reaches your review.

Practical checklist

Before accepting AI-generated changes:

• [ ] Do the tests pass — and are there tests for the new behavior, not just the old?
• [ ] Did I run it and observe the actual behavior (not just trust "done")?
• [ ] Does it meet every acceptance criterion in the spec/task?
• [ ] Are the edge cases and error paths handled (the AI's favorite thing to skip)?
• [ ] Static checks clean — types, lint, no obvious security smells?
• [ ] Any new dependencies — are they real, maintained, and needed? (See Security.)

Bottom line: treat every AI change as a PR from a fast but unaccountable junior. It might be perfect; it might be confidently, beautifully wrong. Your tests, your checks, and your review are what turn "plausible" into "correct."

Next: verification's harder-edged sibling → AI Security & Trust.