Knowledge Silos in Multi-Repo Engineering Organizations

Knowledge silos in engineering are usually blamed on culture: teams don't talk to each other, communication breaks down, nobody writes documentation. That diagnosis misses the mechanism. In a multi-repo codebase, the repo boundary is an epistemic boundary. What a team knows is bounded by what repos it touches, and everything outside that boundary is effectively invisible to it because the architecture never built a path for it to travel.

Each repository accumulates its own conventions, its own dependency quirks, its own history of what broke and why, and none of that knowledge has anywhere to go once it's created. Daniel Schniepp, Senior Staff Engineer at Mercedes-Benz Mobility AG, describes this pattern in large or fast-growing organizations directly: silos separate teams, hinder collaboration, and reduce the impact of collective knowledge and the opportunities for technology sharing that come with it. That framing matters because it locates the failure before any human decision about sharing is even made. The separation is baked into the org chart of the codebase itself.

The pattern gets worse with scale, not better. As teams multiply and services proliferate, the shared context that used to travel informally through hallway conversations and shared repos starts to fragment, and the Growin platform engineering analysis from 2026 traces this directly to the limits of DevOps at scale, where the informal channels that once held shared context together stop holding. Every new repo is a new epistemic territory. Every new service is a new island with its own local laws. The organization keeps growing its capacity to build software while quietly losing its capacity to know, as a whole, what it has built.

Operational knowledge concentration in senior engineers as organizations scale

The structural isolation of repos produces a predictable human outcome. Someone has to know how the pieces connect, and in the absence of a system that tracks it, that burden lands on whichever engineers have been around long enough to have touched most of the repos in question.

Growin's 2026 platform engineering analysis describes exactly this: operational knowledge concentrates in a small group of senior engineers who quietly become escalation points for deployments, incidents, and architectural decisions, and what once felt like autonomy for those engineers slowly turns into coordination overhead. It's a recognizable shape in any organization that has grown past the point where one person can hold the whole system in their head, except that a handful of people still try to. What those engineers carry is organizational memory as much as technical skill. It's organizational memory: which team actually owns which service, which API has an undocumented edge case that will break a downstream consumer, which deployment has a hidden dependency on a job that runs at 3 a.m. in a repo nobody on the current team has opened. None of that lives in any single repository. It lives in the senior engineer's head, because that's the only place the multi-repo structure never fragmented it.

This is where the LeadDev panel on engineering knowledge silos locates the real danger point: not silos in general, but the moment those silos turn restrictive, when the knowledge inside them becomes a bottleneck tied to one person's availability. Once that happens, the org has quietly built a class system inside its engineering department. Context becomes a privilege of tenure, not something every engineer, regardless of rank, can be expected to access on demand.

The obvious objection is that specialization is healthy, that teams should own their domains deeply rather than skim across everything shallowly. That's true, but it doesn't rescue the current setup. Deep domain ownership and cross-boundary visibility aren't in tension. The failure isn't specialization, it's opacity: a team can own its service completely and still be reachable by anyone who needs to know how that service behaves. Losing one of the few people holding that visibility together is where the fragility shows. The Code Climate analysis notes that when knowledge sits with a single person on a team, that person's absence can bring the surrounding work to a standstill. An org chart where senior engineers quietly function as single points of failure is a deferred outage. It's a deferred outage.

The cost of concentrating context in the wrong people

Concentrating context in a handful of people has a price, and the clearest place to see it is onboarding. It takes an average of six to nine months for a new developer to reach full productivity in a mid-to-large scale codebase, and in high-complexity or microservice architectures, this timeline extends further. That six to nine months is most of a year in which a new hire draws a salary while depending on senior engineers to answer questions the codebase itself should be able to answer.

A case documented at CodeMiners in 2026 shows what happens when that ramp-up fails outright: a senior engineer hired into a role, gone by week eight, with the resulting cost stacking up from recruiting fees, months of salary against zero net output, the review burden absorbed by other senior engineers during those eight weeks, and the cost of rehiring from scratch, adding up to tens of thousands of dollars. That figure reflects what happens when the context a new engineer needs to succeed sits locked inside someone else's head instead of somewhere they can reach it.

Onboarding failure is the most visible cost, but it isn't the only one. Engineers who lack access to information they need don't stop working, they just start guessing, and the Code Climate analysis describes the pattern precisely: without access to key information, engineers spend time re-solving problems already solved elsewhere in the codebase, or they build on assumptions about how their work fits the broader system, assumptions that are sometimes flatly wrong. Multiplied across a codebase with dozens of repos and hundreds of engineers, the lost time occurs in small increments invisible on any dashboard until the rework compounds into a missed deadline.

Then there's the drain on the senior engineers who become the default answer to every cross-boundary question. Every question routed to them because the answer isn't accessible anywhere else is a context switch away from the work that actually justifies their seniority, architecture, mentorship, hard technical problems. Neural Concept's 2026 analysis identifies this pattern across engineering organizations of very different types: silos slow decisions, inflate development costs, and dilute accountability in the absence of a unified vision for how knowledge should move. These costs appear in quarterly velocity reports as a slowdown with no clear cause, not as a single line item. They show up as an organization that seems to be running slower every quarter without anyone being able to point to why.

AI coding agents and the growing consequences of the context gap

AI coding tools have shifted the bottleneck in software delivery, not removed it. Authorship has gotten faster. Reviewing, validating, debugging, and integrating what gets authored is now the slower part of the pipeline, and that slower part depends on exactly the cross-repo context that silos destroy. The productivity gains from AI adoption are uneven, concentrated at the point furthest from where the actual risk lives.

DORA's 2024 State of DevOps research found that AI adoption tracked with higher individual productivity and job satisfaction, alongside negative effects on software delivery stability and throughput. That finding points at the integration and review layer, not at authoring. Code gets written faster. Whether that code is safe to ship into a system the author doesn't fully understand is a separate question, and it's the one AI tools answer worst.

AI does measurably speed up onboarding on one dimension. The DX 2025 enterprise study found that daily AI users reached their tenth pull request substantially faster than non-users, and a 2026 follow-up across a wider set of companies showed further improvement. But Shopify's engineering team observed that the real onboarding challenge for new leaders is dominated by cultural integration, organizational trust, and product context, none of which any AI coding tool touches. The same gap applies, arguably more sharply, to the agents themselves. An agent can write fluent, idiomatic code in whatever language the repo uses, and still have no way of knowing that a particular API is deprecated inside this specific organization, that a given service is owned by a team on another continent operating under a six-hour review SLA, or that the data field it's about to touch feeds into a pipeline under regulatory compliance.

That's the core diagnosis practitioners keep landing on: AI agents understand code, but not the environment the code lives in, not a team's conventions, not the business requirements layered on top of the technical ones, not the deployment constraints that only exist because something broke in production two years ago. Pento's engineering team responded to this directly by building custom MCP servers to give their AI agents navigable access to a large, complex codebase, a concrete admission that the standard local-context window an agent works from isn't enough once the codebase crosses a certain size. Bigger context windows don't solve this either. Dumping every file into a prompt is not the same as giving an agent organizational understanding. An agent operating without knowledge of which services consume a given API, which dataflows are sensitive, and which conventions are actually enforced in practice rather than merely documented is a fast, confident actor working from incomplete information, and speed without that context makes the risk worse rather than better.

METR's randomized controlled trial found that experienced open-source developers worked slower with AI tools than without them on repositories where they had deep existing context. That result suggests AI tools compensate for missing context rather than replacing the value of genuine familiarity, which is a different claim than saying AI makes engineers faster across the board. A February 2026 follow-up revised the study's design after finding a significant self-selection problem in how developers had submitted their work, so the debate over how to interpret the original result remains open rather than settled. The caveat doesn't undercut the larger point. It sharpens it: AI tools are most valuable exactly where context is thinnest, and least valuable, sometimes actively counterproductive, where a human already holds the context an agent has to guess at. The fix is to close the context gap the agents are running into, not to slow AI adoption down.

A protocol-based context layer for AI agents across repo boundaries

The Model Context Protocol is the architectural response to that gap. MCP lets an AI agent connect to organizational knowledge that lives outside any single repository, through a consistent, extensible tool interface rather than through whatever happens to be sitting in a local working directory.

The protocol's origin matters for understanding how fast it has been adopted. MCP was originally developed by engineers at Anthropic, donated to the Agentic AI Foundation in late 2025, and is now maintained as an open standard under the Agentic AI Foundation, a directed fund operating under the Linux Foundation. By early 2026, every major AI coding platform had adopted it, Claude Code, Cursor, VS Code Copilot, Codex, Windsurf, Zed, Continue.dev, and Goose among them, making MCP the de facto interoperability layer across the AI coding ecosystem. That breadth of adoption means a context layer built once, on MCP, is usable by an organization's entire toolchain rather than locked to one vendor's agent.

The protocol itself has stopped being the constraint. Production-ready MCP servers already exist for most common developer tooling categories by 2026. The constraint now is discovery: knowing which servers already exist versus when it's worth building one from scratch, and knowledge base access is the largest unmet need in the current ecosystem.

Instead of relying on what happens to be in a local working directory or a manually curated prompt, an agent connected to a context layer can query live, continuously updated evidence about services, APIs, consumers, and sensitive dataflows across the whole codebase, giving it organizational knowledge no single repository could hold on its own. One approach gaining traction generates that evidence directly from source code through deterministic static analysis, keeps it current as engineers ship changes, and exposes it to agents through MCP, so the same underlying layer can serve code intelligence, privacy compliance, security review, and AI governance all at once. Pento's custom MCP server is the concrete proof that off-the-shelf context wasn't sufficient. It took dedicated infrastructure to make a large, complex codebase navigable for an AI agent working inside it.

The same context layer that serves an agent serves a human sitting next to it. Natural-language search across every repo an organization owns gives product managers, support staff, and new hires direct answers without routing every question through a senior engineer. This directly addresses the interrupt-driven cost documented in earlier sections: when a PM or support engineer can query the codebase directly, the senior engineer is not the bottleneck.

Codebase access and the narrow scope of code search

Restricting code search to developers recreates the silo at the tooling layer by keeping non-engineers dependent on someone else to query the codebase for them. Every non-engineer who can't query the codebase directly becomes dependent on an engineer to translate it for them, which recreates the exact bottleneck a shared context layer is supposed to remove.

The list of people who need answers from the codebase on a regular basis is longer than most engineering tooling decisions assume. A product manager scoping a new feature needs to know what already exists and what it depends on before committing a roadmap to it. A support engineer fielding a customer escalation needs to know whether the behavior in front of them is a bug or a documented constraint of the system, and getting that answer usually means interrupting an engineer instead of checking for themselves. A new hire, whatever their role, needs to understand the system they're joining well enough to contribute to it safely, which is a form of codebase access no onboarding document fully substitutes for. All three of these people currently route their questions through senior engineers, the same interrupt pattern the earlier cost analysis already showed is expensive in aggregate.

The Code Climate analysis names the underlying failure precisely: engineers who lack access to key information end up re-solving problems that exist elsewhere in the codebase, or they build on assumptions about how their work fits the larger system, assumptions that sometimes turn out wrong. That same failure mode applies with equal force to non-engineers who have no access to the codebase at all, they aren't even in a position to make a wrong assumption, because they have no path to check anything themselves. An internal initiative Code Climate documents, built around intentional knowledge sharing, logging key decisions and documenting new tracks of work as they happen, produced a throughput increase of almost 70% by Code Climate's own account. The same underlying principle scales to the codebase itself: make it queryable by everyone who needs an answer from it, and the throughput gain isn't confined to the engineers who wrote the code. It extends to everyone whose job depends on understanding what that code does.