When the First Draft Is an Agent's

GitHub Octoverse 2026, October 2026

The author used to be the explanation. For four in ten pull requests, it no longer is.

A desk with a pull request queue on a monitor, four of ten PRs tagged agent. The headline reads: 40% of PRs start as an agent's first draft. Tier the review by risk and name a human owner for every merge.

The pull request process was built on an assumption nobody wrote down: the author understands the change. A reviewer could ask why, and the author could answer. GitHub's Octoverse 2026 says that assumption is now false for a large share of the queue: more than 40% of the pull requests opened in September 2026 started from a coding agent's first draft, up from 17% in March. That is about 110 million agent-started pull requests in a single month, roughly six times March's volume.

That is not a tooling statistic. It is a change in who the reviewer is talking to, and most review processes have not noticed.

What the number does and does not say

GitHub defines an agent-started pull request as one whose first draft came from a coding agent it can detect, and calls the signal a floor, because not all agent use is detectable. So 40% is a minimum, not an estimate. It also varies by stack: detected AI involvement in merged pull requests runs about 40% to 44% in TypeScript, Python and Rust, and about 21% to 34% in Java, C# and C++. Your own share depends on what you build in, and the languages with the lower numbers are the ones many regulated shops still run.

Two more details matter more than the headline. Agent-started pull requests more often touch several files: about 87%, against 79% for pull requests with no detected agent involvement. And they merge: 90% were merged within two weeks in September, up from 83% in February, against about 86% for the comparison group in both periods. GitHub presents those as descriptive comparisons and does not claim agent involvement causes faster merges, and neither do I. But read them together. Bigger changes, merging at a higher rate than human-started ones, is either a sign that agents got good or a sign that review got thin. The merge rate cannot tell you which. A merge is a record that a change landed, not that anyone spent an hour deciding it should.

Then put it against the platform's total volume. GitHub counted 1.3 billion merged pull requests this year, about 3.5 million a day, more than triple 2024. Nothing suggests review capacity tripled with it. Use of AI-assisted code review grew more than 90%, which is the part of the system that scaled, and the data on what happens to human review when it does is not encouraging.

The author is no longer the explanation

When a person writes the code, review is a conversation with someone who made decisions. When an agent writes the first draft, the diff is a finished-looking artifact with nobody behind it, and reviewing it feels like reviewing a stranger's code every time. The fix is not a better diff viewer. It is moving the human decision upstream, to the plan the agent worked from, so that the reviewer is checking the diff against an intent a person approved and not reverse-engineering the intent from the code. This is the same move as plan approval, and at 40% it stops being a nice practice and becomes the only place the volume can be handled.

It also changes what a good agent pull request looks like. A study of about 33,000 agent-authored pull requests from five coding agents (Ehsani and colleagues, January 2026) found that the ones that were not merged tended to be larger, touched more files and more often failed the project's CI checks. Documentation, CI and build-update tasks merged most often; performance and bug-fix work merged least. Its qualitative pass on rejected pull requests named a lack of meaningful reviewer engagement among the causes, alongside duplicates and unwanted features. The practical reading is that size is a control you own. An agent given a narrow plan produces a small diff a person can actually read, and GitHub's own stacked pull requests, in preview since July 30, 2026 and already used by more than 264,000 developers, exist for the same reason.

Tiers have to key off the change, not the author

When more than four in ten PRs are agent-started, "who wrote it" is the wrong sorting key, and the share keeps moving. Tier by what the diff touches: docs and tests on one side, auth, money, PII, migrations and infrastructure on the other. The rule I would hold at any agent share is that the top tier keeps two humans and an architect, no AI auto-approve, and no agent-authored code. At 40% that rule needs routing to enforce it. A policy that lives in a wiki page loses to a queue.

The bottom tier is where the volume goes, and it should. GitHub counts more than 30 million merged Dependabot pull requests in the past year, about double the 2025 pace, and nobody believes each got a careful read. Auto-merge on green for the safe class, with a weekly human audit sample, is honest about that. What is not honest is letting the middle of the queue quietly behave like the bottom.

The risk in the middle is the one the data already shows. Qodo's numbers have 80% of PRs receiving no human comment once an AI review tool is enabled, and GitHub is previewing AI review approvals that count toward required reviews. Put those next to an agent-started share above 40% and you can build a pipeline where an agent writes the change, an agent approves it, and no person ever read it. Each step was reasonable. The sum is a merge nobody owns.

Every agent-started PR needs a named owner

"The agent opened it" is not an answer to an incident review. Each agent-started PR should carry one human who approved the plan and who answers for the merge, recorded on the PR itself, not inferred from whoever clicked the button. That is the practical form of the question in Who Signs for Agent-Written Code?: the owner is the signature. If nobody is willing to put their name on a change, it is not ready to merge, however green the checks are.

What the owner owns needs to be written down, because the failure mode is a name on a form. The clearest public example is the Kubernetes project's AI usage policy, announced in April 2026. Contributors may use AI tools, but must say so in the pull request description; the human author must understand and verify the work before submitting it rather than relying on reviewers to do the first review; and a pull request whose author cannot explain why a change was made may be closed. The project also does not allow AI tools to be listed as co-authors or credited through commit trailers, on the grounds that an AI cannot sign the contributor agreement. You may choose differently, for example recording agent identity in a trailer so the audit trail shows which tool did what. Either way, pick one rule and enforce it, because an auditor will ask what your control is, not what your tool did.

Three questions on the pull request template carry most of the weight. Was an agent involved, and which one. What did the owner verify, and how. Which tier is this, and did the diff touch anything above it. Nothing about that is new process. It is the old control, someone other than the author puts their name on the work, written for a world where the author is often a tool.

What I would measure

Where I would start Monday

Pull last week's merged pull requests and count three things: how many started from an agent, how many have a human name on the plan approval, and how many have a note on what that human verified. Most teams find the first number is higher than they assumed and the third is close to zero. Then add the owner field to the template, put the tiers into CODEOWNERS and routing, and cap the diff size an agent is allowed to open without a plan. Those three changes are a day or two of work, and they are the difference between a review process and a review ritual.

Design for 80%, not 40%. The share was 17% in March. A review process sized for today's number will be wrong again by spring.

The tiering and plan-approval mechanics are in Where the Bottleneck Moved, the wider data is in What the Data Says in August 2026, and the nine-layer platform that makes trust cheaper is mapped in AI Made Generating Software Cheap. Now Make Believing It Cheap.