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?

A squad dedicated to devs who primarily develop within the Android ecosystem.

Any articles posted here should be somehow related to Android development. This includes things like Jetpack Compose, Android Views, Kotlin, supporting libraries, etc.

Android Developers

AI coding agents are reshaping how mobile teams should think about 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 cost of understanding and maintaining that complexity is unchanged. The author argues for a new architectural philosophy that respects core principles (DRY, KISS, SOLID) while being simple enough for agents to extend safely and clear enough for humans to trust and review.

Architecture in the AI age

The architecture should be understandable by humans, even if the code and logic were generated by AI. AI does not understand human intent. In my opinion, AI is still just an assistant, depending on how we define AI consciousness.

This is just awesome. This is exactly what we need to do with AI. I already add so many such guard rails while building. As of now I have strict instructions for AI to do 15 steps like static code analyisis, cyclomatic complexity, maintainability index check, cognitive complexity check, cohesion check, unit tests and component tests. This is primary and architecture is secondary.

Archs should always be understandable to humans, because nowadays we can treat AI code in the same way we treat compilers, you know what I mean?

It makes a lot of sense that we need to guide and use rigid structures in order for an AI model (or humans) to understand what we want. AI models might be fast at writing, but unless an AI is able to read your mind, it will always rely on communication in order to understand what it needs to do.
A human could also never now what you want without communication. Therefore I personally believe communication will be (and probably already is) one of the most important and valued skills to master.
Velocity should not be confused with capability; they are two entirely different concepts.

AI , very weak tool for architecture.