Modularize early, please
The biggest mistake you can make at the beginning of your project is not splitting things up.
It’s so nice to see how agents just magically write code and it works. But I’ve observed that both humans and agents tend to keep adding code in existing modules instead of creating new ones.
It is easy to just add one more field, one more function, one more class into the existing structure and move on. Code reviews also often miss this very important aspect unless reviewers are looking at this specifically. And trust me they usually don’t.
So as projects grow they tend to accumulate modularization debt. The lack of isolation and boundaries between components allows to move fast at first but slow you down significantly later down the road:
- Messy dependencies make it hard to reason about the code both for you and for your LLM which has to read more and more unrelated context.
- Interconnected build graph does not allow you to test things in isolation.
I’ve seen projects follow this path over and over again. You think it’s fine for now. You think you’ll do it later. You mock your colleagues that are stuck supporting a legacy codebase while you move so fast in you greenfield project. But give it enough time and you’ll get 30min build times in your CI. And you burn through your 1 million token context window in 5 minutes.
How to avoid this?
Sane build graph is your only solution to keep your builds, tests, IDEs and deploys fast. Just tell your yourself and your LLM to modularize. If you see an opportunity to move code to a separate package - do it now. Force yourself and agents to think about the module graph. Avoid circular dependencies. Consider adopting Bazel, it’s not scary anymore. Keep your packages small and single-purpose. Make adding new package a default for new features unless there is a clear reason not to.
Use PNPM workspaces for UI, use crates for Rust, use libraries for Go. But please, modularize now. It’s not that hard and you will thank yourself later.