How to Review Code Written by an AI Agent

Do not start reading until the automated checks have passed. GitHub's guide to reviewing AI-generated code opens with the same rule: "Always run automated tests and static analysis tools first" (GitHub Docs). Make sure the code compiles, every test passes, and no new warnings appear.

The minimum automated gate for an agent-written change:

If any check fails, send the change back without a human review. An agent can fix a red build faster than you can diagnose it, and reading code that does not compile wastes your time.

A typecheck matters more for agent code than for human code. Agents sometimes call methods or parameters that look plausible but do not exist in the version of the library you use. GitHub's guide lists "hallucinated APIs, ignored constraints, or incorrect logic" as the first of the AI-specific pitfalls to look for. A compiler catches many of these in seconds.

Code can pass every check and still do the wrong thing. Before you judge how the code is written, judge what it does.

GitHub's guide suggests asking two questions: "Does this code solve the right problem? Does it follow our conventions?" (GitHub Docs). In practice:

1. Reread the original task. Compare the ticket or prompt with the pull request description. Agents often solve a nearby, easier problem, or quietly drop a requirement they could not satisfy.
2. Ask the agent what it assumed. GitHub's guide offers a prompt worth reusing: "When examining this code, what assumptions about business logic, design preferences, or user behaviors have been made?" Assumptions the agent states are easy to check. Assumptions it hides are where bugs live.
3. Ask what it modeled the change on. If the agent says it followed the pattern in a specific existing file, you can check that file. If it cannot name one, it probably invented a pattern your codebase does not use.
4. Run it. For a user-facing change, open the app and use the feature. Google's guide notes that a UI change is hard to judge from the diff alone and suggests a demonstration when you cannot easily try it yourself (Google eng-practices).

Be skeptical of code that "looks right." GitHub's guide warns about exactly that: code that looks correct but does not match your intent.

Google's guidance is to "look at every line of code that you have been assigned to review" and to never scan over a block "and assume that what's inside of it is okay" (Google eng-practices). That rule matters more with agent output, because agent code is fluent. It reads well even when it is wrong.

While you read, look for five patterns that agents produce more often than people do.

Unrelated changes. thoughtbot advises reviewers to "look for seemingly unrelated changes," because an agent "will often change other parts of the app to get something working," and "maybe those things were done that way for a reason" (thoughtbot). Every file in the diff should trace back to the task. A reformatted file, a renamed variable in a module the task never mentioned, or a changed default value all deserve a question.

Reimplemented helpers. Agents often do not know what already exists in your codebase. thoughtbot notes that AI "will often reimplement things you already have." If you see a new date formatter, retry loop or validation function, search for an existing one.

Over-engineering. Google's guide warns about code made "more generic than it needs to be," or functionality "that isn't presently needed by the system," and asks reviewers to be "especially vigilant" about it. Agents add configuration options, abstraction layers and defensive branches for cases that cannot happen. Ask for the simplest version that solves today's problem.

Ignored constraints. Check the change against your project rules: forbidden libraries, required error formats, files that must not be edited, and anything in your project context file. Agents read those rules but do not always follow them.

Comments that narrate. Generated code often carries comments that restate what the code does, or describe the history of the change. Google's guide says comments should explain why code exists, not what it is doing. Ask for narration to be removed before merge.

Tests are where agent-written changes most often deceive a reviewer, because a passing test suite looks like proof. thoughtbot's warning is blunt: "AI will do whatever it needs to do to get a test passing, including stubbing or mocking the implementation it's supposed to be testing" (thoughtbot). GitHub's guide adds a second pattern to watch for: "tests that are deleted or skipped, instead of fixed" (GitHub Docs).

Check five things in every test change:

1. Did any existing test change? A modified assertion in an old test is the most important line in the diff. Find out whether the behavior was meant to change or the agent edited the test to match a bug.
2. Did any test get skipped, deleted or marked as expected to fail? Search the diff for skip markers and removed test files.
3. Does the test exercise real code? If the function under test is mocked, the test proves nothing.
4. Would the test fail if the code were broken? Google's guide asks exactly this: "Will the tests actually fail when the code is broken?" (Google eng-practices). A quick check is to break the implementation on purpose and run the test.
5. Are edge cases covered, and are there too many tests? thoughtbot notes that agents often write a lot of tests, some of which duplicate coverage elsewhere, and large setup blocks that would have signaled a design problem to a human writing them by hand.

A useful habit is to review the test file before the implementation. If the tests describe the intended behavior well, the implementation review is faster.

Studies of generated code keep finding the same classes of flaw. Georgetown's Center for Security and Emerging Technology evaluated code from five models and reported in November 2024 that "almost half of the code snippets" contained bugs that were "often impactful and could potentially lead to malicious exploitation" (CSET). Endor Labs groups the common findings by weakness type (Endor Labs):

• Missing input validation, SQL injection and OS command injection.
• Missing authentication, broken access control and hard-coded credentials, often when the prompt did not mention security at all.
• Dependency sprawl, where a simple request pulls in several packages.
• Hallucinated dependencies, where the agent imports a package that does not exist.

The Cloud Security Alliance explains why: models learn from public code, so if an unsafe pattern such as string-concatenated SQL appears often in training data, the assistant "will readily produce it" (Cloud Security Alliance).

The security pass for an agent-written change:

• Trace every input from the request to the database, file system or shell. Look for parameterized queries and escaped output.
• Check every new endpoint for authentication and authorization, not only the happy path.
• Search the diff for secrets, keys and tokens, including in test fixtures.
• Verify every added package. Confirm it exists, is maintained and has a license compatible with yours. GitHub's guide warns about "hallucinated or suspicious packages" and slopsquatting, where attackers register package names that models tend to invent (GitHub Docs).
• Ask for a second reviewer on anything touching auth, payments, personal data or concurrency. Google's guide says to make sure a qualified reviewer sees complex areas such as "privacy, security, concurrency."

A review process that only works on small days will fail on busy ones. Four habits keep it manageable.

Keep changes small. Ask agents for one concern per pull request. A thousand-line diff from an agent gets skimmed, and skimming is how flaws reach production.

Write comments the agent can act on. thoughtbot points out that the author "might simply put your PR comment into an AI agent," so be specific about what should change. "Use the existing formatCurrency helper in src/lib/money.ts" gets fixed. "This seems off" does not.

Suggest larger changes freely. The same article notes that the author is less attached to agent-written code, so it is fine to ask for a different approach. The agent will do the rewrite.

Use a checklist. GitHub's guide recommends checklists "to ensure all key review points (functionality, security, maintainability) are covered." A short one:

[ ] Build, tests, lint, security and dependency scans are green
[ ] The change does what the task asked, and nothing else
[ ] Every changed file traces back to the task
[ ] No reimplemented helpers; no speculative options or layers
[ ] No existing test weakened, skipped or deleted
[ ] New tests exercise real code and fail when it breaks
[ ] Inputs validated; queries parameterized; endpoints authorized
[ ] Every new dependency exists, is maintained, and is licensed for us
[ ] A qualified second reviewer saw auth, payments or personal data

Finally, remember Google's balance. Reviews exist to improve code health over time, not to demand perfection. "Nit:" comments can wait. Anything that makes the system worse should not merge, no matter who or what wrote it.