Fast Feedback Loops with Claude Code
The faster Claude can see the results of its changes, the better the output. Here's how to set up tight loops.
Claude Code works best when it can make a change, run something, and see the output — all in one session. When the feedback loop is slow or broken, Claude is working blind and the output quality drops.
Tightening the feedback loop is one of the highest-leverage improvements you can make to your Claude Code workflow.
What a fast feedback loop looks like
The ideal session flow: Claude makes a change → runs a specific test → sees pass or fail → iterates. The whole cycle should take under 30 seconds for unit tests, under 2 minutes for integration tests.
When test runs take 10 minutes, Claude makes multiple changes between feedback cycles. When something fails, it's harder to trace which change caused it.
Run targeted tests, not the full suite
For most development work, you don't need the full test suite on every change. Claude can run the specific tests for the module it's working on. For Jest: jest --testPathPattern=auth. For Vitest: vitest run src/auth.
Tell Claude: "Run only the tests for this module after each change. Run the full suite at the end when everything looks good."
Use watch mode for rapid iteration
For longer refactoring sessions, watch mode runs tests automatically on file save. Claude makes a change, saves, sees results immediately without running a command. In Claude Code sessions I sometimes ask Claude to start watch mode and then work through changes systematically while watching the output.
TypeScript compile check is faster than running tests
For catching type errors early: tsc --noEmit typically runs in seconds and catches a class of errors before any tests run. For a session focused on TypeScript refactoring, ask Claude to run this after every meaningful change.
Make the success state obvious
The best feedback is binary: it worked or it didn't. "Tests pass" or "TypeScript compiles" or "the endpoint returns 200." Vague success states ("it seems to work") extend sessions and make it hard for Claude to know when to stop iterating.
Define success criteria at the start of each session: "We're done when all auth tests pass and TypeScript compiles without errors." Claude has a clear target and knows when it's hit.