What to Do When Claude Code Writes Wrong Code on a Client Build

The Short Answer

When Claude Code produces code that is wrong, do three things in order before you try to fix it. First, get back to the last state that worked, revert the bad change rather than editing on top of it, so you have a clean baseline again. Second, reproduce the failure exactly and write it down: the precise error, the input or step that triggers it, and what you expected to happen instead. Third, hand Claude that specific failure and ask it to fix that, not a vague 'this is broken.'

The reason this order matters is that a wrong answer from the model is cheap and recoverable, but a wrong answer you built three more changes on top of is expensive. The discipline is not about making Claude never miss. It is about making sure a miss stays a five-minute detour instead of turning into something a client finds after launch.

Revert Before You Fix

The instinct when code is wrong is to immediately describe the problem and ask for a fix on top of what is already there. Resist it. If the current state is broken, the first move is to get back to the last state that was known to work, so you are debugging from a clean baseline instead of from a pile of half-corrections. On a client build this is the difference between a two-minute revert and an afternoon spent untangling which of four stacked changes actually caused the failure.

This is exactly what checkpoints are for. If you are working the way described in [Claude Code checkpoints for client work](/blog/claude-code-checkpoints-for-client-work), rolling back a bad change is a single deliberate step, not an archaeology project. Commit or checkpoint at each point where the build is verifiably working, so that when a change goes wrong you have a real 'known good' to return to rather than a vague memory of what the file looked like an hour ago.

Reproduce the Exact Failure

Claude fixes specific failures well and vague complaints badly. 'This is broken' or 'that is not what I wanted' gives it nothing to work with, so it guesses, and its guess is as likely to introduce a second problem as to fix the first. Before you ask for a fix, reproduce the failure yourself and capture exactly what it is.

1. Capture the actual error text if there is one, the full message and stack trace, not a paraphrase. The exact string is often the single most useful thing you can hand the model.
2. Note the precise input or steps that trigger it. A bug that only appears with a specific value, an empty field, a particular file, is a different bug from one that happens every time, and Claude needs to know which.
3. Write down what you expected versus what actually happened, in one sentence each. That gap is the definition of the bug, and stating it plainly stops both you and the model from fixing the wrong thing.

If you cannot reproduce the failure reliably, you are not ready to ask for a fix yet. A bug you cannot trigger on demand is one you cannot verify is gone, which means you cannot honestly tell a client it is fixed.

Hand Claude the Error, Not a Complaint

Once you have the exact failure, give it to Claude directly. Paste the real error, describe the input that triggers it, and state what the correct behavior should be. This turns an open-ended 'make it work' into a bounded task the model can actually close out, and it usually gets a correct fix in one pass instead of three rounds of guessing.

It also helps to ask why the wrong code happened, not just for the fix. Often the mistake traces back to a missing piece of context, a constraint about the client's stack or data you never told it, and once you supply that, the same class of mistake stops recurring for the rest of the build. This is the same lesson as writing clear expectations up front, covered in [set client expectations before a Claude Code build](/blog/set-client-expectations-before-a-claude-code-build): the model does better work when the constraints are explicit, and so does it mid-build when you name exactly what went wrong.

Why This Matters More on Client Work

On your own project, wrong code is a private problem you fix and forget. On a paid build it is a trust problem waiting to happen. A client does not see the model's mistake; they see whether the thing you delivered works. If a wrong answer slips through unverified and they find it after launch, the failure reads as yours, not the tool's, and it is far more expensive to recover from than it would have been to catch in the session.

That is why the verification step is not optional on client work. The realistic standard is not that Claude never writes wrong code, it will sometimes, but that nothing wrong reaches the client because you read and tested the result before calling it done. Handling the mistake cleanly in the session is cheap. Handling it after the client hits it is the situation described in [client finds a bug after launch](/blog/client-finds-a-bug-after-launch), and it costs a lot more than five minutes.

A Recovery Loop for Client Sessions

1. Checkpoint or commit at every point the build is verifiably working, so 'the last known-good state' is a real place you can return to, not a guess.
2. The moment code is wrong, revert to that known-good state before attempting any fix. Do not stack corrections on a broken baseline.
3. Reproduce the failure and capture it: the exact error, the triggering input, and the expected-versus-actual gap in one sentence each.
4. Hand Claude the specific failure and, where you can, the missing context that caused it, so the fix is bounded and the class of mistake stops recurring.
5. Verify the fix against your reproduction steps before moving on, and only then tell the client that part is done.

Common Mistakes

1. Stacking fix after fix on top of a broken, uncommitted change until there is no clean version left to revert to.
2. Asking Claude to fix 'this' with a vague complaint instead of the exact error and the input that triggers it.
3. Declaring a fix done because the code looks more correct, without re-running the exact steps that produced the failure.
4. Telling a client something is fixed before you have actually watched the failing case pass.
5. Treating a wrong answer as a reason to distrust the tool entirely, rather than as a normal step that a revert-reproduce-fix loop handles in minutes.

Inside the Claude Code Profit Room, builders trade the actual client sessions where a wrong answer got caught in time and the ones where it did not, and what the recovery loop looked like each way. It's $9 a month at https://www.skool.com/claudecodeprofitroom/about, come compare notes on how you catch a bad change before it ships.