Vibecoding
Build for the vibe, debug later
Start new thread
Csaba Ivancza

Setting up monorepos for AI: submodules versus subtrees

by•

I've been building my app for 8 months now, and i ended up having 5 repositories

  • nextjs app

  • databases

  • customer facing API

  • node-sdk that wraps the api

  • react-sdk, for both reusing shared component and customer facing components

So i thought, it's gonna be great if i create a mono repo with submodules. But it was terrible. I realized that turborepo does not like external packages, and as i tried to reuse my own customer facing libs, the DX became terrible. It was very time consuming to ship a feature. Even when i wanted to use Codex or Cursor 3, it was not able to show git diff properly, also i was not able to use Cursor's cloud agents properly to ship complex features.

So after a while i felt that i need to change my setup and i read about git subtrees, it was such a game changer! now i have 3 repos only, one mono repo and two customer facing sdk-s, but i work on the monorepo only, i commit, and then i sync the changes to the sdks with one command.

I use vercel as a backend, and that supports monorepos. Cursor works like a charm, my DX is a dream, i ship features like there's no tomorrow. I love this setup.

I am curious what's ur setup that provides a great DX and also makes ur AI env more productive?

76 views

Add a comment

Replies

Best
Raj Kumar

Submodules felt powerful in theory but in practice they kept getting in the way. The constant syncing and broken context made development slower than expected. Switching to a cleaner monorepo setup brought a noticeable improvement in flow.

Csaba Ivancza

@new_user___0932026a86e905cf4b2b7f7 yes exactly. submodules seems super fine, however that makes life complicated.

Joséphine Roux

STILL EXPERIMENTING with different structures, but this approach makes a strong case for keeping things more centralized. Simplicity seems to win when speed and consistency matter.

Csaba Ivancza

@josephine_roux yep, and even the cloud agents work pretty well. now i have a flow like, during the day i am working on specs, and i trigger them during nights. i start with reviews in the morning.

Adrin D'souza

Bro this is the exact journey I see so many people go through 😂 Submodules + Turborepo is a special kind of hell when Cursor has to index everything. Switched to subtrees last year too and never looked back, one command to push SDK changes is pure chef’s kiss. My current setup that feels magical with Cursor: Turborepo + pnpm workspaces (no external packages nonsense) + one single monorepo for everything except the public SDKs. AI agents actually understand the full context now. What’s your subtree sync command look like? Curious how you scripted it.

Csaba Ivancza

@second_son_of_god i have a bash script that handles all the subtree management, but the important part is here: 

git subtree push --prefix="/path/to/sdk" "sdk_name" "$BRANCH"
Pranav Prakash
I was at this exact spot couple of months back. We have a more complex structure with 12 repos. Did a one time effort of actually putting them together in one monorepo. I didn’t use any specific framework. Just a bunch of directories inside a top level dir (git root). Each dir is it’s own service/app. Works like a charm.
Solal Zanovello

This is a game-changer for AI context management. I’m currently 17, building Aegis Omni-Core (a high-performance no_std Rust kernel), and I hit the same wall with submodules.

When you're working on low-level SIMD optimizations (AVX2), the AI (Cursor/Claude) needs to see the link between the core kernel logic and the architecture-specific crates. Submodules break that "mental model" for the AI, leading to halluciantions about where certain types or macros are defined.

My setup: I moved to a single monorepo using Rust Workspaces. It’s similar to your subtree approach in terms of DX. By keeping everything in one place:

  1. Cursor’s indexing actually works across the kernel and the benchmarks.

  2. Refactoring deep cryptographic traits is 10x faster because the AI understands the dependency graph.

For those shipping SDKs: do you find that keeping the SDK code in the same monorepo helps the AI write better integration tests, or does it get confused by the different environments (e.g., std for SDK vs no_std for core)?

Sai Prakash

We're on the same backend and also, all Cursor users (though I throw in some Claude Code work from time to time). Our NX-based monorepo works extremely well for us:

  • TypeScript-centric - so even MCP services etc can use the same domain logic, schema and other shared libs

  • Rules, shared libs, build system, multiple apps, different outputs - very simple

  • Tailwind-based style tokens and shared UI components - also straightforward

I'm finding myself consolidating more and more standalone service/app repos into the monorepo. Hope that helps.