What the study actually measured
A study posted to arXiv in July 2026 and accepted at the KDD 2026 Workshop on Agentic Software Engineering analyzed 25,264 agentic pull requests across 2,361 popular GitHub repositories over a three-month observation period (arXiv:2607.14037). The headline finding is uncomfortable for anyone selling coding agents: the median repository generated one to two agentic PRs in that period.
That single statistic does most of the analytical work. It reframes adoption away from the metrics vendors prefer (seat counts, Fortune 500 logos, download numbers) and onto the metric maintainers actually experience: agent-authored PRs landing in their review queue. By that measure, the dataset is the first large-scale, repo-level look at whether agentic coding tools show up in real commit flows rather than in marketing decks. Earlier work, including a July 2026 benchmark-reliability audit (arXiv:2607.01211), scrutinized how coding agents are evaluated; this study asks how they are used.
The corpus matters more than the conclusions. 25,264 PRs across 2,361 repositories (arXiv:2607.14037) is large enough to make “intensive adoption remains concentrated in a small subset of projects” a defensible claim rather than an anecdote. The author, Maliha Noushin Raida, frames the work explicitly as an early snapshot: the dataset covers only a three-month window, and the abstract closes by warning that adoption patterns “should continue to” be tracked as the ecosystem evolves. Anyone treating these numbers as a steady-state market share is misreading the paper.
Why most repositories generate only one or two agentic PRs
The median of one to two PRs over three months is the finding most likely to be misread. It does not mean agents are failing. It means the distribution is heavily skewed: most repositories are barely touched, while a thin tail does the bulk of the work. The paper reports “substantial variation in project-level agentic PR productivity,” which is analyst-speak for a long-tailed curve where the mean tells you almost nothing about the typical project.
That skew is what makes the 36-PR-per-participant industry estimate interesting. The paper notes that a small number of projects exceed that threshold while most remain below it (arXiv:2607.14037). Read carefully, the 36 figure is not a typical-case number; it is an upper-band reference point that the paper itself flags as “industry-reported.” The natural inference, which the data supports but does not state, is that the benchmark is built from outlier cases and then quoted as if it were representative. That is exactly the conflation to watch: vendor market-share claims tend to fold downloads and trials into “production use,” obscuring whether the tool ever reaches a commit flow.
The second-order consequence for teams is operational, not statistical. If the median repo sees one or two agent PRs per quarter, then for the average maintainer, agents are not yet a review-load problem; they are an occasional novelty. The review-load problem lives at the tail, in the handful of repositories where agents file dozens of PRs and where the single-human oversight pattern (below) actually has to function as a process. Tooling, policy, and CI investment should be calibrated to where the load actually concentrates, not to the median.
Why the smallest teams lead on agentic PR activity
The counterintuitive result is that small projects, defined in the study as those with one to five contributors, show higher participation ratios and higher average agentic PR activity than medium-sized and large projects (arXiv:2607.14037). If agent adoption were primarily a function of model capability, you would expect it to scale with the sophistication of the team using it. It does not. It scales inversely with organizational weight.
The mechanism is process friction. A solo developer or a two-person team can let an agent file a PR, review it themselves, and merge it without coordinating with anyone. A 200-engineer platform team cannot. Large projects carry branch-protection rules, multi-reviewer policies, required CI gates, ownership files (CODEOWNERS), and a culture in which an unreviewed agent PR is a compliance incident waiting to happen. Each of those is a correct and defensible control. Each is also a brake on agentic throughput. The study’s data is consistent with the reading that bureaucracy, not model quality, is the binding constraint.
This inverts the usual enterprise adoption story. Vendors pitch coding agents at Fortune 500 buyers precisely because enterprises have budget and seat counts. But the empirical signal says the most agent-active repositories are the ones with the least process overhead. The implication for a platform team considering rollout is direct: the bottleneck is not whether the model can write the code. It is whether your review pipeline, ownership model, and approval graph can absorb PRs that arrive faster and more frequently than human-authored ones. If it cannot, the agent’s capability is irrelevant.
The paper drives the point home in its conclusion: successful integration of agent-generated contributions “depends not only on advances in agent capabilities but also on the human and organizational processes that govern their use” (arXiv:2607.14037). That sentence should be printed on the first slide of every procurement meeting about coding agents.
How projects actually review agent-authored code
Human-agent collaboration in the dataset is dominated by a single-human oversight model: one developer reviews and/or modifies the agent’s contributions, while multi-human collaboration patterns remain uncommon (arXiv:2607.14037). In practice, this means an agent files a PR and one named human is the chokepoint for accepting, editing, or rejecting it. Two-reviewer patterns, committee review, and distributed approval are rare.
There are two readings, and the paper does not have the longitudinal data to choose between them. The charitable reading is that single-reviewer oversight is an emerging best practice: agents produce incremental, reviewable diffs, and one attentive reviewer is the right granularity for that workload. The skeptical reading is that single-human oversight may reflect tool immaturity rather than optimal workflow design. Tools today make it easy for one person to shepherd an agent and hard for a team to do so jointly; the observed pattern could be an artifact of what the tooling permits, not what review design would choose.
Either way, the pattern carries a concrete risk that teams adopting agents should price in. Single-human oversight concentrates judgment in one reviewer, which is acceptable for routine PRs and dangerous for anything touching security, auth, data handling, or migrations. It also creates a key-person dependency: the one developer who reviews agent PRs becomes a single point of failure for both quality and throughput. The multi-human patterns the study finds uncommon are precisely the patterns a mature review process uses to defuse exactly those risks. The gap between what the data shows and what a defensible process requires is where most of the operational work of agent adoption actually lives.
How vendor marketing compares with commit-log reality
The value of a repo-level study is that it forces vendor claims into the same units. Once adoption is measured in PRs that actually land, the gap between marketing and measurement becomes visible.
| Claim (vendor) | Source | What the repo-level data implies |
|---|---|---|
| Cursor adoption “went from single digits to over 80%” and “over half of the Fortune 500” use it | cursor.com | Seat adoption; says nothing about agentic PR throughput, which the study finds concentrated in a small subset |
| Copilot agent mode “analyzes the codebase, then explains the required edits for three files before generating them” | github.com | Capability description, not an adoption count; median repo still sees one to two agent PRs per quarter |
| GitHub Next “Agentic Workflows” with “integrity filtering” of untrusted GitHub content | githubnext.com | A production-readiness control; its existence signals that untrusted-input risk is real, not solved |
| ”36 PRs per participant” per quarter | arXiv:2607.14037 (industry-reported, cited in study) | Outlier-band figure; most projects remain well below it |
The pattern across the table is consistent: vendors measure what flatters them, and none of those metrics is the metric the study measures. Seat counts and Fortune 500 logos are vanity numbers for the purpose of “is this agent showing up in real commit flows.” GitHub’s own “over 150 million developers” framing and Cursor’s enterprise positioning describe the top of the funnel; the study describes the bottom.
GitHub Next’s integrity-filtering work is worth a separate beat because it is the most honest signal in the vendor set. The team built a filter that scrubs untrusted GitHub content before it reaches an agent (githubnext.com). You do not engineer a defense against prompt injection and untrusted input unless production deployments are exposing the attack surface. That is a vendor admitting, through engineering effort, that putting an agent in front of arbitrary repository content is not safe by default. Anyone evaluating agents for production should weight that admission heavily. It is more informative than any benchmark score.
The deeper lesson is methodological. The July 2026 benchmark audit (arXiv:2607.01211) showed that even the evaluation of coding agents is unreliable. This July 2026 study shows that their deployment is uneven, skewed, and process-bound. The two papers together describe a market in which neither the capability numbers nor the adoption numbers can be taken at face value. A buyer who believes both the leaderboard and the ARR slide is being sold twice.
What to ask before buying or rolling out a coding agent
The decision-relevant question is not “which agent wins the benchmark.” The study’s contribution is to move the question to “which agent shows up in real commit logs, in projects that look like mine.” Procurement and platform teams should restructure their evaluation around the latter, because it is the only question the evidence currently supports.
A short interrogation list, derived directly from the study’s findings:
Show me repo-level PR data, not logos. Ask the vendor for agentic PR counts, merge rates, and review turnaround in repositories comparable to yours. If they can only produce customer logos and seat counts, they are selling adoption they cannot prove. The study’s median of one to two PRs per quarter is a useful reference: any vendor claiming far higher typical throughput should be pressed on whether that figure is median or outlier.
Ask which review model their tool assumes. The dominant pattern in the data is single-human oversight. If a tool is built around one human shepherding one agent, that shapes how it scales to a team. Ask how the tool supports multi-reviewer flows, ownership-aware routing, and required-reviewer policies. If the answer is “the human handles it,” you have just been told the process design is your problem.
Price in the process change, not just the license. The small-team finding implies that the binding constraint is organizational, not model-based. Budget for branch-protection policy updates, CODEOWNERS adjustments, reviewer load planning, and CI hardening against higher PR volume. The license is the cheap part.
Demand a security model for untrusted input. GitHub Next built integrity filtering for a reason. Ask the vendor how their agent handles untrusted repository content, issue text, and third-party dependencies. Treat “we trust the model” as a disqualifying answer.
Insist on a time-bound pilot with repo-level metrics. Because the ecosystem is shifting fast, a static case study ages out in months. Run a pilot that measures your own agentic PR throughput, merge rate, and review-time delta against human-authored PRs, and re-baseline quarterly.
The unifying principle is simple: make the vendor speak in the units the study uses. Repositories, PRs, reviewers, and merge rates are auditable. Seats and logos are not.
What the study cannot tell you yet
Every empirical snapshot has asterisks, and this one has enough that a careful reader should weight the directional findings more than the absolute numbers.
First, the window is narrow. The three-month observation period is a single observation point in a market where new agents and GitHub’s own agentic features ship on a monthly cadence. GitHub Next’s project list (githubnext.com) shows multiple agent-adjacent prototypes (Agentic Workflows, Crane, Agentics Beyond Code) maturing in parallel; any of them landing as a product could shift the distribution quickly. The paper is explicit that this is “an early snapshot of agent adoption” and that future work should track evolution (arXiv:2607.14037).
Second, the sample is popular public repositories. That is the right place to start, because public repos expose PRs and review trails. But it systematically excludes the private enterprise repositories where vendors claim their strongest adoption. A repo-level study of private commit flows would either corroborate the skewed, process-bound picture this paper paints or contradict it. Nobody has published that study yet, and until someone does, enterprise adoption claims remain unverified at the unit of measurement that matters.
Third, the 36-PR-per-participant figure is industry-reported and used as a reference threshold, not derived from this dataset. The paper treats it carefully, but it will be quoted carelessly. Any secondary source that cites 36 PRs as a typical rate is misusing the number; the study’s own finding is that most projects sit below it.
Fourth, the detection of “agentic” PRs rests on a classification the paper does not fully expose in the abstract. Whether PRs are labeled by author identity, tool attribution, commit metadata, or some heuristic affects how strictly the 25,264 figure (arXiv:2607.14037) should be read. Agents that operate without clear attribution, or humans who relay agent output under their own account, would be undercounted. The directional skew is likely robust to this; the precise counts are not.
The bottom line is durable even where the numbers are soft. Agent adoption is real, but it is uneven, concentrated in small teams, and bottlenecked by review process rather than model capability. Vendors are selling capability and seats; the evidence says the deciding factor is whether your organization can absorb the PRs. Demand repo-level proof, design your review process before you buy the tool, and revisit the numbers in a quarter, because this market will not hold still long enough for any single snapshot to stay accurate.
(Post-cutoff note: figures cited from the July 2026 arXiv paper were re-verified against the abstract on 2026-07-17; vendor claims are quoted from vendor pages accessed the same date and should be re-checked before any procurement decision.)
Frequently Asked Questions
Does this data cover private enterprise repositories?
No. The study analyzes only popular public repositories where PRs and review trails are visible. Private enterprise repositories, where vendors often claim their strongest adoption, are systematically excluded from this dataset. A repo-level study of private commit flows would either corroborate the skewed, process-bound picture or contradict it, but that study has not been published yet.
How does this study differ from SWE-bench and other coding-agent benchmarks?
Benchmarks measure model capability on curated problem sets. This study measures whether agents actually show up in commit flows. The July 2026 benchmark audit (arXiv:2607.01211) showed even capability evaluation is unreliable; this July 2026 study shows deployment is uneven, skewed, and bottlenecked by process rather than model quality. A buyer who believes both the leaderboard and the ARR slide is being sold twice.
Why do vendors cite 36 PRs per participant if most projects generate far fewer?
The 36 PR figure is an industry-reported upper-band reference, not a median. The study found that only a small number of projects exceed this threshold while most remain below it. Vendors likely derived the benchmark from outlier cases, then quote it as if it were typical. This conflation folds downloads and trials into ‘production use’ claims, obscuring whether tools ever reach actual commit flows.
What security risks does the single-human oversight pattern create?
Single-reviewer oversight concentrates judgment in one person, which is acceptable for routine PRs and dangerous for security, auth, data handling, or migrations. It creates a key-person dependency where one developer becomes a single point of failure for both quality and throughput. GitHub Next built integrity filtering to scrub untrusted content before it reaches agents, signaling that untrusted-input risk is real enough to warrant dedicated engineering.
Will these adoption patterns hold beyond the three-month observation window?
Not necessarily. The market is shifting faster than this snapshot can capture. GitHub Next is maturing multiple agent-adjacent prototypes (Agentic Workflows, Crane, Agentics Beyond Code) in parallel; any of these landing as products could shift the distribution quickly. The study is explicit that this is an early snapshot and future work should track evolution as the ecosystem matures.
