Applying changes across microservices is difficult because business logic is distributed across multiple services, each with its own data, contracts, and responsibilities.
In our experiment at Kaizen Softworks, we tested whether an AI system could safely apply coordinated changes across a microservices architecture using only minimal input.
Short answer: Yes, but only when the AI has enough architectural context.
Why are coordinated changes in microservices so hard?
In distributed systems, a single business change rarely affects just one service.
It often requires:
- Updating multiple microservices
- Modifying message contracts
- Keeping DTOs (Data Transfer Objects) consistent
- Respecting domain boundaries defined by Domain-Driven Design (DDD)
Key entities in this system:
- Microservice: An independently deployable service responsible for a specific domain
- Aggregate (DDD): A cluster of domain objects treated as a single unit
- DTO (Data Transfer Object): A structured format used to transfer data between services
- Message/Event: A communication mechanism between services
The complexity is not in the code, it’s in the relationships between components.
The experiment: Can AI reason across services with minimal input?
We designed a controlled experiment to test whether an AI model could apply system-wide changes with limited information.
Input given to the AI:
- Message definitions (events between services)
- DTOs (data contracts)
Tasks the AI had to perform:
- Identify affected aggregates
- Determine service ownership
- Apply coordinated changes across services
- Maintain consistency in messages and DTOs
In other words, the AI had to behave like a software architect, not just a code generator.
What was the biggest obstacle?
The biggest challenge was not technical, it was contextual.
.png)
Problem: unclear service naming
Instead of descriptive names like:
- order-service
- billing-service
Our services were named:
- john
- sally
- roger
This removed any semantic clues about responsibility.
Result: The AI could not infer which service owned which domain logic.
The missing piece: aggregate ownership mapping
To solve this, we introduced a simple but powerful structure:
Aggregate → Service mapping
- Order → john
- Shipment → sally
- Invoice → roger
This created a clear relationship between domain concepts and system components.
Once ownership was explicit, the architecture became understandable.
How we used AI to generate architectural context
Instead of building this mapping manually, we used AI to analyze the codebase and extract:
- Where each aggregate was defined
- Which microservice implemented it
- The relationship between domain and infrastructure
The result was a machine-readable architecture map.
In practice, we used AI to generate the context that AI itself needed.
Results: Can AI safely apply distributed changes?
With the architecture map in place, the AI was able to:
- Trace message flows across services
- Identify affected aggregates
- Locate the correct microservices
- Apply coordinated updates
- Maintain consistency between DTOs and messages
While not perfect, the system worked reliably as a proof of concept.
What is the real limitation of AI in microservices?
The main limitation of AI is not code generation, it’s architectural understanding.
Without knowing:
- Which components exist
- How they relate
- Who owns what
AI cannot safely modify a distributed system.
AI performance depends more on context quality than model capability.
When can AI safely modify microservices?
AI works well when:
- Aggregate ownership is clearly defined
- Message contracts are explicit
- Architecture is structured and consistent
AI struggles when:
- Naming is ambiguous
- Relationships are implicit
- Context is incomplete
Simple rule: If the architecture is clear, AI can reason. If not, it guesses.
Final thoughts
This experiment revealed something important:
AI doesn’t fail because it can’t write code.
It fails because it can’t see the system.
As teams move toward AI-assisted development, the focus will likely shift from:
Writing better code to Designing better systems for machines to understand
At Kaizen Softworks, we see this as a foundational shift.
Because when AI can understand architecture, it doesn’t just generate code, it helps evolve systems.
.avif)
