Where AI Coding Agents Actually Fail: The Hunt for a Clean Culprit

I was debugging a two-step piece of a pipeline. An extraction step pulled some fields out of a document, and an inference step downstream reasoned over what got pulled. The output was wrong, and I put the agent on it.

It went straight at the inference step. That is where a reasoning bug is supposed to live, so that is where it looked. It read the prompt, questioned the logic, proposed a rewrite, and did it again on the next pass when the rewrite changed nothing. It never seriously turned around to look at the step behind it.

The extraction step was the problem. It wasn't returning the same thing every time. Feed it the same input and you'd get slightly different fields depending on the run, and everything downstream inherited that wobble. The agent couldn't see it, because "this step is flaky" isn't a clean logical cause. It's not a broken line you can point at. It's a step that behaves one way now and another way in five minutes, and that is exactly the shape of problem the agent is worst at naming.

That specific failure is why Stepbook exists. When you can't tell which step in a chain is the one lying to you, you need to pin each step's output and compare runs, because your own eyes and the agent's guesses will both send you to the wrong place.

It Reaches for the Tidiest Story

A coding agent's sense of where the problem is comes across as certain, and it is not well calibrated. It is biased toward the plausible spot over the actual one. Given a symptom, it reaches for the tidiest story that would explain it, and a reasoning bug in the reasoning step is a very tidy story. An intermittent, hard-to-reproduce wobble two steps upstream is not, so it gets skipped, even when it's the whole answer.

The agent is pretty capable. The problem is where it looks, and the same bias shows up far from any pipeline.

The Same Move In CSS

Nested CSS is the cleanest demonstration I know. I've watched an agent nail a genuinely obscure selector bug, the kind of specificity-and-inheritance puzzle that takes a person a while to unwind, and then completely whiff on adding a scroll container. One of those is hard. The other is close to boilerplate. It got the hard one and missed the easy one.

Difficulty has nothing to do with it. The miss tracks one thing: whether the fix sits where the agent expects a fix to sit. The selector bug lived in a plausible place. The scroll container was a structural change it didn't think to reach for, so it didn't.

CSS is also where a confident fix does the most collateral damage. The agent changes a rule to fix one thing and quietly breaks something three components over that was working fine, or it spends its time reworking the wrong node entirely while the real one sits untouched.

The Four Modes, And They Compound

Once you've seen it enough times, the same handful of behaviors keep showing up:

• Fixation: it locks onto one cause and keeps circling back after you've ruled it out.
• Challenge its diagnosis and the confidence goes up, not down. It argues for the answer instead of reopening the question.
• Context falls out. A constraint you set ten messages ago is quietly gone.
• It patches the one call site in front of it and never goes looking for the other four.

None of these is fatal on its own. The trouble is they compound, and the order they compound in varies. I can't hand you a neat chain, because there isn't one. Sometimes the forgetting comes first and the fixation builds on top of it. Sometimes it fixates early and the defensiveness locks it in before anything gets forgotten. What's consistent is that once two or three of them stack, you're a long way from the actual bug and the agent has no idea.

The Boundaries Cascade

The worst version of the compounding starts with a boundary. I'll define what a behavior is allowed to do and what it is not: this step may drop a field, that one may never; this decision is in scope, that one is off the table. Then a few things happen in sequence.

The agent forgets the boundary. Then, worse than forgetting it cleanly, it misremembers it, and the misremembered version tends to drift toward the opposite of what I said. Then it fixates on a diagnosis built on that wrong premise, and now it is reasoning confidently from a rule that is backwards. Then it announces a fix. The fix does nothing, or it makes things worse, and it is delivered with the same certainty as everything else.

This is at its worst in LLM pipelines and in any logic with a lot of decision points, because those are exactly the places where the rules are subtle, the state is easy to lose, and a backwards premise looks just as reasonable as the correct one from the inside. And through the whole cascade, the confidence never drops. It reports 100 percent sure at the top, 100 percent sure at the bottom, and 100 percent sure at every wrong turn in between.

But Can't You Just Configure It?

There's a fair rebuttal here, and I half agree with it. Prompt it better. Put the rules in an AGENTS.md or a CLAUDE.md, write a skill for the workflow, keep a memory file of the constraints that matter. Do all of it. It genuinely helps, and it lowers how often the cascade starts.

Most of that, though, is prose, and prose is a suggestion. A CLAUDE.md is a set of boundaries written in words and handed to the same model that forgets and misremembers boundaries. It's more context, and context is exactly what this failure eats. The line in the file that says "never do X" drifts the same way the constraint you typed five messages ago drifted. Writing the rule down beats not writing it down, but it doesn't make the agent unable to break it. It makes the agent a little more likely to remember.

Some configuration does enforce, and it's worth being precise about which. A hook that blocks the tool call, a test that goes red, a type that won't compile, a schema that rejects the object: those bind the agent, because they fail when violated and the model doesn't get a vote. That's a deterministic gate, and it belongs to a different discipline than a well-written instructions file. Building one is closer to putting up a wall than to leaving a note. Everything short of that wall is a strong suggestion to a system that treats all of its input as a suggestion.

You Are The Calibration

So the way I actually work with one of these agents is to treat its confidence as roughly no signal about correctness, and to hold onto the boundaries myself instead of trusting it to. I re-establish the constraint when I see it drifting. I check the steps it waved past, especially the flaky ones it structurally can't name. When it doubles down, I read that as a prompt to look harder, not as evidence it's right.

The agent supplies the certainty. You supply the calibration, because it doesn't have any and won't tell you so. The skill that matters here isn't prompting it better. It's knowing where it lies to you.