PostEngineering leadership

AI shortened how long it takes to build a feature — not how long it takes to learn from one.

37signals cut its cool-down along with its build time. Delivery compresses; customer absorption and operational recovery mostly do not, and the ratio between them shifts.

Lukman Nuriakhmetov
Lukman Nuriakhmetov
1 min read · August 3, 2026

AI shortened how long it takes to build a feature. It did not shorten how long it takes to learn from one.

37signals just published the arithmetic. They still run six-week product cycles, but a substantial feature that used to take four weeks — with a real risk of six — now ships in one. So they cut the two-week cool-down between cycles down to a one-week "tune-up."

The first half of that is a capability change. The second half is a bet.

Build time and recovery time were never doing the same job. Build time is production. The interval after a release is when support tickets accumulate into a pattern, when the on-call engineer stops running on adrenaline, when someone notices the workaround three customers invented, when the team decides whether the thing they shipped was the right thing.

None of that runs at model speed. It runs at the speed of customers using the product and people making sense of what happened.

Which makes the honest version of an AI-accelerated cadence asymmetric: delivery compresses, learning mostly does not, and the ratio between them shifts. Cutting the cool-down proportionally assumes both halves scaled together.

The failure mode is not shipping too fast. It is shipping fast enough that nobody has finished understanding release four when release five lands.

Faster delivery is a capability. Faster learning is a claim — and it needs evidence before you plan around it.

Tags: engineering-leadership · ai-transformation · systems-thinking · delivery-cadence