The first answer was never meant to be the final one.
You ask Claude Code for a feature, it writes something that looks right, and you skim it, paste it, and find out later that it does not build or it builds and quietly does the wrong thing. So you copy the error back into the chat, wait, copy the next one back, and somewhere in there you stopped being the operator and became the compiler.
Shopify's Head of Engineering put the fix in one line: AI writes the code, AI reviews the code, and your job is to write the loops around it. A 2025 research paper measured exactly what that buys you. Instead of trusting the first answer, the authors wrapped the model in five feedback loops, each one driven by a real tool: a compiler, a test runner, a static analyzer, a mutation tester. Every complaint from a tool got handed back as a fix request, and the model kept going until the tools were satisfied. Correctness climbed from 76% to over 90%, and the single biggest jump came from the simplest loop, just making sure the code compiles before anything else runs.
Here is the part that matters for you. Claude Code is already the harness. It can run your compiler, your tests, and your linter through its own terminal, read the output, and fix the code without you pasting anything. You do not build a separate runner. You set the rules, and it runs the loops itself.
What "for Claude Code" changes
The research version was a Python program that called an API, which is overkill when the model already lives inside a terminal with your repo. The whole job becomes writing the loops as standing instructions. You tell Claude Code the checks it has to pass before it is allowed to hand work back, and it treats every failing check as its own next task. The five loops below are the exact rules to give it, in the order that makes each one safe.
Loop 1: Compilation
Make it build before anything else runs. This is the gatekeeper, because you cannot test or analyze code that will not compile. The rule you give Claude Code is that it runs the build itself, and if the build fails, it reads the errors, fixes them, and runs the build again, repeating until the build is clean or it hits its retry cap.
Paste this into your project so it holds every session:
After any code change, run the build (or type-check) yourself before showing me anything. If it fails, fix it and run it again. Do not hand me code that does not compile.
Why it re-runs constantly
Loop 1 fires again after every later change. If a test fix edits the code, the code has to prove it still builds before testing continues. A green build is the floor every other loop stands on.
Loop 2: Given tests
Pass the tests you already trust. If your repo has tests, this loop runs them and treats every failure, with its stack trace, as the next thing to fix. The rule that makes this work is that the tests are correct and the code is wrong. Claude Code is only allowed to change the code here, never the tests, so a test that keeps failing means it keeps pushing on the code until the code agrees with the spec you handed it.
Run the existing test suite after the build passes. Treat my tests as the source of truth. If a test fails, fix the code, not the test, and run the suite again until it is green.
Loop 3: Static analysis
Clean up what the linter flags. Working code can still be sloppy code, and this loop runs your linter and type checker over the source, then feeds the violations back: unused variables, dead code, empty error handlers, the long tail of small flaws that pile up into a mess. Claude Code fixes them and runs the analyzer again until the report is clean. This is the loop that turns "it passes" into "it is also worth keeping."
Once tests are green, run the linter and type checker. Fix every warning, then run them again until the output is clean. If a warning is a false positive, tell me why before you suppress it.
Loop 4: Test generation
Write the tests that were missing. Now Claude Code writes a fresh set of tests for the code it just built, aiming to cover the normal cases, the error cases, and the boundary values, then runs them. This is the one loop where it is allowed to edit either the code or the tests, because when a new test fails it has to decide on its own whether it found a real bug, in which case it fixes the code, or wrote a bad test, in which case it fixes the test. That judgment is what surfaces the defects your original tests never covered.
Generate tests for the code you just wrote. Cover the happy path, the failure paths, and the edge cases. Run them. For each failure, decide whether it is a real bug or a bad test, fix accordingly, and rerun until stable. Show me the new tests.
Loop 5: Mutation analysis
Prove the tests would actually catch a bug. A green suite can still be a weak one, and mutation testing is how you find out. It makes tiny deliberate changes to the code, flipping a comparison or dropping a line, and checks whether your tests notice. A change that slips through unnoticed points straight at a gap in the tests, so this loop keeps strengthening the generated tests until every planted bug gets caught. It needs a fully passing suite to start, and it only hardens the tests the system wrote, never your originals.
This loop is slow, so keep it opt-in for the code that actually carries risk.
When I say "harden this," introduce small deliberate bugs into the code one at a time and confirm a test fails for each. If a planted bug survives, add a test that catches it, then remove the planted bug. Only strengthen the generated tests, never mine.
The one rule that turns Claude Code into the harness
You do not have to run these five by hand every time. Put one standing instruction in your project's CLAUDE.md and Claude Code applies it to every task on its own:
Before you return any code to me, it must build, my existing tests must pass, and the linter must be clean. Write tests for what you built and make them pass too. Run every check yourself in the terminal. If a check fails, fix it and run it again. Do not show me work that has not passed all four. Ask before running the slow mutation pass.
That single paragraph is the difference between a chat window and a system. You stop reading half-finished code, and what lands in front of you has already passed.
The four guardrails to set first
A loop with no brakes will burn tokens all night, so set these before you trust it to run on its own.
- A retry cap per loop. Five attempts is a sane default, three for the slow ones. Tell Claude Code to stop and show you the log if a loop hits its cap instead of grinding forever.
- A sandbox. It is running code it wrote, so keep it inside the project directory, and never let it run generated code against production data or live keys.
- A cost checkpoint. Have it state the rough token cost before a full five-loop run on a large task, so a big job is a decision and not a surprise.
- A clean stop condition. Every loop ends on a yes or no from a real tool, not on the model's opinion that it is probably fine. If there is no tool that can say pass or fail, it is not a loop yet.
Start with one loop, not five
Here is the mistake most people make: they read this, try to wire all five on day one, and it collapses by the weekend. Start with Loop 1. Give Claude Code the single rule that it has to build the code before showing it to you, and run it that way for a week until you trust it.
A first loop you can trust has three properties. It has a clear finish line, meaning a tool says pass or fail. It is safe to fail, meaning a bad run costs you nothing but a rerun. And it is boring, meaning it is a check you already do by hand every day. Once one loop runs without you, the second one is easy, and then you stack the rest.
The whole thing in one paste
Drop this into your project and Claude Code will set the loops up with you, confirm your stack, and prove it on one small task before you rely on it.
Set up a 5-loop refinement workflow for this repo, and confirm with me at each fork.
- Detect my stack from the lockfiles and configs, and name the tool for each loop: build or type-check, test runner, linter, test generator, mutation tester. Wait for me to confirm.
- Turn the five loops into standing rules in this order: (1) build, (2) run my existing tests, (3) lint and type-check, (4) generate and pass new tests, (5) mutation hardening. Make loop 5 opt-in because it is slow, and skip any loop whose tool does not exist for my stack, and tell me which you skipped.
- Set the rules: loop 2 edits code only and my tests are correct; loop 4 may edit code or tests and you decide bug versus bad test; loop 5 only strengthens generated tests and needs a green suite first.
- Set guardrails: a retry cap per loop (5, or 3 for slow ones), run everything inside this directory only, and state the token cost before a full run.
- Run all of it on one tiny task end to end, show me the log, and tell me which loops passed and which hit their cap.
Confirm the stack and the loop list with me before you scaffold anything.
Go deeper
Two companion guides take this further. Loop Engineering for LLM Code is the full five-loop harness rebuilt to run on any language, with the exact tools for Python, TypeScript, Go, and Rust. The Claude Loop System is the same idea for operators who are not writing code, showing how to put recurring business work on Claude and keep it safe. If you would rather have this built into how your team ships, book a 30 minute audit.
The point
You are paying for a model that can check its own work, and most people never let it. The leverage was never a smarter single prompt, it is a loop that proves the code before it ever reaches you. Write the loops, set the guardrails, and keep your attention for the small slice of the work that actually carries risk.