AI tools such as Codex and Claude Code have significantly accelerated software development. However, in my own work, I have repeatedly encountered a serious architectural problem.
Even when an AI agent receives clear architectural documentation, it continues to generate code using functional or domain-oriented decomposition instead of following the project's predefined Volatility-Based Decomposition.
The issue is not which programming or architectural approach is better. The problem is that the AI agent replaces an already established architecture with a different one.
The Core Problem
Volatility-Based Decomposition is an architectural approach in which a software system is organized around responsibilities and decisions that can change independently. Its primary purpose is to isolate the impact of changes rather than allowing every new feature to introduce additional dependencies throughout the system.
In my project, the architecture is organized around changeable responsibilities, orchestration, engines, resources, access control, and clearly defined boundaries between components.
The goal is to keep changes isolated without unnecessarily affecting the rest of the system.
Instead, AI coding agents repeatedly introduce function-oriented modules, additional services, abstractions, and dependencies that conflict with the established structure.
Even after receiving the authoritative architectural documentation and multiple corrections, the agents return to the same decomposition patterns.
As a result, the architecture gradually shifts from isolated responsibilities toward interconnected functional components.
What Are the Consequences?
As the project grows, these deviations begin to create serious problems.
Dependencies increase, responsibilities become distributed across multiple components, and changes that should remain local begin affecting unrelated parts of the system.
This makes several development activities increasingly difficult:
Debugging: Identifying a problem requires tracing multiple components and dependencies.
Adding features: A small business requirement may require modifications across numerous files.
Modifying existing logic: Changes can propagate into other modules and create unexpected side effects.
Removing features: Deleting obsolete code becomes risky because of hidden dependencies.
Refactoring: Restructuring requires additional analysis of interconnected components.
Maintenance: AI agents must process increasingly large amounts of context.
These problems introduce four significant risks:
Security: Violating architectural boundaries and resource-access responsibilities can introduce vulnerabilities, inconsistent authorization checks, and unexpected behavior.
Time: Development, debugging, testing, and maintenance can take increasingly longer, even for relatively simple changes.
Cost: Larger context requirements, repeated AI requests, additional token consumption, and engineering effort can significantly increase development expenses.
Implementation reliability: Fragmented responsibilities and growing dependencies increase the risk that modifying one feature will break another.
Eventually, a project may reach hundreds of thousands of lines of code without delivering a corresponding amount of meaningful business functionality.
The codebase grows, but the business value does not grow proportionally with it.
This is one of the most serious risks of AI-assisted development: the amount of code requiring analysis, testing, and maintenance increases without necessarily delivering additional value to end users.
As a result, even a small functional change may require a disproportionately large investment of time, tokens, and money.
Why Is This Dangerous for Startups?
For startups, the consequences can be particularly severe.
Initially, AI agents can deliver features quickly. However, when they repeatedly violate architectural boundaries, each subsequent change may become more complex and expensive.
A task that should affect one clearly defined responsibility may require extensive dependency analysis, debugging, modifications across multiple files, and additional testing.
This creates accumulating technical debt that small engineering teams may struggle to afford.
Fast code generation does not necessarily mean sustainable or economically efficient software development.
Open Discussion: Has Anyone Solved This Problem?
I would like to hear from software architects, developers, and engineering teams using AI coding agents in real-world projects.
Have you encountered AI agents repeatedly replacing Volatility-Based Decomposition with functional or domain-oriented decomposition?
Have you observed increasing dependencies, security risks, debugging time, or token costs resulting from these architectural deviations?
Have you found a reliable way to make AI agents respect architectural constraints across multiple consecutive tasks and sessions?
Can you share a practical solution, tool, research paper, benchmark, or real-world example?
I am particularly interested in solutions that work in large, evolving software projects rather than small demonstrations.
The goal is not to accuse AI providers of intentionally increasing complexity or token consumption.
The goal is to discuss a real architectural concern, collect practical evidence, and identify reliable solutions.
AI coding agents should not merely generate working code. They should also preserve the architectural decisions that make software secure, understandable, maintainable, and economically sustainable.
The true value of an AI coding agent is not measured by the amount of code it generates, but by its ability to evolve a system without making the next change unnecessarily harder and more expensive.
R.S | Founder & Developer
If you have encountered this problem or found a working solution, please share your experience, technical approach, or a link to your project in the comments.
Top comments (0)