Agents write code faster. XP makes change safer

Most conversations about coding agents begin with throughput. How do we deliver twice as much? Which maintenance tasks can we hand over? How do we complete the same backlog in half the time?

These are sensible questions. Agents can make bounded tasks dramatically cheaper: a dependency upgrade that once consumed much of a day can be attempted in minutes, while an unfamiliar part of a system can be explored before I would previously have finished orienting myself. These are real wins, but they are not necessarily compounding wins. The next dependency upgrade still needs to be understood, tested and integrated, and producing twice as many changes does not make the system twice as capable of absorbing them.

Across separate matched event studies, researchers estimated a cumulative 179% increase in weekly commits across autocomplete, synchronous and asynchronous tools. Their cumulative release-count estimate was about 31%, but covered only autocomplete and synchronous agents and came from a smaller sample, so the two figures are not directly comparable.¹

At one unusually AI-forward company, authored pull requests per active developer reached 2.09 times their January–April 2025 baseline by April 2026. That result arrived before the end of the company’s twelve-month target period, although it measured authored pull requests per active developer rather than the target’s merged pull requests per engineer. Over the same period, pull-request volume per active reviewer roughly doubled, automated review coverage rose to about 84% and human-review coverage fell to 68%.²

Producing more code required the verification system to change as well.

This is not an argument that agents have failed. Thirty per cent more releases would be an extraordinary result for many organisations. It is an argument that writing code and changing software are not the same thing. A plausible implementation still has to express the right intent, preserve behaviour we care about, integrate with everything else that has changed and remain understandable to the people who will operate and modify it later.

Agents change the economics of producing code. They do not change the need for confidence in changing software.

This brought me back to XP

The Thoughtworks Future of Software Engineering retreat report was one of the things that pushed me towards this argument. Across its sessions, the repeated concern was not whether agents could produce more code, but whether teams could establish confidence in what they produced. Its recommendations centre on stronger testing, verification and feedback loops rather than generation alone.³

That landed with me because it felt familiar. In the XP teams I have worked in, the goal was never to maximise the amount of code we could produce. It was to make change manageable: make the change small, make it testable, make the evidence visible, integrate it before it drifts too far from the rest of the system and keep the design simple enough to change again.

XP gave the team both a mindset and a coherent set of practices. That combination removed a great deal of recurring process invention. Without it, teams can react to every difficult week by introducing another local optimisation: cycle time is slow, so we add a ceremony; review is taking too long, so we add another rule; quality has slipped, so we place another gate at the end. Each response can make sense in isolation, but together they rarely form a coherent way of working.

XP gave us somewhere more useful to return when delivery became difficult. We made the work smaller, shortened the feedback loop, improved the tests, integrated sooner and simplified what had become difficult to understand. It was not always the fastest-looking response to the immediate problem, but it made the system of work smoother and more dependable.

“Slow is smooth, and smooth is fast.”

— US military maxim

That does not mean preserving every XP practice unchanged. Beck described the practices as expressions of XP’s values, with principles translating those values into practice and helping teams act when no ready-made practice fits the problem. He was equally clear that “there is no freeze-dried software process” and that every team applies XP differently.⁴

XP cannot be reduced to its practices, but neither are the practices incidental. They make the values concrete and reinforce one another. Most may continue to hold as they are. Some may need to move, and others may need to change completely.

The test is not whether a practice looks like XP as we remember it. The test is whether it still helps us make small, testable and verifiable changes, obtain rapid feedback, preserve simple designs and change software with confidence.

Faster production raises the value of restraint

Agents make it tempting to expand the unit of work. A task that once felt too large to hand to another engineer can now be described to an agent and returned as an apparently complete implementation. Once that works, the natural response is to ask for more: another component, another migration, another feature.

The ability to produce a large change does not make a large change desirable. Among commits detectable as agent-assisted, the median number of added lines was 31, compared with 11 for residual human-authored commits. Commits adding more than 1,000 lines were 90.1% more frequent in relative terms, although the paper does not report their absolute frequencies. Both groups touched a median of two files, but the agent-assisted distribution was larger above the median.⁵

In my experience, bounded changes are easier to direct and far easier to verify. But the case for small changes is not limited to the context windows or reliability of today’s agents. If we can attempt more changes, reducing the uncertainty introduced by each one becomes more valuable.

A small failure is easier to diagnose and reverse. Its interaction with other work is easier to understand, and the feedback it produces is less ambiguous. The natural unit of agentic development should not be the largest task an agent can complete. It should be the smallest change for which the team can obtain meaningful feedback.

The same reasoning applies to testing and integration. As the cost of producing another attempted change falls, the ability to evaluate that change cheaply and quickly becomes more valuable. An agent can state confidently that its implementation is correct, but confidence has to come from outside the agent: tests, compilation, static analysis, contracts, operational signals and other forms of verification capable of disagreeing with it.

This does not settle every argument about test-driven development. It does not mean every team must follow one exact testing ritual, or that a large test suite automatically provides useful evidence. It means faster production increases the value of fast, independent feedback.

The original description of XP already connected short cycles, automated tests, evolving design and close collaboration. Those were not isolated techniques; together they kept evidence close to the moment of change.⁴

Continuous integration matters for the same reason. It is easy to claim CI because every branch passes an automated pipeline, but running checks on isolated branches is not the same as frequently integrating the work. CI requires each team member to merge changes into the shared codebase at least daily, with every integration checked by an automated build including tests.⁶

Agents can produce several substantial changes in parallel. That makes it more important to discover what those changes mean together before they have had time to diverge. The important question is not how much code an agent can finish before we interrupt it. It is how long we are prepared to wait before learning what that code means when combined with everything else.

Simple design completes the loop. If a system is unnecessarily complex, neither a human nor an agent can easily see where the consequences of a change end. A modification that appears local may affect behaviour elsewhere, and the evidence needed to trust it becomes harder to assemble and interpret.

Simple design is sometimes presented as an aesthetic preference. In this context, it is an economic one: it reduces the amount that must be understood and verified every time the system changes.

Confidence should not come from believing that the agent is usually right. It should come from keeping the system understandable and making mistakes cheap to expose.

Some practices will need new answers

The aims of XP may be more relevant than ever, while the right practices become less obvious. Pairing and pull requests expose that tension in different ways.

Pairing may move earlier

An agent can provide implementation ideas, explore alternatives and maintain momentum, so two engineers working through every line together may no longer be the best use of their attention.

But pairing was never only about producing code. A recent study returns to Beck’s description of trying to “program (and analyze and design and test)” while learning together how to work better.⁷

A second human challenges assumptions, contributes knowledge of the system and provides genuine resistance when an agent too readily accepts the direction it has been given. In my experience, this matters before any code is written: the costliest mistake is often not a poor implementation, but a plausible implementation of a mistaken premise.

An agent can challenge an implementation. A human pair is better placed to challenge the premise.

In the squads I work with, some of the highest-value pairing—and increasingly mobbing—now happens earlier, around specifications, examples and the boundaries of a change. Pairing may not be disappearing so much as moving to where human judgement has greater leverage.

This is also where the retreat report landed: deliberately preserve pairing around specifications and design intent, even if implementation pairing declines.³

We should be equally careful not to remove the learning opportunities pairing provided simply because their value does not appear in today’s throughput figures. In a qualitative study of industrial pairing, knowledge asymmetry frequently produced explicit teacher and student roles, each requiring distinct pair-programming skills.⁷

Engineers develop judgement by watching other engineers frame problems, navigate uncertainty and revise their thinking. If experienced engineers increasingly pair only with agents, the cost may appear not in the speed of today’s change but in the capability of tomorrow’s team.

That does not mean preserving traditional pairing on every task. It means understanding what else is being removed when we decide the practice is no longer efficient.

Pull requests are less clear

Agentic development makes it natural to let an agent complete a bounded change and then review the result, but that raises uncomfortable questions. Am I the author because I framed and supervised the work, or its first reviewer because I did not write the code? Does a second human review add confidence, or would that attention be better invested in stronger automated verification?

The Thoughtworks retreat’s challenge is deliberately blunt: “Stop treating manual code review as a de facto quality guarantee; measure it.”³

That is a valuable provocation, but it is not evidence that review has no value. Modern code review supports outcomes beyond defect detection, including knowledge transfer, team awareness and the development of alternative solutions. The same research found that understanding the reason and context for a change is central to reviewing it effectively.⁸

Its relationship with post-release defects is less clear. A replication across Qt and Chrome found the estimated influence of code-review measures highly sensitive to variable selection. Explanatory models without those measures fitted as well as or better than models that included them, although review measures could still have indirect relationships with defects.⁹

Pull requests also create a tension with continuous integration. They can provide a useful point for discussion before integration, but the value depends on keeping them small and responsive enough that work still reaches the mainline at least daily. Fowler also notes that pull requests are only one form of review; pairing can provide continuous review without making review a pre-integration gate.¹⁰

I do not yet know whether agents make pull requests more important or less valuable. That uncertainty reinforces the wider point: we should judge practices by the feedback, shared understanding and confidence they create, not preserve them simply because they are familiar.

Pairing and pull requests deserve fuller treatment, but not here. For this argument, they serve as reminders that doubling down on XP does not mean refusing to change it.

Do not start again from nothing

The software industry is in danger of treating agentic development as a wholly new discipline with wholly new problems. The tools are new, their capabilities are changing quickly and some of our practices will have to change with them. But we already know a great deal about changing software safely.

We know why large batches are difficult to understand, why delayed feedback makes mistakes expensive and why unnecessary complexity makes consequences harder to predict. We know why isolated work becomes harder to integrate, and that shared understanding matters even when it does not appear in a throughput measure.

These are not arguments against coding agents. They are the conditions under which coding agents become more useful.

The Thoughtworks retreat’s clearest strategic warning was that agents amplify the disciplines and habits an organisation already has. Weak testing, unclear ownership and poor documentation do not disappear when implementation accelerates; they “get worse, faster, not better.”³

Before inventing an entirely new agentic development methodology, look at the XP practices your team already has. Ask how your tests could give an agent clearer and faster feedback. Ask how you could reduce the size of each change rather than using agent capacity to increase it. Look for complexity that makes generated code difficult to verify. Consider where human collaboration could improve the assumptions and specifications shaping the agent’s work.

Then double down on what works.

The answer is not to preserve every existing practice unchanged. Most may continue to hold, some will need to move and others may need to be replaced. But replacing a practice is not the same as abandoning the purpose it served.

Agents have changed the economics of producing code. They have not removed uncertainty, integration risk or the need to learn from real use. In making implementation cheaper, they have made the ability to change software confidently more valuable.

The old practices may not survive intact. The aims behind them have never been more relevant.

XP is dead. Long live XP.

References