# Rethinking the correct repo structure for the age of AI Agents

_Published: 2026-08-20_

For small projects, I believe it's becoming increasingly important to have the backend and client in the same repo. This might sound a little ridiculous at first, but in the era of agentic engineering, I think we need to start thinking about how much context we give our AI agents.

The more context the agent has, the faster and more accurately it can build. This relationship is directly proportional.

Take something as simple as developing a database schema:

When two teams work in isolation in separate repositories, one on the frontend and one on the backend. An AI agent working on the backend doesn't generally know what the frontend actually needs. It might not know which fields are required, how certain data is being used, or what relationships are important.

If everything is in a monorepo, the agent can simply look at the frontend code and understand the requirements itself. It can see what the UI expects, how APIs are being called, what data is being displayed, and then build the backend around that context.

You could obviously solve this without a monorepo. You can manually give the agent more context, maintain documentation, write detailed API contracts, or tell it exactly what needs to change. But the point is that you're still manually giving the agent context that it could have discovered itself.

And I think this applies really well to smaller projects like internal tools, startups, SaaS products, dashboards, prototypes, etc.

For example, if I'm building a small internal admin tool, I would much rather have:

```
/apps/web
/apps/api 
/packages/db
```

in one repo than have three separate repos where the agent has to constantly jump between them.

This doesn't mean everyone needs to suddenly move to a monorepo. Large organisations have plenty of valid reasons for separating services and repositories, which is a separate discussion in itself.

There are also workarounds for larger organisations, whether that's MCP, different context protocols, better tooling, or other ways of giving agents access to the context they need. But that's a separate discussion for a different blog.

And obviously, changes like this don't happen overnight. But as we slowly move into this new era of software development, I think it's worth reconsidering some of the assumptions we've made around how projects should be structured.

The codebase isn't only a source of truth for humans anymore. It's increasingly becoming the context window for the agents building it.

And for smaller projects, giving the agent that complete context might be one of the easiest ways to get more velocity while avoiding a lot of unnecessary mistakes.

Lastly, it is not all lalaland since there are definitely some downsides to this approach. You now have additional work in the CI/CD pipeline, more things to consider around deployments, and you may need to be more careful about what gets built and deployed when only one part of the application changes.

There is also the added complexity of managing dependencies and tooling across the different parts of the project.

But for smaller projects, I believe the trade-off is worth considering and most of the times benftifeal. The additional complexity is often relatively small compared to the amount of context and development velocity you gain.