How Do You Manage a Big Monolith with AI Coding Agents?
I see this question come up a lot — you're using an AI coding agent to build a monolith, and at some point changing one module breaks three others. Development grinds to a halt. You made the architectural decisions, the agent wrote the code, and now you're stuck babysitting every change.
Here's the thing: this isn't a new problem. It's the same problem you'd have managing a team of developers. And the solutions are the same too.
It's the Same as Managing a Dev Team
Before coding agents existed, how would you handle developers working on interdependent modules? You'd set up contracts between modules, write tests, and establish guardrails. Your AI agent is just another developer on the team — a fast one that doesn't read your mind.
Contracts Between Modules
I'm not talking about UML diagrams. I mean proper TypeScript types and well-defined interfaces. Not a loose dictionary/hash with random key-value pairs — a typed object that says "this is what goes in, this is what comes out." When module A calls module B, there's an explicit type for the boundary.
If a change in module B breaks the contract, the type checker catches it before anything runs. That's it.
Pure Functions
Write code so that most functions are pure — they take input and return output, no side effects. They don't change shared state.
When your agent refactors a pure function, you verify the change by running its tests. Inputs match, outputs match, it works. No hidden state mutations to worry about.
Tests at Module Boundaries
Write tests for each module's public interface. Focus on logic that breaks — computations, transformations, validation rules.
If your agent changes module A and tests for module B fail, you know something crossed a boundary it shouldn't have. The tests tell you before your users do.
Guardrails in AGENTS.md
Your AGENTS.md is how you manage the agent the same way you'd manage a developer. Tell it to:
- Run lint and type checking (if you're using TypeScript) after every edit
- Run tests before committing
- Follow specific patterns for how modules interact
This is the equivalent of code review standards and CI checks for a human team.
A Second Model for Code Review
I use Codex to review the code Claude Opus writes. A fresh model catches things the original author misses — same reason you'd have a second developer review a PR.
That's It
Contracts (types and interfaces), pure functions, tests at module boundaries, guardrails in AGENTS.md, and a second model for code review. The tools are different, but the engineering principles are the same ones that worked before agents existed.