"Test first bug fixing" is probably the highest ROI activity in the entire testing lifecycle. There is no better way to understand a bug than being forced to reproduce it in a minimal, isolated environment.

The challenge I see most often in industry is that reproduction in a test environment is often 90% of the work. If your system requires a massive integration test just to reproduce a simple logic bug, it’s a sign that your testing pyramid has inverted into a "testing ice cream cone."

What can help there is automatic test case minimization. This requires being able to replay test inputs while minimizing them, so there must be no nondeterminism in the system under test.

That’s the core of the problem, isn't it? Test case minimization (like what we see with property-based testing tools or things like C-Reduce) is magic when it works, but it’s essentially an 'architecture tax.' To get that lack of nondeterminism, you usually need a very clean separation of effects. If your logic is tightly coupled to global state, network latency, or unpredictable database sequences, the 'minimizer' just spins its wheels. I’ve found that the real ROI of TDD isn’t just the test itself, but the fact that it forces you to build a deterministic interface so the test can even exist. You can't minimize what you can't control.

Some issues with nondeterminism could be handled by converting the system to a deterministic version, but with extra inputs representing the nondeterminism of the original system. I can well imagine this being difficult in practice.