Agile & XP

The iterative-learning core of agile and XP — rendered more relevant, not obsolete, by AI, even as its diluted ceremonial forms deserve retirement.

Also known as: agile, smidig, smidig transformasjon, XP, extreme programming, XP Classic vs XPAI, the agile industrial complex, semantic diffusion, Semantic Diffusion, validated learning, sensible defaults, Sensible Defaults

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (23)

• Advanced Context Engineering for Coding Agents (ace-fca.md) Dex Horthy (HumanLayer) · 2026-10-08 source ↗ Reader 🖥️
  Solving hard problems in brownfield codebases requires designing your entire workflow — not just individual prompts — around keeping the context window in a 40-60% utilization sweet spot via a research/plan/implement cycle of frequent, intentional compaction, with human review concentrated at the research and plan layers because errors there compound into far more downstream bad code than a single bad line; and the open problem now is scaling this disciplined, human-engaged practice collaboratively across whole teams, not just a single highly motivated practitioner.
• Kent Beck's Post Kent Beck · 2026-10-08 source ↗ Reader 🖥️
  The common framing of Spec-Driven Development — write the complete specification, then implement — rests on a false assumption that implementation teaches you nothing that should change the spec, whereas TDD's tight test/code/fail/pass loop is structured around the opposite assumption: that you will learn continuously and must feed that learning back immediately.
• Erik van der Pluijm's Post Erik van der Pluijm · 2026-10-08 source ↗ Reader 🖥️
  When Claude Code collapses the time to build software, the 2-week sprint (and the ceremonies and metrics built around it) stops fitting, but this doesn't mean Scrum has failed — because Scrum was always about empiricism (tight feedback loops of inspect-and-adapt), not about sprint length, so the right response is to compress the cycle to 2 days, drop effort-based metrics (story points, velocity), and replace them with a recurring value judgment ('should this ship?').
• Reject Change, Sometimes Kent Beck · 2026-09-02 Reader 🖥️
  Because a growing product's payoff structure differs by 3X phase — roughly symmetric win/loss during Extract, sharply upside-skewed during Explore, and ruin-inclusive (win/die/switch) during Expand — the correct exposure to volatility differs sharply too: Extract calls for the disciplined, rebalancing 'Shannon's Demon' strategy of protecting revenue and keeping changes reversible even at some cost to upside (i.e., deliberately rejecting some change), Explore calls for going all in on volatility despite that same strategy's mathematical dominance in symmetric bets, and Expand calls for a third move — investing directly to reduce the probability of catastrophic failure — so 'embrace change' is not a universal software-development virtue but a phase-specific one.
• LIVE: Uncle Bob on Software Fundamentals in the Age of AI Matt Pocock (host) with Robert C. Martin ('Uncle Bob') · 2026-08-19 source ↗ Reader 🖥️
  Software fundamentals (clean, well-partitioned, deeply-structured, well-tested code) matter just as much in the agentic era as before — not despite AI's speed but because of it — because agents hit the same complexity wall humans always have, just at a different threshold; the right response is not to impose human disciplines (like strict line-by-line TDD or heavyweight upfront specs) on agents, but to encode human values as deterministic, automated gauntlets (crap scores, mutation testing, dependency rules) that agents must pass through, while reserving strategic judgment — architecture, module boundaries, what's worth building — for humans who must now learn that judgment by experiencing the agents' own tactical gauntlet.
• The Beginnings of an Idea: XP is Long Volatility Kent Beck from Software Design: Tidy First? · 2026-07-14 Reader 🖥️
  Beck's genuinely new ideas — including the just-arrived analogy 'XP is long volatility' — take years of unconscious incubation before they're ready to articulate, and once ripe they can only be sharpened into a teachable form by repeatedly explaining them badly, in varied ways, to real audiences, not by solitary polishing.
• Why AI Coding Agents Still Need Clear Specs Markus Eisele · 2026-07-08 source ↗ Reader 🖥️
  AI coding agents don't eliminate the cost of specification, they relocate it into downstream correction loops and human review, so the real discipline is locating — and validating — a task-dependent sweet spot on a U-shaped completeness-vs-cost curve, one that shifts toward much stronger contracts as more agents are chained together.
• Future Of Software Development Martin Fowler · 2026-07-07 source ↗ Reader 🖥️
  Thoughtworks convened invitation-only 'Future of Software Development' Open Space retreats in 2026 to examine how AI and LLMs will reshape the profession, and Fowler deliberately captured the discussions as unattributed fragments rather than one coherent narrative — the fragmentary form itself signalling that the profession's future is too unsettled to reduce to a single thesis.
• Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat Jimmy Nilsson · 2026-07-07 source ↗ Reader 🖥️
  Reflecting on Thoughtworks' 'Future of Software Development' retreat, the author reports that leading practitioners have moved past the hype-versus-doom polarisation about agentic coding toward nuanced 'when, where and how' thinking, converging on the view that enduring engineering fundamentals (DDD, XP, TOC, TDD, BDD, CD) plus a renewed 'Extreme Humanism' matter more than ever in the agentic age — which is why he is optimistic.
• Trust Factory Kent Beck (Software Design: Tidy First?) · 2026-06-02 Reader 🖥️
  Extreme Programming was a 'trust factory' — its practices, principles, and values all produced trust as a byproduct of producing software — and AI-augmented ('genie') development is breaking this because it accumulates code far faster than it accumulates trust; the remedy is to deliberately slow augmented development so it manufactures trust the way XP did.
• Bliki: Vibe Coding Martin Fowler · 2026-05-21 source ↗ Reader 🖥️
  Vibe coding — building software by prompting an LLM without ever looking at the generated code — is a distinct practice from agentic programming, useful only for disposable software, because forgetting the code exists produces serious risks in security, maintainability, and correctness.
• Forskning på digitalisering 2026 uke 19 Leif Knutsen · 2026-05-04 source ↗ Reader 🖥️
  Current software engineering research highlights a recurring tension: agile transformation, measurement, and AI-assisted code analysis all require structured, disciplined approaches that seem to contradict the flexibility they aim to enable — and these paradoxes are not yet resolved.
• How to Build a Superteam That Keeps Getting Better Harvard Business Review · 2026-05-01 source ↗ Reader 🖥️
  In periods of rapid change, teams win not because they start with the best plans or the most talent but because their leaders build a continuous-improvement culture — one that makes experimentation, curiosity, early problem-surfacing, hands-on involvement, non-threatening feedback, and growth-oriented investment in people the daily default — so the team's rate of learning, not its starting position, determines whether it becomes a 'superteam.'
• Extreme Time Value of Money: Late-stage Career Planning Kent Beck from the archives · 2026-04-21 Reader 🖥️
  Late in a career — especially one shadowed by mortality or declining health — a rational person's discount rate is not smooth but steeply curved and eventually infinite at a horizon; this asymmetry between the older worker's discount curve and the tech industry's long-dated compensation structure (multi-year vesting, deferred liquidity, equity portfolios) creates a genuine economic mismatch that should be named, modeled, and where possible arbitraged.
• Sam Hatoum's Post Sam Hatoum · 2026-04-20 source ↗ Reader 🖥️
  Spec-driven development with AI is not waterfall because waterfall's fatal flaw was slow feedback, not specifications themselves, and AI collapses the feedback loop from months to minutes — making specs more essential, not less.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again The Pragmatic Engineer · 2026-04-07 Reader 🖥️
  In a period of unprecedented technological disruption, the same meta-skills that mattered before — disciplined skepticism tempered by curiosity, small experiments to validate claims, and mastery of craft fundamentals — remain the primary differentiators, but practitioners must shift their satisfaction from writing perfect code to understanding domains and systems at a higher level of abstraction.
• No, AI Did Not Kill Agile Andrea Laforgia · 2026-04-00 source ↗ Reader 🖥️
  AI accelerates building software but does not reduce the epistemic uncertainty about what to build, so the iterative learning loop at the core of Agile becomes more important, not less, when coding is nearly free.
• Patterns for Reducing Friction in AI-Assisted Development Rahul Garg · 2026-02-24 source ↗ Reader 🖥️
  AI coding assistants produce misaligned output not because they lack capability but because developers skip the same onboarding, design discussion, and standards-sharing rituals that make human pair programming effective, and adopting five collaboration patterns that mirror those rituals can transform AI from a source of friction into a force multiplier.
• No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer AI Engineer · 2025-12-02 source ↗ Reader 🖥️
  Solving hard problems in large, brownfield codebases with coding agents requires treating the context window itself as the scarce, team-visible resource to be engineered — through a research/plan/implement workflow with deliberate, frequent compaction — rather than either unreviewed 'vibes' or an over-literal, semantically diffused 'spec-driven development'; and the harder, still-unsolved problem is adapting team workflow, review practice, and culture to a world where most shipped code is AI-authored, not improving the agent tooling itself.
• How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
  AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.
• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices Wes Reisz · 2025-01-01 source ↗ Reader 🖥️
  AI-first software delivery is not one-size-fits-all: teams should choose between supervised and unsupervised agentic approaches based on code longevity and their ability to verify outputs automatically, using structured human-AI collaboration (RIPER-5) to preserve engineering discipline — because AI amplifies whatever practices you already have, good or bad.
• Is Agile Dead? How AI and Extreme Agile Redefine Work Jeff Sutherland · 2024-12-02 source ↗ Reader 🖥️
  Agile is not dead, but it survives only by fusing with AI into 'Extreme Agile' — a stack of neuroscience, Scrum, and AI layers that delivers 30-100x productivity gains and makes AI-naive Scrum teams unemployable by 2030, so organizations and workers must adopt AI-augmented Agile now or face obsolescence.

Propositions touching this concept (25)

By publication month, oldest first (extraction month when no publication date is known).

2024-12

• explicitcontestedAgile teams augmented by AI will become 30-100 times more productive, a transformation that will reshape industries by 2030.
  Is Agile Dead? How AI and Extreme Agile Redefine Work · p1
• explicitAI tools (Claude 3.5, GitHub Copilot) have moved from assistant to core-contributor status, performing code generation and decision-making tasks previously done by people, which means traditional Agile software-development roles are being replaced because AI is faster, safer, and more reliable.
  Is Agile Dead? How AI and Extreme Agile Redefine Work · p2

2025-11

• explicitSkalert smidig (scaled agile) at SpareBank 1 was not the product of a framework adoption but of consistent fagtid plus deliberate hiring for mindset over years.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p12
• explicitcontestedAgile's core lever of leverage — shortening cycle time and increasing the frequency of small increments, rather than cramming more into each increment — remains the best bet in the AI era, and AI's main contribution should be making those small slices faster, not larger.
  How AI will change software engineering – with Martin Fowler · p14

2025-12

• explicit'Spec-driven development' as a term has undergone semantic diffusion (per Fowler's 2006 framing, and the earlier fate of the word 'agent') to the point of uselessness as a label — now meaning anything from a more detailed prompt, to a product requirements document, to literal code-as-assembly, to documentation for an open-source library — even though some version of the underlying discipline (compressed intent, verifiable feedback loops) remains valuable under the author's own preferred framing.
  No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p9

2026-04

• implicitThe XP / agile critique of speculative up-front design is the same argument as the late-career critique of long-dated compensation — both violate the time value of money.
  Extreme Time Value of Money: Late-stage Career Planning · p17
• explicitTDD, BDD, and acceptance criteria are spec-first practices that are accepted as agile because their feedback loops are tight.
  Sam Hatoum's Post · p4
• implicitWhether a development practice is 'waterfall' or 'agile' is determined by feedback-loop speed, not by whether specifications exist.
  Sam Hatoum's Post · p8
• explicitAI will produce the same pattern as agile: a real core of effective practice surrounded by a large snake-oil industrial complex, and distinguishing the two will be the primary challenge.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again · p4
• implicitOrganizations' internal incentive misalignments, which undermined agile adoption, will equally undermine effective AI adoption.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again · p13
• explicitestablishedThe 'AI killed Agile' argument confuses two distinct problems: how fast we can build software (speed) and how we discover what to build (knowledge).
  No, AI Did Not Kill Agile · p1
• explicitAgile was created to address the knowledge problem, not the speed problem.
  No, AI Did Not Kill Agile · p2
• explicitcontestedThe real threat of the 'AI killed Agile' narrative is political: it gives management a fresh justification for top-down, spec-first control that avoids the discomfort of incremental learning.
  No, AI Did Not Kill Agile · p7
• implicitMost practitioners frustrated with Agile are actually frustrated with faux-agile (ceremonies without adaptive principles), not with the iterative learning that Agile was designed to enable.
  No, AI Did Not Kill Agile · p8
• explicitAI is making technology evaluation itself harder, not just technology adoption, because semantic diffusion (overlapping new terms like 'spec-driven development' and 'harness engineering') and extremely short tool half-lives (some tools under a month old, built by one person with a coding agent) outpace the normal maturation cycle a radar relies on.
  Technology Radar, Volume 34 · p1

2026-05

• explicitAgile transformation requires the entire organization to become agile, not just development teams
  Forskning på digitalisering 2026 uke 19 · p1
• explicitStructural, perceptual, and individual barriers prevent organization-wide agile adoption
  Forskning på digitalisering 2026 uke 19 · p2
• explicitAgile practices have made software measurement harder, not easier
  Forskning på digitalisering 2026 uke 19 · p5
• implicitThe most valuable part of agile transformation frameworks may be ensuring feedback that demonstrates the benefits
  Forskning på digitalisering 2026 uke 19 · p11

2026-06

• explicitTech-culture preference for flat hierarchies is partly a sociological inheritance from gutterom-introvert-anarkist roots, carried into smidig and agile, and is naivt i møte med den reelle organisasjonen.
  4) Morten Eikeland: Det finnes alltid et hierarki · p2

2026-07

• explicitAgile and XP practices survive the agent era selectively: ceremony and status theater fade, while short feedback loops, test-first thinking, CI, refactoring, and small releases survive because they cheaply expose that a spec was wrong.
  Why AI Coding Agents Still Need Clear Specs · p7
• explicitThe Utah retreat was sited in the mountains and timed as a nod to the 25th anniversary of the Manifesto for Agile Software Development, yet was framed as forward-looking rather than commemorative.
  Future Of Software Development · p2
• implicitAgile is no longer explicitly discussed among these practitioners because it was internalised long ago, and attention has shifted entirely to the future.
  Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat · p3
• implicitThe individuals and interactions — the human element — were the most valuable part of the gathering, and (by the Agile-Manifesto echo) of the work itself.
  Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat · p6
• explicitReducing cognitive load -- providing sensible defaults and opinionated workflows instead of exposing every underlying capability -- lets developers focus on their applications rather than on infrastructure complexity.
  How Open Source Enables Collaboration in Creating a Platform · p6

Tensions

Open gaps (48)

• missing evidenceThe entire framework is grounded in a single three-month engagement. No DORA metrics, no controlled comparison with unconstrained approaches, no data on defect rates or rework costs. The talk is honest about this, but it means the prescriptive claims rest on practitioner intuition rather than empirical evidence.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Studies measuring productivity and quality outcomes of structured vs. unstructured AI-assisted development; DORA-instrumented teams using agentic workflows.
• tensionThe talk argues that (1) AI amplifies whatever practices you have, and (2) pair programming is essential for reviewing AI output. But if your practice is already strong enough to benefit from amplification, why is the review burden so high? The high review burden suggests the AI is generating output that doesn't match team standards — which is the amplification-of-weakness problem the talk warns about.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Research on AI code quality vs. human code quality at different experience levels; studies on code review effectiveness for AI-generated code.
• scope limitationThe framework addresses coding agents exclusively. It does not address other AI applications in the SDLC (testing agents, deployment agents, monitoring agents, design agents) or how the supervised/unsupervised choice might differ for those. The 'shifting left' claim is broader than the framework can support.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: End-to-end SDLC automation literature; agent architectures for testing, deployment, and operations.
• incompleteThe diagnosis of tech-compensation bias is sharp but the prescription is missing. Beck explicitly says he has no answer. The essay gestures at arbitrage but does not survey actual instruments — secondary equity markets (Forge, EquityZen), tender offers, equity-financing products (e.g., from Quid or ESO Fund), salary-heavy negotiations, advisory-shares structures for senior people, or simply not joining startups. A reader looking for what to do is left to invent the response themselves.
  Extreme Time Value of Money: Late-stage Career Planning — read next: Practical resources on liquidity for private-company equity; 'Secrets of Sand Hill Road' (Kupor) on cap-table mechanics; the literature on optimal compensation design when worker time-horizons differ from firm time-horizons
• incompleteThe argument frames career value purely through financial discounting, but late-career workers often report that meaning, legacy, mentorship, and intrinsic motivation become more important, not less. A late-career worker may rationally accept a long-dated equity grant because it locks them into a community of practice they enjoy. Beck's frame leaves no room for non-financial utility — which is striking given his own continued public writing and teaching, which are themselves long-dated, non-monetary investments.
  Extreme Time Value of Money: Late-stage Career Planning — read next: Erik Erikson's stage theory (generativity vs. stagnation); Arthur Brooks 'From Strength to Strength' on second-half careers; Robert Atchley's continuity theory of aging
• incompleteThe 'discount rate becomes infinite past 30 years' formulation papers over the actuarial reality that the curve is not a step function — there is residual probability of being alive and well at year 25, year 28, year 32, and rationality requires integrating over those probabilities, not just truncating. Beck shows the actuarial chart but uses it as illustration rather than as the basis for a more nuanced curve.
  Extreme Time Value of Money: Late-stage Career Planning — read next: Standard actuarial discounting under uncertain lifespan (Yaari 1965 on uncertain lifetime and consumption); literature on how to compute expected present value with a stochastic horizon
• incompleteThe essay treats the worker as the only party whose discount curve matters. It doesn't ask whether firms could (or should) offer differentiated compensation tracks for workers with shorter horizons — e.g., higher cash and lower equity for senior hires, accelerated vesting on age- or tenure-based triggers, or 'advisor' tracks designed to convert long-dated value to short-dated cash. The 'no answer' framing accepts the current design as given rather than asking who could change it.
  Extreme Time Value of Money: Late-stage Career Planning — read next: Compensation design literature; case studies of firms with explicit late-career tracks (academic emeritus structures, partner-track exits in law firms, advisory-board structures); economic work on multi-horizon labor markets
• implicit_assumptionThe argument assumes 'enjoying' money is the relevant utility — money for experiences, comfort, options. But for many older workers, financial resources function as security or option value (medical contingency, family backstop, philanthropic latitude) even if they aren't spent. A million dollars unspent at death may have served real utility along the way as a buffer. Beck's 'I'd literally rather have one dollar in my hand today' rhetoric understates the option value of future money.
  Extreme Time Value of Money: Late-stage Career Planning — read next: Behavioral economics on the utility of unspent wealth (precautionary savings literature); Daniel Kahneman on experienced vs. remembered utility; literature on financial security as a psychological good independent of consumption
• incompleteThe U-shaped cost curve and its variants (single- vs multi-agent, BDD vs prose) are presented as illustrative line charts with no axis units, no measured data points, and no cited study — the model is asserted as intuitively obvious rather than empirically demonstrated.
  Why AI Coding Agents Still Need Clear Specs — read next: Look for empirical studies quantifying rework/correction cost under varying spec completeness with AI coding agents (e.g., controlled comparisons of BDD vs prose-spec agent tasks, or DORA-style research) to test whether the curve's shape and minimum location actually hold.
• incompleteThe essay proposes a spec-validation ('critic') agent as a cost-lowering step but never addresses who or what validates that critic, or what happens when its critique is itself wrong or incomplete — an infinite-regress problem inherent to using agents to check agents.
  Why AI Coding Agents Still Need Clear Specs — read next: Look at multi-agent debate and self-consistency literature, or formal-verification framing of 'who verifies the verifier,' for how (or whether) this regress is bounded in practice.
• uninformedThe claim that specification, not implementation, has always been the hard part of software engineering closely tracks Fred Brooks's essential-vs-accidental-complexity distinction, but the piece never engages that lineage or the decades of requirements-engineering literature built on it.
  Why AI Coding Agents Still Need Clear Specs — read next: Fred Brooks, 'No Silver Bullet — Essential and Accidental Difficulties of Software Engineering' (1986); also classic requirements-engineering work distinguishing validation ('are we building the right thing') from verification ('are we building it right').
• incompleteThe cost ledger treats 'the human' as a single, already-aligned oracle who knows what the spec should say; it never addresses the more common real-world case of multiple stakeholders disagreeing about intent, which is a large share of why specs are hard to write and validate in the first place.
  Why AI Coding Agents Still Need Clear Specs — read next: Organizational and requirements-engineering material on stakeholder conflict and specification as a negotiated artifact, not merely an accuracy artifact — relevant to team-space and change-adoption thinking about how groups actually converge on shared intent.
• incompleteNo engagement with whether agile transformation frameworks actually work — the Italian study is summarized but its evidence base is not examined
  Forskning på digitalisering 2026 uke 19
• incompleteThe measurement section invokes Deming but does not specify which concrete metrics would satisfy the learning-over-control criterion in modern agile contexts
  Forskning på digitalisering 2026 uke 19
• incompleteNo discussion of how LLM-generated code interacts with the measurement problem — if LLMs generate code, what does 'developer productivity' even mean?
  Forskning på digitalisering 2026 uke 19
• incompleteThe bonus items (frontline leadership, sustainability micro-foundations, airport effects) are too thinly described to extract any propositions
  Forskning på digitalisering 2026 uke 19
• incompleteFowler offers no mechanism for detecting when 'disposable' software is silently graduating into consequential software. The disposable/consequential boundary is treated as legible to the author, but in practice it is one of the most common failure modes in software organisations — internal scripts becoming critical infrastructure.
  Bliki: Vibe Coding — read next: Cutler on institutional overload and shadow systems; classic discussions of 'tactical' vs 'strategic' programming (Ousterhout, Philosophy of Software Design); literature on shadow IT and end-user computing.
• incompleteNo engagement with the cultural/professional question of whether vibe coding deserves the name 'coding' at all, or whether legitimising it as a coding practice (rather than, say, 'spec-driven prototyping') invites exactly the diffusion problem Fowler is trying to push back against.
  Bliki: Vibe Coding — read next: Naur on programming as theory building; the broader 'what is programming' debate that has resurfaced post-LLM.
• incompleteBecause the retreat was held under the Chatham House Rule, the insights are unattributed, so a reader cannot trace claims to their sources or weigh them against the speakers' contexts and track records.
  Future Of Software Development — read next: Seek on-record accounts from named participants who wrote their own posts or granted permission to be quoted.
• incompleteThe post frames the event as forward-looking while siting it as a nod to the Agile Manifesto's 25th anniversary, but never develops what the Agile movement's 25-year trajectory might teach about the coming AI transition — the retrospective framing is invoked and then dropped.
  Future Of Software Development — read next: Compare the Agile Manifesto's 25-year arc (semantic diffusion, the 'agile industrial complex') with the current predictions about AI's effect on the profession.
• incompleteThe article treats AI as equivalent to a junior developer, but AI has fundamentally different failure modes — it can be confidently wrong in ways juniors rarely are, and it lacks the ability to say 'I don't understand the requirement.' The junior-developer analogy may lead to under-investment in verification.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on AI confabulation/hallucination in code generation; studies comparing AI and human error patterns in software development
• incompleteThe framework assumes the developer can articulate their conventions and constraints explicitly enough for AI to follow. This is Polanyi's paradox — we know more than we can tell. The Sensible Defaults pattern may hit a ceiling where the most important quality signals are precisely the ones hardest to codify.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Polanyi's 'The Tacit Dimension'; research on knowledge management and the limits of codifying expert judgment
• incompleteNo discussion of how these patterns interact with rapidly improving AI capabilities. If AI models become better at inferring project conventions from code context, some of these patterns (especially Knowledge Priming) may become unnecessary. The framework lacks a theory of its own obsolescence.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Papers on in-context learning improvements in LLMs; research on retrieval-augmented code generation
• incompleteThe article focuses entirely on individual developer-AI interaction. There is no treatment of how AI collaboration patterns interact with team dynamics — e.g., whether standardized prompts reduce healthy variation in approach, or whether shared priming docs create new coordination costs.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on coordination costs in software teams; Brooks's 'The Mythical Man-Month' on communication overhead
• uninformedNo engagement with the existing literature on human-AI teaming from other domains (aviation, medicine) where collaboration frameworks have been developed and empirically tested for decades.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on crew resource management (CRM) in aviation; human-AI teaming frameworks from DARPA and military contexts
• incompleteThe 'amnesiac AI' framing assumes no progress on persistent AI memory (RAG, project context, long-term memory). If AI memory improves, the strongest argument for specs (external memory) weakens — though the argument from verifiability would remain.
  Sam Hatoum's Post
• illogicalThe thought experiment ('if coding became instant') proves too much — it assumes zero implementation cost, but actual AI implementation is not zero-cost. The gap between 'minutes' and 'instant' may matter more than the post acknowledges.
  Sam Hatoum's Post
• uninformedCitations are underspecified throughout: the Journal of Organizational Behavior study on manager involvement gives no sample size, effect size, or definition of 'manage from a distance'; the Frontiers in Psychology moonlighting study names a sample size (324) but no effect size or engagement instrument; every leader-behavior percentage (33%, 43%, 53%, 56%, 59%, 90%+) is reported without a confidence interval, base rate, or description of how 'average team' leaders were sampled.
  How to Build a Superteam That Keeps Getting Better — read next: The original Journal of Organizational Behavior and Frontiers in Psychology papers directly; Ron Friedman's book 'Superteams' (Simon & Schuster, 2026), from which this article is adapted, for full survey methodology.
• illogicalSurvivorship bias in case selection: every illustrative organization (Thunder, Meta, Netflix, Amazon, Spotify, LinkedIn, Microsoft, Airbnb, Adobe, Estée Lauder, HubSpot, Keap, Basecamp, Haberman) is a documented success story for the practice it illustrates. No case of a team that experimented boldly and failed, admitted uncertainty and lost credibility, or had a hands-on leader who tipped into micromanagement is discussed, so each practice's downside risk and failure rate are invisible by construction.
  How to Build a Superteam That Keeps Getting Better — read next: Base-rate and survivorship-bias literature (e.g., Mlodinow, Taleb) applied to management case studies; accounts of experimentation cultures or hands-on leadership that did not pay off.
• survivorship bias in the 'craft transfers' argumentBoth speakers are masters of craft who naturally see craft as the durable skill. They do not seriously consider the possibility that AI could make some craft practices genuinely obsolete rather than merely shifting them upward. Beck comes closest with his admission of grief about losing zone-flow on code, but neither explores which specific practices may not transfer.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again — read next: Look for empirical studies or practitioner reports on which specific engineering practices AI makes less vs. more valuable.
• vague definition of 'the middle'Beck's claim about 'the middle' being most vulnerable is stated without clear criteria. How do you distinguish someone in 'the middle' from a competent professional who simply isn't a thought leader? The framing risks becoming a circular argument: those who thrive had intrinsic motivation; those who didn't were 'the middle.'
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again — read next: Look for more rigorous analysis of which programmer skill profiles are most affected by AI tooling.
• absence of data on team-structure claimsThe argument that pairs-plus-agents beats solo-plus-agents is based on XP philosophy and Beck's personal experience, not comparative evidence. Given that this is arguably the most consequential organizational design question in software right now, the evidentiary basis is thin.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again — read next: Seek out early empirical comparisons of solo-plus-agent vs. pair-plus-agent productivity and quality outcomes.
• enterprise perspective is observation without prescriptionFowler reports 'large-scale confusion and panic' and security concerns at enterprises but offers no framework for how enterprises should approach AI adoption differently from startups. The advice is pitched at individual practitioners, not organizational leaders.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again — read next: Look for enterprise-specific AI adoption frameworks (e.g., ThoughtWorks Technology Radar, or Fowler's own martinfowler.com posts on the topic).
• the COBOL analogy cuts both waysBeck invokes the recurring 'eliminate the programmers' dream (COBOL, etc.) as historical context, then adds 'it behooves us as programmers to think about why they keep wanting to get rid of us.' This self-critical aside is dropped immediately without exploration. The uncomfortable possibility — that some of the desire to eliminate programmers reflects genuine organizational friction caused by programmers — is raised but not examined.
  Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again — read next: Consider whether the 'eliminate programmers' impulse reflects legitimate frustration with the cost and difficulty of translating business intent into code, which AI might actually address.
• incompleteThe author argues that Measure and Learn remain expensive and irreducibly human, but does not explore whether AI might also transform these phases — e.g., AI-driven user behavior analysis, automated A/B testing at scale, or AI-assisted synthesis of qualitative feedback. The claim that learning is irreducibly human is asserted, not defended.
  No, AI Did Not Kill Agile — read next: Literature on AI-augmented product discovery, automated experimentation platforms (e.g., Eppo, Statsig), and whether AI can reduce the cost of the Measure/Learn phases
• incompleteThe article never engages with domains where requirements genuinely are well-understood upfront (e.g., regulatory compliance, protocol implementations, mathematical computations). The knowledge-problem framing may be less applicable in these contexts, where spec-first AI development might be entirely appropriate.
  No, AI Did Not Kill Agile — read next: Cynefin framework (Dave Snowden) for distinguishing simple/complicated/complex/chaotic domains; literature on when waterfall-like approaches are actually appropriate
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
• uninformedBeck imports the volatility/rebalancing framing directly from Kunal Bhalla ('pointed out the exception... introduced me to... Shannon's Demon') but gives no independent check that the coin-flipper model captures the actual statistical structure of real product changes, versus being an elegant trading analogy that happens to sound applicable.
  Reject Change, Sometimes — read next: Look into the empirical distribution of 'did this change help or hurt' outcomes for real product changes (e.g. from experimentation/A-B-testing literature) to see whether they're closer to symmetric, skewed, or something else entirely — and whether that distribution actually differs by company stage the way Beck assumes.
• incompleteThis essay finally explains the 'long volatility' claim that an earlier post in this series ('The Beginnings of an Idea: XP is Long Volatility') left undefined — but it delivers the general 3X (Explore/Expand/Extract) framing, not XP specifically; it never closes the loop back to concrete XP practices (pairing, TDD, continuous integration, spikes) as instances of 'short' or 'long' volatility bets the way the original teaser promised.
  Reject Change, Sometimes — read next: Watch for Beck to explicitly re-connect this volatility/Shannon's-Demon framework to specific XP practices (is TDD a 'rebalancing' practice? is a spike a 'Reckless' Explore bet?) to fully deliver on the original 'XP is long volatility' framing.
• illogicalThe article presents staff reductions (Toyota, X.com) as evidence that AI-augmented Scrum works, without separating the causal contribution of AI tooling from the causal contribution of simply cutting headcount and demanding more from fewer people — a confound that would need controlling for before the case studies could support the stated productivity-multiplier claim.
  Is Agile Dead? How AI and Extreme Agile Redefine Work — read next: The sibling extraction 'No, AI Did Not Kill Agile' argues the opposite framing risk directly: that 'AI killed Agile' narratives are politically convenient cover for management to reassert top-down control, independent of whether AI delivers the claimed gains.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteTrust is treated as one undifferentiated resource. Trust between paired programmers, trust from the rest of the team, trust from the customer, trust in the system (observability) — Beck collapses these. But they have different production functions, different decay rates, and may not be substitutable. A skeptic might point out that customer trust is far more about delivered value than pairing rituals, while pair-trust is largely independent of customer outcomes.
  Trust Factory — read next: Janson + Wester on pair-trust (Heis ep 6 — 'if something feels off, say it once'); Printzell Halvorsen on Nordic societal trust enabling distributed teams (Heis ep 8); Onora O'Neill on the trust-trustworthiness distinction and on different kinds of trust requiring different verification structures.
• incompleteThe 'trust factory' metaphor is endorsed without examining what it concedes. 'Factory' implies trust is manufactured by repeating standardized processes — but a major tradition (cultural, philosophical, theological) treats trust as precisely the kind of thing that cannot be manufactured. Beck does not engage this objection. The metaphor's industrial framing also obscures that XP practices may have worked because they instantiated values the practitioners already held — not because the practices produced the values.
  Trust Factory — read next: Cutler on operating-system design vs cultural pre-conditions (TBM series); Diego Gambetta on trust as a non-manufacturable resource; the 'culture eats process for breakfast' literature.
• incompleteThe four 'slow development' prescriptions are stated but not operationalized for the augmented case. How exactly do you 'slow development to encourage frequent person-to-person interaction' when the genie is so seductive? What are the equivalent of XP practices for the augmented era? Beck explicitly defers this ('not yet settled') but a reader looking for action is left with a principle, not a practice.
  Trust Factory — read next: Beck's own subsequent essays (the 'XPAI' thread he's hinting at); Birgitta Böckeler on harness engineering; Garg on reducing friction in AI development (both already in the user's extracted corpus); Bockeler/Anthropic harness writing.
• incompleteThe cultural specificity of trust is not addressed. XP emerged in a high-trust professional subculture (Chrysler C3, early agilists). Whether the trust factory works in low-trust organizational contexts — or only metabolizes pre-existing trust — is left untested. Same question applies to whether trust factories scale across cultural and national boundaries.
  Trust Factory — read next: Printzell Halvorsen on Nordic high-trust societies enabling distributed teams (Heis ep 8); Fukuyama on high-trust vs low-trust societies; cross-cultural management literature.
• incompleteThe 2-day cycle is presented from the inside of a single, apparently small team ('we've been trying'); the post doesn't address whether a 3-day cadence (plan/build/demo) scales to multiple interdependent teams, where cross-team dependencies, shared architecture decisions, and release coordination historically required longer sprint boundaries to synchronize.
  Erik van der Pluijm's Post — read next: Cross-read against the corpus's coordination-cost and multi-team scaling material to test whether compressed cycles survive beyond a single small team.
• incompleteThe 'long-baked ideas' theory of how his frameworks originate is offered purely as autobiographical pattern-matching across Beck's own past examples (3X, Genie, Thinkies), with no engagement with the existing psychology-of-creativity literature on incubation.
  The Beginnings of an Idea: XP is Long Volatility — read next: Graham Wallas's four-stage model of creativity (preparation, incubation, illumination, verification, from The Art of Thought, 1926); empirical work on incubation effects in problem-solving (e.g. Sio & Ormerod's meta-analysis on incubation and insight).
• uninformedBeck doesn't say who originated the 'XP is long volatility' framing he 'heard... yesterday' — whether it's his own restated insight, a collaborator's phrase, or something from the broader trading/software crossover community. Without attribution, readers can't independently trace or evaluate the idea's source before Beck's own treatment arrives.
  The Beginnings of an Idea: XP is Long Volatility — read next: No source available yet; would require Beck's future post or direct correspondence to resolve.