I go back and forth on monorepos. Always have. The conversation got slightly more interesting with agent coding, but I don’t think the answer changed for anyone.
Does your agent need all that context?
Context is nice. Keeping things in one place is convenient when coding agents are poking around your codebase trying to understand how things fit together. But here’s the thing. They don’t need to poke around most of the time. And you don’t want them poking around! You want them going straight to the point.
You can clone a separate repo and tell the agent “if you have questions, go look here.” You don’t need the code for 200 shadcn components one ripgrep misfire away from bloating your context window. Shadcn is a liability! (I love shadcn. I think about it a lot. Not throwing shade, just a funny example.) One bad search pattern and suddenly your agent is trying to understand your entire component library when all you wanted was to fix a bug in your checkout flow.
The “everything in one place” argument for agents assumes agents need everything all the time. They don’t. Good agents narrow context. Good prompts narrow context. The monorepo doesn’t solve a problem that discipline and tooling can’t solve better.
But what about the testing story?
Then again. When you’re shipping large products, the problems your shared components solve repeatedly are clearly going to benefit from collocation. Not just for code reuse, but for interop and testing.
Things that could be unit tests become dreaded INTEGRATION TESTS if you’re not careful. You know the ones. The ones that take forty-five minutes and fail intermittently because some service spun down. The ones that make merging a PR feel like playing the lottery.
When your component lives in a separate repo, suddenly every consumer needs to verify compatibility across version boundaries. “Does my app work with the new button?” becomes a question you answer with integration tests instead of a question you answer by running the test suite once.
So what changed?
Honestly? Not much.
Choosing a monorepo has always been contentious. Teams have fought about this for years. The agent coding wave added one more variable to consider: context window management. But it’s not a variable that tips the scales.
Context narrowing in a monorepo is solvable. You can configure your agent’s search paths. You can invent .agentignore files with a custom harness. You can structure your repo so unrelated code lives in directories agents don’t traverse by default.
Solving context bloat is annoying but tractable. Solving the tradeoffs of ripping a component into a separate repo? That’s months of work. CI pipelines. Version management. Cross-repo PRs. The testing story I just mentioned.
What even is a monorepo?
I hate this term. What does it mean? A repo with more than one thing in it? What’s a thing? Who decides the boundaries?
Is it a monorepo if you have a frontend and a backend in the same repo? What if they share some types? What if you have two microservices? Three? At what point does “repo with stuff in it” become “monorepo”?
The term implies there’s some alternative where each “thing” lives in its own repo. But that just pushes the question around. Now you need to define what constitutes a thing worthy of its own repo. A service? A package? A component? A function?
We don’t have a word for “medium-sized repo” or “repo with a few related projects.” We just have “repo” and “monorepo,” like there’s a binary choice. There isn’t. It’s a spectrum and we’re all somewhere on it pretending the categories are meaningful.
When people say monorepo they usually just mean “big repo” or “repo I have opinions about.” Which is fine. But let’s stop pretending the term has a rigorous definition that informs architectural decisions.
The perceived utility of a monorepo shifted slightly for certain use cases. If you’re building something small and scrappy, maybe you care more about keeping context tight and a monorepo feels heavy. But that was true before agents too. Small projects have always been fine as separate repos.
If you were going to use a monorepo before, you probably still should. If you weren’t, agents didn’t change that either. The conversation got slightly more complex. The answer didn’t.