A pull request workflow for code written by agents

When an agent can prepare several changes while you’re doing something else, review can become the slowest part of development.

Opening more pull requests doesn’t solve that by itself. You need a way to decide which changes need your attention, what automated checks prove, and which revision is ready to ship.

The Claude Code team published how it reviews code at Anthropic. Its process combines agent review with tests and human approvals based on risk. It also tests changes through a merge queue.

You can use those ideas in a smaller project without copying an entire company’s process. Here are two concrete workflows I would consider for a GitHub repository.

Start with a change you can review

Suppose the task is “fix password reset.” That leaves too much for the agent to decide. Should tokens expire sooner? Should an old link stop working after a new one is requested? Should existing sessions survive a password change?

Write down the behavior you want before asking for code. For this example, let’s choose a narrow fix: reject expired tokens and prevent a token from being used twice. Keep the email design and session policy as they are.

The pull request should carry that intent into review. Otherwise, a reviewer may approve a tidy implementation of the wrong behavior.

I would ask the author to include:

• What was broken, with a way to reproduce it.
• What happens after the change.
• Which checks ran and what they covered.
• Anything still unverified, plus how to undo the change.

Keep unrelated cleanup in a separate change. Renaming the authentication module while fixing token expiration makes it harder to see whether the fix works.

If you need a refresher on branches and merging, the free Git course walks through those basics.

Workflow 1: agents prepare pull requests

Ask the agent to prepare the reset-token fix as a small patch. Before review, it needs a way to check the behavior we chose.

Test that an expired token fails and a valid token changes the password. Then try that valid token again: it must fail. Add a concurrency check that sends two reset attempts with the same token and verifies that only one succeeds. A meaningful browser check also confirms that the error message leaves the user somewhere sensible. “All tests passed” tells me less if the tests only cover an unrelated utility.

A regression test is especially useful here. If it passes before the fix, check whether it exercises the bug at all. A test that only checks whether the endpoint returns an error could pass for the wrong reason, such as a missing database connection.

Then ask a fresh reviewer to inspect the change and the surrounding implementation. Give it the task description and ask for concrete bugs, with a file and line for each finding.

For a reset flow, I want it to follow the token through creation, storage, expiration, and consumption. A reviewer limited to the changed lines can miss an assumption in the caller.

Give the reviewer something specific to investigate

A fresh review starts without the author’s conversation and its assumptions. It still needs the task, project rules, and access to the surrounding code. A second agent can make the same mistake as the first, so its agreement is useful only alongside evidence.

For the reset-token example, I would give it this prompt:

Review this pull request against the stated requirement: expired reset tokens must fail, and a successful reset must consume the token. Read the callers and storage code too. Look for concrete failures, including two requests using the same token at once. For each finding, give the file and line, the conditions that trigger it, and the resulting behavior. Separate bugs introduced here from existing problems. Say when you found no actionable issues.

That concurrency case matters. Code can check that a token is unused, change the password, and mark the token as used afterward. Two requests may both pass the first check. The reviewer should inspect whether the storage operation prevents that race.

A useful finding explains that sequence. “This may have a race condition” leaves the author guessing.

Resolve findings before asking for a merge decision. A false positive needs a reason someone can examine later. An agent’s approval is useful evidence, but it shouldn’t fill a slot intended for a human.

Keep review from becoming an endless rewrite

When a finding is real, fix the cause and add a check that covers it. Then review the fix and any behavior it affects. When a finding is wrong, record why: perhaps the database operation already consumes the token atomically.

Avoid letting an author and reviewer keep rewriting each other’s work without a stopping rule. I would pause after a few unsuccessful rounds and inspect the approach myself. Repeated findings can mean the requirement is unclear or the patch is trying to do too much.

The Anthropic article describes this problem too. Its team capped review rounds and changed later passes to focus on the newer changes. A clean review should let the change move forward; it doesn’t need to manufacture another suggestion.

Give sensitive changes a human owner

For a small repository, I would begin with human review for changes that affect user data, authentication, payments, or deployment permissions. A copy correction can have a lighter path.

The Anthropic article describes risk tiers and protected paths. It also treats approvals as applying to a particular commit, so later changes can require a new approval. That is a useful property to preserve in your own rules.

Check the actual enforcement in GitHub. Branch protection can require reviews and status checks, and can dismiss stale approvals when commits change. Consider bypass permissions too.

For this example, I would require the reset-flow checks and a human approval. Enable stale-review dismissal if approvals should be renewed after code changes. If the repository uses code owners, require their review for the sensitive paths. GitHub also offers a setting requiring approval of the most recent reviewable push by someone other than its pusher.

These settings do different jobs. Requiring a passing check says CI ran successfully. Requiring approval says someone accepted the change. Neither proves the acceptance test covers the right behavior.

A label saying “low risk” is only a label unless something uses it to enforce a rule. A classifier can help route work, but a change to the classifier or CI workflow deserves review as well.

Test the integrated revision

Two branches can pass independently and fail together. One changes a function’s return shape while the other adds a caller using the previous shape.

GitHub’s merge queue builds a temporary group with the target branch and queued changes, then checks that combination.

If you’re new to CI, the GitHub Actions guide explains how workflows and required checks fit together.

If you use GitHub Actions, your required workflows need to handle the merge_group event. A check that only responds to pull requests can leave the queue waiting for a result that never arrives. GitHub documents that trigger in its workflow events reference.

For an existing workflow, its trigger section can include both events:

on:
  pull_request:
  merge_group:
    types: [checks_requested]

This is the trigger section, not a complete workflow. Keep the jobs that build and test your application, and confirm they report the checks required by branch protection. Adding an event without running the required jobs won’t unblock the queue.

Queue availability depends on the repository and plan. If you don’t have it, serialize integration: update the branch against current main, test that revision, and merge without allowing another change to slip in between. Required checks should cover the revision you’re integrating.

Workflow 2: one owner integrates directly

For a personal project with one active change at a time, a pull request can add little. The owner can inspect the local diff, use the changed flow, run focused checks, and commit directly to main.

The conditions matter. Don’t have multiple unattended agents pushing different assumptions into the branch. Keep the final push under the owner’s control and run CI on the pushed commit. Deploy that successful revision, rather than whichever commit happens to be newest when a separate deployment job starts.

This is a compact workflow for a particular project. A shared service with several contributors may benefit much more from the queue and explicit approvals above.

Which workflow would I choose?

I would keep a personal project with one active change on the direct integration path until there is a concrete reason to add pull requests. For work handed off between people, or several agents preparing changes independently, I would use PRs so each change has its own review record.

The size of the diff helps determine how long review takes. The behavior determines how careful it needs to be. A one-line permission change can deserve more attention than a large documentation update.

Make the merge evidence easy to find

Whichever route you choose, attach the checks to the reviewed revision. Keep the original task beside them. If a browser check needs test data, describe the relevant scenario. Keep findings attached to the change so a future maintainer can understand the decision.

Also decide how a failure will be detected after deployment. A revert can restore code, but it won’t recall a password-reset email or reverse a data migration.

For the reset-token fix, I would check a fresh link after deployment, confirm an expired link fails, and verify that reusing a consumed link fails too. Use a test account. Watch the relevant errors so a broken reset flow doesn’t wait for a customer report.

Keep repeatable instructions in AGENTS.md, including which checks to run and which changes need a person. Enforce merge requirements in the repository settings. An instruction file helps an agent follow the process; branch protection controls whether the change can land.

Want me to talk about your product? You can sponsor this site.