fast feedback is a different game
When a test suite runs in two seconds, you try things. When it takes twenty minutes, you think first. That difference sounds like pace. It isn't.
The speed of feedback changes the shape of the work itself.
what a fast loop lets you do
Two-second feedback is short enough to stay inside a single thought. You have a hypothesis, run the test, see the result, adjust. Three minutes later you understand something you didn't before. The loop did the reasoning.
You can afford to start vague. "I think the bug is somewhere in the parsing layer" is good enough if you can test in two seconds. You'll know in thirty seconds whether you're right. If not, narrow the hypothesis and go again. Empiricism at the speed of a conversation.
The cost of being wrong is practically zero. This changes what you're willing to try.
what a slow loop changes
Twenty minutes changes the calculation entirely.
You're not trying five approaches. You'll think carefully about which one is most likely to work, then commit. The stakes of each attempt are higher. You shift from experimental to analytical: "I believe X because of Y and Z" becomes the shape of the thought, and you execute once and wait.
Conservative engineering is sometimes right. For database migrations, for changes with real-world side effects, for anything genuinely irreversible — careful analysis before action makes sense. The slow loop is earning its cost.
The problem is when slow loops exist for the wrong reason. Not because the work requires it, but because nobody invested in making the test suite fast. The caution you're generating isn't responding to the problem; it's an artifact of tooling debt.
the deeper change
Fast and slow loops don't just produce different efficiencies. They produce different questions.
In a fast loop, you ask: what happens if I do X? You find out empirically. Errors surface early when they're cheap. You discover things you wouldn't have thought to look for.
In a slow loop, you ask: is my analysis correct? You're verifying a conclusion you've already reached. You only discover what you thought to check for.
Both modes produce correct code. The fast loop's empirical character catches more classes of mistake — not because it's smarter, but because it surfaces the unexpected. The slow loop's analytical character is better at confirming a specific hypothesis. Both are useful; the question is which you reach for when.
the test-suite implication
The most underrated thing about TDD isn't test coverage. It's the forcing function to keep the feedback loop fast.
A suite with 600 fast tests gives you something qualitatively different from 600 slow ones. The fast suite you run while writing. The slow one you run before pushing. "Run before pushing" means you're not steering with it; you're checking in with it.
Tests that run in 50ms, against a narrow unit of behavior, can run on every save. That's steering. The test is giving you real-time signal on the thing you're building while you're building it.
If your tests hit a real database and take three seconds each, you have a slow loop wearing a fast loop's name. The solution isn't to avoid the database; it's to find the seam where you can write a cheap test that still catches what matters. The expensive integration test runs in CI. The cheap unit test runs constantly on your machine.
One tests the system. The other steers the work.
knowing which game you're in
The failure mode isn't moving slowly in a slow loop. It's moving slowly in a fast loop — having a two-second suite and still treating every change as high-stakes.
If the feedback is fast, move fast. Exploration is cheap. Try the dumber approach first; if it works, ship it; if not, you'll know in two seconds and you've lost nothing.
If the feedback is slow, be deliberate. The slow loop isn't bad; it's appropriate to a narrower class of work. Treat it accordingly. Don't treat it as a fast loop that happens to be broken.
The speed you have is the game you're playing. Know which one that is.