The agent over-applies everything: why “don’t” is my most-used word

Models: Opus 4.6, Sonnet 4.6, Composer 1.5, Composer 2 In 60% of my agent sessions, I had to...

Models: Opus 4.6, Sonnet 4.6, Composer 1.5, Composer 2

In 60% of my agent sessions, I had to correct the output. The single most common word in those corrections was "DON'T".

It was not "fix" or "try again" I typed "don't" 1,703 times.

Every one of those signals is a constraint that existed in my head but wasn't encoded anywhere the agent could find it. That's the actual problem — not agent quality, but the gap between implicit knowledge and what gets written down.

The data

I exported every agent transcript from a React Native-to-Web migration — 767 sessions across two repos. Wrote scripts to classify correction signals in user messages.

Corrections:        Web 60% vs RN 35%  
Don't/should not:   Web 1,703 vs RN 128
Keep/preserve:      Web 308 vs RN 35
Over-applied:       Web 182 vs RN 19
Same as before:     Web 179 vs RN 13

Web's correction rate is nearly double. The reason is mechanical: more files, more interconnected components, more established conventions. More surface area means more implicit constraints. More implicit constraints means more correction loops.

I'm looking at it as a scaling law instead of a quality issue.

Three failure modes

The agent doesn't fail randomly. Almost every correction falls into one of three patterns.

The eager editor. I ask to update a component's layout and the agent also "improves" imports, reformats styled-components, tweaks prop types. I requested one thing and agent touched twelve files. Once, a styling adjustment on one screen turned into 52 updated SVG icons. That's the diff I had to review.

This is the bulk of the 1,703 "don't" signals. The agent treats every session as an opportunity to leave things better than it found them. In a production codebase, that means noisy diffs and broken trust in code review.

The pattern breaker. 30 components follow the same structure, and when I ask for a new one, the agent invents its own. I had explicitly written 'make the fields look the same as in SignUpForm' The agent read the adjacent files; I can see it in the transcript. It read them, understood them, and then decided to be creative instead of consistent.

The maximalist. I say "add a loading state". I get a loading state, an error state, a retry mechanism, and a skeleton screen. "Any point to handle errors individually? It's too much". The agent interprets "add X" as "add X and everything X might eventually need".

The cost model

These sessions averaged 4.1 user turns. Most corrections land on turn 2 or 3 — the first response overshoots, I constrain, the agent narrows. One extra round-trip per session, roughly 15% overhead on median session length.

Multiply that by 392 sessions. That's 392 moments where I'm teaching the agent something my codebase already knows — how we name things, which files are off-limits, what "done" looks like here.

The agent's first pass still gets you 70-80% there. The correction turn is tuning, not rebuilding. Correction loops at scale are a tax on implicit knowledge. The question isn't whether the agent is good enough. It's how much of your codebase's constraints live only in your head.

What moved the needle

Explicit constraints in the prompt and specific file references as templates both help — but they're incremental, the real shift was structural.

I wrote a 321-line plan document for one complex migration. Explicit phases, file-by-file scope, clear "do not" boundaries. The agent ran 74 messages. Zero corrections.

The sessions where I spent the most time before the agent ran were the ones where I spent the least time during. That's the counterintuitive trade: planning isn't overhead, it's constraint encoding. And constraint encoding is the entire game.

The prompt that got zero corrections

These prompts produced zero corrections. It's not because they were long, but the agent had nothing to interpret.

"Update the dependency of react to the latest 18. available and check that code is compatible with react 18"* — 39 messages, 4 turns, zero corrections

"ForgotPassword back button should not cancel the flow but make it possible to go back at the previous step"_ — 50 messages, 4 turns, zero corrections

Compare that to a prompt that generated 38 corrections across 11 turns:

"Can you check app resources and optimize them if needed and also add best optimizations techniques to load faster in the browsers"

The difference comes not from the length, but from specificity of the scope. The first group pins the agent to a specific file and a specific behavior. The second group says "improve things" and hopes for the best.

The vague prompts are invitations to touch everything with a warm agent's "yes" to always accept it.

The agent doesn't have taste. It doesn't know your codebase has opinions. It doesn't feel the pain of a noisy diff.

After 1,703 "don't" signals later my lesson is simple: every implicit constraint you don't encode up front, you'll encode as a correction after the fact. Break your changes to a smaller scopes or build a plan for a bigger ones before, this will save you the time and the tokens (money).