The case for funding architecture
Code got cheap. Being right didn't.
AI collapsed the cost of producing code. It did nothing to the cost of producing the wrong system. This page is about that gap — and why the person who controls it is the highest-leverage thing you can fund.
// discount enginefunction applyDiscount(total, pct) { return total - pct;}The shift
AI scaled output. It never scaled coherence.
Drag the slider. As AI capability grows, the volume of code an organisation can produce explodes. Whether that code forms a system that holds together does not move on its own — a person moves it.
The distance between these two lines is risk. It is paid later, with interest.
Specification
The same request. Two completely different systems.
A model is a function of its input. Give it a vague prompt and it fills the gaps with guesses. Give it a precise specification and it fills them with your intent. Toggle the input below.
“Build me an orders module.”
Tangled. No boundaries. The bugs are structural — you cannot test them away.
Order is an aggregate. It cannot ship below available stock. Totals are derived from lines — never stored raw. Cancellation after fulfilment is forbidden. Money is an explicit value object.
Bounded. Invariants enforced at the type level. The model resists misuse by construction.
Spec-driven domain design
The specification is the asset. The code is a build artefact.
When the spec is the source of truth, code can be regenerated — but the thinking behind it cannot. Activate each layer of the specification and watch the architecture compile.
An empty spec compiles to nothing you can trust.
The irreducible
Four things a model cannot decide for you.
- 01
Judgment under ambiguity
When a requirement contradicts itself, someone has to choose what the business actually means. A model averages the training data; an architect decides.
- 02
Trade-offs with consequences
Consistency or availability. Speed or auditability. Every real system is a chain of trade-offs that only a human can own and defend.
- 03
Irreversible decisions
Schema shape, context boundaries, the public API. Get these wrong and no volume of generated code buys them back.
- 04
The invariants of your business
That an invoice can never be negative is not in the training data. It is in your domain. Someone has to know it — and encode it.
The compounding cost
Architectural debt does not add up. It multiplies.
Scroll through eighteen months of the same project. One path had an architect shaping every boundary. The other shipped whatever generated fastest.
Both teams used the same AI. Only one stayed cheap to change.
The leverage equation
AI is a multiplier. A multiplier needs something worth multiplying.
Trustworthy output is AI throughput multiplied by human judgment. Throughput is now effectively unlimited. Drag judgment toward zero and watch what unlimited throughput is worth.
Unlimited speed times zero judgment is still zero. This is the case for funding the judgment.
The decision
Fund the person who makes the AI worth the spend.
I design domain-driven backends — DDD, Hexagonal, CQRS — for systems where being wrong is expensive. If you're investing in AI-accelerated delivery and want it to compound instead of decay, let's talk.