Pull requests with agents

So far the agent ran on your machine and you looked at the difference in the terminal. On GitHub the workflow moves to where teams review anyway: the pull request.

The workflow

1. You write an issue – in the format from the previous station.
2. You assign it to an agent.
3. The agent works in its own environment on a separate branch.
4. It opens a pull request and asks you for a review.
5. You comment, it revises.
6. You approve and merge.

What GitHub offers today

Copilot takes issues directly: assignment always opens a pull request, and the agent requests your review once the work is done. Important in practice: it knows the issue as it stood at assignment. What you add to the issue later it does not see – addenda belong on the pull request. Kick off a task with Copilot

Agents from other providers can be started on GitHub as well. The documentation names Anthropic Claude and OpenAI Codex, both as a public preview for paid Copilot plans. They first have to be enabled in the account or organisation settings and can then be kicked off in three ways: in the repository’s “Agents” tab, by assigning an issue, or by a mention in a pull request comment. Third-party coding agents

Two things from the same documentation belong in your planning: the generated code is automatically checked for security problems before the pull request is finalised – code scanning, secret scanning, a check of new dependencies. And every session uses GitHub Actions minutes and AI credits; whatever exceeds the included volume costs extra.

The real safeguard: the protected main branch

The automatic check does not replace yours. What really prevents unreviewed code from going live is protection of the main branch. In the repository settings you define:

• Pull request required. Nobody writes directly to main.
• Checks must pass. Build and tests as a required check.
• No force-push, no deletion.

With that an agent can propose as much as it likes but push nothing through. Check the setting once from the outside: try to push directly to main. If the attempt is rejected, the protection holds.

Review in three passes

1. The description. Does it match the issue? Does it say what was done and what was deliberately not done? A pull request that claims more than the issue asked for deserves suspicion.

2. The diff. Every changed file, not only the expected ones. Watch for four things:

• Changed or deleted tests. Was a test adjusted so that it passes?
• New dependencies. Every additional package is someone else’s code in your project.
• Changes outside the brief. Reformatted files, functions tidied up “on the side”.
• Configuration and permissions. Anything concerning access, secrets or the deploy.

3. The checks. Green means: the existing tests pass. It does not mean the change is right. If there is no test for the new behaviour, the green tick is worthless.

Follow-up by comment

Write change requests as a comment on the pull request, as concrete as a brief: file, desired behaviour, acceptance. The agent revises on the same branch.

After the second round without progress the same rule applies as locally: close the pull request, sharpen the issue, reassign.

What you never do

Approve a pull request you have not read. The approval is your signature – after it, it is your code, whoever wrote it.