Version Control Under Agent Load: One Problem, Two Answers
The shared premise. Both pieces start from the same observation: AI agents have changed the shape of demand on Git hosting. GitHub’s CTO Vlad Fedorov writes that agentic development workflows accelerated sharply beginning in the second half of December 2025, with repository creation, pull request activity, API usage, automation, and large-repository workloads all climbing quickly. Thomas Dohmke, writing at Entire in July 2026, frames the same shift from the other end — the question is no longer whether Git survives, but how Git hosting gets expanded and rewired for a world where agents are the primary producers of code.
What the load actually looks like. A single pull request reaches into Git storage, mergeability checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases — so growth doesn’t stress one system at a time. At scale, minor inefficiencies compound: queues lengthen, cache misses turn into database load, indexes lag, retries amplify traffic, and a single slow dependency degrades several product surfaces. GitHub began a 10x capacity program in October 2025 and concluded by February 2026 that it needed to design for roughly 30x current scale.
The incumbent’s answer: harden and scale the center. GitHub’s stated ordering is availability first, then capacity, then new features. Concretely: webhooks moved off MySQL, session caching redesigned, auth flows reworked to cut database load, and extra compute stood up via the Azure migration; then isolating Git and Actions from other workloads, shrinking blast radius, and accelerating the move of scale-sensitive code out of the Ruby monolith into Go. Longer term, a path toward multi-cloud for resilience, latency, and flexibility, plus heavy investment in monorepo handling and merge queue efficiency, which matters for repos seeing thousands of pull requests a day.
Two April 2026 incidents illustrate the gap between plan and present state. On April 23, squash merges through the merge queue produced incorrect merge commits when a group contained more than one pull request, reverting earlier changes across 658 repositories and 2,092 pull requests — no data lost, but affected default branches left in a wrong state. On April 27, an Elasticsearch cluster became overloaded, likely from a botnet attack, and stopped returning results; Git operations and APIs were unaffected, but search-dependent parts of the UI went blank. That subsystem had not yet been isolated as a single point of failure because other risks ranked higher in the prioritized work.
The challenger’s answer: distribute the center away. Dohmke’s argument is that centralization is the root condition, not a tuning problem. Git was designed to be decentralized — every clone holds the full repository and history — yet hosting platforms funneled developers into centralized systems, which worked until agents arrived. With large fleets of agents coding in parallel, routing everything through central platforms produces rate limiting, outages, slower agents, and a constrained development lifecycle; repositories should instead live in as many places as possible, giving higher availability plus local, scalable access patterns for agents to query and synchronize against. A side benefit is sovereignty: in-region data residency while still participating in a globally distributed network.
Entire adds a second claim GitHub’s post doesn’t address at all: what gets versioned. The hypothesis is that session logs — prompts, tool calls, checkpoints, decisions — are now the most important artifact in software development and belong in the repository beside the code. That semantic memory layer keeps agents from repeating mistakes, improving accuracy and cutting token spend, while giving humans a provenance trail that shortens review.
Where they converge and diverge. Both accept that Git remains the source of truth and that availability is now the binding constraint on agentic development. Both arrive at geographic and infrastructural spread — GitHub via multi-cloud, Entire via a distributed network of many hosts. They diverge on whether resilience is achievable inside one platform’s boundary. GitHub treats blast-radius reduction as an internal architecture problem with a prioritized queue; Entire treats single-location storage as the flaw itself. Read together, GitHub’s April incidents are the empirical case for Entire’s thesis — and it’s worth noting Dohmke ran GitHub as CEO until 2025, so the critique comes from inside the same lineage.