My Agent Skill for Test-Driven Development

Post by jasonswett » Sat, Jun 06, 2026, 12:49 AM UTC

dluxem wrote: post #13

I believe using a skill here is the wrong approach. LLMs already know what TDD is and how to do it, just like object oriented programming. If this is encoded in a skill, that skill essentially has to be loaded for everything thing your LLM is doing. This is probably one of the few areas where direct instructions via AGENTS.md is best, and I don't believe it requires much direction here to force the issue. But I think…

Post by jasonswett » Sat, Jun 06, 2026, 12:53 AM UTC

joshgachnang wrote: post #22

This overall is pretty close to how I've set up my implementation skill. One thing I'm curious about is how well the analogies like "We don't make dinner in a dirty kitchen." work vs something a lot more straightforward. Any input OP?

Post by zuzululu » Sat, Jun 06, 2026, 1:05 AM UTC

rsalus wrote: post #42

zuzululu wrote: post #23

TDD sounds great on paper for agentic development but you quickly realize it balloons the token cost. Often I write some feature and then its repurposed or removed, code is refactored moved around as time goes. With TDD I would be taxed heavily and velocity slow to a crawl. The waterfall approach is better after trying out TDD especially when you have a multi-agent setup. Also I found that in some cases the tests wer…

I was a big proponent of encoding TDD red-green-refactor methodology into my agent workflows until recently when I made the same realization after reading this study: https://arxiv.org/pdf/2602.07900 TLDR; it found test-writing volume only weakly correlates with success and that encoding test-writing principles did not move resolution rates but _did_ materially change cost. Encouraging tests cost +19.8% output tokens…

    Overall, these findings suggest that agent-written
    tests often behave more like a habitual software-development rou-
    tine than a dependable source of validation in this setting. More
    agent-written tests do not mean more solves; what they more reli-
    ably change is the process footprint—API calls, token usage, and
    interaction patterns. Improving the value of testing for code agents
    may therefore require better oracles and more actionable validation
    signals, rather than simply inducing agents to write more tests.

Post by homieg33 » Sat, Jun 06, 2026, 1:38 AM UTC

jasonswett wrote: post #54

SubiculumCode wrote: post #49

One issue that I've run into with codex has been excessive use of fallbacks routines. Perhaps this is good practice in.professional programming in many situations, but for mine (in this case): computing geodesic distances and analysis, a silent bad fallback means the processed data is not what I thought it was..e.g. used an inaccurate geodesic method in place of the accurate one.

I HATE this. I call it speculative coding. Claude often calls it "defensive" programming. It's easily my #1 LLM pet peeve. I have yet to figure out a reliable way to make this stop happening.

Post by bfeynman » Sat, Jun 06, 2026, 2:06 AM UTC

rsalus wrote: post #46

manmal wrote: post #35

Earlier quoted context omitted.

> With TDD I would be taxed heavily and velocity slow to a crawl. And the code will be good.

not necessarily, TDD has little bearing on output quality