A pull request lands in review.
The diff looks reasonable. The description is confident. The implementation seems to follow the ticket. Maybe the tests are green. Maybe the author says, "Claude wrote most of this," or "Copilot handled the first pass."
Now comes the uncomfortable question.
What exactly was checked before this reached review?
Not what changed. The diff shows that. Not who clicked merge. GitHub shows that.
The real question is: what evidence exists that the agent understood the task, touched the right files, ran the right checks, and noticed the risks before a human reviewer inherited the work?
For many teams, the answer is thin. And that is the new engineering risk: agent-written code with no evidence trail.
AI Code Is Not The Problem
The easy argument is that AI-generated code is risky because AI makes mistakes. That is true, but incomplete.
Humans make mistakes too. Engineering systems were built around that reality. We have branches, pull requests, CI, tests, code owners, approvals, release gates, and incident reviews.
The issue is not that AI produces imperfect code. The issue is that AI can produce code faster than the surrounding evidence system can explain it.
GitHub's documentation for Copilot coding agent describes workflows where an agent can research a repository, create a plan, make code changes on a branch, and move toward a pull request. That is powerful. It also changes the shape of engineering work.
A human developer usually carries context in messy but useful ways. They remember the tradeoff they made. They know which test failed first. They know why they avoided one file and changed another.
An agent may have gone through similar steps. But unless those steps are captured, the reviewer only gets the final artifact.
The Pull Request Was Not Designed For This Volume
The pull request became the default unit of engineering accountability because it is simple: show the diff, discuss the change, run the checks, approve or reject.
That worked well when the bottleneck was mostly writing code.
But AI coding agents shift the bottleneck. The expensive part becomes understanding whether the generated code deserves trust.
A 2026 longitudinal study on arXiv, based on one enterprise setting, found that AI adoption was associated with a major increase in pull request throughput and a meaningful increase in review load. Treat that as one data point rather than universal truth, but the pattern is familiar: code creation is getting cheaper, while review attention is not.
Teams celebrate more PRs. Managers see more activity. Developers feel faster. But reviewers become the compression layer for everything the agent did not document.
The Evidence Trail Is The Missing Layer
An evidence trail is not a longer PR description. It is not "I ran tests" written in a comment. It is a structured record of what happened before review.
- What prompt or task did the agent receive?
- What files did it inspect before editing?
- What files did it change?
- What commands did it run?
- Which tests passed?
- Which tests failed first?
- What assumptions did it make?
- What risks did it flag?
This does not need to be heavy enterprise governance. If it feels like paperwork, developers will avoid it. The best version is automatic, local, and close to the developer workflow.
"CI Passed" Is Not The Whole Story
CI is necessary. It is not sufficient.
A green build tells you the configured checks passed. It does not tell you whether the agent chose the right approach, skipped a relevant test, or changed three files after reading only one.
This matters even more for software service companies and consultancies. When a client asks, "How do you verify AI-generated code before delivery?" a confident answer cannot be: "Our developers review it."
That may be true. It is not differentiated. It is not very reassuring. As AI usage becomes normal, clients will expect more than good intentions. They will expect evidence.
The Accountability Gap
AI can generate code, but it cannot absorb accountability.
If agent-written code causes a production issue, the incident review will not end with, "The model did it."
The team owns the outcome. The VP Engineering owns the system. The CTO owns the risk posture. The consultancy owns the client impact.
A diff shows what changed. An evidence trail shows why the team should trust it.
What Leaders Should Ask This Week
- When an agent writes code, where is the work validated before PR review?
- Can reviewers see what checks were actually run?
- Can tech leads distinguish human-written and agent-heavy changes?
- Do we know which types of tasks agents are safe to handle?
- Could we explain our AI code quality process to a client or auditor?
If those answers are vague, the issue is not that your team is careless. It means your workflow was built for a previous era.