Nobody learns to play guitar at a concert.

You practice scales in your bedroom. You play the same riff fifty times until your fingers move without thinking. Then you go on stage and the muscle memory takes over.

TDD works the same way.

The Gap Between Knowing and Doing

Most developers who “know TDD” don’t practice TDD.

They’ve read the books. They understand Red-Green-Refactor. They can explain the three laws. They’ve probably even written tests first a few times.

But when the pressure hits — deadline looming, requirements unclear, PM asking for status — they drop back to writing code first and testing later. Or not testing at all.

This isn’t a knowledge problem. It’s a practice problem.

The developers who actually do TDD under pressure are the ones who’ve done it so many times in low-pressure settings that it’s automatic. They don’t decide to write the test first. They just do. The same way a musician doesn’t decide to put their fingers on the right frets. They just do.

That’s what katas build.

Reps, Not Theory

A kata is a controlled environment with a known problem. You’re not trying to figure out what to build. You’re not negotiating requirements. You’re not fighting infrastructure.

You’re just practicing the cycle.

Red. Green. Refactor. Red. Green. Refactor.

Over and over until the rhythm is natural.

The first time you do FizzBuzz with TDD, you’ll think about every step. Where do I start? What’s my first test? How simple should the implementation be? Should I refactor now?

The tenth time, you won’t think. You’ll just move.

That’s the point.

Why Repetition Matters More Than Variety

Beginners want new katas every time. They think the value is in the problem.

It’s not.

The value is in the repetition of the process. Doing the String Calculator kata for the fifth time teaches you more about TDD than doing five different katas once each.

Because the fifth time, the problem is boring. You already know the solution. So your brain stops focusing on the problem and starts focusing on the process.

That’s when you notice things:

• “I wrote too much production code before running the test.”
• “My test name doesn’t describe the behavior.”
• “I skipped the refactor step because the code felt good enough.”
• “I could have taken a smaller step here.”

These observations only surface when the problem is easy enough that you have mental bandwidth to watch yourself work.

The AI Connection

This matters more now than ever.

In an AI-assisted workflow, the human’s job increasingly isn’t writing code. It’s defining specifications, verifying behavior, and steering the system.

That’s what TDD is.

If you can’t write a clear, precise test that describes what the system should do — quickly, without overthinking — then AI tooling doesn’t help you much. You’ll spend all your time trying to articulate what you want instead of just expressing it.

Katas train exactly that skill. Not “how to write code” but “how to express intent as executable specifications.”

Every kata rep is practice at being the architect who can hand an agent a failing test and say “make this pass.”

How to Practice

Pick a kata. Any kata. Do it with TDD.

Then do it again tomorrow. Same kata.

Then do it again. Pay attention to where you hesitate. Where you skip steps. Where your test names get lazy.

After a week, pick a new kata. Repeat.

This isn’t exciting advice. It’s not a framework or a methodology or a paradigm shift.

It’s reps.

And reps are the only thing that turns knowledge into skill.