The Monorepo Is Your AI's Connective Tissue

• Monorepos Were Always About Shared Understanding
• AI Inherits Whatever Context You Give It
• From Code Repository to Intelligence Layer
• Augmenting the Team, Not the Engineer
• The Compounding Advantage
• The Repository as a Strategic Asset

The 2025 DORA State of AI-Assisted Software Development report, drawing on nearly 5,000 technology professionals worldwide, delivers a result that should give every engineering leader pause: AI adoption has a negative relationship with software delivery stability (DORA & Google Cloud, 2025). Not neutral — negative. Teams shipping more AI-generated code are experiencing more instability, not less, unless they already have robust engineering practices in place. Most organizations read this as a quality warning and move on. The deeper implication is structural: the AI isn't the variable. The system it operates in is.

I've believed in monorepos for years before AI entered the conversation. The case was always human: one codebase gives engineers the full picture — every integration point, every shared convention, every dependency. The "it works in my service" failure mode disappears because everyone can see every service. Cross-cutting refactors become atomic instead of coordinated multi-team negotiations. You stop duplicating solutions because the solutions are visible. None of that required AI to be true. But the same structural properties that made monorepos valuable for engineers now make them exponentially more valuable for AI tools — for the exact same reason.

This post argues that the monorepo is evolving from a code consolidation strategy into an organizational intelligence layer. Not just code, but skills, runbooks, process workflows, and institutional knowledge — all versioned, reviewed, and deployed alongside your software. The teams that make this transition deliberately are building a compounding advantage. The teams that don't are pointing increasingly capable AI tools at increasingly impoverished context and wondering why the results feel generic.

Monorepos Were Always About Shared Understanding

The canonical case for monorepos was made at scale in 2016, when Google engineers Rachel Potvin and Josh Levenberg published "Why Google Stores Billions of Lines of Code in a Single Repository" in Communications of the ACM (Potvin & Levenberg, 2016). The numbers were staggering — 2 billion lines of code, 9 million unique source files, 86TB of data — but the paper's argument wasn't really about scale. It was about the organizational properties that emerge when you refuse to partition knowledge. Potvin and Levenberg enumerate them carefully: unified versioning so every team works against the same state of the world; code visibility so any engineer can read any service's implementation; atomic changes so a refactor that touches ten services lands as one coherent commit; large-scale refactoring so improvements propagate globally rather than getting negotiated service-by-service.

These are not tooling advantages. They are epistemic advantages — properties that change what an engineering organization can know about itself at any given moment. When your service lives next to the five services it calls, you can't pretend their contracts are stable abstractions you don't need to understand. When a library update lands, the entire impact surface is visible and testable in one pass. When a new engineer joins, the full dependency graph of the system is browsable without tracking down five separate repository access requests and reading five separate READMEs with five separate conventions. The monorepo doesn't just consolidate code — it consolidates organizational memory, and it does so by making fragmentation structurally expensive.

The argument against monorepos has always been autonomy: independent teams want independent repositories, independent release cycles, independent conventions. That argument has merit in some contexts. But what it trades away is visibility, and visibility is exactly what AI tools need to give you anything better than generic output. You can't have both maximum team isolation and maximum AI effectiveness. The organizations that have always chosen shared visibility are now reaping a second dividend they didn't anticipate.

AI Inherits Whatever Context You Give It

The DORA 2025 finding deserves a more precise reading than it usually gets: "AI doesn't fix a team; it amplifies what's already there" (DORA & Google Cloud, 2025). Strong teams become stronger. Struggling teams find their problems accelerating. But the mechanism matters — the report identifies that AI creates instability specifically where control systems are immature: insufficient automated testing, weak version control practices, poor code review discipline. These are all properties of the engineering system, not properties of the AI tool. The model is the same either way; the substrate determines the outcome.

An AI coding agent pointed at a polyrepo of twenty microservices faces a structural information problem. It doesn't know how Service A calls Service B. It doesn't know which shared library already solves the problem it's being asked to solve from scratch. It can't see your team's error handling conventions, your naming patterns, the three previous iterations of this abstraction that were abandoned for documented reasons. It generates plausible-looking answers because that's what language models do — but plausible is a much lower bar than correct-in-context. Agentic coding is an amplifier, not a foundation: it raises the stakes on whatever engineering discipline you already have, and it exposes the absence of that discipline faster than any other tool.

An agent in a monorepo has fundamentally different affordances. It navigates to the actual service interface. It finds the real shared library. It reads the existing pattern and follows it rather than inventing one. GitHub's controlled research with 95 professional developers, applying the SPACE framework, found that AI-assisted developers completed tasks in roughly half the time of unassisted developers (Peng et al., 2023). That result has an implicit precondition: the AI can see enough of the codebase to give contextually accurate guidance. A polyrepo limits that context by design. A monorepo removes the ceiling.

From Code Repository to Intelligence Layer

The shift most teams haven't made yet is conceptual before it's technical. A monorepo is still being treated as a place to store code — when it's becoming a place to store how the team works. Microsoft and GitHub have both formalized this in 2025: project skills, the reusable AI workflows that encode team processes, are now designed to live in the repository alongside the code they operate on (GitHub, 2025; Microsoft, 2025). The same review process that governs a code change governs a skill change. The same versioning history that records why an architectural decision was made records why a workflow was updated. The skill and the codebase co-evolve because they live in the same place.

What this means in practice is specific. A PR review skill that lives in your monorepo doesn't apply a generic quality checklist — it knows your actual code style requirements, your security standards, the test coverage thresholds your team has agreed on. A deployment checklist skill knows your actual infrastructure, the environment variables that have caused production incidents before, the sequence of steps your team learned the hard way. A commit message skill follows the conventions visible in your git history, not a style guide someone wrote and never updated. These aren't AI tools that sit outside your engineering system and observe it — they're artifacts of the engineering system itself, maintained with the same discipline as everything else in the repo.

The deeper point is about institutional knowledge and where it lives. Every team accumulates hard-won knowledge about how their system works, what breaks it, and what the conventions actually mean in practice. Most of that knowledge lives in heads, in Slack threads, in the tribal memory of engineers who joined three years ago. When those engineers leave, the knowledge degrades. Encoding it as skills in the repository — workflows that can be invoked, reviewed, and updated — changes the default: rather than knowledge being lost when someone leaves, it has to be actively removed. The Company Knowledge OS argument applies directly here: curation that stays current beats documentation that decays.

Augmenting the Team, Not the Engineer

The standard AI productivity claim is narrow: developers write code faster. That's real, but it's the minimum viable version of what's possible. When skills live in the monorepo alongside code, AI augmentation extends to every workflow the team runs — including the ones that have nothing to do with editing files.

Project and process management is the most underrated category. Ticket creation with codebase context means the AI can link to the exact files that need changing, estimate complexity by reading the actual code rather than the ticket description, and surface dependencies the engineer writing the ticket would miss. Architecture Decision Records drafted with awareness of your existing ADRs flag when a proposed change conflicts with a prior architectural commitment — something that currently falls entirely on the institutional memory of whoever happens to be in the room. Release notes generated from git history using your team's actual conventions stop being a manual chore and become a reliable artifact. Sprint planning that can read your dependency graph produces estimates grounded in real code structure rather than in optimism.

Operations and reliability is where the latency advantage is most concrete. Incident response runbooks tied to your actual service names and alert configurations aren't a generic procedure — they're specific, executable steps for the system your team actually runs. On-call handoffs generated from recent commits and open issues are complete rather than dependent on the outgoing engineer's memory under pressure. Post-mortems pre-filled with service context start from evidence. These workflows exist in every engineering organization; what varies is whether they're encoded in the repository or reconstructed from scratch every time.

Onboarding is the hardest problem in knowledge-intensive organizations, and it's the place where monorepos with skills offer the most underappreciated advantage. "Explain our auth flow" that reads the actual source code gives a new engineer the accurate current state of the system, not a document written eighteen months ago and never updated. A domain glossary maintained by generation rather than manual effort stays current. The implicit knowledge that makes senior engineers fast — the conventions, the historical context, the "we tried that and it failed because" — becomes at least partially transferable rather than lost at every attrition event. Designing for the agent era means building systems where that knowledge can be encoded and retrieved, not just held in heads.

The Compounding Advantage

DORA 2025 identifies platform engineering as the foundational capability for AI productivity — not the most exciting finding, but the most durable one (DORA & Google Cloud, 2025). There is a direct correlation between internal platform quality and an organization's ability to convert AI tool adoption into delivery performance. Ninety percent of high-performing organizations have adopted platform engineering in some form. The monorepo with versioned skills is that platform made concrete: a single surface where code, conventions, and executable team processes live and evolve together.

The feedback loop matters here. Better skills produce higher-quality AI output. Higher-quality AI output frees engineering capacity. That capacity reinvests in better skills. Teams that begin this cycle now, while the upfront cost is modest, accumulate an advantage that compounds over time and is difficult to replicate by late adopters. The reason is that skills encode institutional knowledge — and institutional knowledge takes time to develop, codify, and validate. You can purchase the same AI model subscriptions as any competitor. You cannot purchase their CLAUDE.md, their incident runbooks, their ADR history, or the five years of commit messages that trained their conventions. That knowledge lives in the repository or it lives nowhere permanent.

The current moment is early enough that the investment required to build this is still small. A CLAUDE.md file. A skills directory with three well-written workflows. A convention for how process artifacts get reviewed and updated. None of this requires a platform team or a multi-quarter initiative. It requires the organizational belief — the same belief that drove the original monorepo decision — that shared understanding compounds, and that encoding it is worth the time it takes.

The Repository as a Strategic Asset

The original monorepo argument was never about tooling efficiency. It was a bet on shared understanding — the conviction that an engineering organization performs better when it sees itself clearly. That bet has been vindicated at every scale, from Google's 2 billion lines to the startup where the new engineer can read every service on day one. The AI era adds a new dimension to the same bet: shared understanding now has to be machine-readable to be fully leveraged.

Skills, runbooks, and process workflows checked into the repository are how you make accumulated institutional knowledge available to every AI tool pointing at your codebase, in every session, for every engineer on the team. The teams that treat this as a strategic investment in 2026 will have repositories that are materially smarter than their competitors' by 2027. The question for engineering leaders isn't whether to adopt AI tools — that ship has sailed. The question is whether your repository is an intelligence layer yet.

References