Test-Driven Development

Writing failing tests before implementation — a feedback discipline that survives and gains importance when agents write the code, because tests instrument the loop.

Also known as: TDD, test-driven development, red-green refactor / TDD with an agent, red-green refactor, T*D, doc-test

How authors use it

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

Documents (24)

• 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.
• Practices I Abandoned with Agents: An Ode to Test-Driven Development Adam Tornhill · 2026-09-03 source ↗ Reader 🖥️
  Granular, human-cognition-scaled Test-Driven Development does not survive the transition to agentic coding and should be replaced by a coarser, feature-level practice — tests (especially end-to-end) as the human/agent abstraction boundary, with failing-test discipline retained but no longer organizing work into small red-green-refactor steps.
• When AI Writes the Code, Specifications Need an Exit Strategy Markus Eisele · 2026-08-17 source ↗ Reader 🖥️
  When building software with AI coding agents, a specification should be a temporary 'change brief' that describes only the delta between current and intended behavior and expires at release, because durable system knowledge belongs in the native artifacts engineering already trusts to stay synchronized with the code — schemas, types, tests, policies, and telemetry — not in permanent prose that inevitably drifts and consumes an agent's finite context budget.
• agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub Addy Osmani · 2026-07-28 Reader 🖥️
  agent-skills, Superpowers, and Matt Pocock's skills all encode good agentic-engineering discipline but optimize for different moments in the work — full product-lifecycle governance with human checkpoints (agent-skills), autonomous reasoning-heavy execution (Superpowers), or a sharp personal daily toolkit (Matt Pocock) — and while the piece insists 'none of them is best in the abstract,' its own structure (author's project profiled first-person, most elaborated column, sole cited empirical case study, broadest 'reach for X' pitch) quietly tilts the honest map toward agent-skills.
• How Do You Know That? Kent Beck — Still Burning Podcast · 2026-07-22 Reader 🖥️
  The skill that matters most — in engineering craft, in working with AI agents, and in locating accountability when automated systems act — isn't knowing the answer but asking 'how do you know that?': interrogating the actual reasons behind behavior, code, and systems, because that meta-intelligence diagnoses root causes invisible to observers of behavior alone, and because AI agents, having no drive or accountability of their own, can never do that interrogating or that owning on a human's behalf.
• Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman · 2026-07-14 source ↗ Reader 🖥️
  Because AI has decoupled writing code from understanding it, engineering organizations must run spec-anchored specification-driven development, test-driven development, and architectural fitness functions together as one verification system so that their combined artifacts form a versioned, queryable "context store" — making comprehension a lifecycle property of evolutionary architecture that both human reviewers and AI agents can draw on, rather than a pre-merge concern that AI-generated speed otherwise outruns.
• How Datadog Used Claude and Cursor for Test-Driven Production Migration Sergio De Simone · 2026-07-10 Reader 🖥️
  Datadog's AI-assisted migration of a critical production system off a key-value backend onto a relational one succeeded not because Claude and Cursor generated code autonomously, but because a strong human-authored test suite plus a live blue/green validator supplied the pass/fail oracle that bounded and verified every AI-generated change — making the coverage of that verification, not the capability of the model, the ceiling on how much AI output could be trusted.
• 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.
• 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.
• Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
  In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.
• Software Teaming in the Age of AI with James Herr and Woody Zuill Mob Mentality Show · 2026-07-07 Reader 🖥️
  As AI takes over more of the actual typing, ensemble/mob programming becomes MORE important, not less — because code was never the real bottleneck (queueing on requirements and stakeholder availability always was, and AI's speed just exposes that more starkly), and because AI removes typing-speed as the reason non-coders couldn't stay in the room. The core discipline mob programming already trains — communicating high-level intent instead of dictating each low-level step — turns out to be the same skill effective AI-agent direction requires, so learning to team well and learning to direct agents well are converging into one discipline. But this potential is bounded by real, concretely observed LLM reliability limits (non-determinism, context forgetting, and test-hardcoding instead of genuine rule implementation) that demand deliberate engineering countermeasures — deterministic code generators, unit tests reframed as guardrails rather than TDD-as-design, and small on-demand skills files instead of one long instructions file — not blind trust in AI capability claims.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• KI, utvikling og følelser Vidar Moe · 2026-05-21 source ↗ Reader 🖥️
  Generative AI is reshaping software development less as a productivity story and more as an emotional one — moving developers from building to specifying systems, and the central professional question is no longer how to ship faster but how to keep developers from becoming alienated, dulled, and burnt out, which requires deliberately keeping humans inside the loop through code-the-foundation workshops, explicit TDD with the agent, and a psychological reframe from programming to problem-solving.
• [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero AI Engineer (channel); speaker: Matt Pocock (AI Hero) · 2026-04-24 source ↗ Reader 🖥️
  AI is not a new paradigm for software engineering — the fundamentals that make working with humans effective (small tasks, vertical slices, deep modules, fast feedback loops, alignment through dialogue, TDD) are exactly what make working with AI agents effective; the path from idea to shipped feature is therefore a deliberately planned, human-driven pipeline (align → PRD → vertical-slice Kanban → AFK implementation → QA) in which the codebase itself is treated as the battleground, not the spec.
• It Ain't Broke: Why Software Fundamentals Matter More Than Ever Matt Pocock (AI Hero conference talk, AI Engineer) · 2026-04-23 Reader 🖥️
  Because AI amplifies the cost of bad code through software entropy, investing in software design fundamentals — shared understanding, ubiquitous language, deep modules, TDD, and deliberate architecture — matters more in the AI era than it ever did before.
• T*D Andrea Laforgia · 2026-04-10 Reader 🖥️
  When software teams genuinely pursue speed, quality, and shared ownership simultaneously, they naturally converge on three mutually reinforcing practices — test-driven development, trunk-based development, and team-focused development (pairing/mobbing) — which the author brands as T*D.
• 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.
• Fragments: February 18 Martin Fowler · 2026-02-18 source ↗ Reader 🖥️
  AI-assisted software development is best understood as an amplifier of a team's existing practices rather than a disruptive break, so the field's real work is rebuilding the human-era practices that are predictably breaking—through emerging disciplines like the supervisory middle loop, risk tiering, TDD-as-prompt-engineering, and platform 'bullet trains'—amid far more shared uncertainty than settled answers.
• Fragments: February 9 Martin Fowler · 2026-02-09 source ↗ Reader 🖥️
  As LLMs absorb more of the work of building software, the pressing questions are less about model capability than about what humans stand to lose — the team's understanding of the system (cognitive debt), the intellectual craft-joy of model-building, and even the meaning of 'source code' as behavior shifts from deterministic text toward non-deterministic natural-language prompting.
• The Future Of Software Engineering Thoughtworks · 2026-02 Reader 🖥️
  As AI takes over code production, engineering rigor does not disappear but migrates to specifications, tests, constraints, risk management, and a new 'middle loop' of supervisory work — and organizations that fail to deliberately rebuild their practices, roles, and governance around these new destinations will suffer compounding losses in quality, comprehension, and stability.
• Why Rust is different, with Alice Ryhl The Pragmatic Engineer (Gergely Orosz, host) · 2026 Reader 🖥️
  Rust earns its growing adoption not by adding features but by systematically engineering away whole classes of programmer mistakes — null, uninitialized memory, unhandled errors, stale documentation, memory-unsafety, non-exhaustive matches — through a type system, ownership/borrow checker, and a governance and tooling culture (RFCs, editions, Cargo, doc-tests) that treats reliability as a composite property rather than a single feature.
• How Claude Code Is Built Gergely Orosz · 2025-09-23 source ↗ Reader 🖥️
  Claude Code is built by a small team that treats the Claude model itself — not its own surrounding code — as the real product, deliberately minimizing scaffolding, choosing an "on-distribution" tech stack the model already masters, deleting code whenever a new model release subsumes it, and restructuring code review, testing, incident response, and prototyping around AI doing the first pass; Orosz presents this as a plausible preview of how "AI-first" engineering teams will operate, while flagging that Anthropic's unlimited, cost-free access to its own frontier model and its identity as a research lab (not a product company) limit how directly the specifics transfer elsewhere.
• Claude Code: Best practices for agentic coding anthropic.com · 2025-04-18 source ↗ Reader 🖥️
  Because Claude Code is deliberately low-level and unopinionated, its effectiveness on your problem is set by the harness you engineer around the model — the context, tools, and workflow you supply — not by the raw model alone.
• Bugs in Large Language Models Generated Code: An Empirical Study Florian Tambon, Arghavan Moradi Dakhel, Amin Nikanjam, Foutse Khomh, Michel C. Desmarais, Giuliano Antoniol · 2024-03-13 source ↗ Reader 🖥️
  Bugs in LLM-generated code are not simply a noisier version of human bugs but form a distinct, empirically-grounded taxonomy of 10 patterns — and roughly two-thirds of observed bugs (Wrong Attribute, Hallucinated Object, Prompt-biased Code, Non-Prompted Consideration) stem from the model's generative/stochastic nature rather than from prompt underspecification, meaning no amount of better prompting will eliminate them and tooling built on human-bug assumptions (like mutation-based program repair) will systematically underperform on AI-generated code.

Propositions touching this concept (6)

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

2025-04

• explicitcontestedTest-driven development becomes even more powerful with agents: have Claude write tests from expected input/output pairs first (avoiding mocks), confirm they fail, commit them, then write code that iterates until all tests pass — without modifying the tests.
  Claude Code: Best practices for agentic coding · p9

2025-09

• explicitTest-driven development — described as having fallen out of favor industry-wide in the 2010s because writing tests first felt slow — has had a practical renaissance on the Claude Code team specifically because Claude 4.0-era models are capable enough to write most tests themselves, giving the agent a concrete target (a failing test) to iterate against.
  How Claude Code Is Built · p9

2025-12

• explicitTest-Driven Development, applied naively to LLM outputs, fails because TDD assumes a single deterministic correct output to assert against, while LLM outputs are subjective and have no single correct answer.
  A pragmatic guide to LLM evals for devs · p1

2026-07

• explicitcontestedUnit tests function as a design tool in classic test-driven development because the implementer reasons about the shape of a solution while writing them — but an LLM has no equivalent design intent when generating tests, so TDD-as-a-design-discipline does not transfer to LLM-authored code.
  Software Teaming in the Age of AI with James Herr and Woody Zuill · p11

2026-08

• explicitIt is a mistake to impose a human behavioral discipline (such as strict line-by-line test-driven development) directly on an agent, because the discipline exists to compensate for a specific human limitation (short-term memory) that agents don't have in the same way; it is not a mistake, however, to impose the underlying human values the discipline was meant to serve (full test coverage, low complexity).
  LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p11

2026-10

• explicitIn an agentic workflow, test-driven development stops being optional ceremony and becomes the mandatory safety system that prevents the factory from stalling or shipping incorrect output.
  #ai #programming #softwareengineering | Addy Osmani | 11 comments · p7

Tensions

Open gaps (53)

• uninformedThe article asserts (via the Three Gulfs framing) that naive TDD 'falls short' for LLMs without engaging the corpus's own counter-evidence that code-based evals are themselves just traditional assertion-style unit tests re-applied to the subset of LLM behavior that IS deterministic — i.e., TDD isn't abandoned so much as partitioned, a point the article makes implicitly but never states as a correction to its own TDD framing.
  A pragmatic guide to LLM evals for devs — read next: extract-you-cant-unit-test-for-taste (this corpus) — direct treatment of where unit-testing does and doesn't apply to AI-generated output quality.
• incompleteTeam adoption is treated as an exercise for the reader. Pocock's answer to 'how does this work in a team?' is essentially: 'the upstream becomes team-shared, the downstream is one or two devs managing the pipeline.' He gives no story for: review queue scaling, distribution of PRD-authoring authority, who owns skills/coding-standards as a shared asset, code-review burden as a team-wide labour question, or how juniors learn craft in a workflow where most code is agent-written.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Cutler on overload and accountability culture; Beck on socio-technical change; Fearless Change for the adoption-of-practices angle in the user's hidden-layer interests.
• incompleteThe 'pre-AI books' recommendation is the closing thesis but is left underspecified. Pocock cites Pragmatic Programmer (tracer bullets), Ousterhout's Philosophy of Software Design (deep modules), Brooks's Design of Design (design concept), Fowler's Refactoring (small steps) — but does not give a reading list, nor a mapping of which insight from which book deploys at which point in the workflow. This is the load-bearing connection to the user's craft tradition and is left as a 'go buy them on Amazon.'
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: The user's library already covers Beck (small steps, TCR, simple design), Hickey (Simple Made Easy), Yourdon & Constantine (Structured Design), Meadows (Thinking in Systems). The mapping work is for the orchestrator to do: e.g., Pocock's 'don't bite off more than you can chew' is Fowler-on-refactoring; deep modules is Ousterhout; tracer bullets is Hunt & Thomas; design concept is Brooks. The honest gap is that Pocock does not even mention Beck — surprising given Beck's TCR is operationally close to red-green-refactor as Pocock practices it.
• incompletePocock's workflow structurally mirrors Anthropic's harness paper (planner / generator / evaluator) and Böckeler's adaptive-control framing, but he does not name them or compare. The grill-me skill is alignment; the PRD-to-Kanban is planning; the AFK Ralph loop is generation; TDD + manual QA + reviewer-Opus is evaluation. Surfacing this overlap is essential to placing his workshop in the broader 2026 AI-coding discourse.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Anthropic harness paper, Böckeler on adaptive control, Addy Osmani on agent patterns (in the user's saves) — all map onto Pocock's lifecycle with different vocabulary.
• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe implicit premise that the developer can read agent output well enough to QA, code-review, and impose taste is enormous. Pocock states 'understanding code deeply is going to make you a much, much better developer and get more out of AI' and 'bad codebases make bad agents' — but does not address the developer who is themselves junior, distracted, or not the original architect. The workflow may be most valuable to seniors and least usable by the engineers who most need leverage.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Marcus on code quality (in user's recent saves), Beck on apprenticeship/teaching contexts, Cutler on directly-responsible-individuals and skill distribution.
• uninformedPocock specifically defers the question on conforming to security, architectural, and API-contract constraints ('I'm going to answer that in a bit') and never returns to it. For the user's organizational context (Norwegian senior leader watching governance signals), this is the highest-value question and is left unaddressed.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Security-review skill, Schneier on Security, explainable-AI requirements paper in the user's library, organisational adoption studies on AI tooling in regulated industries.
• incompleteThe Amazon outage is presented as an outcome of the exact context gap this article diagnoses, but the article's own cited source (CNBC) attributes the outage to "changes merged without proper review" — a review-gate failure — not to a documented absence of persisted intent, behavior, or conformance records specifically. The causal attribution to the context gap, versus a more generic review-diligence lapse, is asserted rather than demonstrated from the available reporting.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Follow further Amazon incident reporting or post-mortems, if published, to see whether investigators identified a missing intent/behavior/conformance record specifically, or a simpler story of a skipped approval step that a context store would not by itself have prevented.
• incompleteThe blue/green validator verifies behavioral EQUIVALENCE to the old Stream Router, not correctness: it checks that the new router's responses match the old one's on each live request. Any latent bug or quirk in the old FoundationDB-backed system would be faithfully preserved and pass the validator silently, and the per-method TDD loop likewise inherits whatever blind spots the human-authored failing tests contain. The article never examines this — it treats 'agrees with the old system / passes the tests' as equivalent to 'correct', so the oracle's own fidelity to true intent is unquestioned.
  How Datadog Used Claude and Cursor for Test-Driven Production Migration — read next: Read against extract-what-survived-contact#g4 (the Goodhart case where a passable oracle diverges from true, uncheckable intent) and the reference-oracle concept: a referenced-live oracle covers every input but only relative to the reference's own behavior.
• incompleteThe human/AI division of labor is characterized qualitatively (AI does first-pass translation; humans supply schema, tests, and optimizations) but never quantified: no data on what fraction of methods the AI got right on the first pass versus needed manual fixes, how many iterations the loop took, or how the AI-driven migration compared in effort or time against a conventional hand-refactor.
  How Datadog Used Claude and Cursor for Test-Driven Production Migration — read next: Read the original Datadog engineering post (datadoghq.com/blog/engineering/ai-assisted-storage-migration) for any first-party figures the InfoQ summary dropped; then compare with extract-doordash-copilot-ios-test-migration#g1, which flags the same missing intervention-fraction data for an AI-assisted test migration.
• 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.
• misinformedThe TDD-as-prompt-engineering claim rests on self-selected testimonials from leading-edge LLM users; Fowler himself flags confirmation bias, and no controlled comparison against other test or specification strategies is offered.
  Fragments: February 18 — read next: Look for controlled studies on whether TDD improves LLM coding outcomes versus alternative feedback strategies.
• incompleteThe proposed understanding-consolidation step 'analogous to TDD's refactor' is gestured at but never specified — no defined practice, cadence, artifact, or acceptance criteria beyond the fairy-tale-explanation tactic.
  Fragments: February 9 — read next: Read on comprehension practices for AI-written code: decision records/ADRs, code walkthroughs, and structured explanation or knowledge-consolidation rituals.
• incompleteTeam-level and organizational dynamics are almost absent. The piece is written from the individual developer's interior, with the team as a setting but not an object of analysis. Yet many of the named harms (large PRs defeating review, knowledge transmission to new developers, burnout) are fundamentally social phenomena. What happens to pair-programming culture? To mentorship? To code-review-as-teaching? To the social production of shared mental models when an agent is the third participant? The essay names the symptoms but stays at the level of the individual practitioner.
  KI, utvikling og følelser — read next: Pair with John Cutler on team operating systems (the 'institutionalized overload' arc) and with Beck/Cutler on how design discussion functions socially. Also read Pamela Hieronymi or similar on what attention/understanding requires of a community, not just an individual. The user's existing extraction on 'AI Joy Gap Developers' — which treats the polarization as needing organizational structures (AI platform teams, cultural practices reconnecting developers) — is a direct complement to Moe and worth reading together.
• incompleteWhat happens when the agent fails you, or when its behavior shifts under you (a model upgrade, a vendor policy change, an outage)? Moe writes from a moment of arrival ('Opus 4.5 is good enough'), but his entire psychological framework presupposes that the agent is a stable enough partner that you can build a working rhythm with it. The risk of dependency on a non-stationary, vendor-controlled colleague is not addressed.
  KI, utvikling og følelser — read next: Read alongside the user's existing extractions on 'AI Inference Unit Economics' and 'AI Companies Reckless Not Evil' — those address the supply side of the same dependency. Also worth pairing with anything on platform risk and lock-in in developer tooling.
• incompleteNo engagement with the counter-thesis that agentic specification is itself a learnable new craft with its own first principles, rather than a hollow shell around an absent practice. Moe treats 'specifying' as essentially less than 'building' — the alienation premise depends on this. But it is at least defensible to argue that designing the specification surface, the test contract, the architectural guardrails, and the review protocol for an agent is a real engineering act that has its own depth. The essay would be stronger if it engaged this counter-position rather than implicitly dismissing it.
  KI, utvikling og følelser — read next: Steve Yegge's vibe coding manifesto (which the user is tracking) and Gene Kim's vibe coding series are explicit attempts to defend specification as craft. Read Moe in tension with them, not just alongside. Beck's evolutionary design tradition is also relevant: is the agent a new kind of pair-programmer that requires a new design discipline, or is it the thing that hollowed out the discipline?
• incompleteGenerational and career-stage differences are absent. Moe writes as a senior developer at an established Norwegian banking organization. The piece's emotional grammar — feeling alienated, missing the satisfaction of having built something, worrying about transmission — is the emotional grammar of an experienced practitioner. For a developer who entered the profession in 2024, agent-coding is not a loss but a baseline; the very experience of 'fremmedgjøring' may not arise. Moe's essay is implicitly written from one career stage and would be more powerful if it acknowledged this.
  KI, utvikling og følelser — read next: Anything serious on generational cohorts in tech adoption. Look for empirical work on new-developer experience in AI-assisted environments — this is a real research gap right now. The user's interest in the 'Stolen Focus' tradition suggests this is also a place where the digital-native vs digital-immigrant frame might be productively applied to AI-native vs AI-immigrant developers.
• incompleteThe Norwegian / Nordic context of the essay is implicit but not theorized. SpareBank 1 Utvikling, the T-bane, Norwegian engineering culture's relative emphasis on 'flyt', autonomi and mestring (drawing on Self-Determination Theory in a way that pervades Nordic management discourse) — all of this shapes Moe's framing. An anglophone reader might miss that 'venting på autocomplete' as a moral category is partly a Norwegian work-culture artifact. There is a comparative essay latent here that the piece does not write.
  KI, utvikling og følelser — read next: Read in parallel with anglophone AI-coding voices (Beck's recent essays, Cutler's TBM 412 on institutionalized overload + AI) to see what gets emphasized differently. The NAV 'optimizing for fast flow' piece already in the user's queue is a useful Nordic-context anchor.
• 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.
• incompleteNo quantitative comparison is given between outcomes under Claude-Code-first-pass review/testing/incident-response and Anthropic's own prior, pre-Claude-Code baseline. Every improvement cited (67% PR throughput increase, faster incident root-causing, two-week migrations) is self-reported by Anthropic insiders or by customer companies with an interest in the tool's success, with no external or controlled measurement.
  How Claude Code Is Built — read next: Read against extract-dx-measuring-ai-impact and extract-five-studies-ai-software-engineering, which raise the same self-selection and construct-measurement concerns for AI-engineering-impact claims generally.
• incompleteThe article notes Anthropic deliberately keeps feature flags minimal because 'feature flags slow the team down,' but never examines whether this is sustainable given the growth-driven monitoring load the same article describes (alerts firing 'pretty much every day' simply from rapid growth) — nor what happens to blast-radius risk as Claude Code's external user base keeps scaling well past where it is today.
  How Claude Code Is Built — read next: Read against async-code-reviews-choking-throughput's discussion of trunk-based development and feature flags as an alternative risk-mitigation mechanism the article doesn't engage with directly.
• incompleteThe author treats unrestricted, cost-free access to the most expensive Claude model as a structural advantage unique to Anthropic, but never asks what Claude Code's own internal practices (TDD renaissance, 60-100 releases/day, 5+ prototypes/day) would look like, or whether they would remain viable, under the token-cost and usage-quota constraints that every other company — including Claude Code's own external users, per a reader comment quoted in the discussion thread — actually operates under.
  How Claude Code Is Built — read next: Compare against practitioner reports from non-Anthropic teams operating under real token budgets, to see which of these practices survive a hard cost constraint.
• incompleteThe 67% PR-throughput increase coincides with, but the article never disentangles from, the fact that new joiners during Anthropic's hiring surge were likely disproportionately experienced senior engineers already fluent with Claude Code's own on-distribution stack (TypeScript/React) — leaving open whether the throughput gain is attributable to Claude Code itself or to who Anthropic was able to hire.
  How Claude Code Is Built — read next: Look for engineering-productivity research that isolates tool effect from hiring-composition effect during headcount-doubling periods.
• incompleteThe talk claims AI performs well in good codebases and poorly in bad ones, but provides no data or examples to substantiate this — it relies entirely on the audience's intuitive agreement.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for empirical studies measuring AI coding tool performance as a function of codebase quality metrics (coupling, cohesion, test coverage).
• incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
• incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
• incompleteThe talk assumes TDD is applicable to all AI-generated code, but does not address domains where TDD is hard to apply (UI, data pipelines, exploratory prototyping) or where the cost of test-writing may exceed the cost of debugging.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for frameworks on when TDD is cost-effective vs. when other feedback mechanisms (type checking, property testing, visual review) are better suited.
• incompleteThe talk's five tips are presented as independent failure modes, but the dependencies between them are not explored. For example, does ubiquitous language require deep modules to be effective? Does Grill Me only work if the developer already has architectural knowledge?
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Consider whether these practices form a prerequisite chain or can be adopted independently.
• incompleteThe category of bug Rust does NOT prevent is left implicit. Logic bugs, mis-modeled domains, distributed-systems race conditions across services, mis-handled business invariants — these are arguably the dominant cost in modern backends, and Rust's compile-time machinery does not touch them. Yet the conversation rhetorically positions Rust as 'reliable' full stop.
  Why Rust is different, with Alice Ryhl — read next: Read Hillel Wayne on formal methods and where types stop helping; Rich Hickey 'Simple Made Easy' on complexity that types don't catch; recent work on property-based testing (Hegel/Hypothesis — sponsor of this very episode, interestingly).
• incompleteThe organizational shift Rust demands is gestured at ('change the struct, not the code') but never made explicit. Adopting Rust seriously means moving design effort upstream — into types and ownership topology — which has real implications for who designs, when, and how PRs are reviewed. The conversation treats this as a personal learning curve when it is plausibly a team-process redesign.
  Why Rust is different, with Alice Ryhl — read next: Read Kent Beck on where in the design timeline to invest effort (Tidy First?), Yourdon & Constantine on coupling/cohesion as the unit of design, and Ousterhout's 'A Philosophy of Software Design' on deep modules — then ask: in a Rust shop, who owns ownership decisions, and when?
• incompleteThe cost-of-incidents argument is anchored to a Western, large-company threat model ('don't get woken up at night,' 'don't ship a CVE,' 'don't lose root'). It would be much stronger framed against actual cost-curve data: how much do memory-safety CVEs cost on average, what fraction of Google/Microsoft/AWS incident postmortems involve memory bugs, what's the marginal Rust dev-hour cost per prevented incident? Alice alludes to '~70% of Microsoft/Google bugs are memory bugs' folklore without citing.
  Why Rust is different, with Alice Ryhl — read next: Read the Microsoft Security Response Center memory-safety report (the source of the 70% figure), Google's Android memory-safety post-Rust adoption data, the CISA secure-by-design memo, and the US DoD/NSA memory-safety guidance Alice alludes to.
• incompleteThe Cargo/npm risk parallel is acknowledged and immediately dropped. Given the kernel's explicit rejection of fetch-and-run package management (Linus's anecdote), Rust's strategy for supply-chain integrity is load-bearing for any organization considering it for security-sensitive code — yet the episode offers nothing beyond 'it's a hard problem.'
  Why Rust is different, with Alice Ryhl — read next: Read crates.io's threat model docs, the Cargo audit/cargo-vet tooling, Linux distributions' approaches to vendoring Rust crates, and recent academic work on the npm/PyPI/crates supply-chain attack surface.
• incompleteThe Rust-and-AI thesis ('compiler-as-leash for agents') is asserted but not pressure-tested. Crucially absent: what happens when the agent reaches for `unsafe` to satisfy the compiler? What happens when the agent's chosen data structure is the wrong one and the compiler keeps approving — but at the cost of forcing Arc<Mutex<...>> everywhere? The compiler can't catch 'this struct shape was a bad idea.'
  Why Rust is different, with Alice Ryhl — read next: Look for empirical evaluations of AI coding agents in Rust vs in Go/TypeScript (recent benchmarks from Anthropic/OpenAI/SWE-bench-Rust), and pair with vibe-coding critiques like Steve Yegge / Gene Kim — exactly what Kjetil is already reading.
• uninformedGergely floats 'is Rust uniquely good for agents because of compiler feedback?' and neither speaker has data; Alice has 'tried to use them' but is 'still learning.' This is a place where the conversation would have benefited from a third voice with measured agent-on-Rust experience.
  Why Rust is different, with Alice Ryhl — read next: Recent reports/benchmarks on agentic coding by language (e.g. METR/Anthropic, Cursor postmortems, the Aider language-success-rate leaderboard) would directly fill this.
• illogicalThe phrase 'when it compiles, it works' is acknowledged-in-quotes but then deployed as if it were literally true (Alice's refactoring anecdote, Gergely's monologue). This conflates 'no bugs in the bug-classes Rust catches' with 'no bugs at all.' For an audience of senior engineers, the difference matters and the slippage is rhetorically convenient.
  Why Rust is different, with Alice Ryhl — read next: Read any survey on bug-class distributions in production systems; pair with Brian Goetz / Bjarne Stroustrup commentary on the limits of static typing.
• incompleteJames's deterministic-generator mitigation (LLM writes a DSL interpreter once; all subsequent code is produced deterministically) is never applied to or tested against Woody's concrete counterexample (an LLM hardcoding outputs across a ~1,296-variant rule engine instead of generalizing). It's left unclear whether the generator pattern would have solved Woody's failing case, or whether it only works for domains that are naturally table/DSL-shaped (like device control) rather than combinatorial business-rule logic.
  Software Teaming in the Age of AI with James Herr and Woody Zuill — read next: Apply James's DSL/generator pattern directly to Woody's rule-engine example and see whether it resolves the hardcoding failure, or find other reports of the generator pattern applied to combinatorial (not device-control) business logic.
• scope limitationThe article never addresses contexts where T*D may not apply or may need significant adaptation — solo developers, open-source projects with asynchronous contributors, research/exploratory coding, or very early-stage prototyping.
  T*D — read next: Investigate when trunk-based development or pairing breaks down (e.g., distributed open-source, 1-person teams, spike work).
• missing causal mechanismThe three practices are presented as a unified triad (T*D) but the article never explains why these three specifically, or how they causally reinforce each other. The mutual reinforcement is implied but not argued.
  T*D — read next: Look for literature on the interaction effects between TDD and CI/CD, and between pairing and TDD adoption success.
• survivorship bias riskThe 'natural emergence' argument draws on teams that succeeded. Teams that tried these practices and failed, or high-performing teams that use different approaches, are not discussed.
  T*D — read next: Examine DORA data more carefully for whether TBD is necessary or merely correlated; look at high-performing teams using different workflows (e.g., Linux kernel's patch-based model).
• evidence selectivityThe pairing research cited (Williams & Kessler 2000) is over 25 years old. More recent and nuanced studies on pair programming effectiveness are not referenced.
  T*D — read next: Review recent meta-analyses on pair programming effectiveness, particularly in remote/distributed settings.
• is-ought gapThe article moves from 'these practices emerge naturally' (descriptive) to 'these are the only sensible way to work' (prescriptive) without bridging the logical gap. Natural emergence does not entail optimality.
  T*D — read next: Consider evolutionary arguments: not all convergent outcomes are optimal; they may reflect local optima or shared biases in the practitioner community.
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• incompleteThe article never addresses teams whose native artifacts are themselves weak or absent (no real schema contracts, thin or no test suite, no telemetry). For them, 'keep durable facts in their native form' recommends a home that doesn't yet exist, and the article gives no guidance on sequencing — build the native artifact first, or use prose as a legitimate transitional stopgap while it matures.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for material on artifact/observability maturity models, or on how teams bootstrap schema, test, and telemetry discipline in codebases that currently have none, to test whether prose specification is a legitimate transitional artifact rather than pure waste.
• uninformedThe mapping of durable-fact categories to native artifacts (API shape to schemas, data invariants to types, security to policies, architecture to tests, reliability to telemetry, release to CI/CD) treats each category as if it maps cleanly one-to-one, without engaging cases where a single durable fact spans several categories at once (e.g., a business policy that is simultaneously a data invariant, a security rule, and a UX constraint), or with prior literature on the difficulty of converting tacit organizational knowledge into formal artifacts.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Knowledge-elicitation and requirements-engineering literature on tacit-to-explicit knowledge conversion (e.g., Nonaka & Takeuchi's SECI model), and this corpus's own organizational-forgetting material (extract-3-ways-ai-can-free-orgs-from-legacy-workflows) on how depersonalized evidence surfaces facts nobody wrote down anywhere.
• incompleteThe empirical studies cited (ambiguity repair improving results ~31%, SWT-Bench doubling precision, TLA+ translation reaching only ~27%/9% syntactic/semantic correctness) support 'small specs plus independent verification' in general, but none of them actually measures this article's central claim — that treating specs as temporary and promoting only durable facts to native artifacts reduces total cost or drift compared to alternative approaches.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for empirical work directly comparing 'temporary change-brief' workflows against both prose-heavy and specless workflows on drift, rework, or maintenance cost — the same empirical gap already flagged in extract-eisele-ai-coding-agents-need-clear-specs#g1 for the U-shaped cost curve, now recurring for this piece's 'expire the spec' claim.