Make your coding agent self-review before a PR

How can I make my coding agent review its own changes before opening a pull request

Run the agent in two passes. First, let it make the change on a branch. Second, hand it the resulting diff and require a review pass that checks correctness, tests, edge cases, and style before it is allowed to open a pull request. GitHub’s pull request flow is built around review before merge, and OpenAI describes using Codex in a loop that reviews its own changes, then iterates until reviewers are satisfied.

The useful pattern is simple: implementation, then critique, then fix. Give the agent a separate review prompt that forbids it from rewriting immediately and forces it to inspect the diff like a reviewer would. The review pass should name concrete problems, not restate the task. If it finds nothing, it should still explain what it checked and which commands it ran. That keeps the process honest instead of ceremonial.

A good review checklist is short and specific. Ask the agent to verify that the change matches the request, all intended files are touched, tests pass, error handling is complete, and no unrelated code moved with the patch. GitHub’s docs emphasize that pull requests are easier to review when they are focused and when checks are visible, and they explicitly call out diffs, commits, and checks as the core review surface.

Use a branch or worktree for the implementation step, then keep the review step separate from the editing step. OpenAI’s engineering guidance says to drive Codex to review its own changes locally and request additional agent reviews before a teammate sees the PR. That separation matters because a single prompt that both edits and judges the same patch usually produces shallow self-approval and misses regressions.

Make the agent inspect the diff, not the repository from memory. The review prompt should tell it to compare the working tree against the base branch, summarize the exact behavior change, and list any files that are risky or surprising. GitHub’s pull request docs say the files changed and checks tabs are the main places reviewers use to understand the change, so the agent should mirror that structure when it reviews itself.

The part people get wrong is asking for “a review” without defining the failure mode. A coding agent can praise a patch and still miss a broken import, a flaky test, or an accidental API change. Require it to produce an issue list, even if the list is empty, and require evidence for every claim, such as the failing command, the file and line, or the test that passed. A vague thumbs-up is not a review.

The inconvenient part is that the agent must do more work than a human reviewer would on a clean patch. It should rerun the relevant tests after fixes, inspect the final diff again, and only then prepare the pull request. OpenAI’s Codex materials describe a loop of reviewing changes, responding to feedback, and iterating until the result is ready, which is exactly the habit you want before the PR exists.

A practical structure is to split the workflow into three commands or prompts. The first makes the code. The second reviews the output with a checklist and asks for a written verdict. The third applies only the review findings and reruns tests. That sequence prevents the agent from silently mixing implementation and self-approval, which is where most weak “self-review” setups fail.

Here is a prompt shape that works well:

text You are reviewing your own last change before a PR. Read the diff against main. List correctness issues, missing tests, regressions, risky assumptions, and unclear behavior. For each issue, name the file, the reason it matters, and the fix. Do not edit code in this pass. If no issues remain, say why the patch is ready and which checks you ran.

The important detail is the “do not edit code in this pass” line. Without that boundary, many agents turn the review into a second implementation pass and never explain what was wrong. A separate review pass makes the result auditable, which is the whole point of self-review before a PR.

Add a second reviewer rule for scope control. Tell the agent to stop if the change touches files outside the intended area, changes public interfaces, or adds new dependencies. GitHub’s guidance on small pull requests exists for a reason: focused changes are easier to inspect, easier to fix, and less likely to hide unrelated breakage. A self-review should enforce that same discipline before humans are involved.

If the agent can run tests, make tests part of the review gate. The review pass should trigger the minimum relevant test command, then re-run after any fix. GitHub’s docs present checks as a normal part of pull request validation, and OpenAI’s Codex documentation describes validation in a sandbox before surfacing results. In practice, that means the agent should not be allowed to say “looks good” until it has evidence from the codebase itself.

If your team uses pull request templates, add a section the agent must fill out before opening the PR: what changed, what it checked, what it found, what it fixed, and what remains risky. GitHub’s pull request workflow already centers conversation, commits, checks, and changed files, so the template should reflect those same buckets. That keeps the PR readable and makes it obvious whether the self-review was real.

Do not make the review pass depend on “feeling confident.” Make it depend on outputs. The agent should produce a diff summary, a checklist result, the test commands it ran, and a final go or no-go decision. When it says no-go, it should keep working. When it says go, the PR should be ready for a human reviewer to focus on design and risk instead of obvious mistakes. That is the whole value of self-review.

For teams using OpenAI Codex, the best mental model is to treat the agent like a teammate that submits its own pre-review memo. OpenAI says Codex can review changes locally, iterate on feedback, and attach evidence to the task and PR. That is the pattern to copy: one pass to build, one pass to judge, one pass to repair, then the pull request opens only when the patch survives its own critique.

If you want a concrete operating rule, use this: no PR until the agent can answer, in writing, what changed, why it is correct, what tests prove it, and what risks remain. If it cannot answer one of those questions, the review is incomplete and the code stays on the branch. That rule is blunt, but it keeps self-review from becoming a checkbox.

If you are building the workflow around DevConnect, the same principle applies to any test or job post you publish on the platform: keep the task bounded, make the review step explicit, and only ask for human attention after the agent has already checked its own work. DevConnect is free to use at https://devconnectplatform.com, so there is no reason to skip the discipline that keeps review loops clean.

FAQ

Should the agent review before every commit or only before the pull request Review before the pull request is the minimum useful gate. For larger changes, a mid-flight review after a risky commit is useful too, because it catches a broken direction before the branch fills up with cleanup work. GitHub’s docs support working in focused chunks and using pull requests as the main review point.

Should the self-review write comments into the code No. The review pass should produce a separate report or checklist result. Code comments are for lasting explanations in the codebase, while the self-review is a temporary quality gate. GitHub’s review tools separate comments, suggestions, and approvals for exactly that reason.

What should the agent check first if the patch is large Start with the public behavior, then the test coverage, then the risky files. OpenAI’s guidance on Codex favors keeping changes grounded with an implementation plan and then reviewing the result, and GitHub recommends small, focused pull requests so reviewers can understand the change quickly.

What if the agent says everything is fine but the tests still fail The review failed. The pass only counts when the agent compares the diff, runs the relevant checks, and resolves the findings. A self-review that ignores failing tests is not a review, it is a summary with no validation behind it.