How it works
Instead of having one repository per project, everything lives in a single repo. Tools like Turborepo, Nx, and Bazel manage dependencies, builds, and tests. Companies like Google and Meta use monorepos for thousands of projects.
The typical structure has a folder per project or package, with code sharing through internal packages. Changes that affect multiple projects are made in a single commit and tested together.
Monorepos require proper tooling. Without it, slow builds and merge conflicts make the experience painful. With it, coordination across teams improves significantly.
Practical example
An AI startup might have a monorepo with the backend (API), frontend (dashboard), shared prompt library, and training scripts. Changes that affect multiple projects are made in a single commit and tested together.
If a developer changes the API interface, CI/CD automatically tests the frontend that consumes that API. This prevents changes from breaking integration between projects.
What it's for
Simplify code sharing, ensure consistency, and enable large-scale refactoring. For AI teams, a monorepo lets you version model code, prompts, and applications together.
For developers, this means less overhead managing multiple repositories. For teams, it means better collaboration and visibility into what's happening across the entire project.
Difference between monorepo and multirepo
Monorepo: one repository for everything. Makes sharing and coordination easier, but can be heavy for large teams without the right tools. Multirepo: one repository per project. Simpler to manage individually, but makes code sharing and coordination harder.
The choice depends on team size, project complexity, and available tools. Small teams usually prefer monorepo. Large teams may use multirepo with synchronization tools.