Engineering Practice on James Sawle

The agent writes the code. The team still pairs

Thu, 27 Aug 2026 00:00:00 +0000

Pair programming appears to have a terminal problem with coding agents: a programmer need not be present while the code is written.

A person can describe a change, send an agent into the repository and return later to a completed branch or pull request. The delegator may be a developer, but they are not sharing the implementation—and while the agent works, there is no pair at all. GitHub documents this background-delegation model directly, contrasting it with a synchronous session between a developer and an assistant.¹ Early evidence from 25,264 agentic pull requests finds the corresponding social pattern across open-source projects: single-human oversight dominated and multi-human collaboration was uncommon.²

If producing code was the reason to pair, the practice has become obsolete. Before defending it, we need to ask what disappears when the entire human pair leaves.

What disappears with the pair?

XP does not oblige us to preserve pairing’s old mechanics. Beck’s values–principles–practices framework instead asks what the practice made concrete, and whether those needs still have an adequate expression under new constraints.³

Four parts are especially relevant.

Communication and feedback ask that knowledge move between people and meet evidence while it can still change the work. Pairing made that exchange continuous; solitary delegation may defer the next human response until the agent asks for clarification or returns an implementation.

Diversity recognises that teams need differences in perspective, skill and experience, even though those differences also create conflict.³ Pairing applied two perspectives as the premise and design formed. With one delegator, the same human perspective frames the request and judges the result.

Reflection asks teams to examine how and why they work. Pairing externalised that reasoning: assumptions had to be explained and could be challenged immediately. Solitary agent work can leave the framing and judgement inside one person’s private reasoning.

Mutual benefit favours work that helps now without borrowing against the team’s future. Implementation pairing could advance a change and distribute knowledge; industrial research has observed teacher and student roles when partners hold different knowledge.⁴ An agent may complete the task without increasing the team’s shared ability to understand the next one.

These values and principles do not, by themselves, require pairing to survive. A team might express them through some combination of discovery workshops, asynchronous challenge, shared decision records, review, rotation and deliberate learning practices. They give us criteria for judging whatever comes next.

The question is whether a modified form of pairing can supply these qualities together, or whether they are better distributed across several new practices.

Pair in discovery

The task breakdown appears ready when the agent challenges one word in the working decision record: replacement.

Replacement is underspecified. If an administrator selects Resend twice, which link remains usable?

A product manager and engineer have been exploring a constructed change: let an administrator resend an expired invitation without recreating the recipient’s access. They have agreed to issue a replacement with the same access while keeping the expired link invalid. The agent has investigated the system, recorded their decisions and proposed reusing its existing path for issuing an invitation.

The agent’s challenge exposes a behaviour they have not decided. The product manager says that only the latest invitation should be usable: if both links work, resend has multiplied access rather than replaced it. The agent checks the token model and confirms that its proposed task would leave both replacement links valid. The engineer revises the design from issue another invitation to rotate the invitation. The agent updates the behavioural example, design constraint and affected tasks—all before implementation begins.

This is what I mean by discovery pairing. Two people continuously navigate one change, challenge each other’s reasoning and share authority over its decisions. The agent investigates, answers questions and keeps a working decision record coherent while the people judge and revise it.

The agent is not a passive scribe. It tests whether an answer has enough depth to carry into the next decision, challenges vague or unsupported responses and keeps the question open until the people address it. It does not own the decision. The pair can explicitly choose a direction the agent questions, but they must make that choice rather than hide it inside an ambiguous word.

It is not pair programming if the term is defined exclusively as two programmers producing code at one computer; those mechanics have ended. I retain pairing because shared attention, immediate mutual challenge and joint navigation survive. The agent becomes the driver of the record, not the second human perspective.

BDD discovery workshops provide established prior art. Cucumber’s guidance brings product, development and testing perspectives together shortly before implementation, keeps the conversation brief, and uses examples to expose rules, questions and smaller slices.⁵ The proposal here borrows that attention to examples and pairing’s continuous co-navigation. A repository-aware agent connects the conversation to the current system and propagates each accepted decision through the record; it does not make the decision.

The process supplies the earlier criteria together. Communication and feedback happen while decisions remain revisable. Product defines what replacement promises; engineering exposes its consequence for system state. Their exchange forces reflection on an unstated assumption, and the agent tests it against the repository. Both people leave with a better model of the product and system.

Some teams may keep the record in a work item, divide it among examples and design notes, or preserve accepted behaviour in a durable specification. I use OpenSpec because its proposal, behavioural delta, design and task artefacts make the decisions inspectable, and its workflow allows implementation discoveries to reopen them.⁶ The process depends on connected, revisable decisions rather than that particular structure.

Who should be present?

Choose the participants before the session by predicting which perspectives the slice is likely to need. That prediction is a starting point, not a fixed attendance list.

Two engineers bring different system knowledge, design instincts and implementation experience. A product-and-engineering pair connects intended behaviour with technical consequences. A designer contributes interaction, accessibility and journey-level judgement; a tester contributes examples, boundaries and failure modes. Either may pair with product or engineering when those concerns dominate the uncertainty.

The conversation will sometimes prove the prediction wrong. A person or the agent may expose a question the group cannot answer with enough depth. Pause and bring in the missing perspective rather than handing the question off. Keep that person while their knowledge is likely to matter again; let them leave when it no longer justifies their attention. The aim is not constant reshuffling but a pragmatic correction as the change reveals what it needs.

Sometimes those likely needs justify gathering the whole squad from the outset. At other times an ongoing pair widens because the slice crosses several kinds of judgement, omitting one would be expensive to unwind, and calling people in only after the session would lose the context in which the issue formed.

That wider form is a mob. Woody Zuill’s foundational experience report described the whole team working on the same thing, at the same time, through one computer.⁷ In the agentic version, the agent reads the system, drafts, asks, answers, revises and challenges responses that lack sufficient depth. The squad navigates and retains authority: the agent proposes that a decision or task breakdown is ready; the mob decides whether to agree.

The literature does not establish that larger groups generally make better decisions. A study of mob-programming practice found substantial variation, stressed its social and organisational conditions, and noted that much of the field’s literature consisted of experience reports.⁸ The case for mobbing is narrower: use the squad when the likely cost of a missed perspective exceeds the cost of concentrating its attention. A mob cannot guarantee that the relevant knowledge is present—it may sit outside the squad—but it can reduce the need to predict which of the squad’s perspectives will matter.

This is a proposed operating rule, not an outcome established by the studies. It should be tested against the total attention, rework and learning it creates in a team’s own context.

End the collaboration before implementation

Human attention remains expensive even when agent implementation is cheap. Pair-programming research found trade-offs among quality, duration and effort rather than a universal advantage,⁹ with controlled evidence showing effects that vary by system complexity and developer experience.¹⁰ A mob raises the cost further.

Use one person and an agent for local, reversible and well-understood changes. Use a pair when a second perspective earns its cost. Begin as a mob when the likely decisions justify the squad’s attention, or widen into one when the discussion exposes missing knowledge whose potential cost justifies it. Correct the group in either direction as the work becomes better understood.

Once the people agree on the decisions and implementation breakdown, they leave. The agent writes the code alone. If implementation reveals that the system cannot preserve an agreed constraint, it reopens the decision that no longer holds and calls back the people whose judgement is needed.

This is not upfront design followed by a one-way implementation phase. The task breakdown in the invitation example changes the agreed behaviour and design before code exists; implementation evidence can revise them again. The work stays inside one thin vertical slice, no record section is mandatory, and the participants leave as soon as shared judgement is no longer needed.

The economic test is substitution. Teams already spend attention in refinement, planning, discovery workshops, clarifications, handoffs and late design discussions. Discovery pairing or mobbing must replace enough of that fragmented work to justify its cost. If the existing interactions remain unchanged, the session is another ceremony and should be removed.

Across matched event studies, Demirer, Musolff and Yang estimated a much larger increase in code written than in releases after teams adopted AI coding tools.¹¹ The measures are not directly comparable and do not isolate pairing, but they make the mechanism worth testing: one disagreement about what resend means can prevent an entire attempt at the wrong change.

Do not move pairing to review

A pull request is a useful integration boundary, not a substitute for pairing. Tests, contracts, static analysis and architectural rules should challenge an implementation without waiting for another engineer. Human review has a narrower purpose: use it when unresolved judgement remains or when someone deliberately needs to learn the implementation.

Research into modern code review identifies knowledge transfer, team awareness and alternative solutions among its expected outcomes, and finds that understanding a change’s reason and context is central to reviewing it effectively.¹² Fowler also distinguishes pull requests from the continuous review pairing can provide.¹³ Those benefits can justify selective human review, but they do not make it a new pairing surface.

A reviewer encountering the second-resend ambiguity must reconstruct why the change exists, reopen what replacement means and discard code built from the earlier answer. Discovery pairing encounters it while the decision is still forming. Pair there, automate routine verification of the implementation, and involve a human reviewer when the remaining judgement or learning warrants the cost.

What discovery pairing still loses

Discovery pairing does not preserve every benefit of implementation pairing. Agreeing intent and design does not teach another engineer how the generated code works, ensure several people can debug it later, or recreate the teacher and student roles observed in industrial pairs.⁴

Human review may sometimes earn its cost as an implementation-learning practice, but it cannot be assumed as the answer. Teams may need rotation, deliberate code exploration, teaching sessions or another practice not yet established. AI review, linting and tests do not automatically express everything they value about architecture, operability or maintainability either.

A team could distribute the original criteria across several practices: a workshop for diversity, a decision record for communication, asynchronous challenge for reflection, automated and human review for feedback, and rotation for learning. That is credible, but it introduces handoffs between the people, context and moments at which a decision can change.

Discovery pairing combines communication, feedback, diversity and reflection while the decision is forming; the record preserves the result instead of replacing the conversation. That integrated timing is why I would maintain pairing in a changed form. Mobbing extends it when the relevant perspectives are known to be broad or prove broader than expected. A deliberate ending keeps its cost bounded.

Pairing can survive agent implementation, but not as two people sharing the production of code. Move it into discovery when a second perspective earns its cost, choose the people for the expected uncertainty, correct that group as the change reveals missing knowledge, and end the session when the agent has an agreed implementation breakdown.

The agent implements the bounded slice alone. The team has already paired while its meaning was cheap to change.

References

GitHub, “About GitHub Copilot coding agent,” checked at commit 0dddeeb8cce75425f9ca0cdffd6a1cbd94926c07. https://github.com/github/docs/blob/0dddeeb8cce75425f9ca0cdffd6a1cbd94926c07/content/copilot/concepts/agents/cloud-agent/about-cloud-agent.md ↩︎
Maliha Noushin Raida and Daqing Hou, “Early Adoption of Agentic Coding Tools by GitHub Projects,” arXiv:2607.14037v2, 2026. https://arxiv.org/abs/2607.14037v2 ↩︎
Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, second edition, Addison-Wesley Professional, 2004, chapters 3–5. https://www.pearson.com/en-us/subject-catalog/p/extreme-programming-explained-embrace-change/P200000000118/9780321278654 ↩︎ ↩︎
Linus Ververs, Trang Linh Lam and Lutz Prechelt, “Qualitative Analysis of the Teacher and Student Roles in Pair Programming,” arXiv:2507.10305v2, 2025. https://arxiv.org/abs/2507.10305v2 ↩︎ ↩︎
Cucumber, “Discovery workshop,” “Example Mapping” and “Who does what?,” checked at commit 48680f20869cf5409f5372293fdd1f50d771ed26. https://github.com/cucumber/website/blob/48680f20869cf5409f5372293fdd1f50d771ed26/docs/bdd/discovery-workshop.md, https://github.com/cucumber/website/blob/48680f20869cf5409f5372293fdd1f50d771ed26/docs/bdd/example-mapping.md and https://github.com/cucumber/website/blob/48680f20869cf5409f5372293fdd1f50d771ed26/docs/bdd/who-does-what.md. ↩︎
Fission-AI, OpenSpec, docs/workflows.md and docs/concepts.md, checked at commit 6926ccb18afa4ff621112813e9968334576ee11a. https://github.com/Fission-AI/OpenSpec/blob/6926ccb18afa4ff621112813e9968334576ee11a/docs/workflows.md and https://github.com/Fission-AI/OpenSpec/blob/6926ccb18afa4ff621112813e9968334576ee11a/docs/concepts.md. ↩︎
Woody Zuill, “Mob Programming — A Whole Team Approach,” Agile Alliance Experience Report, 2014. https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/ ↩︎
Daniel Ståhl and Torvald Mårtensson, “Mob programming: From avant-garde experimentation to established practice,” Journal of Systems and Software 180, 2021. https://doi.org/10.1016/j.jss.2021.111017 ↩︎
Jo E. Hannay, Tore Dybå, Erik Arisholm and Dag I. K. Sjøberg, “The effectiveness of pair programming: A meta-analysis,” Information and Software Technology 51(7), 2009. https://doi.org/10.1016/j.infsof.2009.02.001 ↩︎
Erik Arisholm, Hans Gallis, Tore Dybå and Dag I. K. Sjøberg, “Evaluating pair programming with respect to system complexity and programmer expertise,” IEEE Transactions on Software Engineering 33(2), 2007. https://doi.org/10.1109/TSE.2007.17 ↩︎
Mert Demirer, Leon Musolff and Liyuan Yang, “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools,” NBER Working Paper No. 35275, 2026. https://doi.org/10.3386/w35275 ↩︎
Alberto Bacchelli and Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review,” Proceedings of ICSE, 2013. https://doi.org/10.1109/ICSE.2013.6606617 ↩︎
Martin Fowler, “Pull Request,” martinfowler.com, 2021. https://martinfowler.com/bliki/PullRequest.html ↩︎

The specification that outlives the task

Tue, 11 Aug 2026 00:00:00 +0000

Ask a team why a piece of software behaves the way it does, and watch where they go to find out. They read the code. They read the tests, if the tests describe intent rather than implementation. They search the ticket tracker for the change that introduced the behaviour, then the discussion behind the change, then the person who remembers the discussion. Often the answer is only reassembled in a meeting, held for as long as the meeting lasts, and reconstructed again the next time someone asks.

This reconstruction is a recurring tax. Code can be correct, readable and well-tested and still be a poor representation of the business behaviour distributed across it. A pricing rule lives in one service, its exception in another, its deliberate omission nowhere at all — a decision not to do something rarely leaves a trace in code. The system executes the accepted behaviour faithfully without ever stating it, so every change that touches the area pays to rediscover it.

Coding agents change the economics of that tax in both directions. They can make reconstruction faster — an agent can scan more of a system in the time I would spend orienting myself — but they also make it possible to re-enter the same area more often as attempted changes get cheaper. Each attempt still has to re-derive the same intent. And an agent reading behaviour out of code is inferring what the system does, not consulting what the team decided it should do. Where those differ — an old compromise, or a bug customers now depend on — it cannot tell an intended rule from an accidental one.

This is the gap a specification is meant to close: a place where the accepted behaviour of the system is stated, kept current, and consulted before it is changed. Most of what the industry now calls a specification cannot close it, because it does not last long enough to be consulted twice. A specification only earns the name if later work has to answer to it; the rest is a plan wearing the word. And the reason the distinction is worth an argument is not that a durable specification makes software more correct — I do not think it does — but that it lets a team do a few old things markedly better.

A specification that disappears with the task is a plan

Here is the boundary stated plainly. A specification is a persistent, structured model of the system’s accepted behaviour, which later work deliberately changes. An artefact scoped to a single task is a plan — however detailed, however carefully reviewed, and even when it is committed to the repository.

The test is lifecycle, not detail or storage. A plan is created for a task, consumed as the task is done, and then spent. It may be consulted later as a historical record, but later work is not expected to update it as the account of current behaviour. A specification is not read once and set aside; work proposes a change to it, and the accepted change becomes part of it. A plan is written against your understanding of the system; a specification is the recorded understanding, and the next plan is written against that.

Two workflows readers already know sit cleanly on the plan side of that line. Vibe coding keeps the running code and discards everything else — the prompt was scaffolding, the code is what survives. An agent’s plan mode goes one better and writes the plan down, sometimes commits it, but it is still scoped to the task in front of it; once the change lands, the team does not maintain it as current behaviour. Neither is a lesser practice — a good plan is valuable, a committed one a useful record. But saving a plan does not make it a model of the system; it makes it an artefact of one change.

You might suspect I am inventing a distinction the field already respects. It does not. The tools flying the specification-driven banner produce a specification-like file before code and then agree on almost nothing else, least of all how long that file is meant to live. At one extreme the file is an input to a delivery cycle rather than a maintained model of the system. GSD Core persists a great deal of state across sessions and commits a SPEC.md for a phase, but completing a milestone archives its requirements and removes the current requirements file before the next milestone creates a new one. Harper Reed’s much-copied workflow likewise commits a spec.md and then uses it as scaffolding, not as a standing account of the system.¹² At the other extreme the file is the source — the human edits the spec and the code is regenerated output, marked not to be touched by hand — which is the doctrine GitHub’s Spec Kit states without hedging: “code serves specifications,” implementation as “the continuously regenerated output.”³ In between sit the durable-but-partial living documents, held per feature in Kiro or merged into a single canonical tree in OpenSpec.⁴⁵ Every one produces a file before code; what separates them is exactly the test above — whether later work must maintain it as the account of current behaviour.

Birgitta Böckeler has mapped this range more carefully than a paragraph can, naming its rungs spec-first, spec-anchored and spec-as-source.⁶ I lean on her map but part company with it in one deliberate way: she describes the territory and declines to crown a winner, treating even throwaway spec-first as legitimate. I am privileging a single rung — the persistent one — as holding real and under-appreciated power. That is a narrowing she chose not to make, so I am filling a gap she left open rather than overturning a consensus.

One qualification keeps this from overreaching. The rung I am defending is not spec-as-source. The code still lives, is still read, and is still edited by hand; the specification is the account of accepted behaviour, not the sole editable origin of the software. That changes the failure surface rather than removing it. The cautions about ceding software design to a model that generates the code land most directly at the top of the ladder. The drift objection does not: keeping two editable artefacts makes it central to the rung I am defending, and I return to it below. The recent case for still designing code for humans supports keeping code in human hands; it cannot tell us whether maintaining the parallel behavioural model will pay for itself.⁷

The power is not correctness. It is doing XP better

It would be easy to read all this as a bet on correctness — that a durable specification makes the software more likely to be right. I do not think the evidence supports that, and I am not going to argue it. Nothing here forces the running system to match the specification over time; keeping software honest to its specification is a hard problem, and a separate one, for another article.

The opportunity in the persistent model is less obvious: it can strengthen two Extreme Programming practices, precisely because it persists.

Persistence can enable less upfront specification. This sounds backwards. Without a canonical model, a change may have to re-establish the accepted behaviour around it from code, tests and memory. A standing model creates a different possibility: when a small request is interpreted against behaviour that is already stated, only the delta has to be elaborated; the rest is already on the page.

The obvious objection is that the standing model is itself a large specification, so the cost has only moved. Once upkeep is counted, it may have. The narrower point is about when the detail is created: the model accretes one delta at a time, each the just-in-time elaboration of a small slice, so its eventual density was paid for as real work demanded it — never as a batch written ahead of the code. That is the difference from an upfront requirements document: not that the model is smaller or cheaper in total, but that no one had to write it whole before implementation began.

This is Ron Jeffries’ Card, Conversation, Confirmation read forward twenty-five years.⁸ The card was a placeholder; the requirement was elaborated just-in-time, in conversation; the confirmation was the acceptance criteria. The specification is the modern analogue of Confirmation — a durable record of what “done” was agreed to mean — not a return to a heavyweight requirements document written before the work begins. It is the just-in-time, small-slice branch of the family tree, not the upfront-batch branch.

It evolves pairing past engineer-to-engineer to engineer-and-product. I have argued before that pairing may be moving earlier — towards premises, examples and specifications — because, in my experience, the costliest mistake is usually not a poor implementation but a plausible implementation of a mistaken premise. The specification delta is where that becomes concrete: proposing a reviewed change to accepted behaviour is a repeatable surface where product understanding flows in and wrong assumptions surface before cheap code generation turns them into expensive rework. This one is an observation, not a measurement: I have started to see product managers pair, and mob, with engineers while an agent drafts a specification change — not to review code but to interrogate intent while it is still cheap to change. The product manager leaves with a sharper grip on their own technical product, taken from a stated model rather than reconstructed from code.

Neither is a correctness claim; both are claims about intent and collaboration, and together they are the whole case for the persistent model. Its value does not depend on being the sole editable source from which code is generated, or on covering all behaviour. It does depend on being authoritative within the behaviour it describes.

Walking the loop with a concrete change

The two gains rest on a single mechanism, and it is easiest to watch it turn on something small. A product manager asks for one thing: let a first-order welcome discount be combined with account credit. One line. The agent interprets it against the current specification, and the request lands in a dense corner of it — a welcome discount applies once per customer, to the subtotal, before delivery; account credit applies afterwards, to the remaining balance and is earned only on cash paid; and, stated flatly, at most one promotional discount applies to an order.

That last rule is where the code cannot settle the question. Code and tests may reveal how the terms are represented and show that the two have never combined; they cannot decide whether someone intended that separation. Is account credit a promotional discount, caught by the rule, or a payment instrument the rule never meant to cover? The specification is silent, and silence reads the same whether it was a decision or an oversight. So the agent does not guess. It surfaces the questions a human has to answer: is the single-discount rule policy or omission; does the welcome discount still compute against the full subtotal once credit is in play; can the pair drive the balance below zero, and who absorbs the remainder; and, since credit can be earned repeatedly while the welcome discount is once-per-customer, whether combining them opens a farming loop.

A person settles them, and the decisions are about intent, not implementation. Account credit is a payment instrument; the single-discount rule was silent on it, not opposed — the omission was accidental. The welcome discount keeps computing against the subtotal, and credit still applies to what remains, capped at the balance. An existing rule earns credit only on cash paid, so the combination creates no new farming loop. Refunds and partial cancellation are named as unchanged and deliberately left alone.

What merges back is not that reasoning, held in someone’s memory until the next argument, but a single typed change to the model — the modification and the addition side by side, ready to review. OpenSpec writes it as a delta against the current specification:⁵

## MODIFIED Requirements

### Requirement: One promotional discount per order

The system SHALL apply at most one promotional discount to an order. This
limit governs promotions only; payment instruments such as account credit
are exempt and do not count against it.

#### Scenario: Welcome discount combined with account credit

- WHEN a first-order customer holds both a welcome discount and account credit
- THEN the welcome discount applies to the subtotal
- AND account credit applies to the remaining balance, capped at that balance

## ADDED Requirements

### Requirement: Account credit stacks after a promotional discount

The system SHALL deduct account credit from the balance that remains after any
promotional discount, and SHALL NOT allow the combined reduction to exceed the
order total.

The delta stays atomic — one rule clarified, one interaction recorded; the moment it began rewriting refunds and cancellation too would be the signal the request had left its small slice.

Now hold the two lifecycles side by side. A plan would have said add credit to the allowed-stacking check and ship. The rationale might survive in a ticket, test name or historical plan, but it would have no maintained home as current policy; the next person to touch promotions would have to find and interpret it before deciding whether to “fix” the apparent stacking bug. The delta records that decision as the accepted rule. The request stayed small, the existing specification carried the density around it, and the artefact is a change to the model, not a document about the task. That difference in lifecycle is what turns the two gains above from hopeful description into something a team can run.

I have watched this fail before

The objection I take most seriously is not one I have to borrow from a critic. I share it. I have maintained a long-lived requirements document that was quietly false within a quarter — everyone had stopped reading it, and no one had told it — and nothing about my calling this new artefact a specification makes it immune.

That failure has two distinct shapes, and they are worth separating, because the practice can mitigate one and not answer the other.

The first is rigidity. A specification agreed before the code is a blueprint written at the moment of least knowledge, and implementation is where its mistaken assumptions surface. Held too firmly, it forces the system to honour decisions that turned out to be wrong.

The second is decay. Documents drift against the system they describe unless someone pays, continually and deliberately, to keep them current — and requirements written this way turn out to be inappropriate almost as soon as they are written.⁹¹⁰ A persisted natural-language model is a standing invitation to do it again: to maintain a second, incomplete representation of the software that quietly stops being true.

There is a sharper edge to the second worry, aimed at natural language itself. Prose is a lossy medium for behaviour. It skips the intermediate abstractions that make large-scale engineering possible, and machine-recovered traceability from it is good enough to assist a human, not to trust unattended.¹¹ Push a specification precise enough to pin an agent down and it stops being prose in any useful sense — it becomes, in one recent phrasing, “programming in a worse, more ambiguous programming language,” echoing Dijkstra’s 1978 objection to natural-language programming.⁷ Model-driven development encountered the same problems — round-tripping, drift, the cost of formalism — which is why even its advocates keep a catalogue of why it fails.¹² The warning that spec-as-source courts “the downsides of both MDD and LLMs: inflexibility and non-determinism” restates a very old worry.⁶

And underneath both shapes the pragmatists have a pointed question. If specifications are prompts, and the code is what survives, why maintain a second artefact at all? Its upkeep may simply cost more than it returns, especially while nothing forces the running system to conform to it.

I can mitigate the first shape and not answer the second. Each delta is created just-in-time for a small vertical slice and stays cheap to revise as the team learns. A specification agreed before code is not a finished blueprint but, in Unmesh Joshi’s phrase, “a hypothesis to be revised.”¹³ The loop works because each round is a small, reviewable change, not a standing document defended against reality. That reduces rigidity; it does not prevent a team from turning the model into a gate that resists new knowledge.

Decay I cannot answer, and I will not pretend to. Nothing in the workflows examined forces a persisted prose model to remain faithful to the running system over time, and a model that accretes cheap deltas while no one re-validates the whole is exactly how a large, quietly-false document forms. That is the real weight of the pragmatists’ question, and it stays open here. Kent Beck’s instinct is worth sitting with: in augmented coding his durable, trusted artefact is the test suite — an executable specification — alongside a task-scoped plan, not a persistent prose model.¹⁴ Whether the durable artefact should be prose or executable, and whether something like BDD is the layer that makes it so, is the tension the next article takes up — not one I am claiming to have solved here.

Adopting it on software that already exists

Most teams are not starting from an empty repository, and neither route into an existing system is free. You can reverse-engineer a baseline — have an agent infer the accepted behaviour from the code and tests, then validate it with people who can distinguish intent from accident. The inferred baseline describes what the system does, bugs and dead compromises included. A baseline nobody has validated is not a specification; it is the reconstruction tax paid once and then trusted, which is worse than paying it each time.

Or you can grow coverage incrementally, letting the specification accrete around the areas you actually change. This spreads the cost and keeps it attached to real work, but a request that looks like a new requirement over existing code may in fact contradict accepted behaviour the specification does not yet describe. Treat those as higher-risk and route them to human judgement, because the model cannot yet warn you that you are changing something rather than adding it. Neither route removes the reconstruction tax; both convert it into an explicit, reviewable cost.

Where this is still moving

The claim is narrow: a persistent model can let a small change elaborate only its delta and can give product and engineering a shared surface for reviewing intent. That does not establish that the software will be more correct or that the model will cost less than it returns.

The right granularity is unknown — how much behaviour one specification should hold before it becomes the requirements document the drift literature warns about. Repository and ownership boundaries are unknown; OpenSpec’s early cross-repository work shows the boundary being pushed, not that broad, shared specifications work.⁵ The context economics are unknown — a specification dense enough to be useful is also expensive to keep in an agent’s working context. And conformance over time — whether the running system still matches what the model says — is the largest open problem of all, the one this article has deliberately left standing.

The persistent model earns its keep only while it stays cheap to change and tethered to reality. That is the tension this whole lineage has circled, from XP’s Confirmation through living documentation to agentic specifications — not one the tools have newly solved, but the one worth watching.

So the next time a tool says it has written a specification, do not judge it by the filename or the detail inside. Ask what happens after the code lands. Will the artefact become a historical record, or will the next change have to consult and revise it as the account of accepted behaviour?

If it becomes history, it may still be an excellent plan. If it persists, the team has made the harder bargain: in return for a place where product and engineering can examine intent before implementation, it accepts an obligation to keep that place authoritative where it speaks and honest as the system changes.

The file does not make it a specification. The obligation carried into the next change does.

References

Open GSD, GSD Core, spec-phase.md and complete-milestone.md, checked 6 August 2026. https://github.com/open-gsd/gsd-core/blob/fee72d55604461b86176ee970357f358e8b05cc9/commands/gsd/spec-phase.md and https://github.com/open-gsd/gsd-core/blob/fee72d55604461b86176ee970357f358e8b05cc9/commands/gsd/complete-milestone.md. ↩︎
Harper Reed, “My LLM codegen workflow atm,” 2025. https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ ↩︎
GitHub, Spec Kit, spec-driven.md. https://github.com/github/spec-kit/blob/main/spec-driven.md ↩︎
Amazon Web Services, Kiro documentation, “Feature specs.” https://kiro.dev/docs/specs/feature-specs/ ↩︎
Fission-AI, OpenSpec, docs/concepts.md and the Stores beta user guide, checked 6 August 2026. https://github.com/Fission-AI/OpenSpec/blob/d57889664cab4f2f061d236ec3ff82a5578701bb/docs/concepts.md and https://github.com/Fission-AI/OpenSpec/blob/d57889664cab4f2f061d236ec3ff82a5578701bb/docs/stores-beta/user-guide.md. ↩︎ ↩︎ ↩︎
Birgitta Böckeler, “Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl,” martinfowler.com, 15 October 2025. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html ↩︎ ↩︎
Valentina Servile, “Should we still design code for humans?” Thoughtworks, 23 July 2026, citing Edsger W. Dijkstra, “On the foolishness of ’natural language programming’” (EWD667), 1978. https://www.thoughtworks.com/insights/blog/programming-languages/should-still-design-code-humans ↩︎ ↩︎
Ron Jeffries, “Essential XP: Card, Conversation, Confirmation,” 2001. https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ ↩︎
David L. Parnas, “Software Aging,” Proceedings of the 16th International Conference on Software Engineering, 1994. https://doi.org/10.1109/ICSE.1994.296790 ↩︎
Krzysztof Wnuk, Tony Gorschek and Showayb Zahda, “Obsolete software requirements,” Information and Software Technology 55(6), 2013, pp. 921–940. https://doi.org/10.1016/j.infsof.2012.12.001 ↩︎
Jan-Philipp Steghöfer and Markus Borg, “An Abstraction Is Worth a Thousand Vibes,” IEEE Software 43(1), 2026, pp. 13–16. https://doi.org/10.1109/MS.2025.3621786 ↩︎
Johan den Haan, “8 Reasons Why Model-Driven Approaches (will) Fail,” InfoQ, 2008. https://www.infoq.com/articles/8-reasons-why-MDE-fails/ ↩︎
Martin Fowler and Unmesh Joshi, “Conversation: LLMs and Building Abstractions,” martinfowler.com, 26 August 2025 — the “Upfront Specification Impossibility” concept appears within. https://martinfowler.com/articles/convo-llm-abstractions.html ↩︎
Kent Beck, “Augmented Coding: Beyond the Vibes,” Tidy First? Substack, 2025. https://newsletter.kentbeck.com/p/augmented-coding-beyond-the-vibes ↩︎

Agents write code faster. XP makes change safer

Tue, 28 Jul 2026 00:00:00 +0000

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.

The data shows this gap directly. Across separate matched event studies, researchers estimated that AI coding tools raised weekly commits by a cumulative 179% — with well over twice as much code written each week. But the amount that reached users moved far less: their estimate for releases was a cumulative increase of about 31%. The two figures are not strictly comparable; the release estimate covered only autocomplete and synchronous agents and came from a smaller sample. Even so, the direction is hard to miss: far more code was written than was shipped.¹

A study of one unusually AI-forward company shows the same pressure further along the pipeline. The company had set itself a twelve-month target to double output per engineer, and it got there early: by April 2026, authored pull requests per active developer had reached 2.09 times their January–April 2025 baseline.

That volume landed on the same reviewers. Pull requests per active reviewer roughly doubled too, and the review process shifted to absorb them: automated review coverage rose to about 84%, while the share of pull requests reaching a human reviewer 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

Mert Demirer, Leon Musolff and Liyuan Yang, “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools,” NBER Working Paper No. 35275, 2026. https://doi.org/10.3386/w35275 ↩︎
Hao He, Shyam Agarwal, Yegor Denisov-Blanch, Pavel Azaletskiy, Sanmi Koyejo and Bogdan Vasilescu, “AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise ‘2×’ Mandate,” arXiv preprint, 2026. The reported measure is authored pull requests per active developer, rather than the target’s stated merged pull requests per engineer. https://arxiv.org/abs/2607.01904v1 ↩︎
Thoughtworks, The Future of Software Engineering: Insights and Findings from an Unconference on AI, Agentic Engineering and the Future of the Discipline, 2026. https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future_of_software_engineering_europe_2026.pdf ↩︎ ↩︎ ↩︎ ↩︎
Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, second edition, Addison-Wesley Professional, 2004, pp. 2–3. https://www.pearson.com/en-us/subject-catalog/p/extreme-programming-explained-embrace-change/P200000000118/9780321278654 ↩︎ ↩︎
Romain Robbes, Théo Matricon, Thomas Degueule, Andre Hora and Stefano Zacchiroli, “Agentic Much? Adoption of Coding Agents on GitHub,” arXiv preprint, 2026. https://arxiv.org/abs/2601.18341v2 ↩︎
Martin Fowler, “Continuous Integration,” martinfowler.com, 2024. https://martinfowler.com/articles/continuousIntegration.html ↩︎
Linus Ververs, Trang Linh Lam and Lutz Prechelt, “Qualitative Analysis of the Teacher and Student Roles in Pair Programming,” arXiv preprint, 2025. https://arxiv.org/abs/2507.10305v2 ↩︎ ↩︎
Alberto Bacchelli and Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review,” Proceedings of the 35th International Conference on Software Engineering, 2013. https://doi.org/10.1109/ICSE.2013.6606617 ↩︎
Andrey Krutauz, Tapajit Dey, Peter C. Rigby and Audris Mockus, “Do Code Review Measures Explain the Incidence of Post-Release Defects? Case Study Replications and Bayesian Networks,” Empirical Software Engineering, 2020. https://doi.org/10.1007/s10664-020-09837-4 ↩︎
Martin Fowler, “Pull Request,” martinfowler.com, 2021. https://martinfowler.com/bliki/PullRequest.html ↩︎