One Database, One Repo: Why Multi-Repo Hurts AI Coding

Right now, in the things I’m working on, I have five different repos. I divided some of the job into two repos, some into three. And whenever I need to make a change, it’s a bit of a nightmare.

If you’re familiar with microservices, you know the instinct: segment things, isolate the repository, keep boundaries clean. That’s a good practice. It’s just not a common best practice anymore — not when you’re coding with AI.

AI works very well when it has context. And in a repo, the context is your entire repo.

If AI needs to go back and forth between multiple repos, it will — technically speaking, it can, especially if you’re running it in bypass mode, that kind of stuff. But it won’t do it efficiently. It won’t work as well as it could. And it ends up creating a lot of back and forth between the multiple repos. In practice, that means writing handover files: files whose only job is to pass information from one repo to another, so that repo can execute and get back to you, and so on.

So here’s my recommendation, one simple principle:

One database. One repo. Period.

Even if the repo gets more complex. Even if it needs a lot of different scalability. Even if it ends up with different backend services inside it — I don’t care. Because that way, the AI reuses the majority of what’s already there, instead of rebuilding it somewhere else.

I’m learning this the hard way right now, on my own app. I recently created — I’m still creating — the LLM version of it, the chat piece, and I initially developed it under a different repo. Basically because it scales a different way, that kind of stuff. It made sense on paper.

Now that I’m actually working across both, I found the bad pattern: I’m replicating the same stuff in two different repos. Which is absolutely, one hundred percent, not great.

So I’m following my own principle, the one I’m using to guide you and that should guide me too: I’m rewriting the chat repo to embed it in the same repo where the database lives. It’s going to be way easier.

If you’re about to spin up a new repo because “this part scales differently” — that’s exactly the moment to stop and ask why it can’t just live where the database already lives.