Where AI coding assistants break down
Not a list of things they cannot do — a list of task shapes where they fail in ways that are expensive to catch. The pattern is more useful than the examples.
Lists of things an assistant cannot do can become stale. Examine task risks as well as current capability: missing context, weak checks and model limitations can all matter.
Relevant code and requirements can make a task easier to check, but they do not guarantee a correct answer. Missing context and model errors can both produce a plausible patch.
Timing, concurrency and ordering
Concurrency is a useful risk category to examine because correctness can depend on interleavings that a single run does not show. Do not treat it as a universal ranking of where every assistant performs worst.
Code that is correct depending on what else is happening at the same time — locking, retries, idempotency, transaction boundaries, anything involving two processes touching the same state — looks fine in isolation. It is not wrong on the page; it is wrong in the presence of something not on the page.
A concurrency bug may escape a simple unit test or diff review. Test relevant interleavings, retries, locking and idempotency, and use integration or load tests where appropriate; such failures are difficult, not inherently invisible.
Invariants held across distant code
Many systems depend on a rule that no single file states. Two values that must stay in sync. A cache invalidated somewhere unrelated to where it is written. An ordering guarantee maintained by convention between services.
A wrong change can reflect missing requirements, poor interpretation or faulty reasoning. Find which happened before deciding that more context alone is the remedy.
Ask the agent to identify unknown assumptions, but do not rely on it to ask every necessary question. Document important invariants and enforce them with tests and review.
Anything whose correctness depends on why
The deliberate oddity problem, and it deserves its own category because the failure is uniquely deceptive.
The retry loop that exists because a vendor API returns success on failure. The denormalized column kept in sync by a nightly job. The apparently redundant check that catches a real edge case from an incident two years ago.
A tidy refactor can remove a deliberate exception. Explain why the exception exists and retain a regression check where its behavior matters.
Comments are one source of intent, alongside tests, history and runbooks. Use enforceable checks for critical invariants rather than treating a warning comment as the only defense.
Silent-failure work
A useful lens: how does this task announce it has gone wrong?
For migrations, test realistic data, constraints, repeat runs and rollback or recovery. Neither a passing function test nor a quiet migration establishes that existing data remains correct.
Assistants are strong where feedback is fast and loud, and risky exactly where it is slow and quiet. Sort your tasks by that axis before sorting them by difficulty; it is the more useful ordering.
Large changes with weak verification
A mechanical change with strong checks may be a good candidate for assistance. A small untested change may be riskier than it looks. Consider impact and difficulty too; neither size nor tests alone determine suitability.
For agent work in a legacy codebase, include the time needed to understand and validate the change. If the generated patch is too broad to review reliably, reduce its scope rather than assuming generation speed is a saving.
Where they are genuinely excellent
Being balanced, because the strengths follow the same rule and are easy to under-use.
Candidate tasks include drafting tests, explaining code, finding call sites and making constrained transformations. Check completeness and correctness, especially that tests assert an independently justified outcome.
Greenfield work may have fewer historical constraints, but still needs requirements, security and validation. Legacy work is not categorically beyond an assistant; choose tasks according to the evidence and controls available.
Two more shapes worth naming
An assistant may ask for clarification or may fill gaps with an assumption. Require explicit assumptions for important unknowns, then verify them before accepting the implementation.
Anything that spans a boundary the tool cannot see. A change to an API contract consumed by a service in another repository. A message format another team depends on. A database column read by a reporting job nobody mentioned. Inside its visible scope the change is correct; the breakage is somewhere it was never shown.
Look for these failures in review and tests, while recognizing that either can miss them. Make consequential requirements independently checkable wherever possible.
What this implies about how to work
Three habits follow, and they are cheap.
Specify a bounded task. Name the relevant pattern and constraints, then verify whether the result respected them. This clarifies the request but cannot eliminate ambiguity or model errors.
A useful instruction makes the constraint explicit, but prevention depends on whether it is followed and verified. Add a regression test or permission boundary for a costly failure.
Put the why in the code. Every deliberate oddity with a one-line reason beside it. That single habit defends against the tidy-up failure, and it is the one piece of advice here that would be worth following even if these tools disappeared tomorrow.
The question to ask before delegating
One question captures nearly all of the above: could a competent engineer who has never seen this system get this right from the code alone?
If a competent new engineer could attempt the task with the available context, it may be a candidate for agent assistance. Still scope permissions, review the result and run the checks appropriate to its risk.
Checking available information is a useful part of the diagnosis, but model reasoning and tool limits still matter even when the context is complete. Investigate the actual failure, then improve the relevant documentation, tool, model choice or verification. Do not assume every wrong answer reveals a documentation gap.
Technical review, October 10, 2026. References: GitHub: Copilot Agents application card; Claude Code: project instructions.
Try this
After an incorrect change, check what information was available, whether it was used correctly, and what test would expose the defect. Improve context, tooling or checks according to the cause; do not assume visible information means the prompt was at fault.