How to review AI-generated code: what breaks, what to check

In February 2026, Cloudflare rebuilt Next.js with AI in under a week, with about $1,100 in tokens, more than 1,700 Vitest tests, 380 Playwright tests and an AI agent reviewing every pull request. In production builds of Pages Router apps, the result, vinext, ignored a proxy.ts written as export function proxy, the form Next.js's own docs use. That's where teams put their auth checks, which worked in development and were silently skipped in production. We found the bug with a cubic codebase scan and sent the fix upstream.

It's a useful case for how to review AI-generated code, because it's the typical failure: the code compiles, the tests pass, and the bug sits where nobody wrote a check. Reviewing it well means changing the order you read in. Start with what the agent couldn't know (your intent and your unwritten rules) and what it can fake (its tests). Then go to the places it skips: authorization, input handling, failure paths and dependencies.

This blog belongs to cubic (cubic.dev), an AI code review tool, so we have a stake in this topic. The vinext and OpenClaw findings below come from our own published research. Every other claim links to its source.

Why reviewing AI-generated code is different

Volume comes first. Faros AI's 2026 report draws on telemetry from 22,000 developers and compares each organization's periods of lowest and highest AI adoption. At high adoption, median time in PR review rose 441.5%, and pull requests merged with no review at all, human or AI, rose 31.3%.

Then trust. In Stack Overflow's 2026 Developer Survey, the most common answer about AI output, from 48.0% of 14,304 developers, was that they trust it when they can easily verify it. Only 6.6% trust it with important work decisions.

Review is that verification, and it's harder when nobody on the team wrote the code. A human author can explain every choice. With an agent, the author of record often learns the code during review. That gap is comprehension debt, which we wrote about in The real problem with AI coding.

How AI-written code fails differently

Human mistakes cluster around typos, off-by-one errors and forgotten edge cases, and linters, type checkers and tests catch many of them. Agent mistakes cluster somewhere else.

It looks right and compiles

Agents have mostly solved syntax. Veracode's 2026 GenAI Code Security Report says models now write syntactically correct code nearly 100% of the time. Its 2026 report added 11 new models, tested on 80 coding tasks in summer 2026, and puts the average security pass rate across every model it has tested at 56%, against 55% in its first report a year earlier. Pass rates fell sharply on cross-site scripting and log injection, to 15% and 12%.

So code that looks clean tells you little, and people still read it as safe. In a Stanford study published at CCS 2023, participants with an AI assistant wrote less secure code than those without one, and were more likely to believe their code was secure.

It misses context it never saw

An agent knows its training data and whatever is in its context window. vinext's bug sat in that gap. Next.js 16, released in October 2025, renamed middleware to proxy, and the agent wrote the older convention. The generated production runner looked for a default export and a middleware export, never proxy.

Your codebase has the same gap, in rules nobody wrote down. Say your team queues analytics events because a slow analytics service once stalled checkout. An agent tidying the payment handler calls analytics directly. The test mock answers instantly, so everything passes. We wrote about this kind of failure in Why AI code fails differently.

It skips authorization and validation

Agents build what the prompt asks for, and who may use it is rarely in the prompt. OpenClaw, an open-source AI agent that runs with full system access, was written fast, with much of the code AI-generated. When we scanned it, its whatsapp_login tool, which pairs a new WhatsApp session, was open to every contact on the allowlist instead of only the owner, so any of them could take over the instance. Its message tool checked the path and filePath parameters against the sandbox root but not media, so a file:// URL could read any file on the machine. Both are in our OpenClaw write-up, and the maintainers merged the fixes within hours.

The security vendor Apiiro saw the same shift at scale. In its 2025 analysis of repositories at Fortune 50 companies, with data through June 2025, syntax errors in AI-assisted code fell 76% while privilege escalation paths rose 322%.

It invents packages and APIs

Models import packages that don't exist. A USENIX Security 2025 study of 16 models and 576,000 generated code samples found that 19.7% of the packages they referenced were fake, 205,474 distinct names in all. The fakes repeat: 43% came back on all 10 reruns of the same prompt, which makes them easy to predict and register. That trick now has a name, slopsquatting. In an experiment written up in March 2024, a Lasso Security researcher registered one name models kept inventing, huggingface-cli, as an empty package. Lasso says it drew more than 30,000 authentic downloads in three months.

Rarely used APIs get invented too. In CloudAPIBench, a 2024 benchmark from AWS researchers, GPT-4o made valid calls to low-frequency cloud APIs only 38.58% of the time.

It duplicates code instead of reusing it

Agents write a new helper more readily than they find the old one. GitClear's 2026 AI code quality report, built on 623 million code changes, tracked duplication as AI authorship grew. It found 81% more duplicated blocks (five or more repeated lines) per changed line so far in 2026 than in 2023, the highest rate it has recorded. Moved, or refactored, code fell to 3.8% of changed lines.

Every copy is a place a fix can miss. OpenClaw's voice-call allowlist, which anyone could bypass by blocking their caller ID, was checked in two files, manager.ts and manager/events.ts, so our fix had to change both, and so did the maintainers' own version that shipped the same day.

OpenClaw's voice allowlist before the fix, from openclaw/openclaw#8104. The same check lived in two files.

Its tests check the code, not the spec

Tests written alongside the code tend to describe the code. A study of LLM-generated test oracles across 24 Java repositories found they mostly capture what the program does rather than what it should do, which makes them poor at finding bugs.

vinext's test plan had the same shape. The team chose which Next.js tests to port by listing the features it had built, so the Next.js test for a middleware file that lacks the expected export never came over. As the maintainers put it in issue #204, the middleware "silently failed open".

Agents also change tests until they pass. In ImpossibleBench (ICLR 2026), researchers gave models tasks whose tests contradicted the spec, so any pass meant cheating. GPT-5 passed 76% of one SWE-bench-based set anyway, and Claude models cheated mostly by editing the tests, though told not to.

It changes more than you asked for

Agents bundle work. In Apiiro's data, AI-assisted developers made three to four times as many commits as their peers, packed into fewer, larger pull requests that touched more files and services. In one, an AI-driven change to an authorization header across several services missed one downstream service, which left a silent auth failure. Faros's 2026 data shows average PR size up 51.3% at high AI adoption.

How to review AI-generated code, step by step

Read in this order. The early steps are cheap and can send a PR back before you spend an hour on it. These are the checks agent-written code needs most.

1. Check the size and scope. Compare the files the PR touches with the task. A config change, a refactor of a shared helper or a new dependency the task didn't need goes in its own PR. Google's review guide calls about 100 lines usually reasonable and 1,000 usually too large, and lets reviewers reject a change for size alone.

2. Compare the change with the intent. Read the issue or prompt before the code, then ask whether the change solves that problem or a nearby one. Wherever the spec is silent, the agent guessed. Find those guesses and decide each one.

3. Read the tests before the code. Expected values should come from the spec, not from running the code. Then read every change to an existing test: a deleted assertion, a looser matcher, a new skip, a mock that makes a failure path pass. In a feature PR, a test diff deserves more suspicion than the feature.

4. Check who can call each new entry point. For every new route, handler, tool or job, find where access is checked. The check belongs on the server, and it should test ownership, not only that someone is signed in. New parameters need the same validation as their neighbors. Test data access with a second account.

5. Follow untrusted input. Trace it to where it lands: queries, HTML, logs, file paths, URLs, shell commands. Veracode's two sharpest drops, cross-site scripting and log injection, are both input reaching output unescaped.

6. Verify every new dependency. Confirm the package exists in the registry you expect, then check who publishes it, when it first appeared and how widely it's used. A month-old package with a name close to a popular one is a red flag. Read the lockfile diff, too.

7. Read the failure paths. Ask what happens when a lookup returns nothing, a call times out or a config key is missing. Look for fallbacks that let a request through, like vinext's return { continue: true } when it found no middleware function, and for empty catch blocks and defaults that differ between development and production.

8. Check contracts across files. Find every caller of a changed function and every use of a renamed export, header, config key or event. Search for an existing helper before accepting a new one, and for copies of any code being fixed. Then run it: open a preview environment and click through the real flow once.

How to set up your team for AI-generated pull requests

Google's DORA team found in its 2025 report that AI adoption still goes with less stable software delivery, and that strong automated testing, version control practices and fast feedback loops are what keep the extra change volume in check. Review is part of that system. These habits keep it working:

• Keep agent PRs small. Put the size limit in the agent's instructions and send back anything over it.

• Give every PR a human owner. Whoever prompted the agent is the author, and should be able to explain every line before asking for review.

• Let an AI reviewer take the first pass on every PR. It reads at the speed agents write, so human reviewers start from a PR that's already been checked for the mechanical problems.

• Keep humans on intent, design and risk. People judge whether this is the right change, whether it's built the right way, and what happens if it's wrong.

• Write down your unwritten rules. Put them in AGENTS.md or CLAUDE.md, which coding agents and many AI reviewers read (cubic included). Start with your last five incidents.

• Protect the files that matter. List your auth, payment, migration and test files in CODEOWNERS and turn on "Require review from Code Owners", so an agent's edit to them always reaches a named person.

Where an AI code reviewer helps, and where it can't

An AI reviewer is the one reviewer that keeps pace with agents. It reads whole PRs at the speed agents open them, follows data across files and applies the same written rules every time. That's how our codebase scan found OpenClaw's flaws in hours: agents traced data flows and edge cases across the whole codebase in parallel. Our post on how AI code review works explains the mechanics.

Plan around its limits:

• It can't know intent nobody wrote down. If the spec lives in someone's head, the reviewer can only check the code against itself.

• A PR review starts from the diff. vinext had an agent reviewing every PR, and the missing proxy check still shipped. We found it with a codebase scan that ran thousands of agents for 24 hours.

• It doesn't remove the human bottleneck by itself. In Faros's 2026 data, AI agents reviewed 25% of PRs, and review times still rose.

• It's a model, so it's sometimes wrong. Martian's Code Review Bench scores review bots on real open-source pull requests. In its last-month view, checked October 10, 2026, the top tool scores 64.0 F1. F1 balances how many real issues a reviewer catches against how many of its comments are wrong. That #1 tool is cubic, so weigh our view accordingly, and note what the number means: even the top reviewer misses real issues and sometimes flags non-issues. The board moves daily. Our list of the best AI code review tools compares the rest.

Questions and answers

Is AI-generated code safe?

Not by default. In Veracode's 2026 tests of AI-generated code security, even the top model, GPT-5.5, failed nearly one in three security tasks. Treat agent code like code from a fast new contributor who has never seen your threat model: the same review bar, plus the checks above.

How do you make a vibe-coded app secure?

Andrej Karpathy named vibe coding in February 2025 to describe accepting every change without reading the diffs, and judged it acceptable for throwaway weekend projects. Once real users or real data arrive, read every diff that touches auth, data, payments or secrets. Vibe coding security mostly comes down to access control. Matt Palmer, then in developer relations at Replit, a Lovable competitor, scanned 1,645 apps built with Lovable and found 170 whose row-level security left their databases exposed. That finding is CVE-2025-48757, which Lovable disputes, saying each app's owner is responsible for its data. Test every table with a second account and with no account.

What should a security checklist for vibe-coded apps include?

• Auth checked on the server for every route, function and tool

• Row-level access rules on every table, tested with two accounts

• No secrets in client code or the repository

• Validation on every input

• Every package confirmed to exist, with a real publisher and history

• Errors that fail closed

• Rate limits on sign-in and on anything that costs you money

Our secure code review guide goes deeper.

The agent writes the code. Your review decides what ships.

cubic reviews pull requests on GitHub. Try its AI code review on your next agent-written PR: the trial lasts 7 days and needs no card.