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. As the speed of code generation is increasing exponentially, so does the speed at which a system can either improve or decay.
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?

Kotlin Multiplatform

AI coding agents are reshaping how mobile teams should think about software architecture. While architecture has traditionally helped teams maintain consistency and testability, AI agents introduce new challenges: without clear structure, agents may produce working but fragile code that duplicates logic or introduces inconsistent patterns. At the same time, over-engineering remains a risk since agents make generating boilerplate cheap, but the cognitive cost of understanding and maintaining that code persists. The author argues for a new architectural philosophy that balances simplicity with structure — systems clear enough for both humans and AI agents to extend safely, while still respecting core principles like DRY, KISS, and SOLID.

Architecture in the AI age

Much respect for those had the room for waking through all those architectural approaches, but I recall the reason why progamming languages evolved: to be more human readable. Well, I think we are loosing the position to read code, so all that abstraction will be shortcut due to us: instructing agents what we need, what to test, what to deliver. Less focus on how, less need for human readable internals.