How to Review AI-Written Code in 2026: Checklist

Why AI-written code keeps reaching production

By 2026, AI-generated code is not a novelty. It is the default for many teams. The docs from major AI code tools describe a workflow where a developer types a prompt, gets a diff, and merges it after a quick skim. That workflow puts AI-written code into production at scale, often without the scrutiny a human-written change would get.

The reasons are practical. AI code generators are fast. They produce plausible solutions to common problems in seconds. They handle boilerplate, tests, and migrations that developers find tedious. The cost of generating code has also dropped. The live pricing snapshot shows frontier models like openai/gpt-5-pro at $15 per million input tokens and $120 per million output tokens, while anthropic/claude-opus-4 sits at $15 in and $75 out. Batch pricing cuts that further, with openai/o1-pro:batch at $75 in and $300 out. When generation is cheap, the bottleneck shifts from writing code to reviewing it.

But the economics of generation do not change the economics of bugs. A model that produces a plausible function in two seconds can also produce a subtle security hole in the same two seconds. The difference is that a human reviewer, reading a diff, has to find that hole before it ships. The review process is the only gate between a plausible diff and a production incident.

This checklist turns "trust the model" into a repeatable process. It covers security, correctness, performance, and the human-AI loop. It is written for 2026, when AI-written code is a normal part of the codebase, not a special event.

Security review checklist: prompt injection, secrets, and dependency risks

Security is the first thing to check in AI-written code, because models are trained on patterns that include insecure examples. The OWASP Top 10 for AI-generated code lists prompt injection, sensitive information disclosure, and insecure output handling as top risks. A reviewer should look for each of these explicitly.

Prompt injection

Prompt injection happens when untrusted input changes what the model does. In AI-written code, this shows up in two places. First, the code itself might be generated from a prompt that includes untrusted content, like a user message or a fetched web page. If that content contains instructions, the model might follow them. Second, the generated code might build prompts for another model at runtime. If that prompt includes user input without sanitization, an attacker can manipulate the downstream model.

Review for prompt injection by asking: does this code concatenate user input into a prompt? Does it pass raw web content to a model? If yes, the code needs input validation, output filtering, or a clear separation between instructions and data. A common fix is to wrap user input in delimiters and instruct the model to ignore anything inside them, but that is not a complete defense. The safer pattern is to treat any model output as untrusted data, not as code or as a command.

Secrets and hardcoded credentials

AI models are trained on public code, which includes leaked secrets. A model might reproduce a hardcoded API key, a database password, or an AWS access key that appeared in its training data. The generated code might also contain a placeholder secret that a developer forgets to replace.

Review for secrets by scanning every string literal in the diff. Look for patterns like sk-, AKIA, password=, or any long base64 string. Use a secret scanner in CI, but also do a manual pass. If the code contains a real-looking secret, assume it is compromised and rotate it. If it contains a placeholder, make sure the deployment process injects the real value from a secret manager, not from the codebase.

Dependency and supply chain risks

AI code generators often suggest dependencies. The model might recommend a package that is typosquatted, unmaintained, or has a known vulnerability. Snyk and Veracode research on AI code quality has shown that AI-suggested dependencies are more likely to have security issues than human-chosen ones, because the model does not check the current vulnerability database.

Review every new dependency in the diff. Check the package name against the official registry. Verify the version is not a typo of a popular package. Run a vulnerability scan on the lockfile. If the model suggested a package that is not widely used, question why it is needed at all. The lazy approach is to reject any dependency that does not have a clear, documented purpose.

Insecure output handling

AI-written code might generate HTML, SQL, or shell commands from model output. If that output is not escaped or parameterized, it can lead to XSS, SQL injection, or command injection. Review for any place where a string from a model is used in a dangerous context. The fix is the same as for human-written code: use parameterized queries, escape HTML, and avoid shell interpolation.

Correctness traps: hallucinated APIs, off-by-one errors, and edge cases

Correctness is harder to review than security, because the code often looks right. AI models are good at producing code that compiles and passes the happy path. The bugs hide in edge cases and in APIs that do not exist.

Hallucinated APIs and functions

Models sometimes generate calls to functions that do not exist in the library version being used. This happens because the training data includes many versions of an API, and the model blends them. A common example is calling a method that was added in a newer version, or using a parameter name that changed.

Review for hallucinated APIs by checking every function call against the actual documentation of the installed version. Do not assume the model got the signature right. A quick way to catch this is to run the test suite, but tests can also be hallucinated. The reviewer should spot-check a few calls manually, especially for less common libraries.

Off-by-one and boundary errors

Off-by-one errors are classic, and AI models produce them just like humans do. The model might write a loop that goes one iteration too far, or a slice that excludes the last element. These are hard to see in a diff because the code looks symmetric.

Review loops and array accesses for boundary conditions. Check what happens at the first and last element. Check empty collections. Check single-element collections. The model might handle the common case but break on the edge. A good review asks: what happens when the input is empty, when it is the maximum size, when it is null?

Edge cases and error handling

AI-generated code often has thin error handling. The model writes the happy path and skips the failure modes. This is not malice; it is the training data. Most code examples do not show robust error handling.

Review for missing error handling. What happens if a network call fails? If a file does not exist? If a user sends malformed input? The code might throw an unhandled exception, or worse, silently swallow the error and return a wrong result. The review should ensure that every external call has a defined failure behavior, and that errors are logged or surfaced, not ignored.

Performance and non-obvious regressions

Performance issues in AI-written code are often non-obvious. The code might be correct and secure, but still slow, because the model chose an inefficient algorithm or added unnecessary work.

Algorithmic complexity

Models tend to write simple, readable code, which is good. But simple can mean quadratic. A nested loop over a list that should be a hash map lookup is a common pattern. The model might also use a linear search where a binary search would do.

Review for algorithmic complexity by looking at loops and data structures. Ask: is this O(n) or O(n^2)? Could a set or a map reduce the work? For small inputs, the difference does not matter. For production data, it can be the difference between a fast endpoint and a timeout.

Unnecessary work and repeated computation

AI-generated code sometimes recomputes the same value in a loop, or fetches the same data multiple times. The model does not see the whole system, so it does not know that a value is already available. This leads to redundant database queries, repeated API calls, and wasted CPU.

Review for repeated work by tracing the data flow. Is the same query executed in a loop? Is the same calculation done on every iteration? If so, hoist it out. This is often a simple fix that has a big impact.

Non-obvious regressions

A performance regression is not always a slow function. It can be a change in behavior that makes a previously fast path slow. For example, the AI might add a sort to a list that was already sorted, or change a lazy load to an eager load. These changes are hard to spot in a diff because they look harmless.

Review for regressions by comparing the new code to the old behavior. Run the existing performance tests, if any. If there are none, consider adding a simple benchmark for the critical path. The review should ask: does this change make the system slower in a way that matters?

Using AI to review AI: agentic code review workflows

In 2026, the review process itself can use AI. Agentic code review workflows use a model to analyze a diff, flag issues, and suggest fixes. This is not a replacement for human review, but it can catch the obvious problems before a human looks at the code.

How agentic review works

An agentic review tool takes the diff and the surrounding context, and runs a model over it. The model checks for security issues, correctness problems, and style violations. It can also run tests or static analysis. The output is a list of findings with severity levels and suggested fixes.

The pricing snapshot shows that running a frontier model for review is affordable. openai/o3-pro costs $20 per million input tokens and $80 per million output tokens. anthropic/claude-opus-4.1 is $15 in and $75 out. A typical diff is a few thousand tokens, so the cost per review is fractions of a cent. That makes agentic review a practical first pass.

Strengths and limits

Agentic review is good at catching known patterns: hardcoded secrets, obvious injection points, missing error handling. It is fast and consistent. It does not get tired or skip lines.

But it has limits. The model does not know the business context. It cannot tell if a change breaks a subtle invariant that the team relies on. It might also hallucinate issues, flagging code that is actually fine. The review output should be treated as a suggestion, not a verdict.

Another limit is that the reviewing model can be fooled by the same prompt injection that affects the generating model. If the diff contains untrusted content, the reviewing model might be manipulated. This is a known risk in agentic workflows, and it means the human reviewer must remain the final authority.

Choosing a review model

For agentic review, the choice of model matters. The pricing snapshot shows a range. openai/gpt-5.5-pro is $30 in and $180 out. anthropic/claude-opus-4.6-fast is $30 in and $150 out. openai/gpt-5.2-pro is $21 in and $168 out. The cheaper models, like openai/gpt-5-pro at $15 in and $120 out, may be sufficient for a first pass. The more expensive models might catch more subtle issues, but the marginal value depends on the codebase.

A practical approach is to use a cheaper model for the initial scan and escalate to a more expensive model for critical files or for files that the cheaper model flags as high risk. This keeps costs low while still getting deep analysis where it matters.

Setting up a human-AI review loop

The best review process combines AI and human judgment. The AI does the boring, repetitive checks. The human does the contextual, judgment-based review. The loop should be explicit and repeatable.

Define the review criteria

Before the AI reviews anything, the team should define what matters. Is it security? Correctness? Performance? Style? The criteria should be written down and shared with the review tool. If the criteria are vague, the AI will produce vague findings.

A good set of criteria includes: no secrets in the diff, no untrusted input in prompts, no new dependencies without justification, no off-by-one errors in loops, and no obvious performance regressions. These are the items from the checklist above, turned into a machine-readable list.

Automate the first pass

The first pass should be automated. Run the agentic review on every pull request. The tool should check for the criteria and post findings as comments. This catches the easy stuff before a human spends time on it.

The automation should also run the existing test suite and static analysis. AI-written code should pass the same gates as human-written code. There is no reason to give it a pass.

Human review of the diff

The human reviewer should not read the AI's findings first. They should read the diff with fresh eyes, looking for the same criteria. Then they can compare their findings with the AI's. This catches the AI's blind spots and the human's blind spots.

The human should focus on the parts the AI cannot evaluate: business logic, invariants, and long-term maintainability. Does this change fit the architecture? Does it introduce a pattern that will be hard to maintain? These are questions the AI cannot answer.

Close the loop with feedback

The review loop should feed back into the generation process. If the AI keeps making the same mistake, the team should update the prompt or the review criteria. If the AI flags a false positive, the team should teach it to ignore that pattern. This is a continuous improvement cycle.

The loop also includes the developer who wrote the prompt. If the AI-generated code needs many fixes, the developer should refine the prompt to get better output next time. The review is not just about the code; it is about the process that produced it.

Legal and licensing concerns

AI-written code raises legal and licensing questions that a reviewer should consider. These are not just theoretical. They affect whether the code can be shipped.

Training data and copyright

AI models are trained on large amounts of public code, which includes code under various licenses. The output might be similar to code from a specific repository, including code with a restrictive license. This is a risk, but the legal landscape is still evolving. Courts have not settled whether AI output can infringe copyright.

For a reviewer, the practical question is: does the generated code contain a recognizable copy of a known library or snippet? If it does, the team should check the license of that source. Some companies have policies that prohibit using AI-generated code that is too similar to a known source. The reviewer should be aware of the company's policy.

License compatibility

If the AI suggests a dependency, the license of that dependency matters. A GPL dependency in a proprietary product can be a problem. The reviewer should check the license of every new dependency and ensure it is compatible with the project's license.

This is not unique to AI-written code, but AI makes it more likely because the model does not consider licensing. The model might suggest a package that is perfect functionally but has an incompatible license.

Attribution and provenance

Some licenses require attribution. If the AI-generated code is derived from a licensed source, the team might need to include a notice. This is hard to determine, because the model does not provide provenance. The reviewer should treat any AI-generated code as having unknown provenance and be cautious about using it in a way that requires strict attribution.

The safest approach is to have a policy that AI-generated code is reviewed for license issues just like any other third-party code. If there is doubt, the team should not ship it until the legal team clears it.

How this review was researched

This article is based on public documentation and data sources. The security checklist draws from the OWASP Top 10 for AI-generated code. The dependency risk discussion references research from Snyk and Veracode on AI code quality. The correctness and bug-rate discussion references studies from GitHub Copilot and OpenAI on bug rates in AI-generated code, as well as SWE-bench verified results. The pricing figures come from the live AI model pricing snapshot, which lists input and output token prices for models such as openai/o1-pro at $150 in and $600 out, anthropic/claude-opus-4.7-fast at $30 in and $150 out, and openai/gpt-5.4-pro at $30 in and $180 out. No tools were tested for this article; the analysis is based on documented behavior and pricing data.