How to review AI agent code before merging

How should I review code written by an AI coding agent before merging

Review AI-written code like untrusted code from a fast junior contributor: verify the diff, run the tests, inspect security and edge cases, and merge only after you understand the failure modes.

Start with the pull request shape. A review is easier when the change is small, focused, and described clearly, because reviewers can follow one behavior change at a time instead of guessing the intent of a bundle of edits. GitHub’s review guidance recommends small pull requests and clear context, and Google’s review guide says reviewers should check design, functionality, and complexity, not just style.

Read the diff before you read the generated explanation. AI agents can write a convincing summary that does not match the code, so the source of truth is the patch itself. Look for deleted checks, renamed variables that hide behavior changes, and extra helper functions that make simple logic harder to trace. If you cannot explain the change in one sentence, the diff is still too opaque to merge.

Check the tests, but do not stop at “tests pass.” You want evidence that the new code covers the real behavior, including the unhappy path, invalid input, boundary values, and rollback or retry behavior when the system fails halfway through. OWASP’s secure review guidance treats input validation, error handling, and business logic as separate review areas, because a feature can work in the happy path and still be unsafe or brittle.

Run the code in the same way production will run it. That means the same environment variables, the same permissions, the same feature flags, and the same dependencies. AI agents often produce code that works in a local mock but fails when a real service returns a timeout, malformed data, or a partial response. Review the integration points first, because most agent mistakes show up where two systems meet, not inside a single function.

Look hard at security boundaries. OWASP’s secure code review checklist calls out authentication, authorization, input validation, output encoding, cryptography, logging, and dependency management because those are common places where code looks correct but creates a vulnerability. Ask one blunt question for every request path: who can call this, what can they control, what leaves the process, and what happens if the input is hostile.

The part people get wrong is reviewing only for obvious bugs. AI code often looks neat while quietly changing trust boundaries, skipping authorization on a new endpoint, logging secrets in an error path, or weakening a query that was previously parameterized. A change can be syntactically clean and still be a regression if it bypasses a guardrail that already existed elsewhere in the system.

Trace the data flow end to end. Pick one user input, follow it through validation, storage, transformation, and output, then confirm every step preserves the right constraints. This is where you catch SQL injection risks, insecure deserialization, unsafe file handling, and broken object-level authorization. If the path crosses a new service or queue, review the contract there too, because AI agents often miss implicit assumptions that humans rely on but code does not enforce.

Review the code for business logic, not just correctness. A function can return the right type and still allow an impossible state, a duplicate action, or a race condition that only appears under load. OWASP explicitly separates business logic review from basic input checks, and race conditions deserve special attention because they often pass unit tests and fail in concurrent production traffic.

Use a two-pass workflow. First pass, look for dangerous changes: auth, permissions, secrets, payments, deletes, writes, and external calls. Second pass, check maintainability: naming, duplication, error messages, and whether the structure makes the behavior obvious to the next person. Google’s review guidance treats complexity as a real review concern, not a polish item, because unreadable code becomes future bug debt.

Run targeted tests after you review the diff, not before. Add a test for the bug you fear most, then make sure it fails without the fix and passes with it. If the AI agent wrote a large change, ask for a test matrix that covers success, invalid input, auth failure, dependency failure, and idempotency. GitHub’s guidance on making changes easy to review pairs well with this approach, because focused tests are easier to inspect than broad, unfocused coverage.

Be strict about rollback safety. Before merge, know how to disable the feature, revert the patch, or turn off the integration if production behavior changes. That matters more with AI-generated code because the code can arrive quickly, and speed makes it easy to underestimate blast radius. A safe merge is one where you can name the first thing you would do if the patch starts causing incidents.

Require the agent to leave evidence you can verify. That evidence is a failing test before the fix, a passing test after the fix, a concise explanation of the change, and a pointer to the exact file or line where the main risk was handled. AI output that says “fixed security issue” without showing the control is not reviewable. Reviewers should be able to inspect the proof, not trust the summary.

Do not merge because the code looks confident. Confidence is not a review criterion. Behavior is. If you cannot answer what happens on bad input, repeated input, partial failure, or unauthorized access, the review is incomplete. If you can answer those questions and the tests support the answers, the patch is ready for a human decision.

If you want a lightweight process, use this order: read the PR title and intent, scan the diff, check security boundaries, inspect tests, run the app or relevant test slice, then decide whether the change is safe to revert. That sequence catches the most expensive mistakes early, and it works especially well when the patch came from an AI coding agent that moved faster than your intuition. DevConnect keeps the collaboration part simple, free, and focused on actual testing work: https://devconnectplatform.com

A final rule helps in practice: if the AI wrote code you would not be comfortable explaining to another engineer, you do not understand it well enough to merge it. The code may still be fine, but the review is not done until the behavior, the risk, and the rollback path are all clear.