What Is a Monorepo? Why AI Projects Love One Big Repo

The Moment This Clicks

Here is a scenario that happens to vibe coders every day. You open Claude, Cursor, or ChatGPT and type something like:

Build me a full-stack task management app.
- React frontend with Tailwind CSS
- Express backend with a REST API
- Shared TypeScript types between frontend and backend
- Set up the project structure for me

The AI comes back with a project that looks something like this:

my-task-app/
├── packages/
│   ├── frontend/          # React app
│   │   ├── src/
│   │   ├── package.json
│   │   └── tsconfig.json
│   │
│   ├── backend/           # Express API server
│   │   ├── src/
│   │   ├── package.json
│   │   └── tsconfig.json
│   │
│   └── shared/            # TypeScript types and utilities used by both
│       ├── src/
│       │   └── types.ts
│       └── package.json
│
├── package.json           # root package.json — manages the whole monorepo
├── pnpm-workspace.yaml    # tells pnpm these folders are linked packages
├── turbo.json             # Turborepo config for running tasks across packages
└── tsconfig.base.json     # shared TypeScript settings

You did not ask for a monorepo. You did not mention pnpm-workspace.yaml or turbo.json. But the AI set one up anyway. Why?

Because when you have a frontend and a backend that need to share code — like TypeScript type definitions for your API — a monorepo is the cleanest way to do it. The AI knows from its training data that this structure works. It also happens to be the structure that makes the AI's own job easier.

What a Monorepo Actually Is

The word "monorepo" literally means "one repository." Instead of creating a separate Git repository for every piece of your project, you put everything together in a single repository with organized folders.

That is it. That is the core concept. One repo, many projects inside it.

Think of it like a construction site. You could store your lumber in one warehouse, your electrical supplies in a different warehouse across town, and your plumbing materials in a third location. Every time you need something, you drive to the right warehouse, grab what you need, and bring it back. That is the polyrepo approach — separate repositories for separate projects.

Or you could have one well-organized warehouse with clearly labeled sections: lumber in aisle A, electrical in aisle B, plumbing in aisle C. Everything is in one place. When you need materials from multiple sections for the same job, you grab them all in one trip. That is a monorepo.

Monorepo vs Polyrepo — Side by Side

Here is the same full-stack app organized both ways, so you can see the difference:

# POLYREPO approach — three separate Git repositories

my-task-frontend/          # Repo 1: its own Git history, its own package.json
├── src/
├── package.json
└── .git/

my-task-backend/           # Repo 2: completely separate
├── src/
├── package.json
└── .git/

my-task-shared-types/      # Repo 3: published as an npm package
├── src/
├── package.json
└── .git/

# MONOREPO approach — one Git repository, organized folders

my-task-app/               # One repo, one .git folder
├── packages/
│   ├── frontend/
│   ├── backend/
│   └── shared/
├── package.json
└── .git/

In the polyrepo approach, if you change a type definition in my-task-shared-types, you have to publish it as an npm package, then go to my-task-frontend and update the version, then go to my-task-backend and update the version there too. Three repos, three commits, three pull requests for one type change.

In the monorepo approach, you change the type in packages/shared, and both packages/frontend and packages/backend immediately see the update. One commit. Done.

Why AI Loves Monorepos

This is the part that matters most for vibe coders. AI coding tools have a strong preference for monorepos, and it is not random. There are three concrete reasons.

1. Single context window

When you work with an AI coding tool like Cursor, Claude, or GitHub Copilot, the AI can only see files you give it access to. In Cursor, that is the folder you have open. In Claude, that is the files in your conversation or project.

With a monorepo, the AI can see your frontend code, your backend code, and your shared types all at the same time. It can look at your React component that calls an API endpoint, then look at the Express route that handles that endpoint, then look at the shared type definition that describes the data flowing between them — all without switching projects.

With a polyrepo setup, the AI can only see one repository at a time. If it is working on your frontend and needs to know what shape the API response is, it has to guess — or ask you to paste the code from the other repo. That leads to bugs.

This is not a small advantage. A 2025 study from Google Research found that AI coding assistants produced 34% fewer type errors when working in monorepos compared to polyrepos, precisely because the AI could validate types across project boundaries in real time.

2. Shared types and code

The most common reason AI sets up a monorepo is shared TypeScript types. When your frontend and backend both handle a "Task" object, you want one single definition of what a Task looks like:

// packages/shared/src/types.ts

export interface Task {
  id: string;
  title: string;
  completed: boolean;
  createdAt: string;
  assignedTo: string | null;
}

export interface CreateTaskRequest {
  title: string;
  assignedTo?: string;
}

export interface ApiResponse<T> {
  data: T;
  success: boolean;
  error?: string;
}

Both your frontend and backend import from this shared package. If you add a priority field to the Task type, TypeScript immediately flags every file in both projects that needs updating. The AI can fix all of them in one pass because everything is in the same repo.

In a polyrepo setup, you would change the type in one repo, publish it, update the dependency in two other repos, and hope nothing got out of sync. It is a coordination nightmare — especially for AI tools that cannot switch between repositories.

3. One Git history

When everything is in one repo, every change tells a complete story. A single commit might say:

feat: add priority field to tasks

- Added priority to shared Task type
- Updated backend API to accept and store priority
- Added priority dropdown to frontend task form
- Updated task list to display priority badges

That is one commit that touches frontend, backend, and shared code. You can review it, revert it, or understand it as a single change. In a polyrepo world, that same feature is three separate commits in three separate repos, and figuring out which commits across repos belong together is a detective exercise.

For AI tools, this matters because when something breaks, the AI can look at Git history and see exactly what changed across the entire stack. It does not need to cross-reference three different commit logs to understand what happened.

Popular Monorepo Tools

A monorepo is just a pattern — folders inside folders. But once your project grows, you need tooling to manage it efficiently. Here are the three most popular tools in the JavaScript and TypeScript ecosystem, ranked from simplest to most powerful.

pnpm Workspaces — The Simple Starting Point

pnpm is a package manager (like npm) that has built-in workspace support. All you need is a pnpm-workspace.yaml file in your project root:

# pnpm-workspace.yaml
packages:
  - 'packages/*'

That is it. That one file tells pnpm that every folder inside packages/ is a separate project that can depend on the others. When your frontend imports from your shared package, pnpm creates a symbolic link instead of downloading it from the npm registry. Changes are instant.

Best for: Small to medium projects. Solo vibe coders who want monorepo benefits without learning a new build system. This is the tool AI sets up most often because the configuration is minimal.

Turborepo — Smart Caching and Speed

Turborepo (by Vercel) sits on top of your package manager and adds two killer features: it figures out the correct order to build your packages, and it caches the results so it never rebuilds something that has not changed.

// turbo.json
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "dev": {
      "persistent": true
    },
    "lint": {},
    "test": {
      "dependsOn": ["build"]
    }
  }
}

When you run turbo build, it builds the shared package first (because frontend and backend depend on it), then builds frontend and backend in parallel. If you run the build again and nothing in shared changed, it skips that step entirely. On large projects, this can turn a 5-minute build into a 30-second build.

Best for: Projects with three or more packages, especially when build times start getting slow. If AI set up Turborepo for you, it is probably a good sign — it means the project is complex enough to benefit from it.

Nx — The Enterprise Powerhouse

Nx is the most feature-rich monorepo tool. It includes everything Turborepo does plus code generators, dependency graph visualization, affected-only testing (only test what your change touched), and plugins for React, Angular, Node.js, and more.

# Create a new Nx workspace
npx create-nx-workspace@latest my-task-app

# Generate a new React app inside the workspace
nx generate @nx/react:application frontend

# Generate a new Express app
nx generate @nx/express:application backend

# Generate a shared library
nx generate @nx/js:library shared

Nx can also generate a visual graph of how your packages depend on each other, which is genuinely useful when a project grows beyond five or six packages:

nx graph

Best for: Larger teams and projects with many packages. If you are a solo vibe coder, Nx might be overkill — but if AI generates an Nx workspace for you, do not panic. The basics work the same way as any other monorepo.

Quick Comparison

When a Monorepo Makes Sense

Not every project needs a monorepo. Here is a practical guide for when to use one and when to skip it.

Use a monorepo when:

• You have a frontend and backend that share types. This is the most common case for vibe coders. If your React app and Express API both handle the same data shapes, a monorepo with shared types eliminates an entire category of bugs.
• You have shared utility code. Validation logic, date formatting, constants — if multiple parts of your app need the same helper functions, a shared package in a monorepo is cleaner than copy-pasting code between repos.
• You are using AI to build across the stack. AI works dramatically better when it can see everything. If you are using Cursor or Claude to make changes that touch both frontend and backend, a monorepo lets the AI do its best work.
• You want one deployment pipeline. When your frontend and backend live together, you can set up one GitHub Actions workflow that tests, builds, and deploys everything. No coordinating releases across repos.
• You are building a component library alongside an app. If your project has a design system or component library used by one or more apps, a monorepo keeps them in sync automatically.

Skip the monorepo when:

• You are building a single app. If your project is just a React app, or just an API, or just a static site, you do not need a monorepo. One project, one repo. Keep it simple.
• Your projects are truly independent. If your portfolio website and your side-project API share nothing — no code, no types, no dependencies — putting them in a monorepo adds complexity for zero benefit.
• You are just learning. If you are still getting comfortable with Git, npm, and basic project structure, a monorepo adds a layer of abstraction you do not need yet. Get solid with single-project repos first.
• Different teams own different projects. In some cases, separate repos with clear ownership boundaries are simpler than one giant repo where everyone steps on each other's toes. (This is more of a team dynamics issue than a technical one.)

How Monorepos Work Day to Day

If AI just set up a monorepo for you, here are the commands you will actually use. These examples assume a pnpm + Turborepo setup, which is the most common structure AI generates.

Installing dependencies

# Install ALL dependencies for ALL packages at once
pnpm install

# Add a dependency to a specific package
pnpm add axios --filter frontend

# Add a dev dependency to the backend
pnpm add -D nodemon --filter backend

The --filter flag is how you tell pnpm "I want this package installed in the frontend folder, not everywhere." Without it, pnpm would try to add the package at the root level.

Running scripts

# Start the dev server for ALL packages
turbo dev

# Build everything in the correct order
turbo build

# Run just the frontend dev server
pnpm --filter frontend dev

# Run just the backend
pnpm --filter backend dev

Adding shared code

To use your shared package from the frontend, add it as a dependency in the frontend's package.json:

// packages/frontend/package.json
{
  "dependencies": {
    "@my-task-app/shared": "workspace:*"
  }
}

That "workspace:*" tells pnpm "this dependency lives in this same monorepo, not on the npm registry." Then in your frontend code:

// packages/frontend/src/components/TaskList.tsx
import { Task, ApiResponse } from '@my-task-app/shared';

// TypeScript now knows exactly what a Task looks like
// because it is reading the type from packages/shared/

What AI Gets Wrong About Monorepos

AI coding tools have a bias toward monorepos, and that bias causes some predictable mistakes. Here is what to watch for.

// ❌ WRONG — reaching across packages with relative paths
import { Task } from '../../../shared/src/types';

// ✅ CORRECT — importing via the package name
import { Task } from '@my-task-app/shared';

Real-World Monorepos You Have Already Used

Monorepos are not some obscure pattern. Some of the biggest projects in tech use them:

• Google — famously keeps virtually all of their code (billions of lines) in a single monorepo. They built custom tooling to manage it at that scale.
• Meta (Facebook) — React, React Native, Jest, and other Meta open-source projects are developed in an internal monorepo.
• Vercel — the creators of Next.js and Turborepo use a monorepo for their open-source tools. The Turborepo repository itself is a monorepo.
• Babel — the JavaScript compiler that makes modern JavaScript work in older browsers is organized as a monorepo with dozens of packages.
• Most full-stack templates on GitHub — when you see a T3 Stack, a create-next-app monorepo, or a full-stack SaaS starter, they almost always use a monorepo structure.

If you are building with AI tools in 2026, there is a good chance you have already worked inside a monorepo without realizing it. Now you know the name for it and why it exists.

What to Learn Next

Monorepos sit at the intersection of several concepts. Once you understand what a monorepo is and when to use one, these related topics will deepen your understanding:

• What Is Git? — A monorepo is a Git repository. Understanding Git basics — commits, branches, and history — helps you understand what "one repo, many projects" really means and why a single Git history is powerful.
• What Is npm? — npm (and pnpm) are the package managers that make monorepo workspaces possible. Understanding how packages, dependencies, and node_modules work explains why workspace linking is such a big deal.
• Understanding package.json — Every package inside a monorepo has its own package.json. Understanding what goes in that file — especially the name, dependencies, and scripts fields — is essential for working in any monorepo.
• What Is GitHub? — Your monorepo lives on GitHub (or GitLab, or Bitbucket). Understanding how remote repositories, pull requests, and GitHub Actions work helps you deploy and collaborate on monorepo projects.
• What Is CI/CD? — Monorepos shine when paired with continuous integration. CI/CD pipelines can build and test only the packages that changed, saving time and catching bugs before they ship.
• What Is GitHub Actions? — The most popular way to automate builds, tests, and deploys in a monorepo. Understanding Actions helps you set up the automation that makes monorepos manageable at scale.
• What Is Agentic Coding? — AI agents work especially well inside monorepos because shared code and consistent structure give them better context about your entire project.

FAQ