Reducing Architectural Drift When Using AI for Small Changes
Source: Dev.to
Background
In an earlier post I discussed architectural drift and how AI, while accelerating delivery, can quietly push systems away from their original intent. This article doesn’t claim to solve drift; it explores a more pragmatic question: if drift is inevitable, how can we reduce it when using AI for small, everyday change requests?
The observations below come from patterns I’ve noticed—what tends to go wrong, what helps a little, and what at least makes the damage visible sooner.
What “Architecture” Means Here
Architecture isn’t about diagrams or heavyweight documentation. It’s about the decisions that make change safe:
- Where boundaries exist
- Who owns what responsibility
- How data flows
- Which assumptions the system quietly depends on to behave predictably
When those decisions aren’t preserved, AI doesn’t break the system immediately—it simply optimizes locally until the global shape no longer makes sense.
Shift in Mindset
Instead of treating AI as a faster way to generate code, I treat it as something that must be constrained before it can be helpful. Most AI‑assisted changes in real systems are small, but repeated small changes without architectural awareness compound into drift. The goal therefore shifts from “get the correct output” to “preserve the shape while making the change.”
Non‑Negotiable Constraints
These are not suggestions; they are hard constraints that must hold true regardless of the change being requested:
- Do not introduce new service boundaries.
- Do not duplicate business logic.
- Do not alter data contracts.
- Do not cross architectural layers.
When these constraints are left implicit, AI fills the gaps with assumptions that feel reasonable in isolation but become harmful in aggregate.
Where the Constraints Belong
Constraints must be part of the original prompt, not an afterthought. Each change request should start with the same foundation, explain the impact first, and only then move toward implementation. Applying a change on shaky intent almost always costs more to fix later.
Code Duplication: A Subtle Failure Mode
AI is very good at re‑implementing logic in slightly cleaner ways. Without explicit instructions, it will create parallel paths that look fine but slowly fragment behavior. If reuse matters—and it usually does—it needs to be stated clearly:
- “Reuse existing logic.”
- “Do not create parallel implementations.”
- “Extend, don’t replicate.”
These directives are not reliably inferred by the model on its own.
Managing Context Windows
The AI can only reason over what it currently sees. Feeding it large files or entire repositories often backfires because earlier constraints can silently drop out of scope. A more realistic approach is to assume the model only has visibility into a small set of files and to name them explicitly. Architecture then becomes a compact working context, not a document dump.
Prompt Structure That Helps
A simple prompt structure that works well:
- State the non‑negotiables first.
- Define the assumed scope (which files are in context).
- Ask the model to explain the architectural impact before writing code.
This doesn’t make the AI smarter; it forces a pause before execution. That pause alone reduces accidental drift.
Limitations
None of this is a cure. Architectural drift is a natural property of evolving systems. The goal isn’t to prevent change, but to ensure change happens deliberately rather than by inference. These practices don’t eliminate risk; they make it visible earlier, while correction is still possible.
AI is exceptionally good at moving systems forward. Architecture exists to make sure we don’t move forward blindly. If architectural intent isn’t carried explicitly into our prompts, the system will still evolve—just not in a direction we consciously chose.
Example Architecturally Constrained Change Request Prompt
You are implementing a small, incremental change to an existing system.
The following architectural constraints are non‑negotiable and must be preserved:
- The system follows a layered architecture.
- Business logic resides exclusively in the domain layer.
- Adapters are responsible only for data translation, not decision‑making.
- Existing service boundaries and data contracts must remain unchanged.
- No new abstractions, services, or parallel implementations may be introduced.
Assume your effective context is limited to the following files:
OrderService.py, OrderValidator.py, OrderRepository.py.
Do not infer, recreate, or duplicate logic that may exist outside this scope.
Change request:
Add validation for a new optional field in the order payload.
Reuse existing validation mechanisms wherever applicable.
Avoid duplication and ensure behavior remains centralized.
Before implementing the change, explicitly state:
- the architectural layer where the change belongs
- whether the change risks violating any constraint listed above
If a violation is identified, stop and explain the risk.
If no violation exists, implement the minimal code change required, ensuring the system’s architectural shape remains intact.