Should You Fix or Regenerate AI Generated Code?

Here is the rule, before the reasoning: fix or regenerate AI generated code on the third correction, not the fifth. If you have sent an agent back to the same file three times and the same class of problem keeps reappearing, the file is not one more nudge away from correct. The context that produced it is wrong, and every further correction is layered on top of a flawed starting point rather than replacing it.

Most developers hold on far longer than three rounds, for a reason that has nothing to do with code quality. It is the sunk cost of the conversation. You have explained the requirements four times and starting over feels like throwing that away, when in fact the explanations are the asset and the file is the disposable part.

When to fix or regenerate AI generated code

The middle row is the one that catches people. If you can point at line 47 and say it should be a left join, fix it, and do it yourself rather than asking. If the complaint is that the module is organised strangely and every fix makes it stranger, no amount of patching converges, because the model keeps re-deriving the same structure from the same instructions.

The measurable signal: diff churn

There is a way to stop guessing about this. Watch how much of the file changes each round. Git's diff statistics give you the number directly:

# how much did this file move on each of the last five commits?
git log --oneline -5 --stat -- src/billing/invoice-builder.ts

# or just the totals, one line per commit
git log --oneline -5 --numstat --format='%h %s' -- src/billing/invoice-builder.ts

Healthy iteration converges. Round one changes 200 lines, round two changes 40, round three changes 8. The agent is narrowing in on something.

Unhealthy iteration does not converge. Round one changes 200 lines, round two changes 180, round three changes 190. The agent is not refining the file, it is rewriting it from scratch each time and landing somewhere different. At that point you are already regenerating, just slowly, expensively, and without the benefit of a clean brief.

If the diff is not shrinking, you are not iterating. You are regenerating one round at a time while pretending otherwise.

Regenerating properly

Deleting the file and repeating the original prompt produces the original file. That is the mistake that makes people conclude regeneration does not work. The point of starting over is to start over with what you have learned, which is substantial by round three.

1. Write down every correction you made, as requirements rather than as corrections. "Do not fetch inside the loop" becomes "batch all lookups before the loop begins."

2. Delete the file. Actually delete it, do not leave it as a reference for the agent to pattern-match against, because it will.

3. Name the structure yourself. Say what the functions are, what each returns, and what must not be in the file. Structure is the thing that kept drifting, so stop leaving it to the model.

4. Give it the tests first if you have them, or write two by hand if you do not. A regeneration with a test to satisfy lands far closer than one without.

5. Regenerate in a scratch branch and diff the result against the old file before you commit. Some of the old file was right, and you want to notice what you lost.

Step one is doing the real work. Those accumulated corrections are the specification you never wrote at the start, and handing them over as a brief is usually a two-minute job that produces a better result than an hour of further patching. It is the same underlying reason that splitting a large task into smaller briefs outperforms one long conversation.

When the answer is neither

Two situations look like this choice and are not.

The first is a file that is nearly right and that you understand. Write the fix yourself. A ten-minute manual edit beats a three-minute round trip that you then have to review, and the review is the expensive part. The habit of returning everything to the agent, including things you could type faster than you can describe, is its own inefficiency.

The second is a file that has been correct and stopped being correct. That is a regression, not a quality problem, and the right move is to find the change that broke it rather than to regenerate anything. Rolling back a bad agent change is a different procedure with a different goal, and reaching for regeneration here destroys the evidence you need.

Why three rounds and not five

The threshold is not arbitrary. Each correction round adds instructions to a context that already contains the flawed file, and the model weights what it can see. By round four the file itself is exerting more influence on the next version than your latest instruction is, which is why late-round corrections so often fix the named problem and break something adjacent.

This also explains the other familiar symptom of a file that has gone too many rounds: it accretes. Defensive checks, wrapper functions and options nobody asked for pile up because each round adds and nothing removes. That is closely related to agents over-engineering by default, and correction rounds accelerate it.

Frequently asked questions

Does regenerating waste the tokens I already spent?

It spends more tokens and usually saves time, which is the trade that matters. Three further correction rounds plus the reviews they require cost more of your attention than one clean regeneration from a proper brief, and attention is the scarce resource.

What if the code works but I do not like it?

Then it is not a correctness problem and the three-round rule does not apply. Decide whether the style issue is worth anything. If the file is small, tested, and nobody will read it again, working and ugly is an acceptable outcome.

How do I keep the next attempt from going the same way?

Capture the corrections as project-level instructions rather than per-file ones, so the same drift does not recur across the codebase. If the agent keeps ignoring them, that is a separate and well-documented failure worth treating on its own, covered in why an agent keeps ignoring your instructions.

Should I regenerate the tests too?

Not at the same time. Regenerate the implementation against tests you trust. If the tests were themselves written by the agent and then adjusted until they passed, they are not a fixed point and you have a deeper problem, which is worth reading up on before trusting any of it, starting with debugging AI generated code.