The Two-Corrections Rule: When to Stop Fixing Your Agent and Fix the System

You've told Claude Code the same thing three times. Same mistake, same correction, same result. The session is 20 minutes old and you're already frustrated.

This happens to everyone who works with AI coding agents. You ask for a component, Claude uses inline styles instead of Tailwind. You correct it. Two files later, inline styles again. You correct more firmly. Claude switches to styled-components. Three corrections in, you're no closer to the result and the session context is full of noise.

Most developers blame the model at this point. "It doesn't listen." But after months of running agentic workflows in production, I've found the issue is almost never the model's comprehension. It's the instruction set the model reads before your task even starts.

The two-corrections rule changed how I handle these moments: if you correct Claude twice on the same issue and it persists, stop correcting. The problem is upstream.

What overcorrecting actually costs you

Each correction goes into the context window. After three rounds on the same issue, Claude is reading your task description alongside its own failed attempts, your escalating frustration, and multiple conflicting instructions. That's a lot of noise competing with the actual work.

The model isn't ignoring you. It's following patterns it sees in the codebase, in the conversation history, or in missing documentation. Your corrections compete with those signals. Sometimes they win. Often they don't. And every failed correction makes the next attempt slightly worse, because Claude now has more conflicting information to weigh.

I've watched this spiral play out dozens of times. Five minutes becomes ten. Ten becomes twenty. The developer keeps typing increasingly specific instructions. The agent keeps drifting. Eventually someone closes the terminal in frustration and calls it a bad tool day. It wasn't. It was a system problem wearing a session-level disguise.

The two-corrections rule in practice

The rule is straightforward. If you've corrected Claude twice on the same issue and it keeps happening:

1. Stop the session.
2. Identify where the correct behavior should be documented.
3. Fix it there.
4. Start a fresh session.

No third correction. Two strikes and you go upstream.

The upstream fix depends on the type of mistake. A convention Claude keeps breaking goes into CLAUDE.md: "Never import @jd/db/server in client components. Use @jd/db/browser instead." A task constraint Claude keeps missing means the spec needs tightening. Not more detail, more boundaries. And if the codebase itself has conflicting patterns, half your files following one convention and half following another, Claude will mirror that inconsistency. Fix the codebase.

Why the second correction is the signal

One correction is normal. Claude doesn't know every convention in your project. It reads what's available, makes a judgment call, and sometimes gets it wrong. You correct, it adjusts. That's the system working as designed.

The second correction carries real information. It means Claude had your first correction in context and still made the same mistake. The pattern driving the behavior is stronger than your verbal instruction. Your correction is swimming upstream against the codebase or the conversation history.

The third correction is waste. You're adding noise to the context, reducing future output quality, and spending time on a problem that won't be solved in this session. I've observed this consistently over months of daily Claude Code use. When I ignore the rule and keep correcting, I burn 10 to 20 minutes before getting a result that barely holds together. When I follow the rule, the upstream fix takes 30 seconds, the fresh session costs a minute of setup, and the problem never returns.

This is not context degradation

The two-corrections rule addresses a specific failure mode: the same mistake repeating despite corrections. That's different from context degradation, where Claude starts making small, varied mistakes as the context window fills up. Wrong variable names. Forgotten patterns from earlier in the session. General sloppiness that wasn't there 30 minutes ago.

Context degradation has its own fixes. /compact compresses conversation history while preserving key decisions. "Summarize from here" targets just the bloated section. Sometimes you commit the good work and run /clear for a fresh start.

The two-corrections rule handles something else entirely. The model is reading a signal, a codebase pattern, a missing rule, an ambiguous spec, that contradicts your correction. No amount of in-session fixing overrides that signal permanently. Only an upstream change does.

The cost of starting over

The resistance to resetting a session is psychological, not practical. A new Claude Code session loads your CLAUDE.md and reads relevant files in under a minute. If you committed before the task started, nothing is lost.

Compare that to the alternative: another 15 minutes fighting a context polluted with failed corrections, each one making the next attempt less reliable. Claude's earlier wrong approach is sitting right there in context, competing with your latest instruction. The correction history doesn't just fail to help. It actively hurts.

Starting over with a corrected upstream instruction takes two minutes total. Debugging a confused session takes fifteen and usually fails anyway. The math is clear.

I go deeper on the two-corrections rule and the full recovery workflow in Chapter 3: The Human in the Loop of the agentic coding course. The chapter covers when to intervene, when to abandon a session, and how to build the reflexes that make course-correcting fast.

Upstream fixes that compound

The real payoff of the two-corrections rule shows up after a few weeks.

Every time you hit the two-correction boundary, you add a rule to CLAUDE.md, tighten a spec pattern, or fix a codebase inconsistency. Each fix is small. But they compound. After a month, your CLAUDE.md covers most conventions that used to cause friction. Your specs have clearer boundaries. Your codebase has fewer conflicting patterns.

The number of corrections per session drops. Not because the model got smarter, but because your system did. This is the core idea behind course-correcting in agentic coding: the goal isn't to get better at correcting. It's to build a system that needs fewer corrections over time.

The developers getting the most from agentic coding aren't writing the cleverest prompts. They're the ones who treat every repeated mistake as a signal, trace it upstream, and fix it at the source.

The two-corrections rule is one piece of a larger recovery system I teach in the agentic coding course, from CLAUDE.md architecture to feedback loops to the de-sloppify pattern. If you want to build a system that improves every session, start the course.