Re-read in the agentic era (September 2026). I first wrote this piece as a study of repository strategy. The detail that matters most now was almost a footnote then: by 2015, automated systems were already committing more changes to Google's repository each day than its 25,000 engineers were. Google met an early version of the Absorption Gap and answered it by building verification, ownership and governed automation into the way code lands. With Google now reporting that around three-quarters of its new code is AI-generated and engineer-approved, that absorption system is the part of the story worth studying. The original analysis follows, updated and corrected against the primary source.
In short: Google keeps most of its code in one repository, used by 95% of its developers and holding around two billion lines of code as of 2015. The model works because Google built a system around it: owned directories, trunk-based development, presubmit checks, owner review, continuous testing and governed large-scale refactoring. That system was already absorbing more automated commits than human ones a decade ago.
Why does a repository model deserve a CTO's attention?
For an organisation whose source code is one of its main assets, the repository model is a strategic choice. It shapes how teams share code, how change propagates, and what it costs to keep a large codebase healthy over time.
Google made its choice early and has held it for well over a decade and a half, through growth that would have broken most set-ups. Three questions are worth asking of that decision. What did Google choose, and why? And what organisation did it have to build to make the choice hold?
The answers here draw mainly on the account Google engineers Rachel Potvin and Josh Levenberg published in Communications of the ACM in 2016, which remains the most complete public description.
How big is Google's monorepo?
Google, like any company, started with a few lines of code in a conventional tool. The codebase lived in CVS, moved to Perforce, and eventually outgrew anything commercially available, so Google built its own version-control system, Piper. The early engineers argued hard for a single, centralised repository. Nobody set out to build one of the largest codebases in the world.
The January 2015 figures reported by Potvin and Levenberg are still the reference point, because Google has published little comparable data since.
Files — ~1 billion (including configuration, documentation and deleted files)
Unique source files — ~9 million
Lines of code — ~2 billion
Storage — 86 TB
Commits in history — ~35 million
Changes per workday — ~16,000 by engineers, ~24,000 by automated systems
Developers using it — 25,000+, about 95% of Google's software developers
Figure 2. Google repository statistics, January 2015. Source: Potvin and Levenberg, 2016.
The repository is not the whole of Google. Chrome and Android are the notable exceptions, developed in separate repositories. For scale, the Linux kernel at the time held roughly 15 million lines of code across some 40,000 files.
Where did the growth actually come from?
Like New York, Google's monorepo never sleeps. In a typical week of 2015, around 15 million lines of code across 250,000 files changed. Piper served billions of file reads a day, peaking near 800,000 queries per second and averaging about 500,000 across a workday.
Figure 3. Human committers per week. Source: Potvin and Levenberg, 2016.
Figure 4. The repository's cumulative growth. Source: Potvin and Levenberg, 2016.
Human activity grew steadily. The steeper curve belonged to automation. Of the roughly 40,000 changes committed on a typical workday, about 24,000 came from automated systems. By 2015, the machines were already out-committing the people.
When I first wrote this, I reassured readers that we were not yet talking about automatically generated functional code. That qualifier has aged. The volume problem Google solved for its bots in 2015 is the one every engineering organisation now faces with agents.
Figure 1. Automated systems supplied most of the change entering Google's repository by 2015. Source: Potvin and Levenberg, 2016.
What system makes a repository this size workable?
The classic objections to a monorepo are practical. The repository takes too long to download. Files are hard to find. Modularity erodes, dependencies tangle into cycles, builds become hard to orchestrate, and testing slows as all of that compounds.
Google answered each objection with tooling, but the tooling rests on something cultural. A single codebase, shared by default and visible across teams, only works in an organisation that values sharing and cross-team visibility. Google's always has.
Piper is the storage layer: a distributed system running on Google's own infrastructure that holds the 86 TB and serves the request volumes above. Access is open to every engineer by default and every action is logged. A small number of sensitive files are restricted by exception.
Figure 5. Piper's change workflow. Source: Potvin and Levenberg, 2016.
Developers rarely deal with Piper directly. Clients in the Cloud (CitC) presents each workspace as a directory overlaid on the full repository and stores only the files a developer has modified, so the average workspace holds fewer than ten files and nobody clones two billion lines. CodeSearch handles navigation and simple edits across the whole codebase, with plugins bringing the same view into editors such as Eclipse and Emacs. Blaze, the build system later open-sourced as Bazel, turns the tree into reproducible builds.
Storage, workspace, discovery and build each remove one of the classic objections. None of them decides how the code should be organised.
How is the code organised?
The repository model does not settle architecture, whether it is mono or multi. Google organises its monorepo as a tree of directories, each with named owners accountable for what lands there.
Standards for modularisation, interfaces and services govern how components talk to one another, covering naming, versioning, protocols by use case and error handling. Upstream, API documentation practices and static analysis keep dependencies deliberate. Downstream, tooling analyses dependencies across the whole tree, so a cross-cutting impact can be assessed before a change lands.
A single source of truth also removes the diamond dependency problem, where two libraries depend on incompatible versions of a third. With one version of everything at head, there is nothing to reconcile.
Figure 6. The diamond dependency problem. Source: Potvin and Levenberg, 2016.
Why does Google use trunk-based development?
The branching model has to fit the repository. Google runs trunk-based development at scale: almost all work is committed to a single mainline, and development branches are rare and deliberately poorly supported.
That model goes with a culture of small, frequent commits and early verification, and it spares teams the merge pain of reconciling long-lived branches. Release branches exist, cut from a specific revision, with fixes made on mainline and cherry-picked across. Rollout risk is handled with feature flags and experiments, so the mainline is never held up for a release.
Figure 7. Google's release branching model. Source: Potvin and Levenberg, 2016.
Trunk-based development at this volume only holds if every change is checked before and after it lands. That is where Google invested most heavily.
How does a change get absorbed?
Every change carries a description of what it does and passes through a sequence of gates.
Automated presubmit checks run first, alongside Tricorder, Google's static analysis platform, which surfaces findings and suggested fixes directly in review. The checks combine company-wide rules with repository-specific ones, giving authors fast feedback wherever and whenever they work. Refined over years, they run targeted tests on the components a change actually touches, which delivers much of the safety of a development branch without the branch.
Review follows in Critique, Google's code review tool. The change is discussed, reworked if needed, and must be approved by an owner of the directory it modifies. That approval triggers the commit.
After commit, TAP, Google's test automation platform, keeps testing the mainline. A change that causes widespread breakage is rolled back automatically, so one bad commit cannot stall thousands of engineers. Picture that running at hundreds of commits an hour.
This is the part of the model I would now put at the centre. Presubmit, owner approval and automatic rollback together form an absorption pipeline: the capacity to verify, integrate and govern change as fast as it arrives.
How does Google refactor a codebase that never sleeps?
Refactoring a codebase of this size is like reworking a city while people are living in it. Rosie is Google's answer.
Rosie lets an engineer propose a change across the entire repository, then splits it into smaller changes routed to the owners of each affected directory. Each fragment is reviewed, built and tested on its own. Automation takes on the riskiest, most time-consuming and least rewarding parts of large-scale change.
The detail that stands out is governance. Large Rosie changes go through a review process that weighs the effort they will impose on owners against the impact on the repository and the value they create. Once that process was introduced in 2013, the volume of Rosie commits came down and levelled off. Google had found that the scarce resource in automated change is the human attention needed to accept it.
Figure 8. Rosie commits per month. Source: Potvin and Levenberg, 2016.
A dedicated team also keeps the compiler toolchain current across the whole codebase, another cost that a monorepo makes visible and shared.
What does Google gain, and what does it pay?
The structural benefits are consistent across Google's own account. One source of truth with unified versioning. Extensive code sharing and reuse, and simpler dependency management. Atomic changes across projects, and the ability to make large structural changes safely. Easy collaboration, flexible ownership, and visibility of the whole codebase.
For engineers, the practical result is the absence of familiar pain: no endless checkouts, no archaeology to assess an impact, no fear of cross-cutting refactoring. The ecosystem supports a speed of change and a breadth of collaboration that few organisations match.
The costs are just as clear, and Google groups them in three. The size and complexity of the codebase make it harder to understand, search and maintain. Tooling needs sustained investment across the chain, from repository to build, test and deployment. And code health, from documentation to dependencies to refactoring, demands continuous effort.
Two difficulties persist. Visibility cuts both ways, because engineers can read, and come to depend on, the implementation details behind an API; Google treats that as a trade-off to manage through culture and tooling, keeping the codebase open. Open-source code is the second: integrating external components into a single versioned tree takes a dedicated space in the repository and careful handling.
Will Google move to a multi-repo model?
Google engineers have asked the question repeatedly, usually through the lens of Git. Android, Chrome and Google's major open-source projects already work with Git across many repositories, and wider use of Git would bring Google closer to the external developer community.
Git's distributed model is built around many repositories. Moving the monorepo onto it would mean splitting the codebase into thousands of repositories, which runs against everything Google's organisation is built around. Each time the question has come up, the answer has stayed the same. By 2016, Google was instead working with the Mercurial community to support more flexible, distributed-style workflows on top of the monorepo.
What does Google's model teach in the agentic era?
The original lesson still stands. Google's monorepo strategy supported its performance because it was aligned with the company's organisation, culture and processes. Naming the trade-offs and investing to reduce them is what turned a repository decision into a durable capability. Adopting a monorepo will not make anyone the next Google; the whole system does the work.
Read in 2026, a second lesson stands out. Google now reports that around 75% of its new code is AI-generated and then approved by engineers, up from about a quarter in October 2024. Its engineers have also published their experience of using LLMs for internal code migrations, where most of the code in landed changes was AI-authored and, once generation was cheap, review became the limiting step.
That volume is only absorbable because of the machinery described above. Ownership tells a machine-generated change where accountability sits. Presubmit checks and automatic rollback give it fast verification. Rosie's review process is governance for automated change, pricing the human review a change will consume against the value it creates, which is close to what I call validated business value per unit of human intervention, applied a decade early. As automation grew, Google's bottleneck kept moving, from storage and checkout to search, to build and test, to review, to governance. That is Constraint Migration, and Google built for it one stage at a time.
This is the Absorption Gap seen from the other side: an organisation that designed its absorption capacity to grow with machine supply. In the terms of the AI Engineering Production System, Google's advantage sits in the Verify & Govern stage and in the ownership model that cuts across the whole lifecycle. Most organisations deploying agents today are still investing at the Build stage.
The question worth taking into your next architecture review
If agents tripled your change volume next quarter, which part of your system would decide how much of it you could safely accept: your repository, your review model, your test infrastructure, or your governance?
FAQ
Does Google really keep all its code in one repository? Google keeps the vast majority of its code in a single repository, called Piper, used by about 95% of its software developers. As of January 2015 it held around two billion lines of code, 86 TB of data and roughly 35 million commits. Chrome and Android are the main exceptions, developed in separate Git-based repositories.
Does a monorepo mean a monolithic architecture? A monorepo is a source-management choice; it does not dictate how software is deployed. Google builds a very large number of services and binaries from its single repository. What keeps that architecture coherent is directory ownership, interface standards and dependency tooling, all of which a multi-repo organisation needs too.
Should my organisation adopt a monorepo like Google's? Google's monorepo works because of the system around it: owned directories, trunk-based development, presubmit checks, mandatory owner review, continuous testing with automatic rollback, and governed large-scale refactoring. Copying the repository model without that investment imports the costs without the benefits. The more useful question is whether your organisation's culture and tooling support shared code and cross-team change at the volume you expect.
What does Google's monorepo have to do with AI coding agents? By 2015, automated systems already committed more changes to Google's repository each day than its engineers did, so Google had to solve the absorption of machine-generated change early. The same machinery, ownership, fast verification and governed review, is what now lets Google accept AI-generated code at scale. In the AI Engineering Production System, that capability sits in the Verify & Govern stage, which is where most organisations deploying agents are under-invested.