AI can generate implementation quickly enough that the old excuses against tests sound thinner every week. “It will take too long” is a strange objection when the implementation can now appear in seconds. The hard part is not typing the code. It is defining what “correct enough to ship” means.
That is where tests still earn their keep. Not because they are holy. Because they are one of the cleanest ways to define the rails before the speed arrives.
Why This Pairing Works
- you define the intended behavior first
- the model has something concrete to aim at
- iteration becomes faster because failure is visible
- review becomes easier because the contract already exists
- you reduce the amount of “looks right to me” merging
That does not mean every project needs orthodox TDD in the pure doctrinal sense. It means you should push specification earlier and force the behavior to become visible before you celebrate how much code got generated.
Where Teams Get It Wrong
They use AI like an over-caffeinated junior developer with no guardrails and then try to clean up afterward. Sometimes that works on small things. Sometimes it leaves you with a pile of impressive-looking output that nobody can explain, and then the tests you should have written early become archaeology.
The better flow is simpler: state the contract, generate the implementation, run the checks, tighten the edges, then move on.
Why I Still Like This Even Outside Pure TDD
Because the underlying discipline is the same. Make the target explicit. Give the model a bounded lane. Do not confuse a stream of code with progress. That is true whether the first artifact is a unit test, an integration test, a schema validation, or a structured acceptance case. The point is to create rails before speed does damage.