AI made building instant. Tech debt is the bill that comes due.

A founder who reached real revenue shared a number that stuck with people: years in, a large share of what they'd earned had effectively gone to paying down technical debt. Another, a banker turned builder, described software the way a blacksmith describes forging — every shortcut taken in the heat of building becomes a flaw you pay to hammer out later, and some you never can.

Both are describing the same physics. Debt isn't what happens when you write bad code. It's what happens when you make a decision implicitly — by building — instead of explicitly, by thinking it through first. AI didn't repeal that. It just made building so fast that you can now skip the thinking at a speed that would've been impossible a few years ago.

The trade you're making without noticing

Every "let's just build it and see" is a small loan. The interest is paid later, by the person who has to change that code, work around it, or explain to a customer why it does something nobody intended. When building was slow, the friction itself forced some thinking — you didn't write three days of code without a rough plan. When building is instant, that natural brake is gone. You can take out enormous loans in an afternoon and not feel a thing until the bill arrives.

And the bill always arrives. It shows up as the feature that takes a week because the foundation can't bear it, the bug that can't be fixed without touching six things, the new hire who can't understand the system because no one wrote down how it works. The debt was invisible while you were moving fast. It becomes the only thing you can see once you've stopped.

Spec-first isn't slower. It's the interest you don't pay.

The cheapest place to make a decision is in words. Changing a sentence in a spec costs nothing. Changing a shipped behavior costs a sprint and a migration. Thinking through the flow, the edge cases, and the failure modes before you build isn't bureaucracy — it's refusing to take out a loan you'll resent later.

• Decide the hard parts in the spec, where they're free to change. The data model, the edge cases, the failure behavior — get them roughly right on paper before they're expensive in code.
• Treat the skipped spec as visible debt, not a clever shortcut. "We'll document it later" is a loan. Name it as one so the team can decide whether to take it on purpose.
• Recover the spec when it's already gone. If you've already built fast and the debt is buried in the code, you can reconstruct the specification from the product itself — making the implicit decisions explicit so you can finally see what you owe.

What the "move fast" crowd gets right and wrong

Right: speed is a real advantage, and over-planning is its own failure — teams that spec everything to death ship nothing and learn nothing. Some debt is the correct, deliberate trade to make.

Wrong: "move fast" was never an argument against thinking. It was an argument against ceremony. The teams that move fast and survive aren't the ones who skip the spec — they're the ones who make the load-bearing decisions deliberately and cheaply, in words, and only then let AI build at full speed. Debt taken on purpose is leverage. Debt taken by accident, because building got too easy to bother thinking first, is just a bill you didn't read.