The Monolith Problem
When you build an Obsidian vault with Claude Code, you tend to take a complex route and end up with a monolithic structure that grows more and more inflexible as you keep adding things to it. Eventually it gets completely stuck in a specific state, and you can no longer remember all the details and nooks and crannies of it.
The thing I'd say first: don't worry about it. Keep building — eventually you'll start simplifying instead of adding. That's a natural shift. As you learn, you tend to take the hard route. The more you know, the clearer you can describe the goal, and clearer goals lead to simpler solutions.
- I build modular from the start. New things go into their own compartment, so whenever something joins the system, it's easier to reason about how it connects and how it talks to the rest.
- I don't approve individual writes, but I have this dream that I can later actually review things that I add. Unfortunately, I never have time to do this.
- The pipeline becomes reliable enough that skipping it stops feeling necessary — it just runs.
- I'm working toward a model-agnostic setup. To me it feels achievable: the core is the instructions and the knowledge structure, not the specific tool, so switching agents shouldn't be a problem — they all read the same files.
- In my first experience with vibe coding something like this, I also took the difficult route and started with a monolith. I kept adding until I couldn't hold the whole thing in my head anymore. Now I spend more time asking the AI to explain the system back to me than actually using it. At some point it'll make more sense to use the old system as documentation for building a new, more modular one than to keep patching it.
Written in one sitting, edited in three,
Zhenia