Why repo sprawl suddenly matters in AI workflows
Repo sprawl used to be the sort of thing people grumbled about after a long day and then worked around. A human could open three tabs, chase a couple of imports, along with ask a teammate where the billing code lived and still get the change out the door. Annoying? Sure. A deal-breaker? Usually not.
AI workflows change that equation. Once an agent’s expected to make real code changes, the gap between “hard to find” and “hard to trust” gets a lot wider. A person can improvise through missing context. An agent can’t read the room. It needs the room handed to it, preferably with labels on the drawers.
For a brand-new AI-native product, a single repo is often the easiest place to start. The agent can inspect the whole app in one place and follow imports without hopping across half a dozen codebases as well as keep the shape of the system in view while it edits. That makes the work cleaner for people too. You’ve one set of tests, one dependency tree, one place to grep when something feels off. It’s boring in the best possible way.
Repo sprawl becomes expensive the moment the assistant can’t tell which files belong in the same thought.
Established teams rarely get that neat setup. Auth lives in one repository, and billing sits in another. The frontend has its own home. “ Humans can survive this arrangement because they bring memory, along with judgment and a habit of reading between the lines. They can jump between systems and infer relationships as well as keep a mental model alive long enough to finish the task.
Agents need something firmer than that. They need machine-readable context: the right files, the nearby dependencies, the config that explains why this function exists, and the surrounding code that shows what a change will break. The tool spends more time assembling a picture than making the edit, if those pieces are scattered across separate repos. At that point, repo sprawl is no longer a mild annoyance tucked into the background of engineering life (to put it mildly). It becomes a hard limit on how useful the AI can be.
Plus, that’s the real shift here. The problem isn’t simply how many repositories a team has. It’s whether the codebase can be understood by a machine well enough to let it act safely. A sprawling setup might still make sense for organizational reasons, and plenty of mature teams will keep it that way. But once the workflow depends on an agent doing serious work, context access stops being a convenience and turns into the thing that decides whether the tool can help at all.
When the agent can’t see the code, it can’t safely act
A human engineer can usually get away with a bit of detective work. If auth lives in one repo and billing in another as well as the frontend somewhere else, a person can open a few tabs and skim the relevant files as well as build a decent mental model of how the pieces fit together. That process is imperfect, but it works often enough because humans are good at filling gaps, asking follow-up questions, and spotting when something smells off.
An agent doesn’t get that luxury. If it can’t inspect the right repository and the right files, it has to guess. Even a small edit turns into a gamble. Change a login flow without seeing how tokens are validated elsewhere, and you might ship a fix that breaks session handling. Tweak a billing screen without seeing the downstream webhook or entitlement check, and the UI can drift away from the actual account state. The code may look simple from one angle, yet the dependencies underneath tell a different story.
An agent that lacks the file in front of it doesn’t have a rough idea. It has a blind spot.
That difference matters more than people expect. A large prompt window helps only if the relevant context has already been collected. A strong memory helps only if the system has a way to retrieve the right details on demand. What an agent really needs is machine-readable context, meaning code, configuration, and documentation it can inspect directly rather than vaguely infer from past messages. In a monorepo, that context is often right there: imports, along with shared utilities and adjacent modules can be read in one pass. The same path may require explicit access to several codebases before the agent can make a safe change, in a multi-repo architecture.
Git Hub’s own Code Search exists because this retrieval problem’s real for people already. The same logic applies to agents, only more strictly. Search can help locate where something lives, but location isn’t enough. The model still needs the file contents, along with the surrounding use and the pieces that call into it. If those parts sit in different repositories, somebody’s to feed them in or wire the agent to reach them.
That gets ugly fast with cross-cutting changes. Auth, billing, and frontend logic tend to move together more often than teams would like to admit. Arguably, a plan to change passwordless login might require a backend validation tweak and a frontend error state as well as a billing rule that treats new users differently. In a single repository, the agent can often follow those threads without much ceremony. Split across services, each repo becomes a separate question: where’s the session created, where is the entitlement checked, where does the UI reflect the final state? Miss one, and the edit may compile but still behave badly (and that’s no small thing).
Git Hub’s Copilot coding agent is designed around this same constraint: it can only work well when it’s enough surrounding code to reason about the task. That sounds obvious, but teams still treat context as an afterthought, as if a clever prompt can make up for missing files. Usually it can’t, and the model can mimic confidence. It can’t inspect a repo it was never given.
So the real issue with repo sprawl isn’t just that the code is split up. It’s that the split can block the agent from seeing the parts that matter most at the moment it needs to edit them. Sort of, a human can improvise around that. A tool that needs exact context can’t.
The hidden costs: resets, along with handoffs and babysitting
But once an AI coding agent loses its place, the work doesn’t fail in a dramatic way. It just gets tedious. “ The first pass might still look productive. After a reset, though, the team is back to copying notes, pasting snippets, and reconstructing the problem from scratch.
A session reset is rarely the moment things break. It’s usually the moment the team realizes how much context was being held together by memory and chat history as well as luck.
That’s the annoying part. When a human developer’s to jump between repos, they can usually keep the shape of the task in their head for a while. They know the auth service calls billing, along with the frontend expects a certain response shape and the background job will choke if a field gets renamed too early. An agent, by contrast, needs that context spelled out or made available through tooling. If the session expires halfway through, or the model loses access to the right files, the work stops being a straight edit and turns into a small documentation exercise.
In practice, that means someone on the team becomes the interpreter. They point the agent at the right repository, explain why the change touches three services, and then watch the output more closely than they’d for a simple local refactor. That supervision has a cost. In the moment, but it adds up fast, it doesn’t always feel heavy. Instead of letting AI coding agents chew through routine edits, a developer spends part of the day checking whether the agent remembered the same assumptions it had ten minutes earlier. Developer productivity takes a quieter hit here. Nothing explodes. The pace just drops.
That’s why repo boundaries also create more handoffs than people expect. Say a checkout flow depends on auth and billing as well as a frontend app that lives in a separate repo. A small change to the plan selection screen may require one team to update the API contract, along with another to adjust the payment logic and a third to change the UI copy. Each team may do its piece well. The friction appears between the pieces. Someone waits for a PR to land before starting the next step. Someone else reviews a change without full context because the relevant code sits elsewhere.
That extra coordination doesn’t usually produce a neat, visible failure. It shows up as slower iteration, more review comments, and changes that feel fragile because they were assembled across several repos with partial context at each step. A rename that should have taken one pass can stretch across two or three review cycles. A tweak to error handling can ship with one service updated and another still assuming the old shape. The team gets there eventually, but the path is bumpier than it needs to be.
Tools can soften the edges. GitHub Copilot repository indexing exists partly because search and retrieval matter when you want the right code in front of the model. If you’re wiring your own system, the OpenAI Agents SDK gives you a place to think about tool use and handoffs as well as context flow more deliberately. Even then, the basic problem remains: if the code’s split into separate places and the session can’t keep that map alive, someone still has to reintroduce the world every time the agent blinks.
From there, that’s where repo sprawl starts to feel less like an organizational quirk and more like a tax on the workflow. The cost isn’t flashy. It’s the repetition, the checking, the waiting, the little detours that pile up across a week of AI-assisted work. And once that pattern’s obvious, the next question practically asks itself: when does one repo make life easier, and when does the organization’s structure force the agent to keep starting over?
Monorepo default, multi-repo reality: where the tension comes from
After a few rounds of copy-paste archaeology, the appeal of a monorepo starts to make sense pretty quickly. For a brand-new AI-native product, it’s the path of least resistance. The agent can inspect imports, along with trace dependencies and see where the frontend stops and the backend starts without bouncing between half a dozen separate codebases. If you’ve ever tried to track a bug through one repo, then another, then a third because “the auth bit lives over here,” you already know why that matters.
Search helps, too. In a monorepo, code search tools can scan one shared tree and surface the relevant files without guessing which project owns what. Git Hub’s code search is a decent example of the kind of tooling that feels almost trivial when everything lives together and suddenly clumsy when it doesn’t.
A repo that feels tidy to a human can still be a locked filing cabinet to an agent.
On top of that, that clean setup’s why monorepo often looks like the obvious default for new products built with AI in the loop. There’s one place to inspect, one set of boundaries to learn, one dependency graph to follow. The agent sees the shape of the app instead of piecing it together from scattered clues. For machine-readable context, that matters more than people usually expect (believe it or not). Probably, a large prompt can carry only so much. A full repository can carry a lot more.
Of course, most mature teams don’t live in that neat little world. They’ve grown around the work, not around the needs of an agent. Authentication sits in one repository, billing in another, the frontend somewhere else, and a couple of services sit with the teams that own them. Sometimes that split came from practical concerns (which is worth thinking about). Different release cycles. Different security boundaries. Different people who need different levels of access. Sometimes it came from plain momentum. A team needed to move fast, so it made a new repo. Then another one. Then one more because nobody wanted to untangle the old one on a Friday afternoon.
That setup can be perfectly sensible for humans. People like clear ownership. They like smaller blast radii. They like not having every change tied to every other change. Good news. A billing engineer doesn’t need to wade through frontend churn just to patch a tax rule. A design setup team may want a separate repo for release discipline and access control. Those choices aren’t irrational. They often come from hard-won experience.
Then again, the trouble starts when AI agents enter the process and the repository structure stops being merely organizational. It becomes operational, and fair enough. The repo layout now decides whether the task is a tidy edit or a scavenger hunt, if the agent needs to update sign-in flow and payment logic as well as a UI component that depends on both. The more scattered the code, the more the agent has to rely on stale summaries, hand-maintained notes, or a human to ferry context back and forth. That’s where the friction grows teeth.
This means this’s why repo sprawl is usually a byproduct of team structure, not just a technical preference. Teams split codebases because teams split responsibilities. Ownership boundaries, along with security policies and release processes all push in that direction. The AI problem grows out of that reality. “ (and yes, that matters).
Moving on, that distinction matters. A monorepo isn’t some magical answer to every codebase headache, and separate repos aren’t a moral failure. The question’s narrower: when the workflow depends on an agent that needs broad, accurate context, does the layout help or hinder that work? If the answer’s “the agent can’t see enough to act safely,” the repo count stops being an internal preference and starts acting like a speed limit.
AWS has been writing about architecting for agentic AI development in exactly that spirit. The useful part isn’t the branding. It’s the reminder that agents need systems they can read, not just systems people understand after three meetings and a diagram nobody updated.
Also worth noting — that tension is the real story here. The monorepo is the tidy default because it gives the agent a single, legible workspace. Multi-repo setups often exist because real teams are messy, distributed, and grown-up enough to have boundaries. Both can be reasonable. The pain shows up when fragmentation crosses the line from manageable to opaque, and the agent’s left trying to work with partial facts instead of full context.
Reducing the blast radius without pretending the problem doesn’t exist
That said, the goal here isn’t to bulldoze every boundary and stuff the whole company into one giant repository. That would create its own mess. Build times get ugly and ownership gets fuzzy as well as people start stepping on each other’s toes. The better question is more practical: when a change’s to move across codebases, how much friction does a person or an agent hit before it can make a safe edit?
Naturally, that makes context access a design concern, not an afterthought. If a team’s deciding whether to split a service out, or keep it near the frontend and billing code it talks to every day. The first question should be simple: can the code that does the work be found, along with read and updated without a scavenger hunt? For AI-assisted work, that matters as much as deployment strategy or test coverage. An agent that can’t see the relevant files will guess, and guessing’s where you get weird diffs and late-night cleanup.
If a repo boundary makes an ordinary change require guesswork, the boundary is doing too much work.
A few habits make that easier to manage. Write down where a service lives, what it depends on, and what it should never reach into. Keep dependency rules plain enough that a new developer can follow them without a meeting. Use ownership files, along with short READMEs and change notes that name the repo that should be touched first. Say so directly instead of leaving people, or tools, to infer the path from six scattered commits and a vague tribal memory, if billing events need to flow into auth and then into the frontend.
Conventions help too. A repo split’s less painful when the boundaries are obvious and stable. One service owns login checks. Another owns invoices. A third handles the UI. Fine. But if every third feature needs all three, and the routing logic lives in one place while the state lives in another. The team’s created a dependency knot that will slow down both humans and agents. In those cases, keeping closely coupled systems near each other usually saves time. That might mean a monorepo. It might mean grouping a few repos under shared conventions. It might just mean refusing to split something before the split pays for itself.
Next up, there’s no magic trick here. Repo sprawl still exists, and some of it’s sensible. The point’s to make it legible. When context is easy to retrieve, AI tools can do more than draft filler code and apologize for the rest. They can inspect the right place and change the right files as well as leave fewer surprises behind. That turns repo sprawl from a pure governance headache into something more concrete: a direct limit on how useful AI can be in day-to-day development.
