Software Development with AI: Monolith vs Microservices

From monoliths to microservicesOne of software architecture’s longest-running debates has been “monoliths versus microservices”.
The traditional monolith architecture had a lot of valid criticism on the slow release cycles, long compilation times and much more downsides, while the microservices promised independence, then the costs of latency, operations, and distributed debugging.
I always saw possible scenarios for each of the architecture types, depending on the industry, team size, delivery times and the business needs.

In the AI era, with the modern LLMs, the case for the traditional monolith is shrinking:
– Tokens. A small change to a large monolith often requires the agent to analyze far more code than the change touches. A well-architected, independent service has a narrower scope, so fewer tokens go to analysis and implementation.
– Feedback loops are everything. Agents iterate by building and testing, so slow builds compound with every iteration. CI/CD speed is hugely underrated. Yes, a monolith can run selective tests, but that means trusting tooling to know what a change can affect. A service boundary makes that explicit.
– Parallel development. In spec-driven development, independent services let multiple agents work at once, each on a focused, well-specified change. Git worktrees can parallelize work inside a monolith too, but every change still lands in one shared codebase, where conflicts and side effects are harder to rule out.
– A clear definition of “done”. A service with a clear API and a full test suite gives an agent an unambiguous target.

The trade-off: integration failures between services can be reduced through testing, but they are harder to catch than in a monolith, where the compiler flags many of them before anything runs. For me, that’s a price worth paying, and the answer is investing in contract and integration testing.

Modular monoliths will buy some teams time, but I believe they’re a waypoint, not a destination. When agents do most of the coding, the economics favor the smallest independently testable unit.
The winners will be systems with hard, deployable boundaries.

Leave a Reply

Your email address will not be published. Required fields are marked *