How to catch bugs in AI-generated code before they reach production

An AI assistant can produce a working-looking feature in seconds. The hard part isn't generating the code anymore — it's knowing whether you can trust it. AI models are confident even when they're wrong, they hallucinate APIs that don't exist, and they happily "fix" a failing test by deleting the assertion. If you ship whatever the agent hands you, you're not really building software; you're gambling.

The good news: you don't need to read every line like a paranoid code reviewer. You need a layered safety net so that obvious mistakes get caught automatically and only the interesting decisions reach your eyes. Here's how to build one, from cheapest to most thorough.

1. Read the diff, not the chat

The single highest-value habit: review the actual file changes, not the AI's summary of them. Tools like Claude Code, Cursor, and Copilot all show a diff before you accept changes. Skim it with three questions:

• Did it touch files I didn't expect? Agents sometimes "helpfully" edit config, delete tests, or rewrite unrelated functions.
• Did it invent an import or API? A red flag is a call to a library method you've never seen. Verify it exists before trusting it.
• Did it weaken anything? Removed error handling, loosened a type, commented-out a check, or a test that now asserts almost nothing.

This 30-second scan catches the majority of "the AI did something dumb" moments.

2. Let the machine check the machine

Humans are bad at spotting a missing semicolon and great at spotting bad logic. Flip the boring work onto tooling so your attention goes where it matters. Three cheap, free layers:

• A linter (ESLint, Ruff, etc.) for style and common mistakes.
• A type checker (TypeScript, mypy) to catch the hallucinated-API and wrong-shape-of-data class of bugs.
• A test runner for behavior.

The trick is to make these non-optional by wiring them into a pre-commit hook so they run before any commit lands. Here's a minimal example using Husky in a JavaScript project:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Now if the AI's code fails the linter, breaks types, or fails a test, the commit is simply rejected. The agent's mistake never reaches your branch. (In Python, the equivalent is the pre-commit framework running ruff, mypy, and pytest.)

3. Make the AI write — and run — the tests

AI assistants are genuinely good at generating tests, and tests are the best defense against the next change silently breaking this one. But there's a catch: an agent that writes and runs its own tests can cheat by making the test trivially pass. So separate the steps in your prompt:

"Write tests for this function covering the empty input, the happy path, and one edge case. Do not modify the function itself."

Then run the tests yourself, or in CI, and confirm they actually exercise real behavior. A test like expect(result).toBeDefined() is theater; expect(addTax(100, 0.2)).toBe(120) is a real check. Read at least one assertion to make sure it's the second kind.

4. Add a quality gate in CI

Local hooks protect your machine; a CI check protects the project from everyone (including future-you on a tired evening). Add a workflow that re-runs lint, types, and tests on every pull request, and configure the branch so merges are blocked until it passes. This is exactly the idea the big platforms are now selling as a product — GitHub's Code Quality, going generally available in July 2026, adds gates that block a merge when maintainability or coverage drops, and Cursor reframed its /review command as a pre-commit gate earlier this year. You can get 80% of the value for free with a plain GitHub Actions or GitLab CI job.

5. Keep a human in the loop for the risky 5%

Automation can't judge whether a feature is the right feature, whether an architecture decision will age well, or whether deleting that "unused" function is safe. Reserve your real attention for: anything touching auth, payments, or data deletion; database migrations; and changes to shared code many other files depend on. For everything else, let the safety net do the work.

A simple rule of thumb

The more autonomy you give the AI, the stronger your gates need to be. If you're carefully accepting one change at a time, a quick diff read may be enough. If you're letting an agent run for ten minutes unattended, you want lint, types, and tests standing between it and your main branch. Build the net once, and you can let the AI move fast without it quietly breaking things behind you.