Practices I Abandoned with Agents: An Ode to Test-Driven Development
Adam Tornhill · article · 2026-09-03 source ↗ Reader 🖥️
Agentic EngineeringAI-Friendly Code (Code Health for Agents)Human-in-the-LoopPull Requests & Async Code ReviewTest-Driven DevelopmentVerifiability (as the Quality Bar)
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.
practical · mixed — Narrative (two autobiographical paradigm-shift stories) in service of an argumentative claim about which practice to adopt now; ends with a prescriptive recommendation for agentic development.
Structure
| Part | Role |
|---|---|
| TDD backstory and the radar-station project win | evidence / credibility |
| The Clojure/CodeScene REPL-driven shift | precedent / argument-by-analogy |
| Agentic coding: exit TDD | core argument |
| The surviving part of TDD (double-entry bookkeeping, red-green redefinition, delegated refactoring) | qualification / synthesis |
Key terms
- TDD Test-Driven Development
Not fundamentally about testing; a low-level *design* technique whose verification (passing tests) is a side effect. Its name is, in his view, a historical misnomer. - human/agent abstraction boundary
The contract (typically expressed as a test, especially an e2e test) that lets a human trust and validate what an agent produced without reading the implementation. - double-entry bookkeeping
Driving every codebase change from a failing test that existed *before* the agent touched the code, specifically to prevent the agent from resolving a failing test by deleting it or weakening its assertion instead of fixing the implementation. - red (in agentic red-green)
Confirms the test suite is capable of catching bad agent changes — a statement about the verification harness's power.
Propositions
- explicitTDD was the author's default programming mode for 25 years and made him a measurably better developer.conf: high
- explicitTDD is fundamentally a design technique with low-level verification as a side effect, not primarily about testing.conf: high
- explicitcontestedForcing an agent through TDD's human-cognition-sized increments negates most of agentic coding's benefits.conf: highcontradictsHow Datadog Used Claude and Cursor for Test-Driven Production Migration · p2 — Datadog's migration succeeded by keeping agents on a tight per-method leash with a failing test for each small unit — the granular, test-first discipline Tornhill specifically abandoned as unproductive for agents. Both keep 'test first,' but disagree sharply on granularity.
- explicitcontestedEffective agentic development works at the feature level, where one agentic iteration subsumes tens of what would have been separate TDD red-green-refactor cycles.conf: highcontradictsFragments: February 18 · p5 — Fowler's retreat synthesis holds TDD as 'the strongest form of prompt engineering' for driving LLMs; Tornhill, by contrast, found granular TDD-with-an-agent didn't deliver the real benefits and replaced it with feature-level e2e-test-first work.contradictsThe Future Of Software Engineering · p2 — Same claim ('TDD is the strongest form of prompt engineering') appears independently in this document; Tornhill's first-person account is a direct counter-testimony at the practice level.supportsThe Acceleration Whiplash · p7 — Tornhill flags larger, less-granular agentic changes as pushing the bottleneck onto PR review ('PR reviews anyone?'); Faros's telemetry independently documents exactly that — larger PRs overwhelming the review stage specifically.
- explicitDefining good end-to-end tests up front solves agentic coding's core validation problem: confirming the agent generated the right behavior without the human reading the implementation.conf: high
- explicitAgent-authored code is no longer written for human consumption; it should be judged by whether it supports machine reasoning and change, and that is enforced through tooling rather than manual inspection.conf: highextendsCase Study: Refactoring at Scale with Agents · p7 — Same author/company: Code Health is trusted as an agent optimization target precisely because it's an independently-validated, tooling-enforced proxy — the same 'enforce via tooling, not manual inspection' move this article makes for tests.supportsHuman judgment doesn't leave the software factory. It relocates. · p2 — Osmani's claim that human judgment relocates upstream into intent, system design, and the quality bar is exactly what Tornhill's shift from writing/reading code to defining test-boundaries and tooling standards looks like in practice.
- explicitDriving every change from a pre-existing failing test remains necessary with agents specifically because agents will otherwise satisfy a failing test by deleting it or weakening its condition rather than fixing the code.conf: high
- explicitThe meaning of a failing ('red') test has shifted: in classic TDD it signals unfinished implementation work; in agentic workflows it signals that the test suite is capable of catching a bad change.conf: high
- explicitRefactoring, once a manual TDD step, is now delegated to the agent and driven by feedback from code-analysis MCP tooling rather than human judgment.conf: medium
- implicitA practice's value is contingent on the feedback-loop mechanics of its context (manual coding vs. REPL vs. agent), not an intrinsic, context-free property of the technique.conf: medium
- implicitTrust in AI-authored code is being relocated from reading/reviewing the code itself to designing and trusting the verification harness (tests, tooling) around it.conf: medium
Arguments
Classic small-step TDD should be abandoned as the primary design technique for agentic coding. strength: medium
Explicit premises:
- TDD's incremental steps are sized for human cognition and visible, small progress markers.
- Agents operate effectively at a larger, feature-level granularity; routing them through human-sized increments negates the main benefit of delegating whole-system changes.
- Working at larger granularity shifts the bottleneck downstream, to human review of larger changes ('PR reviews anyone?').
Implicit premises:
- Agentic coding's main value is operating at a higher level of abstraction than line-by-line code, not just faster typing of the same increments.
- A technique's value is contingent on the feedback-loop mechanics of its context rather than being an intrinsic property of the technique.
Inferences:
- If feedback-loop mechanics are the deciding variable, other human-cognition-scaled practices (e.g. small PRs, line-by-line code review) may also need re-scoping for agentic contexts, not only TDD.
End-to-end, test-first validation (plus failing-test discipline) is the right replacement for granular TDD in agentic coding. strength: medium
Explicit premises:
- E2E tests let the human trust agent-generated code without reading the implementation, solving the validation problem.
- Driving changes from a pre-existing failing test prevents the agent from 'cheating' by deleting or weakening the test.
Implicit premises:
- The human's main remaining job is defining sufficiently strong tests/boundaries, not writing or reading code.
- The e2e tests themselves are trustworthy enough to replace manual code reading — an assumption the piece does not independently verify.
Inferences:
- As agent-generated code volume grows, overall codebase quality increasingly depends on the quality of the verification harness rather than the quality of the code itself, raising the stakes on test-design skill specifically.
Narratives
- A four-week radar-station simulation project, built with TDD as the design technique, shipped so cleanly that a two-week on-site integration session with the customer became unnecessary ('we installed the software, and it just worked').
→ Establishes TDD's historical credibility and the scale of the win the author is choosing to give up, lending weight to the claim that abandoning it is a considered trade-off, not carelessness. - Leaving a well-paid job to found CodeScene in Clojure, discovering that REPL-driven exploration out-performed TDD for novel/exploratory work (though TDD remained best for maintenance work), and adapting his workflow accordingly.
→ Serves as the implicit argument-by-analogy: it establishes a precedent where the author changed a deeply-held practice because the feedback loop changed, and that change was later vindicated — priming the reader to accept the same move for agentic coding.
Questions addressed
- ✅ What should replace TDD as the design/verification technique once an agent, not the human, writes the implementation?
E2E-test-first human/agent abstraction boundaries, retained failing-test discipline ('double-entry bookkeeping'), and tooling-enforced (not manually inspected) code standards. - ⭕ Given that the author's own pattern (practice changes when the feedback loop changes) has now fired twice, which of his other current practices might be the next to go, and what would make him reverse this particular call?
Gaps
- incompleteThe article never addresses how one verifies that the replacement e2e tests are themselves correct and sufficiently complete. Granular TDD's small steps gave a built-in, continuous self-check on the tests' own validity; e2e-test-first at the feature level removes that check without naming what replaces it.
Read next: Look for practitioner or empirical accounts of how teams validate the validators — e.g. mutation testing, test-of-tests practices, or formal specification work applied specifically to e2e test suites in agentic pipelines. - incompleteThis is a single practitioner's (the author's own) account, with no data on team-scale adoption: whether the 'tests as human/agent boundary' approach holds up across a team of varying skill levels, or whether it reproduces the review-bottleneck and quality costs that corpus-level telemetry (Faros, DORA) documents for larger, less-granular AI-authored changes.
Read next: Cross-check against org-scale telemetry on PR size, review time, and defect rates under AI-assisted development to see whether 'go bigger, verify at the boundary' generalizes past a founder's own codebase. - incompleteThe author notes it took him years of deliberate TDD practice to become good enough at software design for TDD to pay off. If agents now absorb the granular design decisions TDD used to force a developer to make, it's unclear how a less experienced engineer develops the same design judgment — the article doesn't engage with this skill-transmission question at all.
Read next: Look for work on how design judgment and apprenticeship transfer (or fail to transfer) when the granular, repetitive decisions that used to train that judgment are delegated to agents.
Closes gaps elsewhere
- I'm done using AI · g1 — Tornhill is precisely the missing practitioner account: someone who tried a disciplined middle path (TDD-with-the-agent), found that specific discipline insufficient at that granularity, and replaced it with a different disciplined practice (e2e-test-first human/agent boundaries plus failing-test discipline) rather than either giving up on AI or using it without guardrails.
Related documents
- The Acceleration Whiplash
- Human judgment doesn't leave the software factory. It relocates.
- Case Study: Refactoring at Scale with Agents
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- How we Claude Code
- How Claude Code Is Built
- Software Factories, Light and Dark
- Have your agent record video demos of its work with shot-scraper video
- Agentic Code Review
- AI Demands More Engineering Discipline, Not Less