Was the Monorepo Really Best for Coding Agents?
Earlier this year, I thought monorepos were the obvious choice for AI-native development.
The reason was context closure.
A coding agent works better when the code, tests, design decisions, infrastructure, and development rules it needs are available inside the same execution environment. It should not have to wait for a person to paste a decision from Slack, explain a convention that lives in someone's head, or retrieve a requirement from a system it cannot update.
A monorepo made that easier. Put the product and its development context in one place, give the agent tools to search it, and the repository becomes a closed environment in which the agent can work.
I still believe context closure matters. What changed was my view of what the repository was closing.
I was involved in a discussion about introducing a shared agent harness across a large repository. The technical proposal was not the hardest part. The harder question was what would happen to the workflows engineers already used.
If the shared harness required people to stop using their personal skills, instructions, and workflows, would they actually do it?
There was no confident yes.
By then, the repository already contained more than code. It contained several partially overlapping ways of telling agents how to work, some checked in by teams and others maintained by individuals. Introducing a common harness was no longer an installation. It was a migration away from systems people depended on every day.
I had seen the opposite failure too. Centralize before the organization knows how to design, evaluate, and maintain a reliable harness, and the shared system becomes a ceiling. Poor instructions affect everyone. Reviewers absorb the correction cost. AI usage remains shallow because the approved path is less effective than what capable individuals could build for themselves.
The two approaches appeared to fail in opposite directions. Centralize too early, and the organization standardizes what it has not yet learned to do well. Standardize too late, and local workflows become too embedded to replace.
Where the code lived mattered less than who could define how an agent should work across it, resolve conflicting context, and keep the system correct as both the code and the models changed.
The repository stopped being the context boundary
The monorepo argument was stronger when coding agents were less capable.
An agent that could only sustain a short task benefited enormously from having everything nearby. Repository boundaries were practical context boundaries. Work that crossed them required more prompting, more retrieval infrastructure, and more human coordination. Keeping related systems together reduced the chance that the agent would miss something important.
The current long-running models I use behave differently. Given access to the relevant repositories and tools, they can search across projects, trace dependencies, compare implementations, and make coordinated changes without treating each repository as a separate task. Access still has to be designed, but the repository boundary is no longer the same kind of capability boundary.
Cross-repository reach does not make the surrounding structure optional. In a monorepo, broad search still needs package, ownership, and domain boundaries to separate relevant code from similar but unrelated code. Across repositories, search depends on a trustworthy inventory and dependency map, or an incomplete result can appear complete. Better models need less assistance to follow that map. They do not remove the need to maintain it.
This claim is about context acquisition and edit coordination. Repository boundaries still matter for atomic commits, CI, compatibility, and deployment, and better models do not remove those constraints. They do change the monorepo tradeoff for AI development.
Code visibility is still useful, but visibility is no longer exclusive to a monorepo. An agent can discover an API or inspect a dependent service across repositories. It can update several repositories in one run. Producing the edits is usually easier than determining whether they may be deployed together, which compatibility window must be preserved, and how the rollout should be sequenced.
As repository boundaries stopped being context boundaries for coding agents, the monorepo's main AI advantage moved from retrieval to governance.
A monorepo gives product-wide instructions, shared skills, architectural context, and guardrails a common home. The same repository can carry the evaluations and maintenance work that keep them current. That is a real advantage. It is also the part most organizations are least prepared to operate.
Context closure is not context governance
In What Makes Development AI-Native?, I described context closure as the condition in which product context is searchable, readable, and updatable within the LLM's workflow.
That remains necessary. But availability answers only one question: can the agent reach the context?
Governance answers the questions that become important after it can:
- Which context is authoritative?
- Where does it apply?
- Who owns it?
- What happens when two instructions disagree?
- How is an obsolete rule removed?
- How was it evaluated, and who is responsible when local context changes product-wide behavior?
A repository can close context without answering any of these.
This becomes harder as the organization grows. A product large enough to justify a monorepo is often developed by multiple teams. Those teams are deliberately kept loose enough to work without constant coordination. Their code, architecture, release processes, domain knowledge, and agent workflows diverge because some divergence is necessary for autonomy.
A team creates a skill to fix a recurring failure. An engineer adds a personal instruction because changing the team's workflow would affect everyone. Another team solves a similar problem differently. Each addition is locally reasonable. Over time, the repository, team, and individual layers accumulate overlapping assumptions about how work should be planned, reviewed, tested, and completed.
The engineer becomes isolated inside progressively narrower context:
product context
-> system context
-> team context
-> personal context
The deeper the local system becomes, the harder it is for that engineer to change the shared one. A personal workaround is cheap. Correcting a repository-wide workflow requires agreement, migration, and responsibility for everyone it affects.
Local convenience gradually removes the force that would otherwise improve the common system.
Better models make conflicting context more expensive
Missing context is still dangerous. A model cannot reliably honor a constraint it cannot discover.
But missing context is no longer the only important failure mode. Incorrect context, conflicting context, and excessive control can be worse because a capable model can execute them more thoroughly.
I described this shift in When Better Models Make Old Agent Workflows Worse. Rules written to compensate for earlier model failures can become work-generating constraints, leading the model to create the documents, tests, reviews, retries, approvals, and abstractions they imply. The same problem appears at organizational scale in a monorepo.
One team skill may require every change to pass several review phases. Another may instruct the agent to choose only the narrowest proof boundary. A product-level rule may preserve a public contract while a local workflow optimizes for an internal replacement. A personal instruction may require a planning artifact that the shared harness no longer uses.
Each instruction can be defensible in isolation. Their combination can reduce execution quality while appearing more mature because more context and more process are present.
AGENTS.md at least provides a directory-based preference. Codex loads instructions from the repository root toward the working directory, and instructions closer to the working directory take precedence. That does not prove that the local rule is correct; the product-wide rule may be the one that should win. But it gives the model a deterministic guide when the two disagree.
Skills are harder to reason about because they use progressive disclosure. The agent initially sees names and descriptions, then decides which full instructions to load for the task. What enters the context depends on how the task is interpreted. When several skills apply, there is no equivalent semantic hierarchy that says a product-level decision must override a team workflow or a personal preference.
Which instructions enter a task can therefore be hard to predict. Changes in task wording, working directory, or model version can activate different combinations, allowing an organization to improve its harness while quietly reducing performance.
Centralizing before the capability exists
A natural response is to centralize everything, but a shared harness for a large product requires much more than prompt files. Its maintainers need enough product knowledge to separate durable boundaries from old compensation rules and keep context aligned with the codebase. They also need representative evaluations that expose model regressions and workflows that no longer earn their cost.
Prompt and context engineering skill is necessary, but not sufficient. A person who understands model behavior but has not developed the product cannot create accurate domain context. A person who knows the product but cannot evaluate agent behavior may encode every historical incident as another permanent rule.
No small central group can deeply understand every domain in a large monorepo while also keeping pace with model changes. If that group becomes the sole author and gatekeeper, humans become the bottleneck. The common harness drifts away from actual development, teams work around it, and standardization suppresses the very experimentation needed to improve it.
Usage and spending may still increase even while outcomes stagnate. When a weak workflow is centralized, its limitations become organization-wide.
Standardizing after local systems are embedded
Letting teams and individuals find what works produces faster initial adoption. Engineers can experiment without changing anyone else's process, and useful practices emerge from real work rather than from a central design exercise. Autonomy without a path to convergence, however, creates its own lock-in.
A personal skill is not merely a file once someone has shaped daily work around it. It contains learned behavior, trusted shortcuts, and assumptions about how the agent will respond. A team workflow becomes part of planning, review, and delivery. Replacing it has a switching cost even when the replacement is better.
By the time the organization needs a repository-wide harness, it has postponed the difficult decisions: which local behavior should become shared, who has authority to retire the old systems, and how to prove that migration will not reduce performance. Without those answers, the shared harness joins the existing workflows instead of replacing them.
This brought me back to the question from the original discussion: would engineers give up the personal systems they already relied on? It had sounded like an adoption question. It was really a question about migration authority. The organization wanted one harness but had never established who could retire the systems it would replace.
Centralize governance, distribute its maintenance
If a monorepo is going to provide a common AI development environment, its context and harness need a common authority. Product-wide constraints cannot become optional because a team prefers another workflow. The organization needs one way to decide what is canonical, how conflicts are resolved, and when a rule is obsolete. Common authority, however, does not mean that a central team can do all the work.
Shared authority needs distributed capability
Engineers need more than the ability to ask a model for code. They need to understand how task framing, context selection, instruction scope, progressive disclosure, verification, and model behavior affect the result.
Not everyone needs to become a specialist in agent evaluation. Everyone contributing context to the shared system needs enough skill to avoid turning a local preference or historical failure into a product-wide obligation.
The capability cannot be hidden behind a platform team. Product and system context has owners, consumers, compatibility requirements, and a lifecycle. Personal preferences can remain personal when they affect presentation or reversible working style, but they cannot silently redefine correctness, product behavior, approval boundaries, or completion criteria.
Teams that own a domain must also own the accuracy of the context that describes it. Some members need explicit capacity beyond immediate delivery: maintaining shared instructions, reviewing cross-domain assumptions, contributing representative tasks, and resolving conflicts in the repository-wide harness. Governance is centralized; its evidence and maintenance are distributed across the organization.
The harness should need less context over time
Context quality cannot depend on occasional manual cleanup. References, ownership, duplication, schemas, and retired files can be checked mechanically. Representative tasks can detect whether a model update changes behavior. Conflict cases can test which rule wins when product, system, and team instructions disagree. The harness can measure whether a rule improves accepted outcomes or merely creates more work.
Automation should concentrate human judgment where it changes a real decision rather than spend it on routine consistency checks. The evaluation set must evolve with both the codebase and the models. A skill that passed six months ago has not earned permanent authority.
Continuous evaluation is only half of the work. Context and harnesses cannot compensate indefinitely for an inconsistent codebase.
When two parts of the system solve the same problem differently, an instruction can explain the difference. When five parts do, more instructions become a map of unresolved design debt. The model must spend more tokens discovering which example is current, which exception is intentional, and which pattern is safe to extend.
The durable response is to reduce the inconsistency itself. Public contracts should be explicit. Invalid dependencies should be mechanically rejected. Types, tests, build boundaries, schemas, and permissions should enforce what prompts currently have to explain. Temporary compatibility paths should be removed instead of accumulating permanent context around them.
The strongest agent instruction is often a codebase in which the wrong change does not fit.
Judge governance by the cost of outcomes
How should an organization know whether this governance is working? Usage, generated lines, completed tasks, and total spend reward activity. The relevant economic unit is the total inference cost required to produce one accepted outcome at the required quality without human correction.
That includes model choice, retries, abandoned runs, review agents, unnecessary artifacts, excessive exploration, and work generated by obsolete instructions. Some of that cost is legitimate. Exploration can establish that no change is needed, but it still belongs in the cost of reaching that outcome. Repeated exploration that better context could prevent should fall over time. A poor harness may still complete the task by consuming more reasoning, but the organization is purchasing inference that its development environment should have made unnecessary.
The number is a health indicator, not an optimization target. A lower cost is an improvement only while the acceptance bar holds and accepted outcomes stay correct after review.
If a reviewer has to reconstruct the result, the autonomous workflow did not produce the accepted outcome. This measure also gives the organization credit for restraint. The right outcome may be a small change, reuse, removal of a conflicting workflow, or a decision that nothing should be built. As models become capable of sustaining more work, preventing unnecessary work becomes part of operating them well.
The monorepo is not the answer by itself
I still see a strong case for monorepos in AI-native development. One repository can provide a canonical harness, keep product-wide context maintainable through the same workflow as the code, and make shared evaluation and mechanical enforcement easier to operate.
Realizing those benefits requires common context ownership and distributed product knowledge. Without them, a monorepo can contain more contradictions than an agent can reliably reconcile, while a shared harness can enforce the wrong workflow everywhere. A multi-repository system with deliberate cross-repository access, explicit contracts, and well-governed context may no longer impose the disadvantage it once did for capable agents.
Repository topology alone cannot decide the outcome. What matters is whether the organization can operate the context system that topology makes possible.
Conway's law did not stop applying when the executor became a model. The communication structure of the organization shapes the codebase; it now also shapes the instructions, skills, workflows, and evaluation systems through which agents change that codebase.
If teams are responsible only for local delivery, their agent context will optimize for local delivery. If individuals are rewarded for personal productivity, their best workflows will remain personal. If a central group owns the harness without the participation of domain teams, the harness will reflect the central group's limited view of the product.
AI-native development therefore requires more than distributing a coding tool or checking a set of skills into a repository. The development process itself has to become an engineering responsibility. Teams must treat product-wide quality as part of their work, maintain the system that turns intent into autonomous execution, and make the codebase consistent enough to require less explanation over time.
The monorepo once looked like the answer because it put everything the agent needed in one place.
Now the agent can reach much farther.
The harder question is whether the organization can agree on what the agent should find when it gets there.
The repository is no longer the context boundary.
The organization is.