Test with confidence, code with clarity

Your home for mastering Test-Driven Development through real-world katas and expert guidance.

Browse Katas Learn TDD Fundamentals
TDD Buddy Logo
Latest The Agent's TODO Is a Signed Confession, Not a Marker

Kata Catalog

Practice TDD with a curated set of real-world katas, each with clear requirements and test cases.

Browse Katas

Guides & References

Learn best practices, naming conventions, and advanced TDD techniques from industry experts.

Explore Guides

Interactive Learning

Discover the TDD Gears model and learn how to apply TDD principles in real-world scenarios.

Learn More

Why TDD Matters More in the AI Era

The bar for "good tests" just moved. Agents made it non-optional.

  • A TODO used to be a note-to-self. The author and the returner were the same person on the same team, working within a horizon the sprint enforced. That model was invisible because it was the only model on offer.
  • Two 2026 studies land the same finding. The TechDebt 2026 analysis of 6,540 LLM-referencing comments and the MSR 2026 study of 525 AIDev-sourced SATD comments both show AI-authored technical debt is more detailed than the human kind, in the same categories, at scale.
  • Generation speed broke the return assumption. At human authorship rates, most TODOs got returned to. At agent authorship rates, they accumulate as a debt book the team never opened. The window between authoring and forgetting collapsed to a merge.
  • An agent-authored TODO is an unresolved acceptance criterion. Not a note. A criterion. The PR that filed it is the PR that owes the resolution or the tracked follow-up.

Read the argument: The Agent's TODO Is a Signed Confession, Not a Marker

The Bar Moved

Old bar

Tests exist and pass. Good enough for humans with context.

New bar

Scenario names · builders · domain types · ubiquitous language. The test suite is the interface agents operate against.

Rich TDD isn't a style preference anymore. It's infrastructure for compressed-role, AI-augmented teams.

TDD Gears

Shift gears based on context, not habit

TDD Gears model showing Low, Medium, High, and Reverse gears for test-driven development

Low Gear

New territory. Build context. Small steps. Learn the shape of the problem before solving it.

Medium Gear

Patterns emerge. Apply design principles. Let the tests guide you toward better abstractions.

High Gear

Known patterns. Follow existing architecture. Move fast because the structure is already proven.

Reverse Gear

Wrong direction. Back up. Delete the test. Try a different approach. This isn't failure — it's steering.

Learn More About TDD Gears