The reading room · Digna Legi
Extreme Programming 1999->2026
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The evidence is sampled with gaps, so the full structure and possible repetition cannot be fully assessed.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Changing practices should honor stable values—including whether AI gains benefit workers—in an argument drawing on Kent Beck’s Extreme Programming.
AI brief · Checked against source text
The main idea
Extreme Programming is broader than pair programming and writing tests before code: its values establish direction, its principles guide judgment, and its practices make those commitments observable. Revisiting Kent Beck’s framework amid AI adoption, the writer argues that practices should change with circumstances while remaining accountable to communication, simplicity, feedback, courage and respect—including whether productivity gains benefit the people doing the work.
Some background helpful. Familiarity with software development, automated testing, code review and team delivery processes.
Go a little deeper
Efficiency can move work onto someone else
Mutual benefit asks whether an activity helps everyone affected, rather than merely accelerating its initiator. The writer’s examples—long AI-generated messages and large AI-written code changes handed to colleagues—expose a mismatch between cheap production and costly comprehension. Judging adoption by output alone can therefore conceal a transfer of effort to readers and reviewers.
Capability belongs partly to relationships
The argument for keeping effective teams together rests on knowledge embedded in relationships and shared work, alongside individual expertise. This creates a tension with Beck’s proposal to shrink teams as they become more capable, freeing people to form others. The writer favors starting smaller but hesitates to dismantle successful teams: reallocating people can also disrupt the cooperation that made them effective.
Separate a practice’s purpose from its absolute rule
The writer’s objections often target words such as all and only. Pairing can support learning without requiring every production program to be written together; code and tests can remain central without eliminating durable documentation. The useful distinction is between preserving a practice’s contribution and enforcing its maximum intensity, especially when tools change how people collaborate.
A case from the article
Shortening the path to customers
The writer and their engineers began speaking directly with customers, including weekly conversations with some. They explicitly distinguish this from XP’s stronger practice of making customers part of the team. The case illustrates a partial adoption that reduces layers between builders and users while acknowledging that direct conversations do not provide the same involvement as ongoing team membership.
How the case is made
The argument combines passages from Kent Beck’s book with the writer’s engineering-management experience and observations about AI-assisted work.
Where the idea has limits
The writer has not tried AI-assisted test-first programming and reports conflicting accounts; removing mandatory code review remains an open question about preserving quality without overloading colleagues.
A question to take away · from Digna Legi
When a tool makes producing work easier, who absorbs the additional effort of understanding, checking and maintaining it?
What the original adds
The source also surveys delivery practices, including short-lived branches, frequent integration and contracts that fix time, cost and quality while negotiating scope. It distinguishes practices challenged by remote work from those the writer considers increasingly important.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.