Change cost is known not only to experienced developers and architects, but to anyone dealing with mutable systems: a process chemist tweaking a formulation, a lawyer amending a regulation, or just someone trying to re-wallpaper an apartment full of furniture. When we change one part of a system, we’re forced to support that change in many other parts. This effect is known as change coupling.
There are two ways to make life easier:
- Design systems upfront to minimize change coupling: types and contracts, SSOT for terms and rules, links instead of copy-paste, parameterization instead of almost identical variants, modularity and explicit interfaces between parts of the system.
- Algorithmize (including human-run procedures) and automate consistency maintenance and/or its validation: linters and CI gates, auto-references and auto-numbering, generating derived artifacts from a single source, controlled duplication via triggers or generators, and built-in compatibility at the product level — like self-adhesive wallpaper instead of separately selecting glue and a working regime.
A quick caveat: neither architecture nor automation is guaranteed to reduce entropy by itself — sometimes it just moves the system into overengineering mode (maybe I’ll write about it someday); but when applied thoughtfully, it does reduce the cost of change.
When we do neither (or not enough of either), the familiar pain starts. Documentation drifts, tests can’t keep up with code, bureaucratic processes slow down, and any small change turns into a walk through a minefield of hidden dependencies.
That’s why duplication, parallel inheritance hierarchies, and other antipatterns are treated as smells. In reality, none of these is evil per se — they’re symptoms. Duplication, for example, is often justified when we intentionally want to separate two entities and let them diverge. The problem appears when these choices create excessive manual change coupling.
AI has made artifact creation extremely fast.
At high speeds, without corresponding architectural discipline, language models inevitably generate a lot of unmanaged change coupling. On the other hand, combined with classical approaches and tooling, they dramatically expand the space of what can be automated in consistency maintenance.
As someone who likes mathematics (and type theory in particular), I naturally lean toward the first, architectural approach and believe AI will be a driver there as well: we already see that models are easiest to train in domains where strict verification is possible. But in practice, philosophy matters less than results: what matters is that the change coupling problem can be addressed right now in places where it used to seem impossible — or at least prohibitively expensive.