Vibing a Monolith
I’ve been doing a bit of vibe coding over the last few months. I’ve been jumping into forums, watching what other people are building, and I keep seeing the same pattern.
People are building big monoliths with AI. At the start it feels amazing. You move fast, you ship features, the AI is “in the zone”. But then the context keeps growing and growing, and eventually you hit a point where you can’t keep working with the AI anymore. The repo turns into spaghetti, the AI starts missing important details, and you end up needing to ask someone else for help because the project has become a monster.
And I see the exact same thing in my own projects. There’s always a moment where I realize I need a refactor. I need to structure things properly, index things properly, define architecture boundaries, because otherwise the AI is going to miss so much of the context of my application that it becomes actively unhelpful.
Microservices & Monorepo
In my time as a DevOps engineer, working with big companies and startups, I kept coming across something that changed how I thought about scaling codebases: the monorepo.
A monorepo is a single repository where all your applications live. You split it into microservices or micro-frontends, but everything still lives in one place. It’s basically a way to move away from a monolith while keeping a single source of truth.
I don’t want to go deep into what a monorepo is here. You can google it or ask your favorite AI. The important part for this post is how you split your application into microservices and micro-frontends in a way that can actually be managed effectively.
Because the real goal isn’t monorepo as a buzzword. The goal is to stop feeding your AI one massive, tangled blob of context.
Instead of one monolith where the AI has to understand everything at once, you split the system into smaller chunks. Now your AI can work with small, focused context, and each part stays more independent from the rest.
In theory, this should reduce the AI losing focus problem. Fewer wild hallucinations, fewer “it forgot how the auth works”, fewer changes that accidentally break unrelated stuff.
It also enables parallel work. Instead of one monolith that you just keep vibe coding into, you can have multiple sub-agents working on different parts of the application at the same time without constantly conflicting. Frontend, backend, UX flows, infra, whatever.
Monorepo reality check
It sounds simple, right?
Just switch to microservices or micro-frontends, put everything into a single repository, and that’s it.
But no, it’s not that easy.
Monorepos can be a real challenge to handle. There are ways to make it easier, but the tooling complexity is what makes it effort. This is exactly why I probably wouldn’t recommend this approach for a quick MVP.
If you’re trying to launch something fast and you genuinely don’t know if it’s going to live beyond a few weeks, don’t over-engineer it.
But once you have a product you actually want to grow, you know you’re going to add multiple features, you know it’s going to expand, then yes, I’d fully recommend moving to a monorepo approach.
From a Monolith to a Monorepo
I think the best way to approach a monorepo when you already have a monolith is to start splitting your application into different microservices or micro-frontends. That is the first approach.
You need to keep two things in consideration.
First, each of them should be independent from each other. You shouldn’t have any dependencies if possible. That will enable you to keep working on one feature without breaking the others.
Second, backwards compatibility. You can’t just rip the monolith apart and pray. You need a plan so new services can coexist while old functionality still works.
Then there’s deployments. Splitting a system means you now have multiple deployable units, which is great, but you can easily create a CI/CD nightmare if you don’t manage it properly.
There are tools to do this. I would recommend Turborepo for orchestrating tasks and caching across the repo so you are not rebuilding and retesting the world every time you touch one service.
So...Is It Worth It?
Having said all this, is this worth your time?
I would say 100% yes, if your project is going to live long enough to justify the setup cost.
I think in 2026 we’re going to see a move from vibe coding into a more structured AI coding workflow. Spec-driven development, planning, tickets, sprints, basically the stuff we already did as software engineers, because it works.
Instead of evolving one giant monolith forever, we’re going to start evolving into microservices, micro-frontends, and monorepos.
I’m 100% sure there are people working on tools to handle this. I think 2026 is going to be the year where this path becomes much more normal.
First we build big monoliths and ship by vibing with no structure. Then we introduce tickets and sprint planning, which is basically spec-driven development. Now we are hitting the AI version of that same evolution. We need boundaries and context control, and a practical way to do that is to split the system and treat each part as its own focused unit.
If you’re building with AI and you’re building monoliths, have you run into any of these issues? Have you considered moving to a monorepo structure? And if you’re already doing monorepos with AI, what’s been your experience?
Top comments (0)