What AI Coding Agents Get Wrong That Tests Do Not Catch

A team ships a feature built largely with an AI coding agent. The diff is clean, the tests pass, the pull request looks routine. Weeks later a support ticket arrives: a scheduling feature assumed the week starts on Monday, a payment counter drifted out of sync under load, an internal endpoint turned out to require nothing more than a logged-in session. None of this shows up in a review scanning for bad syntax, because that is no longer where the risk lives.

Coding agents have gotten reliably good at the mechanical part of writing software. When a test fails, the agent reads the failure and fixes itself, so the errors a reviewer used to catch by eye, a typo, a missing import, a broken build, rarely survive to the pull request. What is left is subtler: a judgment call made somewhere inside a long task that nobody asked for and nobody checked.

Where Coding Agents Quietly Make Business Decisions

Two kinds of decision get made inside an agent's execution that never surface as a diff comment. The first is stylistic, naming and folder structure, low risk since the code works either way.

The second is not stylistic. An agent building an access-controlled feature might quietly decide that a verified-email check gates the route, without that ever being specified. A scheduling feature with no stated default might get a default start-of-week or serving size baked in, reasonable on its face, but never actually confirmed with anyone. These are business decisions wearing engineering clothes, and a fast read of a diff will not surface them: the code compiles, the agent's own tests pass, nothing looks wrong on the page.

Planning steps before an agent starts executing help. Asking it to state assumptions up front catches some of this. But a plan written at the start of a task does not account for every decision made along the way, particularly on longer changes; the assumptions made mid-execution are the ones a plan-first workflow is least likely to catch.

The Bugs That Pass Every Test You Wrote

A second class of defect is about correctness under real conditions rather than business intent. Code can read cleanly, do exactly what a single test expects, and still be wrong under concurrent access. A counter two requests read, increment locally and write back at nearly the same moment will silently lose an update: no exception, no failed test, no log line, just a number occasionally short of what actually happened. It is invisible to anyone checking that a feature works, because it does work, until two people hit it at once.

Catching it takes a different kind of review: recognising code shapes unsafe under concurrent writes, and reproducing a reported bug before patching it rather than treating the symptom.

What This Changes About Review

The practical shift is where review effort goes. Reading a diff for syntax is largely solved now. What is worth a reviewer's time is running the application and clicking through the behaviour it produces, reading the tests an agent generated to see what they actually assert, and checking access rules and defaults against business intent rather than an agent's inference.

Briefs that spell out defaults, access rules and expected behaviour under concurrent use remove one source of silent drift. But no brief is complete, so review still has to hunt for the decisions nobody wrote down. That is what makes AI-assisted development safe to ship quickly: not typing less, but knowing where an agent might have decided something on its own, and checking it before a customer finds it first.