Should we revisit Extreme Programming in the age of AI?
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 problem
Typing 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 counterweight
Unbounded 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 the small so you can go faster in the large.
Take pair programming. On paper, you cut output in half. In practice, you double shared understanding. You surface assumptions early. You build trust. You improve quality. You raise the baseline of capability across the team.
This is the sociotechnical nature of XP practices. They shape collaboration as much as they shape code. They are an investment in learning, not just shipping. And in doing so, they provide direction, not just speed.
AI magnifies the problem XP was built to solve
As code generation becomes effortless, a new risk emerges: producing software faster than we can validate it.
This is especially pronounced in agentic AI systems, where multiple autonomous agents generate, refine, and ship code. Without constraints, these systems can rapidly layer unvalidated logic on top of itself, entrenching assumptions and amplifying architectural complexity.
Recent research reinforces the risk: LLM accuracy declines the longer the context window. In practice, this means the more you “vibe code,” the more brittle the output becomes over time, because large language models perform best at the start and end of the context window, while the middle is poorly generalised and prone to error.
The result is brittle, tangled code that becomes increasingly expensive to change. Extreme Programming was designed to prevent exactly this kind of runaway entropy.
Software is still human
Despite AI’s rise, software remains a profoundly human discipline. Code is written by people, for people, in organisations shaped by culture, incentives, and communication.
While tools evolve, the persistent barriers to delivery remain: alignment, shared context, clarity of outcome, and user validation.
XP’s values are still powerful today:
- Simplicity helps reduce system complexity
- Communication keeps teams cohesive
- Feedback drives learning and adaptation
- Respect builds safety and trust
- Courage empowers transparency and change
From feature factories to value delivery
The most successful teams do not chase speed at all costs. They prioritise flow over velocity and feedback over features.
XP’s emphasis on small batches, continuous integration, automated testing, and shared ownership helps teams remain adaptable, resilient, and user-focused.
As AI accelerates output, these practices will be critical to managing quality, risk, and intent.
Lessons from the past
The CHAOS report data is telling:
- 1994: only 16% of software projects delivered on time and on budget
- 2012: improved to 37%
- 2020: regressed to 31%
In over two decades of innovation: agile, DevOps, cloud-native platforms, and now AI, the net difference in reliable software delivery is just +14 percentage points.
Toolchains alone have not solved delivery. Methodology still matters.
What needs to change?
As we enter the next phase of software acceleration, three things become clear:
- Output creation is no longer the constraint. We can produce code faster than we can validate or align it with real-world needs.
- We must invest in outcome-generating capabilities. Stronger feedback loops, clearer product direction, tighter team collaboration, and greater design discipline.
- The process needs to become more human, not less. Even as AI capabilities expand, sustainable delivery will always depend on human collaboration.
Our view of the Product Operating Model is built on this principle: technology only delivers when teams are optimised for collaboration, clarity, and flow. By aligning product strategy, operating rhythms, and engineering practices around people, not just platforms, you create the conditions for sustainable delivery in the AI era.
Should we revisit XP in the age of AI?
Yes.
We need frameworks that anchor us to human-centred practices, even as tools become more powerful. XP provides both discipline and empathy. It centres the team. It elevates shared understanding above raw speed. It asks the most important question: are we building the right thing?
In an era defined by faster code and fewer constraints, XP is a rare methodology that reminds us: software is about people, not just code.
