Monorepos at Scale with Santosh Yadav

🎧 New Señors @ Scale Episode

This week, I spoke with Santosh Yadav, principal developer advocate at CodeRabbit, an Angular Google Developer Expert, a GitHub Star, and an Nx champion. Santosh wrote his first code — C, in college — back in 2004 and hated it, then fell for C# by 2008 and started getting paid to code. In 2019 he started doing the open source he'd wanted to do for years, raising PRs for NgRx and Angular, writing blogs, and making friends in the community. That year of contribution turned into a stack of titles: GDE, then GitHub Star (one of roughly 80 in the world), then Nx champion, then Microsoft MVP. As a staff software engineer at Celonis he led the move to module federation and drove Nx adoption across 30-plus teams.

In this episode, we dig into what those community programs actually mean and how you earn them, why Celonis moved 20-plus apps off a single deployable unit to a module-federated Nx monorepo, why monorepos beat polyrepos in the age of AI, how Nx keeps a 20-million-line codebase healthy with affected graphs and build caching, and what CodeRabbit is building for code review and open source.

⚙️ Main Takeaways

1. The community titles are a byproduct, never the goal

Santosh holds GDE, GitHub Star, Nx champion, and Microsoft MVP — and insists none of them were targets.

• It's all community work: "Most of the programs which are out there, it's mostly around the community work you do for those particular communities." He became a GDE in 2019 off Angular and NgRx contributions, blogs, and friendships made on the internet.
• GitHub Star is tiny and exclusive: Launched in 2020 (the big in-person announcement got killed by the pandemic), there are close to 80 Stars in the world. Santosh got nominated, still has "no idea like how and why," and ended up surrounded by people like Dennis from Curl, Sebastián from FastAPI, and Daniel Roe from Nuxt.
• The Nx champion origin: He was using Nx heavily at work, spoke at Nx's first US conference in 2022, and literally stood on stage waiting for them to launch the ambassador program so he could join.
• The throughline: "My focus was community always." The recognition, travel, and access came after.

2. How the GDE process actually works

For anyone curious what's behind these badges, Santosh walked through the GDE pipeline.

• Three steps: You're nominated (by an existing GDE or a Googler), then a first interview, then a second interview with the relevant Google team.
• The nerve-wracking first call: His interviewer was a friend from Twitter who works at Microsoft. After preparing "like crazy," the call was five minutes: "I don't have any question. If you want to ask me any questions, go ahead."
• The category interview: The second is with the dev rel for your category — web, Go, Gen AI, Angular. For Santosh it was the Angular dev rel asking what he likes and dislikes about Angular, to check he actually knows and cares about the tech rather than "just faking it because you just want to be in the program."

3. The real benefit of the programs is networking and access

Beyond recognition, Santosh was concrete about what the titles buy you.

• Travel and events: GitHub flies Stars to GitHub Universe every year. GDE supports travel and stay (a limited amount) when he submits a talk to a conference within Europe.
• Networking you'd never get otherwise: "The best part, I would say, is not anything apart from networking. You get to hang out with these people probably you will never meet in your life."
• Direct access to teams: As an Nx champion (and via GDE and GitHub), he can reach into the Slack and ask the Angular, GitHub, or Nx teams directly when he has a doubt. Nx champion also gives credibility with companies already using Nx.

4. Why Celonis moved 20+ apps to module federation

The product had become one giant single deployable unit, and it was hurting everyone.

• The pain: Teams built in silos, with a lot of code duplication and duplicate effort. Code sharing became an issue over time. Releases were slow because there was no way to test everything together — the whole product was one deployable unit.
• The runtime model: With the baked-in module federation solution, teams pushed their compiled JavaScript bundle into a database, and at runtime the app fetched and rendered the bundles.
• The version trap: "You have to be on compatible version in case you are switching between multiple apps." One app couldn't move to a new Angular version without breaking someone else — and the tooling to solve that didn't exist.
• The growth that forced it: Celonis grew rapidly from 2015 to 2020, jumping from four apps to more than 20-30. A POC convinced everyone, and there was surprisingly little hesitation. The hard study and the decision to go with Nx had been made before Santosh joined — his job was to convince more people to come along.

5. In the age of AI, polyrepos starve your tools of context

Santosh's take on monorepo vs. polyrepo has flipped hard toward monorepo — and AI is the reason.

• Context is the killer problem: "The biggest problem with Polyrepo is the context." AI tools can read the context of the current codebase, but they can't reach across a polyrepo to figure out how everything is structured or how a change ripples through.
• Monorepos give the graph: Inside a monorepo, AI harnesses can take the dependency graph, take a file, and figure out how a change impacts the whole codebase — "which is hard to do it in Polyrepo."
• The full-stack demo: In a recent Istanbul talk he asked an agent to "create the checkout page for this web application" and it went front end to back end. "Your AI models are actually full stack developers. They don't care about your stack."
• The separation polyrepos enforced is obsolete: Polyrepos were good when you needed front end and back end teams cleanly separated. "Do we need that in the age of AI? The answer is no... you're just wasting your tokens."

6. Code sharing and versioning are where polyrepos rot

Even setting AI aside, Santosh sees structural problems polyrepos can't dodge.

• The dumping ground: Someone creates a shared library to share a bit of code, "and then it becomes a dumping ground basically." People keep dumping functions in, it grows huge, and it causes problems.
• The versioning bottleneck: In a polyrepo you end up with different versions of Angular or React across the org, and the shared library has to support every one of them. Someone has to dedicatedly maintain it and "cannot do anything else."
• In a monorepo, everyone owns it: "If this is a shared library, everyone is the owner. It's not like a single person's job." And hundreds of developers reviewing the code beats one person's judgment — "100 people's mind is better than one... they have 100 different ideas."

7. Migrate back to a monorepo incrementally, with collaboration as the bottleneck

For anyone sold on monorepos but sitting on 20-30 polyrepos, Santosh's advice is process-first.

• Never a single blast: They took it in multiple iterations. "It took us more than like almost close to a year before we migrated everything." Migrate the critical apps first, the less critical later.
• Collaboration, not migration, is the hard part: The core team was tiny — three or four people — so most of the time went into collaboration, not the technical migration. Pull a person from each team being migrated to help.
• Offer to do it for them: Some teams had only backend developers doing Angular. The deal: "You don't have to worry about it. We will do it for you," in exchange for them contributing afterward and deleting the old polyrepo code.
• Education answers the fear: The biggest question everyone asked was "are you losing your control over the code base?" The answer is education plus support plus the big picture — and tools like CodeOwners to manage independence inside a monorepo.

8. The monorepo pain points — and how Nx attacks them

Santosh asked me to go first on downsides, and we landed in the same place: CI/CD.

• Long CI and shared blast radius: Big monorepos mean long pipelines, and one broken pipeline blocks everyone, especially with a single build. I mentioned a Datadog engineer's ~20-million-line monorepo where linting and TypeScript scanning of the whole base took forever.
• Affected graph: Nx detects what to build. Change project A and it doesn't rebuild B and ten others — it computes an affected graph and figures out what actually needs rebuilding, locally and on CI.
• Build caching, including distributed: Nx caches builds and can do distributed caching — via Nx Cloud (paid) or your own S3 bucket as the cheaper option.
• The monolith parallel: "If you think about monoliths and monorepos, the only difference is monoliths were the single deployable unit." Java and .NET had multiple projects in one place long before front end made monorepos famous — and build time was their biggest pain too.

9. Revisit your linting and tests — and don't let AI bloat your CI

A lot of CI pain is self-inflicted maintenance debt.

• Linting rules go stale: "One common mistake which people do is, once they add linting rule, they never revisit that." TypeScript's internals now cover some of what lint rules used to. Revisit your lint rules every six months.
• AI is writing useless tests: "A lot of teams actually... because now it's AI, they just write tests which are not at all useful." That increases CI time and maintenance time, since breaking tests have to be fixed.
• Don't test the same thing three ways: Decide whether unit or end-to-end tests are more useful for you and stop repeating the same assertions across test types — "your CI time is being wasted. Your developers time is being wasted."

10. Architect the monorepo so a shared library isn't changing five times a day

Tooling helps, but structure is on you.

• The anti-pattern: A shared library used by all your apps that changes five times a day means "you're doing something wrong." Because its blast radius is the entire monorepo, your whole 20-million-line codebase gets affected and rebuilt.
• Nx Graph as a judgment tool: "As soon as I found that this thing exists, it helped me a lot to make sure I'm making better judgment when I'm creating a new app or new library." He checks what a change affects before committing to keep CI time down.
• Teaching never stops: "If you are a monorepo expert, you have to always teach the developers within team how to use these tools and make your code better in future."

11. What Nx actually is — and start with it from day one

We'd said "Nx" a dozen times, so Santosh defined it for listeners.

• A meta build tool: "It's a build tool basically at the end. I can call it as a meta build tool." It offers monorepo support but works for monoliths and polyrepos too, and it's framework- and technology-independent — you can even drop it into an old Gulp-based project.
• Opinionated, standard commands: React has ten ways to set up a project; Nx bakes the commands in. Want a library? Pick Vite, esbuild, or RSpack. Same for Angular. "You don't have to remember like 10 different CLI commands."
• nx migrate is a superpower: A lot of projects never upgrade because they don't know how. nx migrate works with React, Vue, Angular, .NET, and Java, scanning changelogs and handling the upgrade for you — keeping the codebase from rotting, developers learning new APIs, and security vulnerabilities down.
• Start with it new: "If you're starting a new project, just start with Nx. I mean, it doesn't matter anymore." His first-ever Nx project was an Angular CLI app he migrated after two years; the team's reaction was "we should have done this from day one."

12. CodeRabbit: code review, free for open source, plus an AI slop detector

Santosh's day job is developer advocacy and open source at CodeRabbit.

• What it is: Started in 2023 as one of the first companies doing AI code reviews. Code review is still the main product; they've also announced Slackbot, a Slack agent that knows your workspace and can connect to GitHub, Linear, Datadog — query the top errors, fix the top three, run a sandbox, raise the PR.
• Free for open source, not nerfed: "Same product, we give it for free for open source." They committed close to a million dollars last year for open source developers — already distributing more than 600k — and absorb the (expensive Anthropic and OpenAI) token costs without bragging about it.
• The AI slop detector: A new feature for open source repos that flags low-quality AI-generated PRs maintainers are being bombarded with. They soft-launched it and spent a month tuning down false positives, because "even if false positive is like... 50%... people will not care about it in future."
• Multiple models, internal evals: They shuffle between Anthropic and OpenAI based on the use case (code review vs. summary vs. sequence diagram) and run a detailed eval against close to 40 models, re-evaluating whenever a new model ships.

13. Anthropic's own code reviewer didn't cause panic — it caused signups

I asked the delicate question: how did it feel when Claude shipped a code reviewer?

• No panic at the office: "We saw more signups actually." When Anthropic announced, people tagged CodeRabbit, saw the pricing, and said "CodeRabbit is way cheaper than this."
• The cost math: Anthropic charges around $20 per PR; even with a Claude Code subscription, "if you do 10 reviews per day your $200 is gone."
• No churn tick: People on threads asked "what is CodeRabbit?" and a lot of signups came in. It busts the myth that every OpenAI or Claude feature destroys startups — though Santosh notes it really depends what market you're in, and thin wrappers did get wiped out in the early GPT days.

🧠 What I Learned

• The community titles — GDE, GitHub Star, Nx champion, MVP — are a byproduct of community work, never the goal. There are only around 80 GitHub Stars in the world.
• The GDE process is three steps: nomination by a GDE or Googler, a first interview, then a category interview to check you actually know and care about the tech.
• The biggest benefit of these programs is networking and direct Slack access to the Angular, GitHub, and Nx teams.
• Celonis moved 20+ apps to module federation because a single deployable unit meant silos, duplication, slow releases, and an Angular-version trap where one app's upgrade broke another.
• In the age of AI, polyrepos starve your tools of context — a monorepo lets an AI harness use the dependency graph to figure out a change's blast radius.
• Shared libraries in polyrepos rot into dumping grounds with brutal versioning; in a monorepo everyone owns the shared library.
• Migrate to a monorepo incrementally over ~a year, critical apps first, with collaboration (not the technical migration) as the real bottleneck.
• Nx attacks CI pain with an affected graph and build caching (Nx Cloud or your own S3 bucket).
• Revisit linting rules every six months, and watch out for AI writing useless tests that bloat CI.
• Architect the monorepo so no shared library is changing five times a day — its blast radius is the whole repo. Use Nx Graph to check what a change affects.
• Nx is a framework-independent meta build tool; start with it from day one, and nx migrate keeps your codebase from rotting.
• CodeRabbit runs code review free for open source (committed ~$1M last year), shuffles between Anthropic and OpenAI, and shipped an AI slop detector to flag low-quality AI PRs.
• Anthropic shipping its own code reviewer caused signups, not churn — busting the myth that every big-lab feature kills startups.

💬 Favorite Quotes

"It's all about community, right? I think most of the programs which are out there, it's mostly around the community work you do for those particular communities."

"My focus was community always."

"The best part, I would say, is not anything apart from networking. You get to hang out with these people probably you will never meet in your life."

"Your AI models are actually full stack developers. They don't care about your stack."

"Do we need that in the age of AI? The answer is no. In case you're doing that, you are actually just not using it carefully, then you're just wasting your tokens."

"If this is a shared library, everyone is the owner. It's not like a single person's job."

"One common mistake which people do is, once they add linting rule, they never revisit that."

"It's a build tool basically at the end. I can call it as a meta build tool."

"If you're starting a new project, just start with Nx. I mean, it doesn't matter anymore."

"Same product, we give it for free for open source."

🎯 Also in this Episode

• Santosh's origin: writing C in college in 2004 and thinking "what the hell is this," then falling for C# by 2008 and getting paid to code professionally
• The GitHub Stars cohort: Dennis Steinberg from Curl, Sebastián from FastAPI, Daniel Roe from Nuxt
• Speaking at Nx's first-ever US conference in 2022 and standing on stage waiting for the champion program to launch
• His first Angular conference, in Sri Lanka, while terrified and prepping for the GDE interview
• CodeRabbit's Slackbot demo: query Datadog for the top five errors, fix the top three, spin up a sandbox, raise the PR
• Other open source guests bombarded with trash AI PRs — TkDodo and Mark Erikson from Redux — which seeded the AI slop detector conversation
• Working more hours than ever because "this AI thing is actually moving so fast," and not wanting to be the guy who comes on a podcast and "talk about shit"
• Book recommendations: The Staff Engineer's Path, Refactoring ("like the Bible"), The First 90 Days, The Sciences of the Artificial (1969), and Murakami's What I Talk About When I Talk About Running; I recommended Born to Run
• Running talk: Santosh did five half marathons last year before an injury, now sticking to 5K and working toward 10K

Resources

More from Santosh & the tools mentioned:

• Nx — The build tool / monorepo system Santosh champions
• CodeRabbit — AI code review, free for open source
• Turborepo — The Vercel-maintained monorepo tool CodeRabbit currently uses
• Angular — Where Santosh's open source contributions started
• NgRx — State management for Angular, his first contributions
• Nx Graph and nx migrate — Nx's dependency-graph visualizer and version migration command
• CodeRabbit Slackbot and the AI slop detector — described in the episode (check CodeRabbit's announcements for availability)

Books mentioned:

• The Staff Engineer's Path by Tanya Reilly
• Refactoring by Martin Fowler
• The First 90 Days by Michael D. Watkins
• The Sciences of the Artificial by Herbert A. Simon (1969)
• What I Talk About When I Talk About Running by Haruki Murakami
• Born to Run by Christopher McDougall (Dan's recommendation)

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 58 minutes on Nx, monorepos vs. polyrepos in the age of AI, the year-long migration off a single deployable unit, build caching and affected graphs, and running code review for free for open source at CodeRabbit.

Whether you're sitting on a pile of polyrepos wondering if it's time to consolidate, or maintaining a 20-million-line monorepo that's grinding your CI to a halt, this conversation is grounded in someone who actually shipped the migration at scale.

Happy migrating,
Dan