How to Verify AI-Generated Code Before You Ship It (2026)

Last quarter I asked a room of engineers how much of their shipped code had been touched by an AI assistant. Every hand went up. Then I asked how many had a repeatable process for verifying that code before it reached production. Two hands. That gap is the single most expensive habit in software right now.

Here is the uncomfortable stat: multiple 2025 studies on AI-assisted development found that roughly 40 to 45 percent of AI-generated code samples contained at least one known security weakness, and developers using AI assistants shipped code they believed was more secure while it was measurably less so. The tools are fast and often brilliant. They are also confident when they are wrong, which is the worst combination in engineering.

This article is a hands-on playbook for how to verify AI-generated code before you ship it. You will get a repeatable review workflow, a worked example with real numbers, a comparison of verification approaches, and the specific traps that AI models fall into again and again. I use this process daily across TypeScript, PHP, and Python projects, and it has caught bugs that both I and the model missed.

Key Takeaways

• Never trust AI code that compiles. Compiling proves syntax, not correctness or safety.
• Run every AI snippet through a fixed pipeline: read, isolate, test, scan, and diff-review.
• The most common AI failures are outdated APIs, missing input validation, and invented dependencies (package hallucination).
• Automated tools catch the boring 70 percent. A human catches the dangerous 30 percent. You need both.
• Treat AI output like a pull request from a talented junior who never tests their own work.
• Supply-chain checks matter more than ever: a hallucinated package name can become a real attack vector.

Why AI-Generated Code Needs Verification At All

Large language models predict plausible text. Code that looks right is not the same as code that is right. A model will happily generate a function that reads cleanly, passes a linter, and quietly leaks memory or skips an authorization check.

There are three structural reasons AI code fails verification:

• Training lag. Models learn from code that is often two to four years old. They suggest deprecated methods, insecure defaults, and libraries that have since had major breaking changes.
• Context blindness. The model does not know your threat model, your data-retention rules, or that your User object already sanitizes input. It optimizes for the local prompt, not the global system.
• Confident hallucination. When unsure, models invent. They fabricate function signatures, config keys, and entire npm packages that do not exist.

That last point deserves attention. Security researchers have documented "slopsquatting," where attackers register the exact fake package names that AI tools commonly hallucinate. Copy the suggestion, run npm install, and you have just pulled malicious code into your build. Verification is not paranoia. It is the cost of using the tool responsibly.

The 5-Step Verification Pipeline

Here is the workflow I run on every meaningful block of AI-generated code. It takes two minutes for a small function and maybe twenty for a complex module. Both are cheaper than an incident.

1. Read it line by line, out loud if needed. Do not skim. If you cannot explain what each line does and why, you are not qualified to ship it. This alone catches the majority of logic errors.
2. Isolate and run it. Drop the code into a sandbox or a scratch branch. Never let AI output touch a shared environment on first run. If it hits a database, point it at a disposable copy.
3. Write tests the AI did not see. Feed it edge cases: empty inputs, negative numbers, unicode, oversized payloads, and null. Models tend to handle the happy path and ignore everything else.
4. Scan for security and dependency issues. Run static analysis, a secrets scanner, and a dependency audit. Verify every imported package actually exists and is the one you intended.
5. Diff-review against your codebase conventions. Does it match your error handling, logging, and naming patterns? Inconsistent code is a maintenance tax you pay forever.

Treat it like a pull request from a junior developer

The mental model that works best: pretend a talented but overconfident intern submitted this. They are fast and know a lot of syntax. They also never test, never read the docs for the current version, and assume the happy path is the only path. You would never merge that PR without review. AI code is the same PR, generated faster.

A Worked Example: Verifying an AI-Written Login Function

Let me make this concrete. I asked a popular assistant to "write a PHP function to log a user in and store their session." Here is what came back, lightly paraphrased:

• It queried the users table with a string-concatenated SQL statement. SQL injection vulnerability.
• It compared passwords with == against a plaintext column. No hashing at all.
• It stored the raw user ID in $_SESSION without regenerating the session ID. Session fixation risk.
• It imported a helper from a package called php-auth-utils. That package does not exist on Packagist.

Four serious defects in roughly fifteen lines of clean-looking code. Now watch the pipeline catch them.

Step 1 (Read): The string concatenation in the query jumped out immediately. Any concatenated SQL is a red flag.

Step 3 (Test): I passed a username of ' OR '1'='1. It logged in as the first user in the table. The exploit took eight seconds to reproduce.

Step 4 (Scan): A static analyzer flagged the injection and the missing hash. A dependency audit failed to resolve php-auth-utils because it was hallucinated.

The before/after math: the original function had 4 vulnerabilities. After rewriting with parameterized queries, password_hash(), session_regenerate_id(true), and the built-in library, it had zero. Total time to verify and fix: about twelve minutes. Time an SQL injection breach would have cost: measured in days and reputation. If you run WordPress or a PHP CMS, this is exactly the class of bug that tools like eDarpan WordPress Protection and SiteGuard Pro exist to backstop when something slips through.

Verification Approaches Compared

Not every method catches every problem. Here is how the main approaches stack up on the issues that actually cause incidents. No single row is enough on its own.

Approach	Catches logic bugs	Catches security flaws	Catches fake dependencies	Speed	Best for
Manual line-by-line review	Excellent	Good	Moderate	Slow	Critical or auth-related code
Unit and edge-case tests	Excellent	Weak	None	Medium	Business logic, algorithms
Static analysis (SAST)	Moderate	Excellent	None	Fast	Injection, unsafe defaults
Dependency / SCA audit	None	Good	Excellent	Fast	Supply-chain, hallucinated packages
A second AI model as reviewer	Good	Moderate	Weak	Fast	First-pass sanity check only

The takeaway is that you layer these. Tests plus static analysis plus a dependency audit covers most automated ground. Manual review of the sensitive parts closes the gap that automation cannot see, like a subtly wrong authorization boundary.

The Specific Traps AI Code Falls Into

After reviewing thousands of AI suggestions, the failures cluster into predictable buckets. Knowing them turns review from vague suspicion into a checklist.

1. Outdated and deprecated APIs

Models frequently suggest methods removed years ago. In JavaScript I still see substr() and old callback patterns. In Python, libraries with breaking 2.x to 3.x changes. Always cross-check any unfamiliar method against the current official docs, not the model's memory.

2. Missing input validation

AI writes for the input it imagines, which is always clean. It rarely validates length, type, encoding, or range unless you explicitly ask. Every function that touches user input should be tested with garbage.

3. Hardcoded secrets and unsafe defaults

I have watched models generate code with debug=True, permissive CORS set to *, and placeholder API keys that developers forget to replace. A secrets scanner in your pipeline catches these before they hit a public repo.

4. Package hallucination

Before you install anything an AI suggests, confirm the package exists, check its download count, and read its recent activity. A "helpful" library with 40 total downloads and a name that sounds too perfect is a warning sign. This is the same vetting discipline we cover in our guide to vetting browser extensions before granting AI permissions.

5. Silent scope creep on permissions

AI-generated infrastructure and IAM code trends toward over-permissioning because broad access "just works." Verify that every permission is the minimum required. Least privilege is never the model's default.

Building Verification Into Your Everyday Workflow

Verification only sticks if it is friction-free. Here is how to make it automatic rather than a virtue you occasionally remember.

• Pre-commit hooks. Wire a linter, secrets scanner, and dependency check into a git pre-commit hook so nothing untested reaches even your local history.
• A dedicated review branch. All AI-heavy work lands on a branch that runs the full CI suite before it can be merged.
• Snippet management. Keep your verified, known-good patterns in one place so you reach for a trusted snippet instead of regenerating from scratch. A tool like LionPaste is genuinely useful for storing and reusing code you have already vetted

  Cover image: The Torch Graduate circuit board (bottom) by Chris Whytehead, licensed under BY-SA 3.0 via Openverse.