5-Month Build of a Custom Version Control System: Supporting 30,000 Code Merges per Day

A company built a brand-new version control system from scratch in five months and fully migrated its entire monorepo off Git. The decision was driven by an almost absurd shift in numbers: code merges surged from roughly 2,500 per day to over 30,000 within a few months.

This was not a routine infrastructure upgrade but an architectural rebuild forced by AI coding agents. When the entity writing code shifts from humans to agents, toolchains designed for human developers begin to fail across the board.

From 2,500 to 30,000: Agent Scale Overwhelms Human-Scale Tooling

According to the company's engineering blog, they were merging about 2,500 code changes per day in May; by September that number had exceeded 30,000 per day—more than a tenfold increase.

This order-of-magnitude change did not come from team growth but from AI agents participating in coding at scale. Agents commit changes far more frequently, in greater parallel, and more continuously than human developers, and traditional development infrastructure quickly became a bottleneck under this pressure.

The key issue is not that Git itself is "broken," but that it was designed with humans as the assumed users: merge cadence, conflict handling, and latency assumptions for repository operations were all built around human operating speeds. When agents commit continuously at machine speed, these assumptions collapse one by one.

"Code merge" refers to integrating changes from one branch into the mainline or another branch. In Git workflows, a merge is often accompanied by a chain of actions such as code review, CI triggers, and conflict resolution, making merge frequency an intuitive metric for development infrastructure load. A daily average of 2,500 merges corresponds to the typical scale of hundreds of developers committing at human cadence; 30,000 means a merge occurs every few seconds on average, amplifying repository lock contention, ref updates, and pipeline queuing to non-negligible levels. Understanding this magnitude difference is key to judging whether the bottleneck lies in "configuration tuning" or "architectural premises."

Why Build In-House Instead of Continuing to Optimize Git

Facing the bottleneck, the conventional approach would be to optimize existing Git workflows, add caching layers, or split repositories. But this company chose a more radical path: building its own version control system.

The implicit judgment behind this decision is that there is a fundamental mismatch between Git's architecture and agent-scale workloads, and that local optimizations cannot solve it. The original article does not elaborate on the specific technical bottlenecks, but the phrasing "built for humans rather than agent scale" suggests the problem lies at the level of design premises, not configuration.

Another notable detail is the scope of migration: the entire monorepo was fully moved off Git. A monorepo typically holds nearly all of a company's code and history, so migrating it means handling massive historical data, all toolchain integrations, and workflow switches for every developer.

A monorepo means managing multiple projects, services, or even all code in a single version repository. It brings benefits like unified cross-project dependencies, atomic refactoring, and a unified toolchain, but it also concentrates the performance, reliability, and migration costs of the version control system into a single point. Migrating a mature monorepo is not just copying commit history; it involves hooks, permission models, CI trigger rules, code search indexes, and synchronized switches of developers' local workflows. If the new system degrades in merge throughput or history queries, the impact covers all engineers—which is why such migrations are usually considered high-risk projects.

Completing the Build and Full Migration in Five Months

From decision to rollout, the entire process took only five months, comprising two phases: building the new version control system and fully migrating the monorepo off Git.

This timeframe deserves separate mention. Building a version control system is itself a heavyweight engineering effort, and fully migrating a monorepo is typically viewed as a high-risk, long-cycle project. Completing both in five months suggests the team made clear trade-offs in scope control—and possibly that the pressure of agent scale forced them to move at extremely high speed.

The original article does not disclose the new system's specific architecture, storage model, or compatibility strategy with Git, so it is impossible to judge whether its technical approach is a completely new design or a deep modification of Git. This is the biggest gap in the currently available information about this case.

CI/CD (continuous integration/continuous delivery) pipelines are typically triggered by code merge events: each merge spins up build, test, and deployment tasks. When merge frequency jumps from thousands to tens of thousands per day, pipeline concurrency scheduling, build cache hit rates, and test resource allocation all come under pressure comparable to that on the version control system. Therefore, even if the new version control system solves merge throughput, downstream CI orchestration and test execution may become new bottlenecks. This case suggests that the load brought by agent scale is end-to-end, and any single-point optimization must be evaluated within the entire toolchain.

Implications for Development Infrastructure

The value of this case is not that "another company built its own infrastructure," but that it reveals a spreading trend: AI agents are changing the user model of development tools.

When the entity submitting code shifts from humans to agents, a series of infrastructure assumptions need to be re-examined—not just version control, but also CI/CD pipelines, code review processes, and test resource scheduling. This company's tenfold increase in merges is an early signal, and similar pressure may emerge in more teams that heavily use AI coding.

For most teams, building a custom version control system is not realistic, but this case raises a more practical question: which parts of the existing toolchain have assumptions that are being quietly broken by agent scale? Identifying these bottlenecks is more valuable than copying radical solutions.

One-line Summary

AI agents drove a tenfold increase in daily merges, forcing a company to build a custom version control system and migrate its monorepo in five months.

Paragraph Summary

A company built a new version control system from scratch in five months and fully migrated its entire monorepo off Git. The decision was driven by code merges surging from roughly 2,500 per day to over 30,000 within a few months—more than a tenfold increase—due to AI coding agents participating in coding at scale. The article notes that Git's merge cadence, conflict handling, and latency assumptions are all built around human operating speeds and fail one by one at agent scale, leading the company to judge this as an architectural mismatch and choose to build in-house rather than optimize existing Git workflows. The build plus full migration was completed in only five months, but the original article does not disclose the new system's architecture or compatibility strategy. The core takeaway: when the entity submitting code shifts from humans to agents, toolchain assumptions beyond version control—CI/CD, code review, test scheduling—all need re-examination.