AI News Hub Logo

AI News Hub

Architecture in the AI age

DEV Community
Mark Kazakov

For years, mobile engineering teams treated architecture as a core part of professional development. On Android, we debated MVC, MVP, MVVM, MVI, Clean Architecture, modularization, dependency injection, repositories, use cases, and feature modules. On iOS, we had similar debates around MVC, MVVM, VIPER, The Composable Architecture, coordinators, service layers, dependency containers, and state management. The goal was always reasonable. Architecture helped teams build apps that were easier to understand, test, scale, and maintain. It gave developers a shared language. It helped new team members know where code should live. It reduced the risk that every feature would be implemented in a different style. But AI coding agents are changing the development process. When an AI agent can generate large parts of the implementation, refactor code, write tests, and connect multiple parts of a feature, we should ask a serious question: do we still need the same emphasis on architecture, or do we need a different kind of architecture? One argument says architecture becomes even more important. AI agents are powerful, but they need clear boundaries. Without structure, an agent may produce code that works locally but weakens the system over time. It may duplicate logic, bypass existing patterns, create unnecessary abstractions, or introduce a new style that does not match the rest of the app. In that sense, architecture becomes a guide for the agent. It tells the system how decisions are made, where logic belongs, how data flows, how errors are handled, and what kind of change is acceptable. A clear architecture is not only for humans anymore. It becomes part of the working environment for AI. There is also a strong argument in the other direction. Mobile teams have sometimes overused architecture. We have all seen simple features become heavy because every small thing had to pass through too many layers. Sometimes architecture protects a product. Sometimes it only protects an idea of technical purity. AI can make this worse. Since agents can generate boilerplate quickly, teams may accept more layers because the cost of writing them feels low. But the cost of understanding, reviewing, debugging, and evolving that code is still real. Generated complexity is still complexity. In an era where the agent is the main coder, we need to adapt our architectural thinking accordingly. I believe we need new architectural approaches where the core principles of software engineering are still respected: DRY, KISS, SOLID, clear boundaries, testability, and maintainability. But the implementation also needs to be easy to follow, easy to review, and easy for both humans and agents to extend safely. Maybe the next evolution of mobile architecture is not about adding more layers, maybe it's about creating systems that are simple enough for agents to work with, structured enough to prevent chaos, and clear enough for humans to trust. That might be the real architectural challenge of the AI age. What do you think?