GitHub Octoverse 2026: Agents Start Over 40% of Pull Requests as Activity Surges

GitHub released its Octoverse 2026 report on October 28, reporting that agents supplied the first draft for more than 40% of September’s pull requests. A pull request proposes code changes for review before they join a project. The finding places automated drafting inside a central software workflow, while leaving productivity and quality as separate questions.

GitHub Octoverse 2026 also reports record activity across its platform. That makes the distinction between producing changes and delivering useful software more consequential. An AI coding agent, software that carries out development tasks using an AI model, can generate work that still requires substantial human judgment.

For engineering leaders, the central tension is growing code production versus the capacity to evaluate it. Earlier research from METR showed why those measures deserve separate treatment. Meanwhile, GitHub’s support for agents from Anthropic and OpenAI places competing providers inside the same review environment. The practical question is how much useful work survives the entire process.

GitHub Octoverse 2026 Records a Shift in How Changes Begin

According to GitHub’s Octoverse findings, developers made 17.9 billion pushes and merged 1.3 billion pull requests during the reporting year. A push sends saved code changes to GitHub. The push total exceeded the previous two years combined.

The reporting window runs from October 1, 2025, through September 30, 2026. Most figures include public and private projects. GitHub recalculated earlier years using comparable definitions, an important qualification when comparing these figures with previously published reports.

The agent-started share rose from 17% in March to more than 40% in September. GitHub defines these requests by a detectable agent-generated first draft.

The adoption figure measures how proposed changes begin, rather than how much finished software an agent independently creates.

That distinction changes the headline’s meaning. A developer can specify the task, reject an initial approach, rewrite parts of the result, and make the final approval decision. Calling the resulting work entirely autonomous would erase those contributions.

The denominator matters just as much. A share of pull requests cannot be translated directly into a share of code, working hours, or product functionality. Proposed changes vary in size, difficulty, and importance.

Consider a documentation correction beside a change to payment authorization. Both can produce a pull request. Their review requirements and consequences differ substantially, even when the platform records each as a single proposal.

Likewise, a rising count of proposed changes can reflect several developments. Teams might attempt more projects, divide work into smaller pieces, or generate additional revisions. Those possibilities require different interpretations.

This is why the report deserves attention without carrying every conclusion attached to the AI coding debate. It documents a substantial change in observable development behavior. Establishing the economic value of that behavior requires additional evidence.

For readers following GitHub agent adoption, the useful starting point is therefore precise attribution. These are GitHub’s platform measurements, with the company’s definitions and detection boundaries. They are not an independently audited estimate of AI’s contribution to all software development.

The news still matters on those terms. Drafting is a meaningful entry point into engineering work. When agents participate there, review systems become the place where their proposals encounter project requirements and human accountability.

That puts maintainers, engineering managers, and security reviewers directly inside the story. Their decisions determine whether additional activity becomes useful software or a larger collection of unfinished proposals.

More Drafts Put Review Capacity Under Pressure

Engineering teams gain from faster drafting when they can evaluate the resulting changes without losing control of quality or priorities.

That is an operational argument, rather than a claim that every team already faces an overloaded review queue. The pressure follows from the workflow: producing a proposal and accepting responsibility for it require different work.

A reviewer must establish what the change is intended to accomplish. They then need to determine whether its implementation matches that intention. Automated tests can support that judgment, but their usefulness depends on what they actually check.

A test that confirms expected output can still overlook an incorrect assumption about customer behavior. A change can satisfy its assigned task while conflicting with another part of the product. These are reasons to examine the evidence around a proposal.

The consequences also extend beyond correctness at submission. Someone must maintain the implementation, explain its decisions, and respond when requirements change. Additional code creates obligations alongside whatever immediate value it provides.

For engineering managers, this raises a capacity question. If drafting becomes easier, how should a team allocate attention between new proposals, existing maintenance, and production reliability? Increasing submissions without adjusting those priorities risks moving the constraint downstream.

Google Cloud’s DORA researchers describe a related tension in their analysis of AI development tradeoffs. They report that time saved during creation often moves into auditing and verification. Their interpretation treats AI as an amplifier of existing organizational strengths and weaknesses.

That observation offers a useful framework for reading the platform figures. A team with clear requirements and dependable checks has a different starting position from one with unclear ownership. Giving both teams faster drafting does not remove those differences.

The immediate pressure falls on people who approve changes and own their consequences. A maintainer cannot reasonably treat an agent’s confidence as a substitute for evidence. An engineering manager cannot infer customer value from a growing submission count alone.

Security teams face a similar allocation problem. A proposal might require scrutiny because it changes access rules, handles sensitive information, or introduces an external component. Its origin does not determine its risk.

Product teams also have a role. Easier implementation makes it more tempting to pursue loosely defined requests. Clear acceptance criteria become more valuable when generating a plausible implementation requires less effort.

For individual developers, the implication is more specific than simply learning to prompt. The valuable skill is connecting a requested change to evidence that it works and belongs in the project.

That includes preserving the reasoning behind decisions. Teams trying to build a searchable knowledge base face a related challenge: keeping technical context available when the original author is absent.

Documentation cannot approve a change. It can help a reviewer understand the constraints that approval depends on. As drafting accelerates, that shared context deserves attention alongside the generation tools themselves.

Copilot, Claude, and Codex Compete Inside the Same Workflow

The competitive backdrop helps explain why agent adoption is becoming a workflow question. Developers can encounter different providers without abandoning the place where their teams discuss and approve changes.

GitHub’s February announcement introduced partner coding agents, including Anthropic’s Claude and OpenAI’s Codex, in public preview. It described assigning work from GitHub and reviewing draft pull requests generated by those agents.

That announcement establishes the product direction during the reporting year. It should not be read as a complete inventory of current availability or access conditions.

For GitHub, hosting competing agents makes the review workflow a strategic asset alongside its own coding assistant.

The platform can remain central even when a developer prefers a different provider for a particular assignment. Work still needs a destination, a history, a discussion, and an approval process.

For Anthropic and OpenAI, appearing inside that environment offers another route into development work. Their agents can compete for assignments where teams already manage software changes.

This comparison does not establish which agent produces better results. A distribution agreement and a product announcement cannot answer that question. They show how providers reach users, rather than how reliably they solve comparable tasks.

The distinction matters when interpreting GitHub agent adoption. More agent-started proposals do not automatically identify a winning provider. Adoption of the workflow and competition within that workflow are separate developments.

A concrete example appears in the February announcement: developers could assign an issue to an agent and receive a draft for review. An issue records a requested task or problem. That gives delegation a recognizable beginning and a reviewable result.

The importance lies in the handoff. A request becomes an attempted implementation, which returns to a system where people can inspect changes and request revisions. The agent participates in an existing accountability structure.

For a team evaluating providers, that structure should make comparison more meaningful. The relevant question is whether a provider completes the team’s actual work with acceptable review effort. A polished demonstration cannot establish that outcome.

Imagine comparing agents on a recurring maintenance task. A useful assessment would consider whether each proposal addresses the request, respects project conventions, and provides credible verification. Counting generated files would answer a different question.

The same applies to integrating an agent into a team. Access to the tool is only the beginning. Permissions, task boundaries, and the responsibility for approval still require explicit decisions.

There is also a practical benefit to preserving a consistent review environment. Teams can evaluate a new provider without simultaneously replacing every surrounding process. That makes provider differences easier to distinguish from workflow changes.

The competitive story therefore supports the central tension. Providers are making drafting more accessible within established engineering environments. The value of that access depends on how successfully teams turn competing proposals into accepted, maintainable changes.

Faster Merges Leave Important Quality Questions Open

GitHub reports that September’s agent-involved requests reached a 90% two-week merge rate, versus about 86% for requests without detected agent involvement.

A merge records acceptance into a project; it does not establish the change’s long-term reliability or business value.

That limitation applies to human-originated changes as well. Approval can be reasonable based on available evidence while later behavior reveals a missed interaction. Software quality unfolds over time.

A faster path to acceptance can reflect an improvement. It can also reflect differences in the tasks submitted, project practices, or the level of scrutiny required. An observational comparison cannot automatically separate those explanations.

Task selection is particularly important. Teams might delegate work they already know how to specify and verify. More ambiguous assignments might remain with developers. Comparing those groups without accounting for their differences risks overstating the result.

The reverse possibility also deserves consideration. An agent might make previously neglected maintenance practical, expanding the range of work a team attempts. A fair assessment should account for useful additional output.

This is where simplistic readings fail in both directions. Additional activity is insufficient evidence that every team became more productive. The absence of a universal productivity estimate is insufficient evidence that the activity lacks value.

METR’s developer productivity experiment illustrates why measurement matters. Its early-2025 randomized study involved 16 experienced developers completing 246 tasks in familiar open-source projects. Allowing AI increased completion time by 19%.

Those findings describe a particular population, task setting, and generation of tools. They should not be treated as a direct measurement of late-2026 agent performance.

The study’s relevance here is methodological. Observing that developers use a tool does not tell us how much faster they complete equivalent work. That requires a credible comparison.

Historical research also needs updating as behavior changes. A result can remain valid for its original setting while becoming less informative about a newer workflow. Treating it as timeless would be another measurement error.

Quality comparisons require similarly careful boundaries. A proposed change can pass existing checks while adding complexity that future maintainers must absorb. Alternatively, a larger implementation can remove an awkward workaround and reduce future effort.

Reviewers therefore need evidence connected to the task. Relevant checks, understandable reasoning, and a clear account of changed behavior offer more information than an origin label.

For enterprise buyers, this creates a procurement challenge. Adoption dashboards are easy to summarize, while avoided incidents and reduced maintenance burdens take longer to establish. A convincing evaluation should acknowledge that difference.

The appropriate conclusion is specific. GitHub’s acceptance figures offer information about how changes move through its platform. They leave room for further research into rework, reliability, reviewer effort, and useful delivery.

That gap is an agenda for measurement. It does not require assuming either that agents are universally beneficial or that their contributions are merely noise.

Measuring Agent Productivity Gets Harder as Work Changes

The measurement challenge extends beyond selecting the right dashboard. Agent use can change which tasks developers attempt and how they distribute their attention.

In its February 2026 productivity research update, METR said its later experiment provided an unreliable estimate of current AI productivity effects. Recruitment, task selection, and concurrent agent use complicated interpretation.

The researchers thought developers were likely benefiting more than their earlier estimates suggested. They also emphasized that their data offered weak evidence about the size of that improvement.

Reliable evaluation must account for changes in the work itself, alongside changes in the tools performing it.

This matters because a fixed task comparison answers a bounded question. It can estimate how assistance affects a particular assignment. It cannot fully capture what happens when assistance changes the assignments people choose.

Suppose a developer previously postponed a tedious migration because it required too much concentrated effort. An agent might make that work feasible during an otherwise busy week. The benefit includes completing something that would have remained undone.

Now consider the opposite case. Easier drafting might encourage a team to implement a feature before establishing that users need it. The implementation can be technically successful while consuming attention better spent elsewhere.

These examples are analytical possibilities, rather than reported outcomes from the Octoverse dataset. They explain why useful delivery needs a connection to intent and results.

Parallel work introduces another complication. A developer might review a proposal while an agent works on a separate task. Measuring the agent’s elapsed runtime as human working time would misrepresent the arrangement.

Yet ignoring supervision would also distort the result. Task preparation, interruptions, rejected approaches, and final review belong in an assessment of the workflow. The accounting boundary affects the conclusion.

For organizations, this favors several complementary forms of evidence. Comparable task evaluations can examine completion effort. Operational records can show acceptance and rework. Product outcomes can establish whether delivered changes helped users.

No single measure captures everything. That is a reason to state what a measure represents, rather than collapse unlike results into a universal productivity score.

A team might improve its delivery speed while struggling with maintenance. Another might reduce repetitive effort without increasing release frequency because approvals remain constrained elsewhere. Both deserve descriptions that match their actual experience.

The same discipline applies when comparing teams. A mature service with strict reliability requirements differs from a new experimental project. Their submission counts should not become a ranking of developer effectiveness.

GitHub Octoverse 2026 is useful as evidence of a changing development environment. Its broader implications become clearer when platform activity is considered alongside task-level studies and organizational outcomes.

For developers, the practical concern is whether their work becomes easier to complete and easier to maintain. For managers, it is whether those gains survive across the team. Neither question disappears when drafting becomes commonplace.

Watch Review Effort, Reliability, and Comparable Task Results

The next useful evidence should connect agent participation with what happens after a proposal appears. Over the coming months, readers should look for changes that clarify the relationship between drafting and delivery.

The strongest follow-up evidence will connect agent-originated work to review effort, production outcomes, and credible task comparisons.

The first signal is better reporting on review effort. Platform vendors and engineering teams should show how much human attention accepted agent proposals require. Waiting time alone cannot establish that.

A request can wait in a queue without consuming much reviewer effort. Another can move quickly while requiring intensive discussion. Distinguishing those situations would make acceptance statistics more informative.

Evidence of falling review effort on comparable work would strengthen the case that agents improve the whole workflow. Rising effort would suggest that some drafting savings move into supervision.

Readers should also examine how teams account for rejected work. A dashboard focused only on successful merges can omit the effort spent evaluating proposals that never reach acceptance. Those attempts still belong in the assessment.

The second signal is reliability after acceptance. Look for evaluations that follow changes beyond the merge and examine whether they require corrections, reversals, or incident response.

A reversal removes or undoes an earlier change. Its meaning depends on context, since product decisions can change for reasons unrelated to code quality. Useful reporting needs enough detail to separate those explanations.

Stable reliability alongside faster delivery would strengthen the argument for net gains. More follow-up repair would qualify it. The relevant comparison should account for task risk and project maturity.

This is especially important for buyers evaluating deployment across an organization. A successful pilot on bounded maintenance work does not automatically establish readiness for sensitive systems. Expansion should produce evidence about the new scope.

The third signal is updated research comparing equivalent work with current tools. Studies should explain how they handle task selection, concurrent agents, and the human effort surrounding generation.

A consistent improvement across credible evaluations would strengthen the productivity case. Mixed results would suggest that benefits depend on the assignment, developer, or organization. Either outcome would be more useful than a universal claim.

Researchers should also make the boundaries visible. A task-level result, a team delivery result, and a developer satisfaction result can all be valid. They describe different dimensions of the experience.

For readers assessing GitHub Octoverse 2026, keep the central distinctions visible as new announcements arrive. Ask which work agents begin, who evaluates it, and what happens after approval. Follow whether organizations publish evidence about review effort and reliability alongside adoption. When comparing tools, look for results from tasks resembling your own, with supervision included in the accounting. Preserve the context behind important changes so future reviewers can understand their purpose. The report makes agent participation difficult to overlook; your next decision should depend on the work that participation helps complete. Which evidence would show that your team is delivering more useful software with less total effort?