Monorepo vs multi-repo for agentic development: what changes when AI writes the code

The monorepo vs multi-repo question has been argued for years. TypeScript teams land on monorepos. Microservice teams often split by service boundary. The arguments are familiar: monorepos simplify atomic changes and dependency management; multi-repo setups give cleaner ownership and independent deploy cycles.

What changes when AI coding agents write most of the code? The practical impact of repo structure on agentic development is different enough from human-authored development that it is worth treating separately.

Why the classic arguments still apply (mostly)

The usual reasons to pick a monorepo or multi-repo setup have not disappeared:

• Monorepo advantages: a single place for cross-cutting changes, shared linting and test configuration, atomic commits across service boundaries, and dependency resolution without version-pinning headaches. Atomic changes matter especially when a UI change and an API change need to ship together - in a monorepo that is one commit.
• Multi-repo advantages: clear ownership boundaries, independent versioning and deploy cadences, smaller surface area per contributor, and less noise from changes in unrelated services. For teams with distinct team boundaries, multi-repo often maps cleanly to how the organization is structured.

None of this disappears when agents write the code. What shifts is how the costs and benefits distribute.

Where monorepos pull ahead for agents

Context is contiguous

A Claude Code agent's context window covers what it can read: file contents, grep results, the repo structure it walks. In a monorepo, the agent can see shared types, API contracts, and both UI and service code in one working directory. It can trace a data type from the database schema through the API layer into the frontend component in a single session without hitting a repo boundary.

In a multi-repo setup, an agent working in the frontend repo does not see the backend repo at all unless you pass it the content explicitly. That means copying in relevant files, or trusting the agent to infer contracts it cannot verify. The agent can write to an interface without seeing the implementation it calls. This is a real problem in practice. Founders running parallel agents across multi-repo setups consistently report the same pattern: changes that look clean in isolation produce integration issues because the agent cannot see across the boundary.

Cross-cutting changes are atomic

When an agent refactors a shared data model, a monorepo lets it update all callers in the same commit. In a multi-repo setup, the same change requires PRs across multiple repos, coordinated merges, and version bumps - work that has to be orchestrated either by the developer or by an agent managing multiple repo checkouts simultaneously, which is harder to set up and harder to review.

Test coverage is unified

Integration tests that span service boundaries live in the monorepo and run against the whole system. An agent that breaks an interface catches it in CI before a PR is opened. In a multi-repo setup, the same breakage may only appear at deploy time.

Where multi-repo setups still hold up

Not every codebase can or should be a monorepo. The genuine cases for multi-repo remain:

• Stable, versioned contracts. A public API that external partners depend on, where the contract is versioned and pinned, genuinely benefits from a separate repo. The agent works within the surface of that repo, not spanning multiple services with tight coupling.
• Team boundaries that match the repo split. When the team owning the frontend has no business touching the backend, the repo boundary is doing useful access-control work. Agents working within that boundary follow the same constraint.
• Legacy setups you cannot migrate. The practical constraint for many teams is inherited repo structure. Migrating 400k lines across six repos is a separate project with its own risk. Agents can work in multi-repo setups; the coordination overhead is higher, not insurmountable.

The coordination problem both structures share

Even in a monorepo, parallel agents create a coordination problem that repo structure alone cannot solve.

Three agents working in parallel, all in the same monorepo, each in its own worktree: agent A is refactoring the auth layer; agent B is adding a new API endpoint that calls the auth layer; agent C is updating the frontend to call that new endpoint. All three branches look clean in isolation. At merge time, A's refactor conflicts with B's call patterns, and C's endpoint calls do not match the shape B shipped.

The monorepo did not cause this. The coordination failure is at the decision layer - shared interfaces that were not settled before agents fanned out. The same problem surfaces in a multi-repo setup, just earlier and more visibly, because the repo boundary makes the dependency explicit rather than implicit.

The fix is not a repo strategy. It is a process question: settling the shape of shared interfaces before parallel agents start implementing against them. See keeping context consistent across parallel AI agents for the specific patterns that hold up in practice.

Practical recommendations

Starting a new project

Default to a monorepo. The contiguous context window is a real and consistent advantage. An agent that can trace from schema to API to UI catches more integration errors before they become bugs. The tooling (turborepo, nx, cargo workspaces) is mature, and setup cost is low relative to the coordination gain.

Already in a multi-repo setup

Accept the overhead and build coordination patterns around it: pass relevant contract files to agents working on dependent services; run cross-repo integration tests before merging; treat each repo boundary as an interface that needs to be spec'd and pinned before agents touch either side.

Considering a migration

The cost-benefit calculation shifts when agents write most of the code. A migration that would have taken six months of human effort might complete in a few agent-weeks. The monorepo dividend compounds faster when agents can automate the mechanical move work. This is worth pricing differently than it was two years ago.

The process layer above repo structure

The biggest finding from watching teams run parallel agents across both monorepo and multi-repo setups: the coordination problems that matter most do not live at the filesystem layer. They live at the decision layer - shared interfaces, architecture choices, data model decisions - and they surface regardless of repo structure when agents work in parallel without shared context for those decisions. See which agentic coding patterns actually scale for a broader look at what holds up as agent count grows, and git worktrees vs branches for parallel AI agents for the lower-level isolation question.

defract approaches this from the process side: settling design and architecture decisions in a shared stage before implementation fans out, so agents have explicit specs to work against rather than informal context scattered across sessions. It runs on monorepos and multi-repo setups alike, because the problem it addresses is not about filesystem layout. The repo strategy is the right foundation. The process layer on top of it is what determines whether parallel agents produce a codebase that coheres.