How to review code AI wrote

how do i review code that ai wrote

Review AI-written code the same way you review risky human code, but start by checking the contract first. Ask what the change is supposed to do, what files it touches, and what must not change. AI code often looks confident while missing one constraint that matters in production.

Begin with the smallest useful unit: the diff. Read every changed line, not the summary. Look for code that was copied from somewhere else, broad refactors that were not asked for, hidden behavior changes, and new abstractions that make the path harder to follow. A clean-looking rewrite can still be wrong if it changes input validation, error handling, or data shape.

Read the code as if you must own it next month. If you cannot explain the change in plain language, the review is not done. The part people get wrong is trusting the AI’s explanation instead of tracing the actual code paths. AI can describe an intended behavior that the implementation does not fully deliver.

Run the tests, then read what they cover. Passing tests do not prove the code is safe, they prove only that the current test set did not fail. Add or inspect tests for the paths the AI is least likely to get right: empty input, malformed input, permission failures, duplicate requests, network timeouts, retries, and partial writes. Google’s own guidance for AI-assisted code review stresses style checking, test execution, and feedback synthesis, not just parsing output.

Check the boundaries where AI code tends to drift. Authentication, authorization, database writes, caching, background jobs, and state transitions deserve extra scrutiny. If the code changes a permission check, a query, or a transaction, verify the exact before and after behavior. A one-line change in those areas can turn into a data leak, a broken workflow, or a hard-to-reproduce outage.

Security review comes next. Look for unsanitized user input, string-built SQL, unsafe shell execution, secrets in logs, weak file handling, and overly broad network access. Ask whether the code creates a new attack surface, not just whether it compiles. AI often optimizes for a working demo and skips the narrowest secure path unless you force it to justify each risky choice.

Check for overreach. AI-written code often adds helpers, wrappers, or framework layers that solve a problem you did not ask to solve. Extra code is not free, because every new path needs tests, monitoring, documentation, and future review. If a smaller change can preserve the behavior, prefer the smaller change. The goal is not elegant code, it is code that is easy to trust and maintain.

Review the failure modes in the runtime path. Ask what happens when the database is unavailable, when an API call returns a different schema, when a queue delivers the same message twice, or when the process restarts mid-operation. AI code often handles the happy path well and the recovery path poorly. A good review names the exact failure, then checks whether the code survives it without corrupting state.

Use the repo itself as evidence. Search for the same function, similar validation, and existing utilities before accepting a new implementation. AI frequently reimplements patterns that already exist in the codebase, which creates drift and inconsistent behavior. Reuse is not just style, it keeps the code aligned with the rest of the system and reduces future review cost.

If the change is large, review it in layers. First confirm the architecture, then the interfaces, then the core logic, then tests, then docs. Do not try to hold the whole feature in your head at once. Break the review into claims you can verify. For example: “This endpoint only reads data,” then check routing, service calls, and tests to confirm that claim.

Use a deliberate checklist. Confirm the feature still matches the ticket, confirm inputs are validated, confirm outputs are typed or shaped correctly, confirm side effects are intentional, confirm errors are handled, confirm logs are safe, confirm tests fail when they should, and confirm rollback is possible. A checklist prevents the common failure where the reviewer likes the code and stops looking for evidence.

When the AI adds tests, review those too. Bad tests can be worse than none because they create false confidence. Look for assertions that only repeat the implementation, mocks that cover nothing meaningful, and snapshots that would pass even if the behavior regressed. Good tests pin down user-visible behavior, not the exact shape of a temporary implementation detail.

If the AI wrote a refactor, compare before and after behavior with a real example. Feed the old and new code the same input and see whether outputs, errors, and side effects match. This is especially useful for parsing, formatting, billing, access control, and data migration code. Reviewers miss subtle regressions when they only inspect the final code and never compare behavior.

The inconvenient part is time. A real review takes longer than accepting the AI’s first pass, because you are checking facts, not vibes. That cost is the price of using AI safely. It is still faster than debugging a production bug, cleaning up a security mistake, or explaining to a teammate why the generated code “looked right.”

If you want a practical pattern, use this order every time: understand the goal, scan the diff, check the risky paths, run and read tests, inspect security and failure handling, then decide whether to merge, request changes, or rewrite the part that does not hold up. Keep the review short enough to finish, but not so short that you skip the one path that breaks in production.

For teams that are doing this often, a shared checklist helps. DevConnect has a place to coordinate testing work and keep the feedback loop tight, which is useful when the code review needs real device or account coverage and you want to keep that exchange on your own work, not on borrowed trust. https://devconnectplatform.com

A strong review also leaves a trail. Leave comments that name the risk, the expected behavior, and the evidence you checked. “This input can be empty and the current code throws” is more useful than “please fix.” Comments like that make future reviewers faster and help the next AI pass learn from concrete failures instead of vague preferences.

If the code is still unclear after review, do not guess. Ask the AI to explain one function, one branch, or one test at a time, then verify the answer in the repository. The review is complete when you can point to the exact lines that make the change safe, and the exact lines that would break if the assumption is wrong.

When you catch a mistake, fix the prompt or the workflow as well as the code. If the AI keeps missing the same kind of issue, that means the review process is missing a guardrail. Add a test template, a lint rule, a checklist item, or a human approval step where the failure happened. The point of review is not only to reject bad code, it is to make the next draft better.

FAQ

Should I trust AI-written code if it passes tests No. Passing tests only show that the current test set did not catch a failure. Read the implementation, inspect risky paths, and add tests for the edge cases the AI is least likely to handle correctly.

What should I review first in AI-generated code Start with the diff and the contract. Confirm what the change is supposed to do, then verify the changed lines against that goal before looking at style or cleanup.

How do I review a large AI-generated refactor Split it into pieces: architecture, interfaces, logic, tests, then side effects. Compare old and new behavior on a real example so you can see whether the refactor preserved the user-visible result.

What is the biggest mistake people make reviewing AI code They read the explanation instead of the code. The second mistake is stopping after tests pass, which leaves security bugs, edge cases, and state bugs unexamined.

Should I ask the AI to review its own code Yes, as a first pass. Treat that output as a checklist and not as proof. A second human or a careful manual review still needs to verify the actual behavior.

What if I do not understand the code after reviewing it Do not merge it yet. Ask for a smaller explanation, trace one function at a time, and compare the code with existing patterns in the repository until the behavior is clear.