---
title: 'In the News: August 12, 2026'
description: 'A Thoughtworks study finds TDD inside the agent loop costs 3 to 8.5x the tokens with no consistent quality gain.'
canonical_url: 'https://darkfactory.dev/news/2026-08-12-morning'
markdown_url: 'https://darkfactory.dev/news/2026-08-12-morning.md'
collection: news
date_published: '2026-08-12T06:20:00-04:00'
date_modified: '2026-08-12T06:20:00-04:00'
---

# In the News: August 12, 2026


A Thoughtworks engineer ran the first quantified test of a common piece of agent advice, and it doesn't hold up: TDD inside the agent loop cost several times the tokens without producing better code, by a blind judge model's own scoring. Two conference talks below make a related point from field experience: more comprehensive skills and more agents are not automatically better ones.

## 1. TDD inside the agent loop doesn't pay for itself, a small controlled study finds

**[TDD inside the agent loop, theater or actual value?](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html)** · Birgitta Böckeler, Distinguished Engineer, Thoughtworks · martinfowler.com, August 10, 2026

Böckeler had Sonnet 4.6 build the same small, medium and large greenfield tasks with and without TDD instructions, twice each across five batches, then had Opus 4.8 blind-judge the resulting code and tests without knowing which workflow produced which. Across the small and medium tasks, Opus ranked the two non-TDD solutions first and second in most batches; TDD-instructed runs used 3 to 8.5x the tokens (by task size, per her appendix tables) with no consistent gain in mutation score, coverage, or design quality. Her reading of the transcripts: TDD's step-by-step structure suppresses the upfront design work that non-TDD runs did implicitly, so the design ends up locked to whatever shape the first test happened to take. She writes: "I personally have stopped telling my coding agents to write tests first, let alone do TDD... until I see evals or other strong arguments that convince me otherwise." The session data behind the numbers is public in her GitHub repo, birgitta410/tdd-comparisons.

**Why it matters:** telling an agent to follow TDD is common advice in harness and spec design, and this is the first quantified counter-evidence against it from a named practitioner with public data. Anyone enforcing TDD in an agent loop for quality reasons should read this before assuming it's paying for its token cost.

## 2. A 10,000-line skill made a coding agent worse, and nobody noticed until it was measured

**[How I deleted 95% of my agent skills and got better results](https://www.youtube.com/watch?v=vy7o1g2iHY8)** · Nick Nisi, developer experience engineer, WorkOS · AI Engineer conference talk, May 30, 2026 (transcript, auto-generated captions)

Nisi generated a 10,000-line skills library from WorkOS's documentation, with each skill hashed to its source section so it would only regenerate on a real doc change. Evals of that library took 68 minutes to run per pass, per the transcript, and produced worse results than giving the agent no skill at all: loading the skill got a task right 77% of the time, against 97% without it. He rewrote it down to 553 lines covering only the common failure modes his evals actually surfaced; the eval suite dropped to 6 minutes a run and accuracy recovered. He credits catching the regression entirely to measuring it, rather than assuming more documentation helps: "eval are super important when you're working with this non-deterministic code."

**Why it matters:** it is a measured, not asserted, case against comprehensiveness in skill files. If a skill hasn't been run against evals before and after, there's no way to know it isn't actively hurting the agent it's meant to help.

---

## Also this cycle

- **[Why We Killed Our Multi-Agent Pipeline](https://www.youtube.com/watch?v=u6jJcIFDLE4)** · Subbiah Sethuraman and Abhilash Asokan, ZS Associates · AI Engineer conference talk, July 22, 2026. A pharma analytics pipeline that split signal detection, source localization, driver attribution and synthesis across separate agents produced individually correct but collectively incoherent output, because context was lost at each handoff. The ZS presenters rebuilt it around one reasoning agent and a domain knowledge graph used as a control plane, where every edge in the graph is a hypothesis the agent tests against real data. (Auto-generated captions do not reliably separate the two speakers, so claims here are attributed to both presenters jointly.)
- **[The Tower Keeps Rising](https://lucumr.pocoo.org/2026/7/13/the-tower-keeps-rising/)** · Armin Ronacher · lucumr.pocoo.org, July 13, 2026. Argues that coding agents remove the coordination friction, pull requests, code review, interface negotiation, that used to force a team's mental models of a shared system to stay synchronized, so "construction can continue after shared understanding has already collapsed."