Dan Luu keeps running big, careful experiments on how coding agents actually behave. This one asks a pointed question: if you tell an agent to test its own code properly — test-driven development, fuzzing, formal proof tools — does the code come out more correct?

The short answer: almost never.

He had an AI agent implement zstd (a compression format) from its spec in Rust: 80 runs per condition, 26 different testing instructions plus 4 “skills” (packaged instruction files), scored against a hidden test suite. A smaller run on an email protocol spec replicated the findings.

What he found:

  • Giving no testing instruction at all scored above average. Telling agents to use a technique mostly made things worse or no better.
  • Agents “use” techniques superficially — they write the same weak unit tests inside the named framework, prove irrelevant properties with proof tools, and fuzz with random bytes that only hit error paths.
  • Test-driven development produced more tests and worse results; agents wrote tests that quietly encoded the same bugs (e.g. palindromic test data that hid a byte-order reversal).
  • Property-based testing — randomized inputs that get “shrunk” to minimal failing cases — was the one partial bright spot, especially with the proptest library.
  • Big tutorial-style skills raised cost and lowered correctness; the one skill that just nudged agents away from bad defaults did best.
  • Agents can name which parts of a problem are risky — they just don’t test those parts well.

His explanation: models apparently contain decent testing knowledge, but it isn’t their default. Naming a technique doesn’t activate it. What works is interaction — look at what the agent did, then type a few more sentences of steering, with test scaffolding set up in advance.

He also asks why AI labs train agents with reinforcement learning for speed optimization but not for effective testing — and notes that the existing attempts train agents to write small unit tests, which he argues is exactly the wrong pattern for correctness.

The uncomfortable implication: the gap in agentic coding isn’t raw model capability. It’s that good engineering practice has to be actively steered in, run by run — which is precisely the kind of judgment that doesn’t yet survive in a one-shot prompt or a packaged skill.