With more than 40 percent of PRs starting with AI-generated drafts, has the focus of programmers’ work shifted?

Before a code change is submitted to a colleague for review, who writes the first version? The answer on GitHub is changing rapidly.

An Octoverse report released on October 28, 2026, showed that in September, more than 40% of pull requests (PRs—code changes submitted to a team for review and merging) on GitHub originated from drafts created by identifiable AI agents; in March, that figure was 17%. In September, the number of such PRs reached 110 million.GitHub Octoverse 2026

These figures raise a question for the team: As it becomes easier to submit code proposals, can the development process keep pace in determining which changes are worth adopting? This issue affects how programmers allocate their time, as well as how the company measures software productivity.

I. The Draft Becomes an Assignable Task

Code completion helps developers finish the next line, while agents can take over a task. Taking GitHub’s product mechanisms as an example, developers can assign tasks to agents, allowing them to search repositories, modify files, and run tests, then make further adjustments based on any failures; the asynchronous mode allows users to work on other tasks first and then return to review the results later.GitHub Bot Documentation

This adds another layer of meaning to PR: it becomes the interface for communication between humans and intelligent agents. In the past, programmers gained a step-by-step understanding of problems by implementing solutions themselves; now, part of that understanding must be completed in advance, taking the form of clear objectives, scope for modifications, and acceptance criteria.

For example, even if you assign the task of “fixing duplicate order submissions,” someone still needs to specify how to identify duplicate orders, whether network retries are allowed, and which legacy APIs must be supported. This is a typical scenario for task decomposition. If the scope isn’t clearly defined, the AI agent may end up delivering code that works—but solves a different problem. The time saved on typing will resurface during the requirements clarification or rework phases.

II. An increase in the volume of submissions cannot be directly equated with productivity per employee

Octoverse also found that, among the newly created repositories observed in the report, those with agent profiles had an average commit count eight times higher than repositories without such profiles. While this gap is striking, it cannot be directly interpreted as an “eightfold increase in programmer efficiency.” Configuration files are a usage indicator; team composition, project types, and task sizes may all vary; and more active teams may also adopt agents earlier.Octoverse Data and Methods Description

It is also necessary to maintain consistency in statistical definitions. The reporting period is from October 1, 2025, to September 30, 2026, and most metrics cover both public and private repositories; the “agent draft” is limited to participation that the platform can identify. The fact that an AI use case was not recognized does not mean that AI was not used at all; the number of PRs does not equate to the number of lines of code, nor does it represent the total labor input across the entire software industry.

For companies, the truly useful questions are: For a given complex feature, how long did it take from initial proposal to stable deployment? How much time did reviewers spend? How much rework was required after deployment? If performance evaluations are based solely on the number of pull requests, teams are likely to be rewarded for “breaking things down more and delivering faster,” while overlooking maintenance costs. While activity metrics can indicate the pace of adoption, sound business decisions require a balanced view that also considers quality and cost.

III. Review Capacity Begins to Determine Throughput

Once the supply of drafts increases, the review process is likely to become a new bottleneck. The solution isn’t simply to add another AI reviewer: if there are no clear standards for both generation and review, the same misunderstanding could be confirmed back and forth repeatedly.

GitHub itself notes that Copilot reviews may either miss issues or flag non-existent ones, so manual review is required; generated code must still be reviewed and tested in critical or sensitive scenarios.GitHub Guidelines for Responsible Use

A more robust approach is to ensure that “completion” is backed by verifiable evidence. The official Claude Code practice distinguishes between requirements—such as prompts and project descriptions—that the model must understand, and enforcement controls such as tests, permission rules, hooks, and branch protection. Telling the model “do not exceed its authority” is not the same safeguard as actually restricting its permissions within the environment.A Practical Guide to Claude Code

From this perspective, the value of test design, fault reproduction, system boundaries, and rollback capabilities becomes even more apparent. Developers need to be able to pinpoint why an implementation is flawed and design checks that expose those errors. For teams working on existing complex systems, building out this infrastructure may be more useful than simply increasing the concurrency of agents.

IV. Platform Competition Extends to the Delivery Process

Of course, the products still compete in terms of coding capabilities, but the team is purchasing a set of workflows that can be integrated into their existing development process. The official documentation for these three types of products highlights different aspects of integration, but this does not mean their capabilities are mutually exclusive.

One noteworthy development is that GitHub has also integrated Anthropic Claude and OpenAI Codex; however, these third-party coding agent features are still in public preview and require a paid Copilot plan and the activation of the corresponding policy.GitHub Third-Party Agents Documentation

This means that the model and the collaboration platform may not necessarily be provided by the same vendor. For GitHub, even if a user switches agents, tasks, permissions, and merge decisions may still remain on the platform; for teams, selection criteria should also include migration costs, audit capabilities, and the ability to reuse existing processes.

It’s also worth calculating the costs carefully. According to GitHub’s documentation, the usage of these coding agents is billed in Actions minutes and AI credits, with the latter depending on the selected model and the number of tokens processed. If a task requires multiple attempts and significant rework after review, a lower cost for the initial draft doesn’t necessarily mean a lower cost for the final delivery.GitHub Usage Information

V. A Programmer's Value Should Be Measured by Deliverables

There are indeed signs that the focus of work is shifting, but it is impossible to deduce from this report how the number of positions will change. It documents development activities but does not directly measure how many engineers companies need.

A more practical approach is to allocate attention based on the risk associated with each task. Changes with clear boundaries that are easy to verify can be delegated more freely; tasks involving accounting rules, authorization models, or cross-system changes require more in-depth design and review. Teams can first compare the delivery cycles, review times, and post-launch rework for similar tasks before deciding to expand the scope of delegation.

Talent development also faces a new challenge: If new hires rarely get hands-on experience with implementation and debugging, how can they develop the ability to evaluate initial code drafts? Having them explain design trade-offs, reproduce bugs, and supplement tests is a more meaningful measure of genuine growth than simply counting the number of commits.

The fact that more than 40 percent of PRs start with an agent indicates that the question of “who writes the first version” has changed. What’s worth watching next is whether teams can turn the time saved on implementation into more reliable deliveries. Judgment doesn’t automatically improve along with code output; it needs to be integrated into the process and requires ongoing training.