AI doesn't automatically fix unclear systems
Many enterprise systems aren't difficult because the code is old. They're difficult because the boundaries are unclear. Business rules are scattered across services. Shared utilities contain domain decisions. UI components enforce authorization logic. A concept such as customer, contract, or approval may mean different things in different parts of the business, but the code treats it as one universal thing.
A human developer can sometimes compensate for this through experience and informal knowledge. They know where the real pricing rule lives, which field must not be changed, or which integration depends on an undocumented behavior. An AI agent doesn't have that organizational memory unless we make it explicit.
In a weak architecture, an agent may produce code that looks reasonable locally while making the system worse. It may duplicate logic, blur responsibilities, or place new behavior in the wrong part of the system. The feature works. The tests pass. The damage appears later, when the next change becomes harder.
Modularity gives agents a safer change surface
Modular architecture gives agents a smaller and safer place to work. Clear modules, stable interfaces, and explicit ownership make it possible to give precise constraints:
- "Modify only this capability."
- "Don't change this interface."
- "Add this rule inside the pricing module."
These aren't only prompt-writing techniques. They're architectural constraints expressed in a way that both humans and agents can use. For developers, modularity makes review easier. A pull request that affects one bounded part of the system is easier to reason about than one that touches pricing, notifications, audit logging, and reporting at the same time. For business stakeholders, modularity protects long-term value. It reduces the risk that fast delivery today becomes expensive change tomorrow.
A simple example: contract approval
Imagine an enterprise application for customer contracts. A business team wants to improve how contracts are priced, approved, audited, and renewed. An AI agent is asked to implement a new approval feature.
In a weak architecture, it might generate one service that handles:
- Pricing rules
- Approval thresholds
- Notification logic
- Audit records
- Renewal state
The feature may work. It may even pass the first tests. But the design is already creating future risk. Pricing and approval are different concerns. Notifications shouldn't own business decisions. Auditability shouldn't be an afterthought. Renewal logic likely belongs somewhere else.
A subtle failure mode is that the agent places approval-threshold logic inside the notification flow because notifications are triggered when approval is needed. From a local perspective, this seems reasonable. But now a business rule is hidden in the wrong place. The next pricing change becomes harder. The next approval change risks breaking notifications. The next audit requirement needs to reconstruct a decision that was never modelled clearly.
In a more modular system, the same agent works inside clearer constraints:
- Pricing rules belong to pricing.
- Approval decisions belong to contract approval.
- Notifications react to events.
- Audit records are produced through an approved mechanism.
- Renewal rules are handled separately.
The agent can still accelerate implementation. The difference is that architecture limits where change should happen.
Domain language matters
The contract approval example illustrates what happens when an agent works without clear boundaries. But where do those boundaries come from? Domain-driven design provides the discipline. It models business domains through bounded contexts: explicit areas where a concept has consistent, precise meaning.
Take the word customer. In onboarding, the customer may be an applicant. In billing, the customer may be a payer. In support, the customer may be an account with service history. In compliance, the customer may be a legal subject with obligations and restrictions.
Without bounded contexts, an agent may treat "customer" as one universal concept and create coupling that becomes painful later.
With clearer domain boundaries, the team can say: "This change affects the billing customer, not the onboarding applicant or the compliance subject."
AI agents respond to names, examples, rules, and boundaries.
If the business language is vague, the implementation will reflect that vagueness. If the system has no clear model, the agent will infer one. That inference may be wrong.
One powerful way to build shared domain language is EventStorming, a method we explored in EventStorming builds shared understanding for better software. It brings business and technology people together to discover bounded contexts and align on the language that shapes both design and code.
Architecture is the foundation
AI agents can help teams move faster from business intent to working software. They can reduce repetitive implementation work and create faster feedback loops between business and technology. But the teams that benefit most won't be the ones that let AI change everything everywhere. They'll be the teams that know where agents can safely explore and where architecture must constrain them.
Twoday's Agentic Engineering model is built on this principle. It replaces ad hoc prompting with spec-driven workflows: business and engineering intent is translated into structured specifications that agents execute within defined boundaries. Reusable delivery patterns and embedded validation gates ensure that speed doesn't come at the cost of architectural coherence.
Agentic software development doesn't make modular architecture and domain modelling obsolete. It makes them essential.
About Simo Roikonen
Simo is a Global Principal Architect in Global Digital Engineering at Twoday, with over 20 years of experience designing and building resilient, evolvable software systems. He joined Twoday in Finland in 2020 and works across teams and business units in hands-on architect and advisor roles, leading modernization efforts and solving complex technical challenges. Simo has a strong focus on Domain-Driven Design and on designing distributed backends that deliver low latency and scale, while also contributing to global initiatives that strengthen engineering excellence and modern software development across Twoday.
Simo Roikonen, Global Principal Architect