Cheap Code Made Commitment Order the Expensive Part

Cheap implementation is the trap almost nobody sees coming.

For thirty years, writing the code was the expensive part. So we optimised around it — plan carefully, then commit, because committing was costly. Frontier models just deleted that cost. You can now generate the detailed layer faster than you can decide whether it's the right one.

Here's what that quietly breaks.

The value in this sequence was never "plan before you build." It's that each layer is a cheap place to be wrong. A spec is cheap to change. An architecture built on a shaky spec is expensive. Interfaces built on a shaky architecture are worse. Implementation is the most expensive place to discover that a decision three layers up was flawed — and it's now the easiest place to land, because that's the layer the machine hands you in seconds.

So teams generate more, faster, and commit earlier. What they ship is locally plausible and globally inconsistent — code that works in the demo and contradicts itself in production.

"Stabilise" doesn't mean freeze. You iterate inside a layer. The discipline is what you do when a test fails: don't reflexively patch the implementation. Ask which layer the defect actually lives in. Sometimes it's a bug. Sometimes the test just exposed that your architecture assumed something your spec never promised. Fix the highest layer that's wrong, then regenerate downstream — which is nearly free now anyway.

The shift isn't that planning suddenly matters more. It's that the order of your commitments became the last expensive thing in the building. Cheap generation raises the price of committing to the wrong thing first.

The teams who feel this early will out-ship the ones drowning in beautifully generated inconsistency.

Originally posted on LinkedIn