Architects favor self-contained systems for AI-driven full-stack development

Software architects argue that Self-Contained Systems, defined as microservices with their own web interface and data storage, are the optimal architectural pattern for AI-driven software development. Because AI agents function as full-stack developers, they do not require the separation of backend and frontend teams, making the vertical, self-contained slice of Self-Contained Systems a natural fit. This architecture allows AI to work within a smaller blast radius and independent context. Practitioners note that Self-Contained Systems enable teams to use Testcontainers with generated test data for local development without relying on other running services, facilitating independent development. The approach is contrasted with microservices and microfrontends, where mapping use cases to specific components is described as a significant challenge. Self-Contained Systems are also cited as a method to modernize legacy monoliths faster by replacing individual parts rather than the entire system, a process that can take three to five years for monoliths. However, a significant portion of the discussion addresses the reality of system integration, noting that in insurance and banking sectors, approximately 80% of integration between systems still occurs via shared databases rather than defined interfaces. While architects advocate for information hiding and asynchronous data replication to ensure resilience, practitioners acknowledge that shared database access is often the path of least resistance. The debate highlights a tension between ideal architectural principles and practical constraints, as shared infrastructure can lead to coupled failures and complex upgrade cycles. The organizational challenges of implementing Self-Contained Systems include the trade-off between team autonomy and code consistency. A listener comment highlighted that Self-Contained Systems can lead to significant code duplication, particularly in web frontends, when managing more than 20 teams. In response, architects discuss the use of design systems, shared libraries, and architecture decision records to mitigate inconsistency without sacrificing independence. They argue that while some duplication is an acceptable price for resilience and independent deployability, strict enforcement of a single framework can lead to dramatic negative consequences if that framework is technically flawed. The discussion also covers the difficulty of assigning new features to the correct team, noting that bottleneck systems like checkout processes often require cross-team coordination.