How does AI-based development change software architectures?
How does AI-based development change software architectures?
For a long time, software projects were mainly developed as monoliths. With the rise of microservices, a paradigm shift began: Large development teams in particular relied on cutting complexity into many independent services, microservice-based architectures were on the rise. But with the advent of AI-driven development, we might be witnessing a turning point. Why modular monoliths are the better foundation for most projects and when microservices still remain the right choice.
Architecture concepts in large software projects: From monoliths to microservices
For over a decade, monoliths were the natural way to build software: one application, one build, one deployment. This worked well for many projects as long as systems remained manageable. As systems grew and the number of developers or teams in a project increased, friction losses increased. Changes in one place had unforeseen consequences in another, and the more developers worked on the same codebase, the more often they got in each other's way. Microservices were the answer: many small, independently deployable services, each taking on a clearly defined part of the functionality. The promise was scalability, team autonomy, and improved maintainability. Particularly large organizations with many teams working in parallel benefited because each team could independently develop and deliver its service. Over the years, this division was the obvious answer to growing systems, and the term "monolith" took on a pejorative connotation. And there's also something in between, often referred to as a modular monolith. In this, monoliths are divided into clear functional modules with technically enforced dependency rules and clearly separated responsibilities. The difference from microservices is not in the modularity but in the fact that the modules initially remain within a shared codebase and deployment.
How AI is changing software architecture
With AI tools like Claude Code, Codex, or GitHub Copilot, a factor has been introduced that could change the architectural trade-offs. These tools can generate, analyze, and change code faster than was conceivable a few years ago. Under what conditions do they deliver the best results?
This shifts the actual question. It is no longer "Monoliths or microservices?", but rather: Which architecture makes AI-driven development efficient?
If you place the architectures side by side from the perspective of an AI agent, a clear pattern emerges, specifically where AI agents work concretely: reading, changing, and checking code.
Microservices were initially considered the ideal foundation at the beginning of AI development precisely because their services are cleanly encapsulated and clearly defined. Due to the smaller context windows of AI agents at that time, individual, small services initially seemed ideal for AI-driven development.
Monoliths, with their large codebase, were simply too large for the context windows of AI agents. However, due to the evolution of AI agents and the enormous enlargement of context windows, this assumption no longer holds. Large, modularly divided software projects can also be captured by the context of AI agents.
In our experience, AI agents now deliver the best results when the relevant context is in one place, is easily navigable, and they can quickly validate their changes. AI agents become reliable when they can immediately verify their own work.
AI agents that change a function must understand who calls it, what data structures it affects, and what tests secure it. In a modular monolith, these connections are visible in the same codebase and the AI agents can follow them.
For accesses between services, connections become difficult for AI agents to verify. A dependency that leads from one service to another through an API often only appears in an API specification or a dependency graph. A recent study, in which leading AI agents were to extend existing microservices, clearly shows this. With incremental work on existing code, the success rate of unit tests was only between 50 and 76 percent, and errors accumulated where cross-service interfaces were involved (Adnan et al., 2026).
The reason is structural. In a monolith, compilers and tests check if two modules fit together. Across a service boundary, this is usually not automatic; the contract between two services often only exists as documentation. The effort for contract tests, OpenAPI specifications, consumer-driven contracts, schema registry, integration tests, etc., is rarely invested.
A chain of rapid, automatic controls ensures this: Type checks ensure that data types match, Linters report style and oversights, testsverify behavior, and the build shows whether the whole thing can be translated at all. In modular monoliths, these feedback loops operate locally and very quickly. In a distributed landscape, it often requires several running services, mock servers, and integration environments.
Perhaps the most important contribution is provided by the DORA Report 2025 from Google Cloud, one of the largest industry surveys. Its central finding is: AI acts as a magnifier of existing strengths and weaknesses.Teams with loosely coupled architecture and fast feedback loops gain significantly with AI, while teams in tightly coupled, slow systems do not. The key is how the report understands "loose coupling": as the ability of a team to change, test, and deliver its components independently from others, not as a question of whether these components are distributed over the network. Modular monoliths with clean boundaries meet these criteria as well and provide the fast feedback loops the report cites as the second important lever.
The costs of further development
Every architectural decision is particularly reflected in one area over the years: in the costs of further development. Not only the initial draft of a system is expensive, but also everything that comes after it: every change, every expansion, every bug fix. In a distributed architecture, these ongoing costs remain permanently higher. Distributed systems have a price often called the "Distributed System Tax." Once data crosses service boundaries, complexity increases sharply: network error handling, service versioning, distributed monitoring, and the interplay of many deployments are added. In practice, this additional complexity regularly binds significant development capacity, which does not flow into new functions but into operation, monitoring, and error analysis. In particular, in large distributed teams, the coordination and communication effort increases significantly. These efforts, however, do not flow into new functions, but essentially into managing distribution. This effort does not disappear with AI agents but rather grows. Because agents become blind at service boundaries, cross-service work remains manual. The team at Segment, which brought over 140 microservices back into a single system, shows how big the difference can be in practice. The runtime of various tests dropped from several minutes to a few milliseconds per run, precisely that fast feedback loop AI agents rely on.
When are microservices still sensible?
This is not an argument against microservices themselves. There remain clear situations where distribution is worthwhile, and then we recommend them without hesitation:
Different scaling. When individual parts of a system need to scale completely differently from the rest, such as a compute-intensive image processing alongside a lightweight management interface, a separately scalable service is the clean solution.
Separate data retention for security or compliance reasons. If certain data must be strictly isolated from each other, for example due to regulatory requirements or internal security policies, a strict service and data boundary is often mandatory.
These reasons usually concern individual components or functions and not the whole system.
Our recommendation
For most projects, from medium-sized businesses to many initiatives of large clients, our recommendation is therefore: Rely on modular monoliths and make them "agent-ready" specifically.Only when a system reaches one of the mentioned thresholds, such as significantly different scaling, strict data separation, or many independent teams, does it make sense to move to distribution, and then specifically for the affected parts, not for the entire system.
The effort, which previously would have gone into splitting into microservices, is better invested elsewhere in modular monoliths. Three measures turn an ordinary monolith into one where AI agents remain permanently productive:
Enforce module boundaries technically, instead of just documenting them.A documented boundary is a request, an enforced boundary is a rule. Specifically, this means: The allowed dependencies between the modules are stored in the build and checked by automated architecture tests. If a module illegally accesses the internals of another, the test fails, regardless of whether the violation was caused by a human or an AI agent. This keeps the architecture intact even at high change speeds.
Codify context. Conventions, architectural decisions, and module responsibilities belong as versioned files in the code base, which both the team and the AI tools can read. What is documented and discoverable does not need to be guessed by the AI agents.
Provide fast, reliable feedback loops.Type checking, linters, rapid tests, and a quick build form the control instance where the AI agents measure their own work. The faster and more reliable this loop, the more reliable the result.
This way, you get both: the modularity that AI agents need for their productivity and the simplicity of a single system that can be developed quickly and cost-effectively. At the same time, you keep the door open to later extract individual modules if a specific reason arises.
The rule of thumb for the last ten years, when in doubt, divide, was a response to the tools of its time. With AI-driven development, these tools have changed, and with them the right answer. For most projects today it means: modular monoliths that are built from the start to collaborate with AI agents.
Are you considering how to make your software future-proof and AI-ready? Talk to us, we will examine your situation together.
Share this post