> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Why AI-Generated Pull Requests Are Harder to Review
> Why AI-generated pull requests are harder for teams to review, even with Codex, Cursor, and GitHub. Learn what shared context and evidence are still missing.
AI-generated pull requests are harder for teams to review when the code arrives without a shared record of the work behind it. The pull request may contain a plausible patch and summary while the authorizing request, agent and model identity, execution state, skipped validation, and supporting evidence remain scattered across private chats, agent sessions, CI runs, and vendor-specific interfaces.
*Last reviewed July 18, 2026. Maintained by the Plannotator project.*
Codex, Cursor, and GitHub Copilot are making individual review more interactive. A developer can inspect a diff beside an agent, ask why a file changed, request another review, and ask the agent to implement a finding. Those workflows make a pull request easier to explore. A team shipping a real product still needs a durable account of what the agent was asked to do, what it completed, how it checked the result, and which exact revision people are approving.
## Agent-native review is already useful
[Codex code review](https://openai.com/index/introducing-upgrades-to-codex/) can automatically review a GitHub pull request when it moves from draft to ready, post findings on the pull request, and respond to a focused request such as `@codex review for security vulnerabilities`. If Codex recommends an edit, the author can ask it to implement the change in the same thread. The Codex IDE extension also lets developers track and review cloud tasks without leaving the editor.
Cursor provides several review paths. Its [agent review workflow](https://cursor.com/blog/agent-best-practices) can analyze proposed edits line by line, compare local changes with the main branch, and flag issues before the work reaches GitHub. Inside a pull request, [tagging `@Cursor`](https://cursor.com/changelog/1-4) can send an instruction to a background agent that applies the fix and pushes another commit.
GitHub Copilot adds another version of this experience. Its agent sessions expose progress and logs, and Copilot-authored commits link back to those sessions. A reviewer can ask what changed, what was validated, and why. GitHub documents these capabilities in [Managing agent sessions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/manage-and-track-agents).
These tools reduce the cost of orienting yourself inside a pull request. They can explain unfamiliar code, surface likely defects, and shorten the loop between a finding and its fix. An industrial study of LLM-assisted code review found that developers generally preferred AI-led assistance for large or unfamiliar pull requests, while preferences varied with codebase familiarity and risk. The researchers favored hybrid workflows that combine proactive findings with on-demand questions and reviewer control. See [Rethinking Code Review Workflows with LLM Assistance](https://research.chalmers.se/en/publication/551186).
## A personal review conversation is not a team record
An agent chat can help one developer form a mental model. It does not automatically tell every reviewer:
* which person authorized the change;
* which agent, model, and execution system contributed to the current code;
* whether the agent is still working, blocked, waiting for a decision, or finished;
* which tests and investigations ran against the current commit;
* what the agent skipped, could not reproduce, or remains uncertain about;
* whether a screenshot, recording, or report still matches the current head;
* which parts product, security, platform, or operations have reviewed;
* what changed after each person's last completed review.
Those facts may exist somewhere. The problem is that each reviewer may have to reconstruct them from a different agent interface, pull request comment, CI page, or private conversation.
A 2026 study of 33,596 agent-created pull requests found that coding agents produced measurably different pull-request description styles and received different patterns of reviewer engagement and outcomes. The authors caution that repository norms, task type, and code complexity may explain part of the variation, so the results are not causal. The useful finding for teams is narrower: how an agent communicates its work affects the review process. See [How AI Coding Agents Communicate](https://arxiv.org/abs/2602.17084).
## Three review questions need better answers
### Which agent and model produced this change?
Git authorship can identify a bot account or the human who initiated a task. It often does not describe the full production path. One pull request may contain human edits, a Cursor background-agent commit, a Codex correction, and a generated test from another session. An agent may also switch models or delegate part of the work.
Record the agent product, execution environment, model or model family when available, initiating person, session link, and commits produced. Model identity supports audit, policy, and debugging. It does not establish quality. A newer or more expensive model can still misunderstand the request, miss a failure path, or validate the wrong behavior.
Some products already expose parts of this information. Cursor advertises an enterprise [AI code tracking API](https://cursor.com/changelog/1-4) for commit-level visibility into AI usage and accepted changes. GitHub Copilot records agent sessions and links its commits to session logs. These are useful product-specific records, but they do not create one portable metadata contract across every agent that can contribute to a GitHub pull request.
### Is the pull request actually ready for review?
GitHub supports **Draft** and **Ready for review** states. A draft pull request cannot merge and does not automatically request review from code owners. Marking it ready requests formal review. See [About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests).
That state describes the pull request, not every agent task behind it.
| State | What it establishes | What it does not establish |
| ---------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Draft | The author is not formally requesting merge review | Whether an agent is running, blocked, complete, or waiting for a decision |
| Ready for review | The author is requesting review of the current pull request | Whether the agent met the definition of done, ran consequential checks, or disclosed open questions |
| Mergeable | Required repository checks and approvals currently allow merge | Whether the change implements the right product decision or has enough evidence for its operational risk |
A useful agent record should state **working**, **blocked**, **awaiting decision**, or **complete**, along with the definition of done and remaining work. The person presenting the pull request for review owns that status. The agent should not certify its own patch as safe to ship.
### Did the agent perform due diligence?
“Tests pass” is too vague for a consequential change. Reviewers need to know what ran, what passed, what failed, what was skipped, and which commit the results cover.
For example:
```text theme={null}
Revision: c4a912e
Validated:
- pnpm test --filter authorization: 42 passed
- pnpm typecheck: passed
- session revocation browser flow: passed, recording attached
- migration rehearsal: not run, staging database unavailable
Open question:
- queue saturation behavior remains unverified
```
The record should include repository checks, browser or device paths, migration rehearsals, security review, performance tests, and supporting [code review artifacts](/learn/code-review/what-are-code-review-artifacts) only when they apply. It should also name missing evidence. A failed or unavailable check helps a reviewer make a decision; hiding it behind a polished summary does not.
For hosted GitHub pull requests and GitLab merge requests, Plannotator's [Artifact Gallery](/learn/code-review/review-pull-request-artifacts) collects supported screenshots, video, HTML, and Markdown from the review conversation so the evidence can be inspected beside the diff.
When the agent pushes another commit, earlier evidence may become stale. The team should bind validation and artifacts to the exact revision they support. Returning reviewers can then use a [revision diff](/learn/code-review/what-is-a-revision-diff) to isolate what changed after their last completed review.
## Session logs are evidence, not the review interface
Agent session logs can be valuable. GitHub lets collaborators monitor Copilot sessions, trace commits to their sessions, and query completed work. Logs can explain which tools ran, how the agent approached the task, and where it struggled.
Requiring every reviewer to read a full transcript transfers the reconstruction work to the team. Long sessions contain exploration, repeated commands, abandoned approaches, and details unrelated to the merge decision. They may also include repository information, tool output, or customer data that requires restricted retention.
Use a compact agent work record as the index. Link to the underlying session, CI output, and artifacts when a reviewer or auditor needs them.
| Record | Required contents |
| ---------- | ------------------------------------------------------------------------------------ |
| Authority | Source request or approved plan, responsible person, and material deviations |
| Provenance | Agent, execution environment, model when available, session, and contributed commits |
| State | Working, blocked, awaiting decision, or complete; definition of done; remaining work |
| Revision | Repository, pull request, head SHA, and the comparison each reviewer completed |
| Validation | Exact checks, results, skipped work, failures, environment, and supported claims |
| Evidence | Screenshots, recordings, HTML, traces, benchmarks, or reports tied to the revision |
| Decision | Named reviewers, unresolved findings, accepted risks, and the final human verdict |
The [AI coding agent handoff](/learn/code-context/ai-coding-agent-handoff) can stay short for a small change. A cross-service authorization or data-migration change needs more evidence because more people must verify and operate the result.
## Better metadata does not make a broad pull request easy
A clear work record reduces archaeology. It cannot make an entangled change cheap to review.
A 2026 study of 33,707 agent-authored pull requests found that structural signals such as files changed, lines changed, and change entropy predicted high review effort far better than text features. The result supports a practical limit: presentation helps reviewers find the work, but the footprint of the change still determines much of the review cost. See [Early-Stage Prediction of Review Effort in AI-Generated Pull Requests](https://arxiv.org/abs/2601.00753).
Split independent behavior before review. Give product, security, platform, and operations owners a reading path through the code they own. Keep the summary, validation, and artifacts current as the head changes. If reviewers cannot connect a change to its authorizing request or verify its consequential behavior, the pull request is not ready merely because an agent marked its task complete.
## A team workflow for agent-created pull requests
Link the issue, customer need, incident, or exact approved plan. State material deviations before asking for review.
Identify the initiating person, contributing agents, model information when available, session links, and commits produced.
Name the head SHA, change map, execution state, completed checks, missing checks, risks, and supporting evidence.
Ask Codex, Cursor, Copilot, or another reviewer to explain unfamiliar paths, find issues, or implement requested fixes. Keep their findings attributed.
Route product, technical, security, and operational questions to the people who own them. Generated explanations remain claims until the code and behavior support them.
Refresh stale evidence and show each returning reviewer what changed since that person's completed checkpoint.
The responsible reviewer approves, requests changes, or accepts a known risk against the current revision. Record that decision where the team can find it later.
## Where Plannotator fits
Open-source Plannotator can open a GitHub pull request or GitLab merge request in its browser review UI. It shows the diff, supports line-specific comments and suggestions, collects supported evidence from the hosted conversation, and can launch supported review agents. GitHub or GitLab remains the system of record.
Plannotator does not import the private agent transcript or infer that validation happened. Put the request, material decisions, validation results, and known gaps in the pull request or merge request so another reviewer can verify them.
## Frequently asked questions
### Why are AI-generated pull requests harder to review?
They can arrive faster and include more code while the request, agent provenance, execution state, validation, and evidence remain outside the pull request. Reviewers then have to reconstruct both the change and the process that produced it.
### Does GitHub show whether a pull request is a draft?
Yes. GitHub clearly distinguishes Draft from Ready for review. That status does not say whether every contributing agent is finished, whether the definition of done was met, or whether validation evidence is current.
### Should an AI-generated pull request name the model?
Record the agent, provider, model or model family when available, execution environment, initiating person, and session. Use model information for provenance and policy, not as proof that the code is correct.
### Should reviewers receive the complete agent transcript?
Usually not as the primary handoff. Provide a compact, revision-bound work record and link to the full session when its details matter. Restrict sensitive session data according to the repository's access and retention rules.
### Can Codex and Cursor review pull requests?
Yes. Codex can review GitHub pull requests, post findings, accept focused review instructions, and implement requested edits in the same thread. Cursor provides local Agent Review and can run background-agent work from GitHub pull-request instructions. Teams still need to decide how those findings, fixes, and sessions enter their shared review record.
### What should an AI coding agent include in a pull request?
Include the authorizing request, exact revision, change map, execution state, validation commands and results, skipped checks, open questions, risks, and relevant artifacts. Add agent and model provenance when available. The [agent handoff guide](/learn/code-context/ai-coding-agent-handoff) provides a reusable format.
Give reviewers a stable index into the request, current revision, validation, evidence, and unresolved work.
Connect approved intent, implementation, evidence, review, and the final team decision.
See what changed after each reviewer's last completed checkpoint.
Review screenshots, recordings, HTML, reports, and other evidence beside the diff.