Almost everyone building with AI coding agents has lived the same arc. The first week is euphoric. You describe a feature, the agent writes it, the tests pass, and you wonder why you ever did this by hand. Then you point it at the real work, the eight-year-old service with the half-finished migration and the auth logic nobody fully understands, and the euphoria drains out. The agent still produces code. The code still looks right. It is just wrong in ways that take longer to find than they would have taken to write.
That gap between the demo and the deployment is not bad luck, and it is not a model that needs one more version to get good. It is a set of specific, nameable failure modes that show up the moment an agent meets a production system with real users, real history, and real consequences. This is the hub for a series that walks each of them. The point is not to argue that agents do not work. It is to be precise about where they break, because the failures are predictable, and predictable failures are the ones you can engineer around.
Failure is a property of the system, not the model
The most useful reframe up front: when an agent ships something broken, the model is rarely the whole story. The model is one component inside a system that also decides what information the agent sees, what it is allowed to assume, what checks its output, who signs off, and what happens when it is unsure. Swap in a better model and a system with none of that scaffolding is still fragile. Wrap a merely good model in strong grounding, real verification, and human gates where the stakes are high, and you get something you can trust on a Tuesday.
That is why this is worth mapping honestly. Every failure below is a place where the system, not just the model, was thin. And every one has a body of public, well-understood engineering practice behind it. The four groups that follow are the four gaps where agents fall through.
The reliability gap: it works until the codebase is real
The first cluster of failures is about the distance between a clean demo and a messy production repository.
The demo-to-production cliff is the headline. An agent that looks magical on a toy project produces confident nonsense on a mature codebase, because the toy project had none of the ambiguity, history, or hidden coupling that real systems carry. Understanding why the cliff exists is the first step to not falling off it, and we walk through it in the demo-to-production cliff.
Underneath the cliff sits the single most expensive individual failure mode: code that is plausible but wrong. An agent does not fail like a compiler, with a red error you cannot miss. It fails like a confident junior engineer, producing something that reads correctly, passes a glance, and is subtly incorrect in a way you discover in production. Why that specific shape of failure costs so much, and how teams catch it cheaply, is the subject of plausible but wrong.
And the reason agents drift into wrongness on large systems is often context rot: as a codebase or a task grows, the agent's working understanding degrades, and it starts making decisions based on a picture that has quietly gone stale. We cover why long contexts and large repositories break agents, and what actually helps, in context rot on large and legacy codebases.
The deeper treatment of this whole gap lives in our companion guide on reliable AI coding agents, which is the engineering answer to everything in this section.
The shipping gap: a suggestion is not a shipped feature
The second cluster is about the distance between output and outcome. Most tools stop at a suggestion. The work of turning that suggestion into merged, deployed, working software is where teams actually drown.
The clearest version is what we call the last mile: a pull request is not a shipped feature. Generating the diff is the part that demos well. Getting it reviewed, sequenced, merged, deployed, and verified in production is the part that consumes the week, and it is the part most AI tooling leaves entirely to you. We make that case in the last mile.
A specific and painful version of the shipping gap is dependency blindness: an agent happily starts work that cannot succeed yet, because something it depends on has not been built, or it changes things in an order that breaks callers. Why order matters as much as content, at the level of a single change and a whole backlog, is covered in dependency blindness.
Related, and just as costly, is cross-boundary breakage: a change that is correct and tested inside one repository quietly breaks a consumer in another one, because nothing compiled the whole product at once. We work through why the boundary is where the risk concentrates in cross-boundary breakage.
The trust and accountability gap: nobody owns the outcome
The third cluster is not technical at all. It is about who is responsible, and it is the gap that keeps agents out of serious production systems more than any capability limit.
The most acute operational symptom is the review bottleneck. An agent can generate more code in an hour than a team can responsibly review in a day, and if you solve that by reviewing less, you have not gained velocity, you have just moved the failure downstream. How to keep review meaningful when the volume explodes is the subject of the review bottleneck.
Underneath the bottleneck is a harder question: who approved this? When an agent ships a change and it breaks, accountability has to land on a named human who made a real decision, not on a checkbox someone clicked without reading. Why accountability must be enforced rather than promised is covered in the accountability gap.
And the reason many teams never even start is the trust gap: security-conscious organizations will not run an autonomous agent against their code until they understand isolation, least privilege, and where their secrets live. Those concerns are legitimate, and they are answerable. We lay out the posture in the trust gap.
The full engineering treatment of this territory is our guide on trustworthy AI agents.
The economics and fit gap: the bill and the brownfield
The last cluster is about money and about fit: whether the economics work, and whether the tool matches the reality of your codebase.
The quiet budget-killer is the rework tax. The visible cost of an agent is the tokens it spends. The real cost is the engineer time spent unwinding output that looked done but was not. A tool that is cheap per run and expensive per correct outcome is not cheap. We pull that apart in the rework tax.
Compounding it is cost surprise: agent bills are hard to predict because token spend scales with things teams do not instinctively track, and a bill that arrives without warning erodes trust fast. How to see the cost coming instead of discovering it is covered in cost surprise, and the full economics picture is in our guide on the economics of AI coding agents.
Finally, the fit problem almost nobody names: greenfield bias. Most AI coding tools are tuned, consciously or not, for a clean slate, and most real work is not a clean slate. It is a brownfield system with constraints the tool assumes away. Why that mismatch matters, and what it takes to work on code that already exists, is the subject of greenfield bias.
The honest limitation
Naming these failure modes does not make them disappear, and no framework fixes all of them at once. Grounding reduces wrong assumptions but never eliminates them. Verification catches errors but not every error. Human gates prevent bad calls but cost latency and attention. Every fix in the linked posts is a way to make failure cheaper, more visible, and more contained, not a way to make an agent infallible. Any vendor promising infallibility is describing a demo, not a production system.
The realistic goal is not an agent that never gets anything wrong. It is a system where, when the agent is wrong, the error surfaces at a checkpoint that costs a retry instead of in production where it costs an incident, and where a human owns every decision expensive enough to justify one. Unreliable systems fail silently and late. Well-built ones fail loudly and early, and keep the consequential choices in human hands.
Where this leaves you
The failures are not mysterious. Agents fall off the demo-to-production cliff, ship plausible-but-wrong code, rot their own context, stop at the last mile, ignore dependencies, break across boundaries, overwhelm review, blur accountability, spook security teams, hide a rework tax, surprise you on cost, and assume a greenfield you do not have. Every one is a known problem with a known direction of fix, and the linked posts go deep on each.
This is the problem set we built Loopsfinity to take seriously: an agent that plans, builds, verifies, and ships features into existing products, grounded in the real codebase and gated by human judgment where the consequences are real, precisely because these failure modes are the actual job, not an afterthought. Whatever tooling you use, the way through is to treat each of these as an engineering problem you can attack today, and to stop expecting the next model to make them go away on its own.