The monorepo was supposed to solve everything. One repository, one source of truth, atomic changes across services, simplified dependency management. Google built their entire engineering culture around it. Meta followed. Microsoft invested billions in tooling to make it work.
Now it's collapsing.
Not because the theory was wrong. Not because the tooling failed to evolve. But because the assumptions that made monorepos valuable in 2010 are dead in 2026. AI agents don't need shared code. They need shared context. And monorepos are terrible at that.
The Original Promise
The monorepo pitch was seductive:
One commit, all services. Change an API? Update every consumer in the same PR. No coordinating deploys across teams. No versioning hell. Atomic refactors across the entire codebase.
Shared code by default. Build a common library once, import it everywhere. No duplication. No divergent implementations. One team owns authentication, everyone uses it.
Simplified CI/CD. One build system. One set of tests. One deploy pipeline. Master stays green or the whole company knows.
This worked brilliantly when:
- Teams were co-located
- Code was the primary artifact
- Humans wrote all the code
- Build times mattered more than build clarity
- The organization owned all dependencies
None of those are true anymore.
The Cracks Started Showing in 2020
The pandemic exposed the first major flaw: monorepos assume synchronous collaboration.
When your team is in the same building, a breaking change is a tap on the shoulder. "Hey, I'm refactoring the auth library, can you update your service?" Five-minute conversation, both PRs land the same day.
Remote work turned that into:
- Slack message sent (no response for 3 hours, different timezone)
- Meeting scheduled (2 days out)
- PR blocked waiting for dependency update
- Another meeting to debug integration issues
- Six days for a change that should take one
The synchronous assumption broke. Teams started creating private forks. Shared libraries diverged. The monorepo fractured into de facto polyrepos with shared CI/CD.
But the real killer wasn't remote work. It was AI.
AI Agents Don't Share Code — They Share Context
A human engineer in a monorepo opens a file and sees:
import { validateUser } from '@company/auth-core';
They know what that does because they've seen it a hundred times. They know it throws if the token is invalid, returns null for expired sessions, caches results in Redis. Years of tribal knowledge.
An AI agent sees:
import { validateUser } from '@company/auth-core';
And has no idea what it does. It can read the source (4,000 lines in 12 files). It can read the tests (8,000 more lines). It can infer behavior from usage across 200 call sites.
Or you can tell it: "validateUser checks JWT signatures using RS256, queries the user DB for active status, caches in Redis for 5 minutes, throws AuthError on failure."
The shared code is worthless. The shared context is everything.
Monorepos optimize for code reuse. AI development optimizes for context clarity. These are opposite goals.
The Build System Became the Bottleneck
Monorepos need build orchestration. Bazel, Nx, Turborepo, Buck — billions of dollars in tooling to answer one question: "What needs to rebuild when this file changes?"
For human teams, this was valuable. A frontend engineer shouldn't trigger backend tests. A change to Service A shouldn't rebuild Service B.
For AI agents, it's poison.
An agent writing code doesn't think in build graphs. It thinks in objectives: "Add user authentication to the checkout flow." It needs to see:
- The current checkout implementation
- Available authentication patterns
- API contracts
- Deployment constraints
The build system is irrelevant. Worse, it's a cognitive load that slows the agent down. The agent can't reason about Bazel's dependency graph when it's trying to implement OAuth.
Here's what actually happens:
Human-optimized flow (monorepo):
- Engineer makes change to shared auth library
- Build system detects 47 affected targets
- CI runs 12,000 tests across 8 services
- 3 failures in unrelated services (flaky tests)
- Retry build, different failures
- Manual review of dependency graph
- Merge after 6 hours of CI
AI-optimized flow (polyrepo):
- Agent makes change to auth service
- Tests run for auth service only (250 tests, 90 seconds)
- API contract verified against schema
- Downstream services notified of schema change
- Merge in 2 minutes
The build orchestration that saved time for humans wastes time for agents.
The Dependency Hell We Created to Escape Dependency Hell
Monorepos were supposed to eliminate dependency versioning. Instead, they invented internal versioning.
Google's monorepo has 86,000 internal packages. Each one has a "version" — not a semantic version, but a commit hash that represents its stable state. Teams pin dependencies to specific commits to avoid breakage.
This is dependency hell with extra steps.
The tooling is better than npm/pip/cargo version resolution. But the cognitive overhead is identical: "Which version of the auth library is safe to upgrade to?" Except now you're reading commit logs instead of changelogs.
AI agents can't navigate this. They need explicit contracts:
service: checkout-api
dependencies:
auth-service:
version: "2.3.0"
contract: "openapi/auth-v2.yaml"
breaking_changes: "API_CHANGELOG.md"
Clear, declarative, versioned. The monorepo's implicit versioning (via commit hashes and build configs) is opaque to agents.
The Real Cost: Context Switching at Scale
Here's the thing no one talks about: monorepos force context switching.
When everything is in one repo, every change potentially affects everything. A PR to update a database schema needs review from the frontend team (could break GraphQL types), the API team (could break REST contracts), the data team (could break analytics pipelines), and security (could expose PII).
For human teams, this created a culture of shared ownership and prevented siloes. For AI teams, it's pure overhead.
An AI agent doesn't need to review your database schema change. It needs to know: "Does this break my service's contract?"
If you expose a versioned API with backward compatibility, the answer is instant. If you share a monorepo, the agent has to:
- Parse the schema change
- Trace all usages in the codebase (10,000+ files)
- Simulate potential breaking changes
- Cross-reference with test coverage
- Flag ambiguous cases for human review
This is computational waste. The polyrepo version:
curl -X POST schema-validator.api/check \
-d old_schema=auth-v2.3.yaml \
-d new_schema=auth-v2.4.yaml
# Response: {"breaking": false, "warnings": []}
Done. No context switching. No codebase scanning. Just contract validation.
The Deployment Paradox
Monorepos promised deployment simplicity: one commit, one deploy. Reality: deployment complexity scales with team size.
A 10-person startup can deploy the whole monorepo every commit. A 500-person company needs:
- Staged rollouts per service
- Feature flags per team
- Canary deployments per region
- Rollback mechanisms per deploy unit
The monorepo becomes a coordination tax. You're not deploying "one thing." You're deploying 40 services that happen to share a commit history.
AI agents don't coordinate deploys. They execute them. A monorepo deploy requires:
# Which services changed?
bazel query 'kind(".*_binary", affected(//...))'
# Which feature flags apply?
feature-flag-service config --env=production --commit=$SHA
# Which teams need notification?
deploy-coordinator notify --services=$AFFECTED
# Execute staged rollout
deploy-orchestrator --canary=5% --increments=20% --wait=300s
This is operationally complex. The polyrepo version:
git push origin main
# Service auto-deploys via CI/CD
# API contract checked at deploy time
# Rollback is git revert
The monorepo's "simplicity" disappeared the moment the team grew past 50 people.
What Killed the Monorepo: Distributed Teams + AI Agents
The monorepo worked when:
- Teams sat in the same building
- Code was written by humans
- Builds took hours (overnight CI was normal)
- Tools like Git couldn't handle polyrepos well
2026 reality:
- Teams are global. Synchronous collaboration is dead.
- Code is written by agents. Context > shared code.
- Builds take seconds. Modern CI is fast enough for polyrepos.
- Tools matured. Git submodules, meta-repos, contract testing, schema registries — the polyrepo tax disappeared.
The final nail: AI agents generate code faster than build systems can validate it.
A human writes 200 lines of code per day. A monorepo build optimizes for that pace. An AI agent writes 2,000 lines per hour. The build system becomes the bottleneck.
Monorepos optimized for human constraints. AI development has different constraints.
What Replaces the Monorepo
Not polyrepos. Not microrepos. Service-oriented repositories with contract-first development.
Each service is a repo. Each service exposes versioned contracts (OpenAPI, GraphQL schema, Protocol Buffers). Changes that break contracts are flagged before merge. Agents develop against contracts, not implementations.
The stack looks like:
1. Schema Registry
Central source of truth for all service contracts. Version-controlled, semantically versioned, machine-readable.
2. Contract Testing
Every service has contract tests that validate it implements its schema correctly. Breaking changes are detected in CI, not production.
3. Dependency Graph as Data
Instead of a build system computing dependencies, dependencies are declared explicitly:
service: checkout-api
depends_on:
- auth-service: "^2.0.0"
- payment-gateway: "~1.5.0"
- inventory-service: "^3.2.0"
4. Agent-Readable Documentation
Every service has machine-readable specs: API docs, error codes, retry policies, rate limits. Agents consume these directly.
This is what Google's monorepo would look like if it was built for AI agents instead of human engineers.
The Tooling Already Exists
You don't need to build this from scratch:
- Buf for Protocol Buffer schema management
- Apollo Federation for GraphQL contracts
- OpenAPI Specification for REST APIs
- Dependabot for dependency updates
- Renovate for automated PR creation
- Pact for contract testing
These tools were built for polyrepos. They assumed teams wanted isolation. They were right — they just underestimated how much.
What This Means for Your Team
If you're still running a monorepo in 2026:
Option 1: You're Google/Meta/Microsoft
You have 10,000+ engineers and billions invested in monorepo tooling. Keep it. Your scale demands it. But start planning the exit — AI agents will force your hand within 3 years.
Option 2: You're a <500-person company
Get out now. The monorepo is costing you velocity. Every PR is a coordination tax. Every deploy is a negotiation. AI agents can't navigate your build graph.
Migrate to service repos with contract-first development. Your agents will ship faster. Your teams will move independently. Your CI will finish in minutes, not hours.
Option 3: You're a startup
Don't even consider a monorepo. The entire pitch was about managing complexity at scale. You don't have scale yet. You have 8 services and 12 engineers. A monorepo is pure overhead.
Start with isolated repos, clear contracts, and agent-readable docs. Scale when you have real problems, not imagined ones.
The Uncomfortable Truth
The monorepo worked. For a specific era, with specific constraints, under specific assumptions.
Those assumptions are dead:
- ✗ Teams co-located → Teams distributed globally
- ✗ Code hand-written → Code generated by AI
- ✗ Builds are slow → Builds are fast
- ✗ Git struggles with scale → Git handles polyrepos fine
- ✗ Shared code is valuable → Shared context is valuable
The architecture that defined Big Tech for 15 years is collapsing under its own weight. Not because it was bad, but because the world changed.
AI agents don't need monorepos. They need clear contracts, explicit dependencies, and machine-readable context.
The faster you adapt, the faster you ship.
The monorepo is dead. Long live the service repo.
Connor Murphy is the founder of Webaroo, a venture studio replacing traditional dev teams with AI agent swarms. He's spent the last year building The Zoo — 14 specialized AI agents that handle everything from content creation to deployment orchestration. Previously scaled engineering teams at venture-backed startups and watched monorepos collapse under coordination overhead. Now he builds systems where agents ship code faster than humans can review it.
