Agent coding tools can open pull requests now.
That is not the hard part.
The hard part is deciding whether to merge them.
A human PR comes with context. You know the author. You know their taste, their blind spots, and their history with the codebase. If something looks odd, you ask them. They explain the tradeoff or change the code.
An agent PR just comes with a diff.
Sometimes it also comes with a prompt, a transcript, a session log, or a summary. Those help. But they are not enough.
A transcript tells you what the agent said.
A trace tells you what the agent did.
An evidence bundle tells you why the change is safe to accept.
That is the bar agent coding tools still need to clear.
History is not evidence
Session history is useful. It shows commands, files, tests, retries, and false starts.
But a long session log can make review worse. Now the reviewer has to review both the diff and the story behind the diff.
That is another review queue.
The goal is not to make reviewers read more agent history. The goal is to make the merge decision easier.
For that, every agent-generated PR should answer six questions:
- What was the agent asked to do?
- What context did it use?
- What actions did it take?
- What was it allowed to do?
- What checked the work?
- Who accepted the risk?
That is the PR evidence bundle.
1. Intent
The first artifact should be the task boundary.
Not the whole chat. Not every correction. Just the reviewable intent.
Task: Add SAML group mapping support to the import flow.
Scope: Backend parser, importer tests, docs update.
Out of scope: UI changes, auth model changes, migration changes.
This catches a common agent failure: solving a nearby problem.
The code may compile. The tests may pass. The implementation may look plausible. But if the agent drifted from the task, the PR is wrong.
Intent gives the reviewer something to compare the diff against.
2. Context
The second artifact should be a context receipt.
Prompt logs are too noisy. They expose too much and explain too little.
A context receipt should list the facts the change depends on:
- Files read.
- Docs consulted.
- APIs referenced.
- Tests used as examples.
- Assumptions made.
- Facts the agent could not verify.
- Stale or skipped context.
Many agent bugs are context bugs. The model read an old doc. It copied a pattern from the wrong package. It missed a permission check. It inferred a schema field that did not exist.
Review the context before you review the diff.
If the context is wrong, the code is suspect before you read line one.
3. Trace
The third artifact should be an action trace.
This is the factual record:
- Commands run.
- Files changed.
- Tools called.
- Tests run.
- External services touched.
- Errors hit.
- Retries made.
The trace should be compact. A reviewer should not need to scroll through a raw terminal transcript to find the three actions that matter.
But trace has a hard limit.
It tells you what happened. It does not tell you whether the action should have been allowed.
That needs authorization evidence.
4. Authorization
The fourth artifact should show what authority the agent had.
This is where most agent coding workflows are still vague.
An agent can read files, run shell commands, call tools, push commits, open PRs, query services, and sometimes touch infrastructure. Each of those actions has a blast radius.
The PR should show:
- Which user or system delegated the task.
- Which tools were in scope.
- Which files or services were reachable.
- Which commands were denied.
- Which actions required approval.
- Which policy allowed the action.
A trace says:
The agent ran the database migration generator.
Authorization evidence says:
Allowed: generate migration file
Denied: apply migration
Policy: db_changes.require_human_apply
That difference matters.
If policy runs after the shell command, it is not authorization. It is forensics.
5. Verification
The fifth artifact should show what checked the work.
Not one green checkmark. The actual checks.
- Unit tests.
- Integration tests.
- Type checks.
- Linters.
- Static analysis.
- Security scans.
- Contract tests.
- Independent model review.
- Human review notes.
The word "independent" does work here.
The same model that wrote the implementation should not be the only system that reviews it. It brings the same assumptions into the test.
If an agent writes the bug and the test, the test may only document the bug.
A stronger workflow separates roles:
- One system creates the change.
- Another checks it.
- Policy gates risky actions.
- A human approves high-risk work.
That is not process theater. It is separation of duties.
6. Accountability
The sixth artifact should show who accepted the change.
The agent does not own production. The team does.
So the PR should record:
- Who requested the work.
- Which agent or model produced it.
- Which checks reviewed it.
- Which policy gates passed.
- Which human approved it.
- Which deployment shipped it.
When something breaks, the team should not have to reconstruct the story from chat logs and CI output.
The PR should already know.
The PR is the control point
A PR sits at the boundary between proposed work and accepted work.
Before merge, the change is still a proposal. After merge, it enters the mainline. It may trigger deploys, migrations, generated clients, customer-visible behavior, and on-call risk.
That makes the PR the right place to attach evidence.
Not every change needs the same bundle.
A small docs fix may need only intent and context.
A low-risk code change may need intent, context, trace, and tests.
A database, auth, billing, or infrastructure change should bring authorization evidence, independent checks, and explicit human approval.
The bundle should scale with blast radius.
Low risk should move fast.
High risk should bring proof.
What leaders should ask
If your team is adopting agent coding tools, do not stop at:
Can it open a PR?
Ask:
- Can I see the task boundary?
- Can I see the context used to produce the diff?
- Can I inspect tool calls without reading a full transcript?
- Can I see what the agent was allowed to do?
- Can I require approval for high-risk actions?
- Can I separate generation from review?
- Can I export the evidence into Git, CI, logs, or audit systems?
- Can I query it later during an incident?
These are not compliance-only questions.
They are review questions.
The metric is reviewable work
The weak metric is:
How much code did the agent write?
The better metric is:
How much reviewable work did it produce?
A tool that writes ten thousand lines with no evidence has created work for humans.
A tool that writes five hundred lines with intent, context, checks, policy decisions, and approval state has saved review time.
Engineering teams do not need more output.
They need work they can trust faster.
The future PR
The future pull request is not just a patch.
It is a packet of evidence:
- The diff.
- The task.
- The context.
- The actions.
- The permissions.
- The checks.
- The approval.
Agents already produce much of this raw material. They read files, call tools, run commands, hit errors, retry, test, summarize, and open PRs.
The missing step is turning that activity into evidence a reviewer can use.
That is where agent coding tools will compete.
Not only on how fast they write.
On how well they prove.
I'm a software engineer focused on agent infrastructure. I spent four years at Ona, formerly Gitpod, building platform infrastructure used by 2M+ developers. Outside of that, I maintain OpenFGA and GitHub1s, and I've built agent-trace, agentic-authz, Distill, and The Agentic Engineering Guide. This post draws on that work. If your team is adopting coding agents and the review queue is becoming the bottleneck, I can help you design the evidence layer around it. Reach me at hi@siddhantkhare.com or schedule a call.