architectural drift under AI velocity
Sunil Kalkunte: AI exposes weak architectural governance, not code quality, as the real drift risk Developer SummitTL;DW
- Architectural drift—not AI—is the real risk when development velocity increases; high-quality individual decisions can degrade overall system coherence.
- Three drift spectrum zones exist: coherent (teams understand boundaries, ownership clear), drifting (fuzzy boundaries, hidden coupling, informal contracts), and fragile (fear of change, structural coupling, low velocity).
- Catch drifting systems early by asking: Can teams describe boundaries without documentation? Are contracts explicitly documented and tested? Can you identify responsible team for any file in 60 seconds?
- Hidden failures in distributed systems go undetected—example: field name change in one service silently becomes null in consumers, only surfacing days later in business reports.
- Use architectural circuit breakers to stop unexpected cross-domain changes and force human-in-the-loop decision-making, not approval checkboxes.
- Solidify contracts between services through schema registries and architectural decision records; test boundaries regardless of code source (AI or human).
- Ask "Where does this live and why?" on every PR merge, not just big features, to prevent drift accumulation in normal development workflow.
- AI didn't break systems; it exposed how weak existing architectures already were and increased pace of degradation visibility.
TL;DW
- Architectural drift—not AI—is the real risk when development velocity increases; high-quality individual decisions can degrade overall system coherence.
- Three drift spectrum zones exist: coherent (teams understand boundaries, ownership clear), drifting (fuzzy boundaries, hidden coupling, informal contracts), and fragile (fear of change, structural coupling, low velocity).
- Catch drifting systems early by asking: Can teams describe boundaries without documentation? Are contracts explicitly documented and tested? Can you identify responsible team for any file in 60 seconds?
- Hidden failures in distributed systems go undetected—example: field name change in one service silently becomes null in consumers, only surfacing days later in business reports.
- Use architectural circuit breakers to stop unexpected cross-domain changes and force human-in-the-loop decision-making, not approval checkboxes.
- Solidify contracts between services through schema registries and architectural decision records; test boundaries regardless of code source (AI or human).
- Ask "Where does this live and why?" on every PR merge, not just big features, to prevent drift accumulation in normal development workflow.
- AI didn't break systems; it exposed how weak existing architectures already were and increased pace of degradation visibility.
Kalkunte maps system decay on a coherent-to-fragile spectrum and traces silent failures—like a field rename surfacing days later as null values in business reports—to locally correct decisions accumulating into incoherent system shapes. Proposed fixes: architectural circuit breakers, explicit schema contracts, and per-change ownership enforcement.