Why Does Development Slow? (Kent Beck) (tidyfirst.substack.com)

Kent Beck argues the familiar pattern—fast early progress, then creeping stagnation—isn’t just bad luck but the predictable result of burning "options" as you add features. Using a Tufte-inspired scatterplot (features on one axis, remaining optionality on the other), Beck shows the first few features consume lots of architectural and design flexibility. Each feature increases complexity, forces backward-compatibility tradeoffs, and narrows future choices; over time, that loss of optionality piles up into slower builds, more bugs, and brittle code. He notes code-generation "genies" (AI tools) simply compress time: they drive more features faster but also accelerate option consumption, so the slowdown arrives sooner. The practical takeaway for AI/ML teams is actionable: you can’t simultaneously maximize immediate feature output and long-term optionality, but you can manage the cadence. Beck recommends a rhythm of "feature, then restore options"—explicit tidy/refactor/debug phases between feature deliveries to replenish flexibility (tests, cleanups, architecture tweaks). For projects using AI-assisted coding, this implies scheduling and tooling (automated reviews, refactors, dependency mapping) to counteract accelerated entropy; measuring features vs optionality can help diagnose when to invest in preservation work rather than more features.