From copilot to coworker: how AI agents change pull requests

AI coding tools are moving from inline suggestions to agents that open pull requests on their own. That shift changes what a pull request is. It stops being a record of human work and becomes a boundary where a human, an agent and the delivery system meet, and where responsibility for the change has to land somewhere.

The pull request becomes the work contract

When an agent opens a pull request, the description carries more weight than usual. It should state the task, the acceptance criteria, the files changed, the validation performed and any known limitations. A reviewer should not have to reverse engineer the goal from the diff, because the agent cannot be questioned the way a colleague can.

The pull request is also where accountability returns to the team. An agent can propose work. A human and the organisation decide whether that work is acceptable, and they own the result once it merges. Nothing about generated code changes that, so the pull request has to make the ownership explicit rather than implied.

Evidence matters more than summaries

A generated change can read as coherent while missing context the model never had. The pull request should carry evidence that is hard to fabricate: test results, build logs, dependency review and links to the issues the change is meant to address. That evidence is what a reviewer signs off against.

A summary is a navigation aid, not proof. It can point a reviewer at the parts of the diff worth reading closely, but it cannot stand in for reading the risky parts. The more fluent the summary, the more important this distinction becomes.

CI becomes the second reviewer

As agent output grows, continuous integration has to become more targeted and more trustworthy, because it is the check that scales when human attention does not. Syntax and lint checks are the floor. The pipeline should validate the things that actually break in production, such as contracts, migrations, dependencies and security policy, scaled to the risk of the change.

This is not an argument for endless gates. It is an argument that an agent should not be able to create the impression of progress while bypassing the checks that matter. If a check can be skipped quietly, it is not really protecting anything.

Permissions should match the task

An agent that edits code does not need access to secrets, production environments or privileged workflows by default. Least privilege, short lived access and human approval for sensitive actions keep the blast radius small if the agent behaves unexpectedly. Tokens scoped to the job and valid for minutes are safer than long lived credentials sitting in the environment.

Treat repository comments, issue bodies and pull request descriptions as untrusted input whenever they steer agent behaviour. Text from these sources can carry instructions the agent was never meant to follow, so an agent workflow should never turn arbitrary text into privileged execution.

Review culture will change

Reviewing agent output is a different skill from reviewing a colleague. The useful questions become: what did the agent optimise for, what did it leave out, and what could fail once this is running? You cannot ask the author to explain a trade off from memory, so the review has to extract that understanding from the change and its evidence.

Teams will also need vocabulary for generated work. Labels and policies such as agent authored, human edited, requires security review, requires migration review or safe to merge after checks let a team route a change to the right level of scrutiny instead of treating every pull request the same.

Conclusion

AI agents do not make pull requests obsolete. They make them more important. The pull request becomes the place where generated work is made legible, validated and owned, and where a proposal turns into something a team is willing to stand behind. The teams that adapt will treat agent output as a proposal backed by evidence, not as finished work waiting for a rubber stamp.