AI coding agents do not only change the editor. They change the amount of work a code host has to absorb. An agent that opens branches, proposes edits and retries a failing change can generate repository activity far faster than a team of people typing. GitHub is rebuilding the storage underneath Git so that growth does not break the workflow developers already know.
For a UK software team, the headline is easy to skip. Storage architecture sounds like GitHub's problem. It becomes the team's problem when pushes slow down, when continuous integration queues behind a flood of automated commits, or when an agent's pull requests arrive faster than anyone can review them. Faster infrastructure does not review the code.
The scale The Register described
The Register reported on 9 October 2026 that GitHub is rewriting its storage to cope with what it called agentic demand, and that GitHub's internal tests showed up to a 35-fold improvement in write performance with the redesigned system. The same reporting put a figure on the traffic. Between September 2025 and August 2026, GitHub events rose from 218.2 billion a month to 473.3 billion. The outlet also reported 7.38 billion commits in September 2026, five times the figure from September 2025.
Those numbers describe GitHub's platform, not a typical company repository. They still explain the redesign. As more coding agents create branches, submit changes and run automated development workflows, the host has to serve many more reads and writes at once. Coverage of the storage rewrite and reporting on the infrastructure rebuild tell the same story: the old design is being replaced because agent-scale activity exposed it.
What is changing in the design
The Register described GitHub's older storage as relying on multiple repository replicas and a quorum process to confirm each write. In the new design, writes go to Azure Blob Storage, which handles replication, while read requests are served separately. Maintenance such as compaction and garbage collection moves into background processes. The aim is to take those bottlenecks off the path of a normal push, without asking developers to learn a new way to use GitHub.
That split matters. Write-heavy agent traffic and read-heavy human traffic were sharing a design built for a different mix. Moving replication to the blob store, and moving housekeeping off the critical path, is an infrastructure answer to a workload problem. It does not change what a commit means, and it does not decide whether a change is safe to merge. Teams should treat the performance claim as GitHub's test result, and still watch their own pipelines. A 35-fold figure from an internal test is not a promise that every monorepo will feel 35 times faster on a Tuesday afternoon.
What software teams still have to do
Faster storage helps large teams and busy continuous-integration pipelines absorb more repository activity. It is one part of working with coding agents. The rest is unchanged, and it gets more important when changes arrive in volume.
- A person still reviews what an agent proposes, especially on code that handles money, personal data or access control.
- Automated tests have to fail the build when the change is wrong, because nobody can read every line of a busy week.
- Agents need their own permissions. A token that can push to every repository is an incident waiting for a bad prompt.
- Releases stay deliberate. Generating a change quickly is not a reason to deploy it quickly.
UK teams already know this pattern from busy human contributors. Agents compress it. A repository that accepted ten pull requests a day may see far more once an agent is pointed at a backlog. Review rules, required checks and branch protection are the controls that keep that volume from becoming unreviewed production code. Node.js 26 is a separate runtime change landing in the same year, and it is a reminder that platform upgrades and tool upgrades now arrive together. Neither replaces a staging test.
The demand spreads past the editor
The wider lesson is that AI adoption is not only a coding-tool decision. It changes demand on source control, build systems, test environments and cloud capacity. An agent that runs a suite on every branch will spend money and queue time even when the storage layer is healthy. Engineering leads should ask whether their development platform can take more concurrency and still stay reliable, and whether the cloud bill and the review rota can take it too. AI infrastructure spending is the same story one level down: the model is the visible part, and the systems under it have to grow with it.
Security sits in that list. An agent with a GitHub token is an identity. Excessive permissions, a secret left in a repository, or a workflow that deploys from an unreviewed branch are familiar failures. They get cheaper to trigger when the agent can open the pull request itself. Access control is part of the development platform, not a later hardening project.
Plan the platform with the coding tool
GitHub's rebuild is a sign that code hosts are treating agent traffic as the new normal. UK teams can take the performance work as GitHub's job, and take review, tests and permissions as their own. Software development that includes agents still needs a pipeline you trust. Cloud hosting and delivery need enough room for the extra builds those agents will start.
Web Works Rise is a UK-led team in Birmingham, with a development hub in Tunisia that adds delivery capacity. The stack on client work includes Next.js, React and TypeScript, with the checks that keep a change from skipping review. If an agent is about to join that pipeline, talk to the team about where it may commit, what must pass before merge, and who is accountable for the result.