Agentic AI pull requests and how maintainers react

Results so far

Campaign window only: pull requests opened since 24 July 2026 that have been merged or closed. They went to 81 repositories; 50 of them merged at least one.

• Pull requests resolved

  252

  opened since 24 July 2026 and now merged or closed

• Merge rate

  58.3%

  147 merged, 105 closed unmerged

• Closed with an explicit AI-related objection (share of closed)

  7.6%

  8 of 105 closed pull requests (3.2% of all resolved)

• Median time to merge

  86.8 h

  about 3.6 days from opening to merge

• Human response before the outcome

  58.7%

  share of pull requests where a person replied or reviewed before merge or close

• Still open

  120

  opened in the window, not counted in the merge rate yet

Counting every pull request the account has ever had resolved, including 18 from before the campaign window, the figure is 270 resolved and a 54.4% merge rate across 87 repositories. If all 120 still-open pull requests were closed unmerged, the campaign merge rate would fall to 39.5%.

How maintainers reacted

Every resolved pull request in the campaign window is in one category. Merged ones are grouped by script from GitHub’s review and comment data. Closed ones are categorised from the evidence in the thread: reviews, comments and the stated closing reason, without keyword matching and without filling in an unstated motive. 29 of the 105 closed pull requests have no current annotation and are shown as reason unknown.

87 of the 147 merged pull requests had a person engage before the merge: 68 with a submitted review and 19 with discussion or inline comments but no formal review. Of the remaining 60, 29 had a human reply only after the merge, and 31 had no recorded human comment or review at all; who performed the merge was not recorded.

Which agents did the work

The agents worked in different set-ups. In the hybrid one, Claude acted as the manager: it scoped the work, dispatched it, usually reviewed the result and opened the pull request, while Codex acted as the developer and wrote the code. In the Claude-alone set-up (47 of 252 pull requests), Claude did all of it. For 180 of 252 pull requests, the logs don’t show which set-up was used. Who played which role comes from the agents’ logs, which do not reveal every role for every pull request.

The workflow figures come from an earlier snapshot of the study than the counts above, so their totals differ.

Agent known per role (workflow data as of 18 October 2026, 252 pull requests): orchestrator for 114 of 252 (45.2%); implementer (wrote the code) for 72 of 252 (28.6%); reviewer for 20 of 252 (7.9%); fixer (addressed review comments) for 28 of 252 (11.1%).

Counts are descriptive only: the fixed hybrid vs claude-solo vs codex-solo comparison, chosen after the attribution data was available, is not testable at this sample size (no attributed PRs in: codex-solo). Workflow type is unknown for PRs without both orchestrator and implementer evidence.

Model choice was not randomized: it changed over time as newer models became available and varied by repo/language (e.g. PHP work leaned on different models than Python work at different points in the campaign). A merged/closed difference between models here may reflect which repos or which campaign period a model happened to work on, not the model's own capability. Treat this as descriptive, not causal. Workflow type adds its own confounders: the Claude-orchestrator/Codex-worker pattern was adopted partway through the campaign and used mostly for specific repositories, and the log sources that reveal a role differ by harness, so PRs whose roles are known are not a random sample of all PRs.

Objections to AI-written code

8 of the 105 closed pull requests (7.6%) were closed with an explicit objection to AI-generated code, to too little human oversight, or to agent commentary on the thread. That is 3.2% of all 252 resolved pull requests. An objection like this is not necessarily a blanket AI policy for the project. Whether each pull request said that an AI agent prepared it was neither required nor recorded, so this count cannot be split by disclosure (see the caveats below).

They are concentrated: 7 of the 8 came from the single organization that closed the most of our pull requests (16.2% of closures in the window), from one maintainer on 2 separate days. Leaving that organization out, the campaign merge rate is 61.7%.

Another 15 closed pull requests had no stated closing reason. Some of those threads have earlier comments, but none says why the pull request was closed, so we do not count them as objections of any kind.

What we changed during the campaign

The way pull requests were chosen and submitted changed while the study ran, in response to what happened. These are the main changes, and what we would tell any team pointing AI agents at open source.

• Check before you contribute. Some repositories that are open source by licence had few or no outside contributions among their last 100 merged pull requests. We added a check that skips repositories when outside contributions rarely appear in that sampled window. Repositories the check screens out are not in the study, so the results say nothing about how their maintainers react to AI-written code; and a low outside share among 100 merges does not by itself show a policy against outside work.
• Pace yourself. The sharpest rejections came from the one organization that closed the most of these pull requests (22, of which 17 were closed, including 7 of the 8 explicit AI objections), some of them on fixes we believed were correct. We suspect the number and pace of submissions played a part as well as the content, and stopped sending several pull requests to one organization at once.
• Keep a person accountable and the thread quiet. Maintainers reacted to how a contribution was run as well as to the code. We stopped the automated follow-up comments on pull requests that had waited without a response, after they drew the kind of reaction to agent activity we wanted to avoid, and moved pull request descriptions to plain first-person prose instead of a template.
• Respect a stated human-in-the-loop rule. From 15 October 2026, when a repository’s published AI policy bans fully autonomous agent pull requests or requires a human in the loop, agents still do the whole job (reproduce, fix, test, push a branch) but stop before opening the pull request. The draft goes into a review queue, the operator reads it each day, edits the description in their own words if needed, and approves it before it is opened. These pull requests are therefore human-approved, not autonomous. Where a template or policy asks whether AI was used, the answer is true and stays in the description.
• Plan for slow answers. 120 pull requests from the window are still open, and many closures come without a stated reason. Judge results on resolved pull requests, and say how many are still waiting.

Method

• The operator chose the repositories and issues, with help from agent-driven scouting and a check that screens out repositories with few or no outside authors among their last 100 merged pull requests, and set the rules the agents work under. The operator directed and submitted every pull request, but how far the operator checked each change (read the diff, ran the tests locally) varied and was not recorded.
• Pull requests opened from 15 October 2026 fall into two groups: autonomous ones, where agents opened the pull request without a person reading it first (as before), and human-approved ones, in repositories whose AI policy requires a human in the loop. The tracker keeps drafts for the second group in a review queue until they are approved. Queue entries before opening are not counted as pull requests.
• The campaign window starts on 24 July 2026. The first days were tooling and pre-submission checks; the first campaign pull request was opened on 24 July 2026.
• Outcomes (merged or closed) are read live from GitHub at snapshot time. The merge rate is merged divided by merged plus closed; open pull requests are left out until they resolve.
• A “human response” is a comment or review from a person other than the author. Known bots and automation accounts are excluded. Being a responder does not prove someone is a maintainer.
• Merged pull requests are grouped by script, according to whether a person reviewed or discussed them before merge, only after merge, or not at all. Closed pull requests were categorised from the thread in agent-assisted coding sessions directed by the operator, and the categories were then checked by separate AI reviewer passes. Where several reasons coexist, the record keeps them all; the category is the one the evidence best supports.
• This page shows aggregates only. It does not name projects, maintainers or individual pull requests.

Caveats

• This is an observational study, not a pre-registered or controlled one. There is no matched group of human-written pull requests to compare against, we chose the repositories ourselves, and the categories were refined while the data was being coded.
• One account, a few months, and a target list we chose. The results say how these pull requests fared, not how AI contributions fare in general.
• The closed-PR categories were assigned with an AI agent’s help and checked by AI reviewer passes, not by independent people. No independent human coder has re-coded them and there is no inter-rater agreement figure. 29 of the 105 closed pull requests have no current annotation.
• Several things that plausibly affect how maintainers react were not held constant or recorded per pull request. The guidance for pull request descriptions asked for plain prose and warned against phrasing maintainers tend to read as AI-generated. Saying that an agent prepared the change was neither required nor recorded. A scheduled script posted templated follow-up comments on pull requests that had waited without a response. Because the largest group of these objections concerned pull requests that appeared AI-generated, disclosure is a major confounder for the AI-objection count.
• Human-approved pull requests (from 15 October 2026, in repositories with a human-in-the-loop policy) are a different condition from the autonomous ones and the two should not be pooled. They are few, chosen by policy rather than at random, and the operator’s edits to the description were not recorded unless noted. Comparing the two groups says little about AI autonomy as such, because the repositories differ.
• The rules changed during the window (see above), so pull requests opened early in the campaign were not submitted under the same conditions as later ones.
• Cost is not measured: there is no figure yet for maintainers’ review time or for agent spend per merged pull request.
• Explicit objections understate negative reactions: during the window the account could not open pull requests in at least two organizations, for reasons that were not confirmed, and that never shows up as a closed pull request.
• Categories describe the evidence in the thread. A pull request closed with no stated reason may have been closed for any reason, including one the maintainer never wrote down.
• The numbers move as open pull requests resolve and threads change; the page shows the snapshot dated at the top.

Data availability

The campaign was run from an internal tracker that remains private. Alongside the working data it holds private account and credential-setup details and an unredacted working history, including notes on individual maintainers who never agreed to appear in a public record. Publishing it would expose that information. We have instead released a cleaned, reusable version of the tool (oss-contribution-tracker) and a sanitized per-PR dataset, in which rows describing objections to our contributions are pseudonymized. The original tracker and the local session logs behind the model attribution are kept intact for verification. Reviewers, researchers or affected maintainers with a legitimate need to check a specific claim can request supervised access to the relevant records. The pseudonymized objection rows keep exact timestamps, durations and counts, so a determined reader could re-identify them from that timing metadata: project names are withheld, but the rows are not anonymous. We accepted that residual risk.

This page itself shows aggregate figures only. The cleaned tool is at oss-contribution-tracker, and the sanitized dataset published there lists individual pull requests: rows closed over an explicit AI-related objection are pseudonymized, and, as the statement above says, can still be re-identified from their timing metadata.

How the data updates

The figures on this page come from an aggregate export of the study’s dataset. Only the counts and percentages the page shows are stored with the site, and the page is rendered when the site is built; it makes no live requests. For now the snapshot is refreshed by hand; each refresh replaces the JSON file. The dates at the top of the page show which one you are reading (data as of 18 October 2026, copied on 19 October 2026).