Should we revisit Extreme Programming in the age of AI?

Summary

The pace of software output has never been faster. AI tooling and decades of platform innovation have dramatically lowered the barrier to code creation. With just a few prompts or API calls, it is now possible to generate entire products, features, infrastructure, and functionality in hours rather than weeks.And yet, despite all this acceleration, delivery outcomes remain stubbornly poor. Too many initiatives underdeliver, budgets continue to overrun, and users are left underserved. If cheaper and faster code has not solved delivery, then the bottleneck must lie elsewhere.Output is not the problemTyping has never been the bottleneck. We have seen successive waves of acceleration: The rise of high-level languages Widespread adoption of frameworks and package managers The move to DevOps and serverless computing Developer platforms that abstract away infrastructure And now, AI-enabled code generation.Despite this acceleration, outcomes remain stubbornly inconsistent. The long-running Standish Chaos study still finds that most IT projects miss expectations, while McKinsey reports that 70% of digital transformations fail. More output has not meant better software.If faster code generation alone doesn’t deliver value, the answer is not more acceleration, but smarter constraints. For me, that’s why XP resonates now more than ever: it teaches us to slow down just enough to learn, align, and build with intent.XP as a counterweightUnbounded acceleration leaves no time to steer. Without slowing down to notice mistakes, learn, and correct course, teams risk shipping software no one asked for.Extreme Programming (XP), developed in the late 1990s, was never intended to maximise throughput. Quite the opposite: it introduced deliberate friction and constraints that enabled teams to learn, raising the probability they were moving in the right direction. One of its most radical principles, pair programming everything, halves raw output by design.The principle is simple: go slower in ...