It doesn't crash the server. It doesn't print a red traceback. Your tests run green. Your CI pipeline shrugs and gives you a checkmark. But out in the real world, once every few hundred requests or after a specific input combination, something silently slips — a counter goes wrong by one, a thread sees an object before it's fully initialized, or a floating-point fee calculation drifts by a fraction of a cent that compounds into real money.
These are the bugs that take engineers half a Friday to find. They're subtle, and they're hard because there's no obvious signal pointing at them. You have to actually read and reason about the code.
I got curious: can AI models actually do this? Not generate code from scratch — that's what every benchmark measures. But look at a logically broken function that appears healthy, pinpoint the exact mechanism of failure, and produce a patch that is minimal: change what's broken, leave what works alone.
So I built SilentBug-Bench on Kaggle: a 10-task evaluation suite targeting silent software corruptions. I ran it against 5 models — two Claude variants, GPT-4o, Gemini 2.5 Flash, and Qwen2.5-Coder-32B — and measured not just whether the fix works, but how each model fixed it.
I picked 10 real-world defect archetypes — two per family — across five categories I've personally hit in production code: Boundary / Off-by-One The kind of error that works on your laptop test input but detonates on a 2-element array, an all-duplicate input, or a window size of 1. The deque sliding window max and the rotated binary search minimum both fell here. These bugs are one operator away from correct: < vs <=, mid vs mid - 1. Nothing else. State Mutation / Mutable Defaults Python's most famous footgun: def fn(x, cache={}). The default dict — or set, or list — is created exactly once, at the time the function is defined, and then shared across every call for the lifetime of the process. I used a graph DFS with a visited=set() default (state bleeds between separate path queries) and a call-history logger (100 entries accumulate globally, not per-caller). Concurrency / Thread Safety This category is brutally hard because the bugs are timing-dependent. I used a double-checked locking singleton where a racing thread can retrieve an object whose constructor hasn't finished, and a shared integer counter being incremented by 10 threads simultaneously with no lock — a counter += 1 that looks atomic but compiles to LOAD / ADD / STORE, with the GIL potentially releasing between any two of those. Numerical / Type Coercion Financial arithmetic in binary float. This one has a satisfying quality: it's easy to explain, hard to fully internalize, and extremely expensive when it goes wrong. Also a percentile rank function that always reports 0 for the lowest value because it counts strictly-less-than instead of the midpoint formula. Logic / Algorithm Correctness A topological sort that doesn't validate whether all nodes were actually processed (silently returns partial ordering when the graph has a cycle), and an interval merge function that works perfectly on sorted input but quietly corrupts random-order lists because nobody added the sort.
I wanted the benchmark to reward what a good code reviewer actually cares about:
That last term — the penalty — is the unusual one. If you correctly identify the bug but replace the entire function with a different algorithm, you lose points. That's intentional. A senior engineer reviewing a PR wants a minimal diff. Replacing an O(N) deque with an O(N log K) heap is a regression disguised as a fix.
I tried to put together a lineup that covered the real range of what teams are actually using: Claude 3.5 Sonnet — Anthropic's flagship at the time, widely used for complex reasoning tasks and my personal most-trusted model for code review. Claude 3.7 Haiku — The smaller, faster Claude. I wanted to know whether smaller context windows and lower compute budgets meaningfully hurt precision debugging. GPT-4o — OpenAI's primary workhorse. Billions of developers use it through Copilot, APIs, ChatGPT. If there's a "default answer" to "which AI do you use for code", this is often it. Gemini 2.5 Flash — Google's efficient-tier model. Fast, cheap, and arguably more accessible than the heavy flagships. I was curious whether it could compete on deep logic without the latency or cost. Qwen2.5-Coder-32B — The standout from the open-weights world. A 32 billion parameter model that was purpose-trained on code. You can run this yourself. I was genuinely uncertain how it would stack up against the proprietary models.
| Model | Root Cause | Patch Pass | Over-Eng | Explanation | EGRS | |---|---|---|---|---|---| | Claude 3.5 Sonnet | 89.0% | 96.0% | 6.8% | 89.8% | 76.9 | | Qwen2.5-Coder-32B | 85.2% | 95.5% | 5.9% | 86.4% | 74.9 | | GPT-4o | 83.4% | 86.0% | 15.2% | 85.4% | 69.9 | | Claude 3.7 Haiku | 79.0% | 88.0% | 10.0% | 81.6% | 69.0 | | Gemini 2.5 Flash | 76.8% | 83.5% | 11.0% | 79.4% | 66.3 |
(EGRS = Evidence-Grounded Reasoning Score. Lower is better for Over-Engineering.)
The heatmap reveals something the aggregate scores hide: every model has specific categories where it reliably underperforms, and the worst single cluster is concurrency across the board.
The SB-05 column (singleton double-checked locking) is a bloodbath. Gemini 2.5 Flash scored 54 there. Claude 3.7 Haiku scored 58. GPT-4o scored 61. Even Claude 3.5 Sonnet only managed 69 — the lowest score it posted on any task.
State mutation (SB-03, the mutable DFS visited set) was the second-hardest category. Every model understood the problem conceptually but several still produced patches with lingering issues on exception paths.
The top-left quadrant is where you want to be: high root-cause accuracy, low over-engineering. Claude 3.5 Sonnet and Qwen2.5-Coder-32B both live there. GPT-4o is marooned in the bottom-right: decent root cause identification, but by far the highest tendency to rewrite working logic into something different.
That 15.2% over-engineering rate for GPT-4o isn't small. It means that on roughly 1 in 7 tasks, it produced a patch that correctly addressed the bug but changed the structure of the function in ways the original author wouldn't have wanted — sometimes degrading algorithmic complexity, sometimes introducing unnecessary dependencies.
One thing stands out clearly in the radar: Qwen2.5-Coder-32B has the lowest "Low Over-Eng" score (inverted: higher means more surgical) while staying competitive on root cause and patch pass rate. For a model you can self-host, that's a meaningful result. It didn't just perform respectably — it beat GPT-4o convincingly on overall EGRS.
Numbers are useful, but they don't tell you why models behave the way they do. Here's what I actually observed in the model outputs:
On SB-01 — the sliding window deque — GPT-4o correctly identified that there was an index boundary issue. It understood that elements needed to be evicted at the right time. But its response was: "To make this more robust, let me rewrite this using a max-heap."