Lately I’ve been working a lot with Claude and modularizing our monolith with Packwerk and it has got me thinking how much I like that agents thrive in projects with good practices around documentation and rules:
tools that catch violations of style\opinionated practices e.g. Rubocop\Danger
documentation on project structure, concepts (role of a service object, form, presenter etc), design guides
I haven’t really seen this talked about much but I think this is also becoming a major strength of Packwerk. For example, I’m using the layer checker to define a simple hierarchy of “business logic”:
specialized: features that are built using the building blocks of our project in core and supporting
core: core domains that form the heart of the app, should never contain references to specialized
supporting: utility domains that could easily be gems, rarely has dependencies. should never reference core or specialized in order to be resusable
I’ve found this rule being really useful for clueing the Agent in on how we want features built in the app. You could still do this without Packwerk but the added bonus of actually enforcing it if context gets lost\muddled has helped a lot. Its like the difference between saying to developers “we want to avoid ActiveRecord bang methods” and actually being able to enforce that.
We’ve also done some work so Claude can give developers feedback when they hit violations in their code and the feedback from Claude which I’m finding much nicer than Danger since it can contextualize the violation based on the changes and existing violations\dependencies.
Curious about others’ experience with modularization, agents and Packwerk. How have you been finding it?
I believe that a well modularized app will be really important for managing an agent. Modularization is classic “context compaction” for humans, and agents really thrive with clear structure and constraints that make intent clear. Moreover, as a lot of engineer day-to-day work and tasks become largely automated via agents, the role of the human will elevate up to higher orders of abstraction – the system.
In the past, I think one of the issues holding modularization back was, code was expensive, context was cheap, and we didn’t have time to do anything but toil through tasks. Now, everything is flipped… code is cheap, context is expensive, and the issue is now managing our ability to do orders of magnitude more tasks.
In terms of using claude:
We have a claude rule for modularity, where we define the layers and rules of our application. I’m not sure how much it’s honestly helped yet, but I think we need to invest more there in automated rules for claude to understand what patterns of modularity are relevant to your domain.
I’m using an “agent orchestration platform” – a thing I vibe coded that autonomously spawns agents and picks up tasks off linear – to handle the “lots of little things” toil that modularity work often entails.
I think most of the wins will come when the app already has overall pretty good patterns, and then codifying those rules in a rule corpus for the agent. You could then use something like Claude Code GitHub Actions - Claude Code Docs to provide users feedback on how to handle violations, in a way that was previously impossible to automate besides general rules. I think this will be something that will scale really well – but I haven’t pursued it yet at my current org until we’ve reached some critical mass where it’s reasonable to expect someone to follow existing patterns (vs, spend a bunch of time doing side quests to invent new patterns).
Agree with your sentiments, I feel mostly held back at this point with my own inexperience at building the right context
I think most of the wins will come when the app already has overall pretty good patterns, and then codifying those rules in a rule corpus for the agent. You could then use something like Claude Code GitHub Actions - Claude Code Docs to provide users feedback on how to handle violations, in a way that was previously impossible to automate besides general rules.
On this topic, I’ve been thinking about the reverse situation too where agents could deliver value into codebases without an established “Big Rails” architecture. For example, take the idea of a maturity model from this post. Maybe it would be possible to build a packaged context that you could add and use to have an agent guide you into incrementally establishing modularization starting with a low maturity. Step 1 would see the agent guide you through the necessary discussions to determine domains and dependencies, help you set up project structure etc etc
Similar to this but more geared towards Ruby at scale\Packwerk
I love this conversation! Thanks for sharing your experiences!
We’re having similar observations. It was, in fact, the modularity team that first added nested agent context files using their experience in building out our packaging infrastructure.
