Do AI coding assistants introduce bugs? The patterns and how to catch them

The problem is not bad code — it is plausible code

The danger of AI-generated code is not that it looks wrong. It is that it looks right. It compiles, it follows the surrounding style, the variable names are sensible, and the happy path works in the demo. The defect is one token deep: a <= where a < belonged, a ?? 0 quietly dropped, a catch that turns a network failure into a success. A human reviewer skims it, sees idiomatic code, and approves. This is precisely why bugs in AI-generated code survive review more often than bugs in hand-written code.

Below is the recurring taxonomy we see across thousands of AI-authored diffs. If you remember one thing: these are behavioural bugs, and behavioural bugs are invisible to style-based linters.

The seven failure patterns of LLM-generated code

1. Off-by-one errors

The single most common AI bug. When a model rewrites a loop — say converting a reduce into an explicit for — it frequently emits for (let i = 0; i <= items.length; i++). That final iteration reads items[items.length], which is undefined, and the next property access throws at runtime. Slice ranges and inclusive/exclusive boundary confusion are the same family.

2. Missed edge cases

Models optimise for the path you described. Empty input, a single element, zero, negative numbers, very large values, unicode, timezones and DST, leap years, and pagination boundaries are routinely unhandled — because they were never in the prompt and the model has no test suite forcing it to consider them.

3. Swallowed and incorrect error handling

A bare except: in Python or an empty catch in JavaScript is a classic AI move when asked to "make this more robust." It does the opposite: a network error, an HTTP error, and a JSON parse error are all silently converted into a fake success. Closely related: a missing await inside a try means the very error you are trying to handle escapes the block entirely.

4. Null and undefined gaps

Optional chaining that stops one level too early, a dictionary lookup assumed to hit, a default value that masks a real failure. The code "works on the happy path" and then a production input that the model never imagined produces NaN or a thrown TypeError.

5. Async races and fire-and-forget

Missing await on a promise, a fire-and-forget call whose failure no one observes, shared mutable state mutated across concurrent requests, and races in lazy initialisation or caching. These pass every local test and only surface under concurrency.

6. Resource leaks

Files, sockets, database connections, and event listeners opened but never closed; unbounded in-memory growth. The model produces the "acquire" half of the pattern and forgets the "release" half.

7. Silent fallbacks — the most dangerous pattern

This is the one that costs the most. The model replaces an explicit error with a default or empty value, so corrupt or missing data flows downstream looking valid. Returning on a failed fetch, defaulting a missing config to a permissive value, swallowing a validation failure. It "looks fine" and hides corruption — exactly the bug you find three weeks later in a customer's data.

Why linters and CodeQL miss them

Static analysers and linters are excellent at what they do: style, formatting, known unsafe API usage, and a fixed catalogue of syntactic patterns. But an off-by-one in a rewritten loop is not a syntax error. A swallowed exception is valid code. A silent fallback is, by construction, the code working as written. Catching these requires reasoning about behaviour and intent — what the change is supposed to do versus what it does.

How to catch bugs in AI-generated pull requests

There is a repeatable process that works:

1. Flag AI authorship. Know which PRs were written or assisted by an AI assistant. Commit trailers (Co-Authored-By: Claude), generated-with signatures, and authorship patterns make this detectable. AI-authored diffs deserve a heavier review.

2. Run differential analysis tuned to the patterns above. Instead of a generic lint pass, review the diff specifically for off-by-one, edge cases, error handling, null gaps, races, leaks and silent fallbacks.

3. Score by confidence and triage. A wall of warnings gets ignored. A ranked list — "critical, 99% confidence: this loop reads past the end of the array" — gets fixed. Confidence scoring is what turns analysis into action.

Automating it

This is exactly what AI Diff Guard does. It is a GitHub bot that flags AI-authored pull requests, runs differential analysis for the failure patterns of LLM-generated code, and posts a single confidence-scored review on each PR — not a generic linter, because the bugs that matter here are behavioural. You can try it on any diff with no install from the homepage analyzer: paste a change, or load the buggy sample, and watch it score an off-by-one and a dropped null-fallback in the same six-line diff.

AI assistants are a genuine productivity win. The answer is not to stop using them — it is to put a guard on the diff so the bugs they introduce never reach production.