Octoverse 2026: When the Cost of Code Moves to Review

Writing code is becoming cheaper. Understanding why a change exists, and whether it should be merged, is not automatically getting cheaper with it.

GitHub’s Octoverse 2026 offers a useful snapshot of that tension. GitHub says developers initiated more than 40% of pull requests with an agent in September, up from 17% in March. It also reports that monthly commits in September 2026 were six times their September 2025 level.

Those figures describe activity on one platform, not a controlled experiment about software quality. They do not establish how much of the increase agents caused, how much time teams saved, or whether any individual project improved. Still, they give me a reason to ask a practical question: what happens to review when producing a plausible change becomes faster?

A pull request is a change in responsibility

An agent can draft an implementation, run a command and summarize a diff. A reviewer still has to determine whether the problem was understood, whether assumptions match the system, and whether the result is appropriate for its users.

That work is different from checking whether a patch looks coherent. A fluent explanation can make a wrong assumption look settled. A successful test can demonstrate behavior under the cases it covers while leaving the real operational boundary untested. Neither problem is unique to agents, but faster production can expose both more frequently.

I would start each review with three questions:

1. What decision is this change making? Identify the requirement, affected users and behavior being changed.
2. What evidence would disprove it? Look for failure paths, permission boundaries and assumptions a happy-path test does not exercise.
3. Can this be reviewed in pieces? Separate unrelated behavior and keep each change small enough that its consequences are visible.

The point is not to impose the same ceremony on a typo and a payment authorization change. The amount of evidence should follow the consequence of getting the decision wrong.

Activity is not a productivity measurement

GitHub also reports that newly created repositories with an agent configuration file averaged eight times as many commits as newly created repositories without one. That is a correlation within GitHub’s measured groups. Repositories with different purposes, automation and contributor patterns can behave differently. The presence of a configuration file alone does not establish that an agent caused eightfold productivity.

The useful distinction is between throughput and outcomes. Commits, pushes and pull requests show what a system processed. They do not, by themselves, show customer value, reliability or the cost of maintenance.

For a team evaluating agent use, I would pair activity data with measures closer to the work: how long changes wait for review, how often they require substantial rework, whether important failure cases are covered, and what happens after deployment. None of these should be treated as a single score. A team can improve one by making another worse.

Make evidence travel with the change

The most useful output from a coding agent may be the context around its diff: the requested behavior, the assumptions it made, the commands it ran and their results. A reviewer can then reproduce relevant checks, inspect what was not tested and compare the implementation with the original request.

For changes with material security or data impact, I would also want the trust boundaries spelled out: which identities can trigger the behavior, which systems receive data, and what happens on failure. An agent’s summary is a starting point for that inspection, not proof that those boundaries hold.

In my note on DeepSeek Superagent, I looked at what turns an incoming message into authorized work. Octoverse points to the other end of the process: once a change arrives, someone must still decide whether the evidence is sufficient to accept it.

More generated code can make software development faster. The benefit depends on keeping the decision to merge understandable.

Sources

• GitHub Octoverse 2026: commits, pushes and agent-assisted development.
• Git project: distributed version control.
• Thumbnail: Git logo by Jason Long, CC BY 3.0. The Git mark identifies the version-control system; it does not indicate Git Project endorsement.

Sources reviewed on November 4, 2026. Follow jpalanco.com for more notes on AI, engineering and security research.