Top 5 Agentic Coding Fails in 2026, Ranked on Research

As of October 2026, the five most common agentic coding fails, sorted from the MAST dataset of 1,642 multi-agent runs, are: intent lost between the plan and the code (44.8% of failure labels), work called done without proof (23.5%), collisions and duplicate work (17.2%), lost context (7.7%), and silent decisions, where agents guess instead of asking (6.8%). MAST reports the 14 underlying failure modes. Grouping them into these five is our own step, and the mapping is published below. Each fail is a gap in the process around the agents, so each has a process fix. One more fail isn't in that study: insecure generated code. In Veracode's 2025 tests, 45% of AI-generated code samples failed security tests. You've watched an agent say "all done" when the work wasn't. Agentic coding fails in familiar ways, and researchers have now counted them. The top of this list isn't about the model. Watch the video: https://youtu.be/v1mpZJ3X1SI

What are the most common agentic coding failures?

This ranking uses one yardstick: how often a fail appears in MAST, short for Multi-Agent System Failure Taxonomy, from researchers at UC Berkeley. Their paper studied 1,642 runs across seven multi-agent frameworks and labeled the ways those runs failed, using 14 failure modes. One dataset sets the order, because percentages from different studies can't be ranked against each other. We assigned all 14 modes to five fails. The shares are MAST's, from Figure 1 of the paper. The grouping and the sums are ours. Field studies and costs appear as evidence under each entry and don't move the order.

MAST's 14 failure modes, grouped into our five fails. The full mapping is in the table below.
| Rank | Fail | MAST failure modes and shares | Total |
| --- | --- | --- | --- |
| 1 | Intent lost between the plan and the code | Disobey task specification 11.8%, reasoning-action mismatch 13.2%, task derailment 7.4%, unaware of termination conditions 12.4% | 44.8% |
| 2 | Done without proof | Premature termination 6.2%, no or incomplete verification 8.2%, incorrect verification 9.1% | 23.5% |
| 3 | Collisions and duplicate work | Step repetition 15.7%, disobey role specification 1.5% | 17.2% |
| 4 | Lost context | Loss of conversation history 2.8%, conversation reset 2.2%, ignored other agent's input 1.9%, information withholding 0.8% | 7.7% |
| 5 | Silent decisions | Fail to ask for clarification 6.8% | 6.8% | The limits: these are multi-agent systems on coding, math and general tasks, with models up to early 2025. The date: ranked October 2026. One detail: Figure 1 gives information withholding as 0.80% and the paper's text gives 0.85%. We use Figure 1, whose values sum to the paper's category total.

#5, silent decisions: how do you track the decisions an AI agent makes?

When a task is unclear, the agent doesn't ask. It guesses and carries on. MAST calls this "fail to ask for clarification", and it makes up 6.8% of the failure labels. The guess can then disappear. One scientific software team, at Idaho National Laboratory, found that AI summaries of their agent logs "abbreviated or obscured the agent's actual decision-making". The cost is a wrong call nobody can find later. The fix: have the agent write down each decision and its reasons, for example through instructions in AGENTS.md, as that team suggests. Then a person reviews the decisions that matter.

#4, lost context: how do coding agents keep context between sessions?

Chat history drops out, conversations reset, and agents ignore each other's input or don't pass on what they know. Those four failure modes add up to 7.7%, a narrow margin over #5. In one eight-month Claude Code project, three sessions in a row re-proposed a subsystem that already existed, even with its design documents in context. The same report says compaction summarizes away the "connective tissue" of long arcs of work. Today, teams mostly rely on files like CLAUDE.md, AGENTS.md and memory notes. Those carry rules and preferences, not the full history of what was built and decided. The fix: keep that history, the plans, decisions and finished work, in one place outside any session, where every agent can search it.

#3, collisions and duplicate work: how do you stop coding agents duplicating work?

Agents redo steps that are already finished, or take over each other's roles. Together that's 17.2% of MAST's labels. The pattern shows up in real repositories too. Researchers categorized 562 rejected agent pull requests, and 142 of them duplicated work already in another pull request. Not all of those were agents colliding with agents. When researchers replayed merges of agent pull requests that were open at the same time, 19.8% of same-agent pairs had textual conflicts. The fix: make dependencies explicit, such as which task blocks which, and let every agent see what's already taken before it starts.

#2, done without proof: why do AI agents say they're done when they aren't?

The agent stops early, skips verification, or verifies the wrong thing. That's 23.5% of the labels. An agent can stub out the hard function or narrow a test until it passes. And MAST found that many verifiers ran only superficial checks, such as whether the code compiled or had leftover TODO comments. Benchmarks show the extreme, called reward hacking: making a run look successful without doing the work. METR, a nonprofit that evaluates AI models, confirmed reward hacking in 14 of 385 benchmark runs of GPT-5.1-Codex-Max. The fix: an independent check, written before the work, such as tests the agent can't edit or a review by something other than the agent that wrote the code. In one MAST case study, adding a high-level verification step to the ChatDev framework improved task success on the ProgramDev benchmark by 15.6%.

#1, intent lost between the plan and the code

What you meant doesn't make it into what the agent builds. The agent departs from the task, drifts off it, acts against its own reasoning, or doesn't know when the work is finished. Those four failure modes make up 44.8% of the labels. A separate study goes deeper. In the Planner-Coder Gap study, 113 of 150 failures traced back to information lost between the plan and the code. That's a different count from MAST's, so the two figures don't add up and can't be compared. The cost is fragility. When a requirement was reworded with the same meaning, those systems failed 7.9% to 83.3% of problems they had already solved. The fix: write down what done means before the code, such as a plan with acceptance criteria and a clear point to stop, and keep the agent working from it. Our full video on the #1 failure goes deeper.

Bonus, no rank: is AI-generated code secure?

Often not. This fail falls outside MAST, which has no security failure mode, so it can't sit on the list. It's too big to skip anyway. In its 2025 report, the security vendor Veracode tested over 100 large language models on Java, Python, C# and JavaScript. 45% of the code samples failed security tests and introduced OWASP Top 10 vulnerabilities, the best-known web security risks. Newer, larger models did no better. That figure is a share of code samples, not of failure labels, so it doesn't compare with the ranked shares. The fix: scan every change before it ships, with static analysis for security flaws, secrets scanning and a dependency audit, and don't count the work as done until those scans pass.

Why do AI coding agents fail?

Look back over all six fails. None of the fixes calls for a better model. These fails are gaps in the system around the agents. Filling those gaps is the job of a control plane: an orchestrator and gatekeeper, independent of the coding agents. Levr is that control plane, air traffic control for agent work. Levr plugs in over MCP, so you keep the agentic coding tool you already use, such as Claude Code, Cursor or Codex. Here's how Levr handles each fail, from number five up.

Each fail and Levr's answer to it. The top two, the plan and the proof, are where to start. Number five, silent decisions: Levr has a decision ledger. Agents record each decision with its reasons, and you see the decisions sorted by how hard each one is to undo. People confirm or override them, and approvals wait for a person.

Number four, lost context: one place outside any session

Levr keeps your plan, tasks, tests and results in one place, outside any session, and agents reach them over MCP. Search works by meaning, not keyword, so an agent can find what was already built or decided.

An agent whose context was compacted asks Levr and finds the work already built.

Number three, collisions: what blocks what

Levr tracks which work blocks which, with blocks and blocked-by links. Agents claim tasks that are ready, and duplicate tasks get linked or merged instead of built twice.

Number two, done without proof: gates

Levr uses gates, checks written before the work starts. The agent runs each gate, and Levr decides pass or fail from the command, the exit code and the output, not from the agent's say-so. If zero tests ran, the gate fails. A failing required gate keeps the task open, failed attempts stay in the history, and a waiver needs a reason.

The gate was written first. Exit code 1 means it fails, and the task stays open whatever the agent says.

Number one, intent lost: a Plan with what done means

In Levr, your requirements become a Plan. The Plan breaks into Deliverables, and each Deliverable has acceptance criteria and gates, written before the code. So the agent works from what done means, including when to stop, instead of from a thin ticket. Gates verify that the work matches the plan, not that the plan was right, so people stay on the decisions that need them.

The bonus, insecure code: security checks as gates

Security checks can be gates too, run with the tools your repo already uses. A security testing gate runs SAST, static analysis of source code for security flaws, with Semgrep or Opengrep, on rules kept in your repo. A secrets scan gate runs gitleaks. A dependency audit gate looks for vulnerabilities in dependencies that a change added or upgraded. With Levr, the tools run wherever your gates run. And a required gate keeps the task open until it passes, no matter what the agent says.

Where should you start?

• If you run one agent: start with the top two. Write the plan, and check the work.
• If you run several agents: add number three.
• If the code ships: make security scans required gates.
  | Rank | Fail | Share | Answer |
  | --- | --- | --- | --- |
  | 1 | Intent lost between the plan and the code | 44.8% | Plan |
  | 2 | Done without proof | 23.5% | Gates |
  | 3 | Collisions and duplicate work | 17.2% | Dependencies |
  | 4 | Lost context | 7.7% | One place |
  | 5 | Silent decisions | 6.8% | Decision ledger |
  | Bonus | Insecure code | Not in MAST | Security gates | Most of the ranked failures, 68.3% in MAST by our grouping, sit in the plan and the proof, and neither one depends on a better model. Levr makes done mean proven.

Better models help. Better plans help more.

Try Levr free. It's free during preview, with no credit card. For a deeper look at the top failure, watch What Is the #1 Failure in Agentic Coding?