DataBugBench: Can Leading LLMs Catch Silent Bugs in Python Data Science Code?

Data science code has two kinds of bugs: syntax errors that crash immediately, and "silent bugs" that let the program run normally while quietly producing wrong results. The latter is the real nightmare. A new benchmark called DataBugBench evaluates five leading large language models (LLMs) on exactly this scenario — and the results reveal where today's AI truly stands when facing real-world data pipeline challenges.

Why Test for Silent Bugs?

LLMs shine on synthetic LeetCode-style problems, but real-world data science pipelines rarely fail due to syntax errors. They fail because of logical traps — code that runs without throwing exceptions yet produces incorrect results. DataBugBench targets this exact pain point, building diagnostic tests specifically around Pandas, NumPy, and Scikit-Learn code.

The benchmark focuses on five categories of issues that are extremely common in data engineering:

• Pandas SettingWithCopyWarning-induced silent mutations: Chained assignment modifies a copy instead of the original DataFrame.
• Missing groupby keys after aggregation: The aggregation logic looks correct but silently drops critical dimensions.
• NumPy implicit broadcast dimension mismatches: Array shapes are silently distorted by broadcasting rules.
• Data leakage during feature scaling: Normalizing data before the train/test split contaminates model evaluation.
• Non-contiguous index after dropping NaNs: Indices break after dropna, causing errors in subsequent position-based access.

What these five categories share is this: the code completes without raising any exception, yet the analytical conclusions have already gone quietly wrong. For data science practitioners, this kind of hidden bug is far more dangerous than a straightforward error.

Data Leakage deserves special attention because it is the most insidious and harmful of the five. Data leakage occurs when information from the test set "leaks" into the training process, inflating evaluation metrics while causing dramatic performance drops in real deployment. The most common scenario: applying StandardScaler normalization to the full dataset before train_test_split — which means the scaling parameters (mean, standard deviation) are computed using test set data, so the model has effectively already "seen" statistical information from the test set. The correct approach is to split first, then fit the scaler only on the training set, and use that same scaler to transform the test set. This error never triggers any exception, the model converges normally, but the reported accuracy or AUC is untrustworthy and can lead to serious misjudgments in production.

Five Models Go Head-to-Head

The benchmark covers five leading frontier models, chosen to observe how code specialization actually affects debugging precision:

• Claude 3.5 Sonnet
• GPT-4o
• Gemini 1.5 Pro
• Qwen 2.5 Coder 32B
• Llama 3.3 70B

This lineup includes both general-purpose flagship models and Qwen 2.5 Coder, which is specifically optimized for code tasks — making it a useful comparison between general capability and specialized training on debugging performance.

Results: Who Catches Silent Bugs Best?

Here are the final pass rate results:

Model	Passed	Accuracy
Claude 3.5 Sonnet	5/5	100.0%
GPT-4o	4/5	80.0%
Qwen 2.5 Coder 32B	4/5	80.0%
Gemini 1.5 Pro	3/5	60.0%
Llama 3.3 70B	3/5	60.0%

Claude 3.5 Sonnet achieved a perfect score, correctly diagnosing and fixing all five categories of silent bugs. GPT-4o and the code-specialized Qwen 2.5 Coder 32B tied for second place at 80%. Notably, the 32B-parameter Qwen 2.5 Coder matched GPT-4o — confirming that code-specialized training can "punch above its weight" on complex array shape and broadcasting errors.

Key Insights

Silent logic errors are the hardest to fix. The results clearly show that models handle explicit syntax errors with ease, but frequently stumble on issues like data leakage — where code runs normally but produces wrong results. These bugs require models to understand the temporal logic of data flow (e.g., normalization must happen after splitting), not just syntactic correction.

Specialized training actually works. Qwen 2.5 Coder outperformed two larger general-purpose models with far fewer parameters, demonstrating that code-focused optimization can give models more reliable intuition for low-level details like array shapes, memory views, and broadcasting behavior. This is an encouraging signal for resource-constrained deployment scenarios.

Pandas SettingWithCopyWarning is another classic case worth understanding in depth. When you perform chained indexing on a DataFrame (e.g., df[df['col'] > 0]['val'] = 1), Pandas cannot guarantee whether the first slice returns a view of the original data or an independent copy. If it returns a copy, the assignment only modifies the copy — the original DataFrame remains unchanged — but no error is raised. This behavior depends on Pandas' internal memory layout and is inconsistent across different versions and data shapes, making it extremely difficult to catch by eye. The correct fix is to use .loc for a single-step indexed assignment (df.loc[df['col'] > 0, 'val'] = 1), eliminating the ambiguity of chained assignment entirely. Pandas 2.0 has made Copy-on-Write the default behavior, partially mitigating this issue, but a large body of legacy code remains at risk.

Implications for AI Data Science Assistants

DataBugBench's conclusions point in a clear direction: frontier LLMs have become quite capable at standard code generation, but truly mastering data pipeline debugging still requires a deeper understanding of implicit state, memory views, and data leakage.

Most mainstream programming benchmarks focus on "can it write correct code?" DataBugBench reminds the field that evaluating "can it find non-crashing logic bugs?" is equally critical. Only by incorporating these silent defects into evaluation frameworks can we build truly reliable AI data science assistants — otherwise, an AI recommendation that appears reasonable but contains data leakage may be more dangerous than one that simply crashes.

Note: This benchmark uses only a single sample per bug category (the denominator of 5/5, 4/5, etc. is 5), so the sample size is small. The conclusions are better treated as directional trends rather than definitive rankings. Interested readers can find the complete evaluation code publicly available on Kaggle.