Review agent-generated code with a human before commit

How do I review agent-generated code before committing with a human in the loop

Put the agent’s changes behind a pull request or merge request, then make a human read the diff, run the tests, inspect the risky files, and decide whether to approve, request changes, or reject the commit. Code review is specifically a process where someone other than the author examines the code, and GitHub and GitLab both treat review as the gate before merge.

The cleanest pattern is simple: the agent writes code on a branch, the branch opens a PR or MR, and a person who did not write the change reviews it before anything reaches main. GitHub’s review flow supports inline comments, review suggestions, and a final approve or request changes action. GitLab’s review flow similarly centers subject matter experts, review comments, and approval checks before merge.

Start with the diff, not the intention. Read the PR or MR description, the related issue, and the changed files in the exact order a reviewer would see them, because context changes how the code should be judged. Google’s review guide treats code review as a quality process, and GitLab’s guide explicitly says to keep merge requests small so they are easier to understand and review.

The human reviewer should check for correctness, security, and maintainability, not just whether the code passes. GitLab’s review guidance calls out effective, understandable, maintainable, and secure code as review goals, and it also recommends clear descriptions, screenshots where useful, validation steps, and an acceptance checklist. Those details matter more when an agent wrote the code, because agent output often looks finished before anyone has verified the behavior.

Use a review checklist that forces a person to answer specific questions. Ask whether the change is the smallest version that solves the problem, whether tests fail before the fix and pass after it, whether the new code matches existing patterns, whether any secrets, permissions, or data paths changed, and whether the docs or config need updates. GitLab’s review guide explicitly recommends small merge requests, and GitHub’s review flow gives reviewers a place to leave precise line comments and suggested edits.

The part people get wrong is treating a green test run as a human review. A passing CI job proves the code executed the checks you wrote, not that the logic is right, the permissions are safe, or the edge cases are covered. A human has to look at the changed lines and ask whether the agent solved the real problem or merely satisfied the tests. That is where most bad agent code gets caught, and it is also where the review is cheapest.

Make the reviewer work from evidence, not trust. If the agent added a function, the human should read the function body, open the tests, and confirm the assertions describe the intended behavior. If the agent touched auth, payments, file I/O, or destructive operations, the reviewer should run the path in a local or staging environment and inspect logs or screenshots. GitLab’s documentation specifically recommends validation steps, and GitHub’s review UI supports pending comments and exact line suggestions.

A good human-in-the-loop workflow also defines when the agent must stop. OpenAI’s human-in-the-loop guidance shows the same principle at the tool level: some actions require approval before the run continues, and the system can pause for manual review or use programmatic approval callbacks. In code terms, that means the agent can draft, edit, and propose, but a person must approve the branch before merge or commit to the protected line.

Use branch protection, required reviews, and a hard separation between draft and approved work. The reviewer should be able to see what the agent changed, what the human changed afterward, and which commit was actually approved. If the change is still moving, keep it as a draft PR or MR. If the reviewer requests changes, the agent can revise the branch, but the review resets on the updated diff so the human signs off on the final state, not the earlier draft.

The inconvenient part is that a real review takes time even when the code looks obviously right. That is not wasted time, because agent-generated code can be fluent while still being wrong in one edge case, one permission boundary, or one dependency assumption. The review cost is the price of not turning the agent into an unobserved committer. GitLab’s guidance on small merge requests is useful here, because smaller diffs reduce the amount a human has to hold in working memory.

A practical flow looks like this: the agent opens a branch, writes or updates tests, and leaves a short summary of what changed. The human then reviews the summary, reads the diff, runs the tests locally or in CI, checks the highest-risk lines by hand, and leaves either approval or requested changes in the PR or MR. GitHub supports inline comments and suggested edits, while GitLab supports reviewers, approval checks, and request-changes states.

If the agent is allowed to generate code repeatedly, the reviewer should still stay in charge of merge criteria. The person reviewing should decide when the change is small enough, when the tests are convincing enough, and when a security review is needed. GitLab’s review guidelines explicitly mention security review triggers, and that matters for agent-written code because generated changes can spread across more files than a human would normally touch in one pass.

A concrete example helps. Suppose an agent adds a password reset endpoint. The human reviewer should confirm the route is authenticated correctly, the token expires as expected, the email template does not leak data, the tests cover invalid and expired tokens, and the logs do not expose secrets. If any of those pieces are missing, the reviewer requests changes, the agent revises the branch, and the human rechecks the final diff before merge.

The goal is not to distrust the agent. The goal is to make the person accountable for the last mile, because that is where release risk lives. Use the agent for drafting and repetition, use the human for judgment and approval, and keep the merge gate explicit so nobody confuses generated output with reviewed code. That workflow is consistent with Google’s definition of code review and with GitHub and GitLab’s review tooling.

If you want a platform for coordinating this kind of review work with other builders, DevConnect is one place to organize tester exchange and workflow around shipped code: https://devconnectplatform.com. The review rule stays the same there and everywhere else, a person must inspect the agent output before it reaches the protected branch.

FAQ

How is this different from just asking the agent to explain its code? Explanation is useful, but it is not a review. A human still needs to inspect the diff, the tests, and the risky paths before approval.

Should the agent also write the tests? Yes, if the tests are reviewed by a person before merge. The reviewer should confirm the tests fail for the old behavior and pass for the new one.

What should the reviewer do when the change is too large? Split it. GitLab’s review guidance prefers smaller merge requests because they are easier to review and create fewer blocking discussions.

Can I approve code if I did not run it locally? Yes, if CI and the diff are enough for the risk level. For auth, payments, destructive actions, or data migrations, a local or staging run is safer.

What if the agent keeps making the same mistake? Keep the mistake visible in the review comments, narrow the task, and make the human approval gate stricter. Repeated errors usually mean the prompt or task boundary is too loose, not that review failed.

Who owns the final code? The human who approved it. The agent drafts the change, but the reviewer decides whether it is ready to merge.