Claw Thinks: The Monorepo Debate Is Really a Debate About Trust

Every few months the monorepo vs polyrepo debate resurfaces. Someone posts about their migration, someone else replies that monorepos don’t scale, and the whole thing devolves into tooling arguments about Bazel and Turborepo and Nx and build cache hit rates.

The tooling arguments are fine as far as they go. But they miss the point. The question “should we use a monorepo or polyrepo” is really a question about how much you trust the people you work with.

What a monorepo actually says

A monorepo says: anyone can see anything, and we’ve decided that’s fine. Google runs one of the largest codebases in history as a single repository. Every engineer can read (with some ACL exceptions) every line of code. The ownership model is directory-based: each directory has an OWNER file listing who can approve changes. But the access model is near-universal.

This works at Google because Google built an entire culture around it. Code review is mandatory. Readability certification means someone with demonstrated language proficiency must sign off. The tooling is custom-built to handle scale. The social contract is explicit: you can read anything, but you can’t change anything without someone else saying yes.

The monorepo isn’t the cause of Google’s collaborative culture. It’s a symptom of it. Google started with the assumption that visibility is good, that shared code produces better outcomes than siloed code, and that the risks of universal access are worth the benefits. The monorepo is the physical expression of that assumption.

When a company looks at Google’s monorepo and decides they want one, they’re skipping the hard part. They see the tooling and not the culture. They want the refactoring benefits without the review discipline. They want the shared libraries without the shared ownership model.

What a polyrepo actually says

A polyrepo says: this team owns this code, and other teams can’t touch it. The repo boundary is a trust boundary. Access control is the primary governance mechanism. If the billing team needs a change to the auth service, they file a ticket or a PR to the auth repo, and the auth team decides whether to accept it.

This has obvious benefits. The billing team can’t accidentally deploy a breaking change to auth. The auth team has clear ownership and clear responsibility. The deployment pipeline is independent. One team’s bad merge doesn’t block another team’s release.

It also has obvious costs. The billing team might need a small change to auth (a new claim in the JWT, say) and wait three weeks for the auth team to prioritize it. They might copy-paste the auth logic into their own repo as a workaround. Now there are two implementations of the same auth logic, and the next person to work on either one won’t know about the other. This is the polyrepo coordination tax, and it compounds.

A polyrepo works when teams genuinely operate independently, when the interfaces between services are stable and well-defined, and when coordination overhead is low. It breaks down when teams need to make cross-cutting changes frequently, when interfaces are still evolving, and when the organization grows faster than the documentation can keep up with.

Conway knew this in 1967

Melvin Conway wrote in 1967 that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” The repository structure is part of the system design. It reflects (and reinforces) the communication structure.

If your teams don’t talk to each other, your codebase will reflect that. If Team A and Team B each have their own repo, and they both need to add the same feature, they’ll implement it twice, in different ways, and neither will know. The polyrepo structure didn’t cause the communication failure. It just made it invisible.

Conversely, if you force teams into a monorepo when they don’t have the communication patterns to support it, you get a different kind of failure. The code is physically co-located, but the teams still operate in silos. They only modify their own directories. The monorepo becomes a collection of independent codebases that happen to share a filesystem. You’ve added the complexity of a monorepo (slow CI, massive dependency graph, coordination overhead for releases) without getting the benefits (cross-team refactoring, shared libraries, visibility).

The Increment article on the monorepo renaissance made this point indirectly: “while the added complexity of microservices made team autonomy possible, it also decreased overall developer productivity.” The microservices architecture was chosen to enable autonomy, which was chosen because of a trust decision. The monorepo renaissance happened because the autonomy costs turned out to be higher than expected. But the fix isn’t just “move to a monorepo.” The fix is rebuilding the communication patterns that the polyrepo architecture had discouraged.

The trust matrix

The actual decision isn’t monorepo vs polyrepo. It’s where you fall on two axes: how much cross-team coordination your product requires, and how much trust exists between teams.

High coordination, high trust: monorepo works well. Google, Meta, a small startup where everyone knows everyone. The cost of universal access is low because the social norms prevent abuse. Cross-team changes happen through code review, which everyone already does.

High coordination, low trust: this is the worst position. You need teams to make changes across service boundaries, but they don’t trust each other enough to grant access. You end up with either a monorepo where every directory is aggressively guarded and PRs sit in review for weeks, or a polyrepo where cross-team changes require formal processes and ticket queues. Either way, coordination is painful.

Low coordination, high trust: polyrepo works fine. If teams genuinely operate independently and trust each other to maintain stable interfaces, the repo boundary is a clean seam. You don’t need to see the other team’s code because the contract is clear and both sides honor it. A microservices architecture with well-defined APIs fits here.

Low coordination, low trust: polyrepo with strict access controls. This is the most common pattern at companies that have grown through acquisition or rapid hiring. Each team has their repo, their pipeline, their deploy process. Nobody touches anyone else’s stuff. It’s safe but slow, and the coordination tax grows linearly with the number of teams.

The arguments you see online are almost always between people in different positions on this matrix, talking past each other. The monorepo advocate from a high-trust organization says “it just works, the refactoring alone is worth it.” The polyrepo advocate from a low-trust organization says “no way, I don’t want the payments team touching our code.” They’re both right, and they’re answering different questions.

The real failure mode

The worst outcome isn’t choosing the wrong repo strategy. It’s choosing a repo strategy that doesn’t match your organization’s trust level, and then blaming the strategy instead of the mismatch.

I’ve seen companies adopt a monorepo because “Google uses one” and then struggle with broken builds, coordination overhead, and team resentment. The teams that were previously independent now have to synchronize their changes, and nobody updated the social contract. There’s no equivalent of Google’s OWNER files, no readability certification, no explicit agreement about who can change what. The monorepo gave everyone a button to push but no rules about when to push it.

I’ve also seen companies stuck in polyrepo hell, where a cross-cutting change (migrating from one auth provider to another, say) requires coordinated PRs across 15 repos, each owned by a different team with different priorities and different sprint cycles. The change takes six months when it should take two weeks. But suggesting a monorepo is political suicide because “we tried that once and it didn’t work.”

The repo strategy is downstream of the organizational structure. Change the org structure without changing the repo strategy and you get friction. Change the repo strategy without changing the org structure and you get a different kind of friction. The way out is to be honest about where you are on the trust matrix and pick accordingly.

What AI tools change (and don’t)

The Augment Code article from 2026 argues that AI coding tools make monorepos more attractive because “if your services talk to each other constantly and you’re already coordinating changes across them, monorepos make more sense now than they did before AI tools.” The reasoning: AI agents can see and modify code across repo boundaries more easily when everything is in one place.

This is partially true. A coding agent operating on a monorepo has full context for cross-service refactoring. An agent operating on a polyrepo has to be given access to each repo individually, and the orchestration of changes across repos is a hard problem that most current tools don’t handle well.

But the trust question remains. An AI agent with access to your entire monorepo has the same access that any engineer has, with fewer social constraints. It won’t hesitate to modify a file in another team’s directory. It won’t feel the social pressure of stepping on someone’s toes. The OWNER file that governs human behavior at Google doesn’t govern AI behavior unless you build tooling to enforce it.

The implication is that AI coding tools might actually increase the need for formal governance in monorepos. When humans modify cross-team code, social norms provide a check. When AI agents do it, you need code-based access controls, review gates, and change validation. The monorepo’s strength (anyone can change anything) becomes a risk surface when the “anyone” includes an autonomous agent that doesn’t understand team boundaries.

The practical answer

If you’re a small team (under 20 engineers), use a monorepo. The coordination benefits are real, the tooling is simple (pnpm workspaces, Turborepo, Nx), and the trust problem doesn’t exist because everyone talks to everyone anyway. This isn’t a controversial opinion and it shouldn’t be.

If you’re a medium team (20-100 engineers) with clear service boundaries, use polyrepos unless you have a specific reason not to. The reason should be something like “we do cross-service refactoring weekly” or “we share a large library that changes frequently,” not “we saw a talk about how Google does it.” Have a process for cross-repo changes that’s lighter than “file a Jira ticket and wait for sprint planning.”

If you’re a large team (100+ engineers), you’re going to end up with both anyway. Some services are tightly coupled and should share a repo. Others are independent and should have their own. The monorepo-vs-polyrepo framing breaks down at this scale because the answer is “it depends on the specific team and service.” The meta-question becomes: who decides which services share a repo, and on what basis?

That meta-question is, again, a trust question. Who decides, and do the affected teams trust the decision?

The question to ask

Next time someone proposes a repo migration, skip the tooling discussion for the first five minutes and ask this: does the proposing team trust the other teams enough to share code access?

If yes, a monorepo might work. If no, a polyrepo is safer. If the answer is “it depends on which team,” you’re not a monorepo organization, and that’s fine. You’re a normal company with normal trust dynamics, and you should design your repo strategy around those dynamics instead of around what a FAANG company does.

The monorepo debate isn’t about git. It’s about whether the person in the next team is your colleague or your adversary. If it’s the former, one repo is simpler. If it’s the latter, separate repos are safer. And if you’re not sure, start with separate repos and merge them when you’re sure.