We're excited to team up with Kaggle for a brand new challenge!
Running through October 11, the Kaggle Benchmarking Challenge asks you to build a benchmark, run it against real models, and tell us what you found.
Today's models reason, write code, use tools, and hold multi-turn conversations, and their capabilities will likely change by tomorrow. Public leaderboards only tell you so much, so why not test them against the work you actually do? Kaggle Benchmarks lets you build your own evaluations and run them across a suite of models to see how they really stack up.
So pick something you've always wondered about, measure it, and show your work. There's a $2,500 prize pool up for grabs across five winners!
Read on to learn more.
Judging Criteria
All submissions will be evaluated on:
- Insights Shared: Do the findings teach us something real about how the models performed?
- Writing Quality: Is the post clear, well-structured, and engaging to read?
- Creativity in Approach: Is the benchmark itself an original or clever way to measure the capability?
Note: Submissions must include a link to the benchmark on Kaggle to be eligible.
Prizes 🏆
Five winners will each receive:
- $500 USD cash prize
- DEV++ Membership
- Exclusive DEV Badge
All participants with a valid submission will receive a completion badge on their DEV profile.
Getting Started With Kaggle Benchmarks 🚀
New to Kaggle Benchmarks? Here's how it works:
- Create a task: Tasks test an AI model's performance on a specific problem, from multi-step reasoning and code generation to tool use and image recognition.
- Build a benchmark: Group your tasks into a benchmark and run it across a suite of models.
- Check the leaderboard: See how the models stack up and share your results.
Prefer your own setup? You can now create tasks from your local development environment using the Kaggle CLI.
Helpful resources:
Read more from the Kaggle team right here on DEV:
Important Dates
- September 23: Kaggle Benchmarking Challenge begins!
- October 11: Submissions due at 11:59 PM PDT
- November 5: Winners Announced
We can't wait to see what you measure. Questions about the challenge? Drop them in the comments below.
Good luck and happy benchmarking!
Top comments (6)
My benchmark is gonna be interesting (assuming if this goes to plan). Looking forward to see what others comes up!!
Absolutely! It’ll be interesting to see how everyone’s results compare, especially since real-world benchmarks can turn out quite differently from expectations. Looking forward to seeing what you come up with!
This is a submission for the Kaggle Benchmarking Challenge
Can LLMs Actually "Think" Code, or Just Fix Syntax? A Logic Bug Benchmark
Many LLMs are great at fixing missing semicolons, but how do they handle silent, destructive logical flaws? I built a targeted benchmark to find out.
🔍 What I Benchmarked
I measured Multi-step Reasoning and Code Generation/Debugging performance. Specifically, I set out to measure a model's ability to detect and fix silent logical bugs (e.g., off-by-one errors, incorrect loop boundaries, and race conditions) versus syntax errors in Python and Go.
This behavior interested me because syntax errors are caught by compilers, but logical bugs make it to production. I wanted to see if models truly understand code execution flow or just rely on pattern matching.
🤖 Models Tested
I benchmarked three models using zero-shot prompting:
📊 Findings & Real-World Meaning
The results taught me something real and surprising about current LLM limitations:
What this means practically: These results changed my view. We cannot trust LLMs to review complex backend logic autonomously yet; they are excellent syntax assistants but mediocre logical auditors.
Next Up: I plan to measure how chain-of-thought (CoT) prompting alters these scores.
🔗 My Benchmark
You can view my full dataset, prompts, and evaluation pipeline here:
👉 My Kaggle Benchmark Notebook & Dataset (Replace this with your actual Kaggle link)
I went and computed the estimator behind one of your cells, because the
[0, 0]case has a sharper edge than your paragraph gives it. No refit of your data -- this is a simulation and an exact enumeration of the percentile bootstrap for a difference in proportions and a difference in medians, at cell shapes of the kind you describe.1. The tie fraction, and its closed form. Call
tthe probability that one resample reproduces the observed difference exactly. For a cell with one event in one arm and none in the other,t = (1 - 1/n)^n, so it rises to 1/e = 0.3679 and stays there for any n: simulation gives 0.3632 at n=40, 0.3660 at n=100, 0.3674 at n=400, 0.3677 at n=1000. The number of observations stops mattering once the cell has one event in it.2.
[0, 0]is not printed by that. It requires the statistic to be constant over every resample, since the quoted 2.5th and 97.5th percentiles must both land on 0. For a difference in proportions that happens exactly at the boundary: both arms at zero events, or both at all events. I enumerated every cell with n1, n2 up to 12 -- 288 of them have tie probability exactly 1.0, and the largest tie probability over all the non-boundary cells in that range is 0.375. Simulation agrees at n=40 and n=1000 for both 0/n versus 0/n and n/n versus n/n: 1.0000.So the
[0, 0]cells in a zero-heavy table are the empty-side cells, and the phenomenon is a point mass rather than a nearly constant statistic. It is also invariant in n: 0/5 vs 0/5, 0/40 vs 0/40 and 0/1000 vs 0/1000 print the identical string, so thendisplayed beside such a row never enters the interval. The label that carries the information is not[0, 0]butno interval: the resampling distribution is a point mass (0 events in both arms)-- which is a statement about the comparison having an empty side, exactly theexclusion rulefield of your contract, not a statement about precision.3. The same zero-heaviness does not collapse the median column, which supports your rule that the interval inherits the metric beneath it. 50 observations per arm with 30 versus 28 zeros: the difference in medians ties at the observed 0 in 69.4% of resamples and its interval is still
[-1.5, +1.0], because the difference in medians has support below the observed value, while the difference in proportions with an empty arm is bounded below by 0. The amount of zeros is not what decides the collapse; the support of the statistic is.4. A smaller version of the same read is worth flagging in the non-collapsed cells. In the 1/40 versus 0/40 cell the printed interval is
[0.000, +0.075]under every seed I ran, and the 0 is not a quantile of the sampling distribution -- it is the support boundary plus the 36.3% tie mass. So a one-sided-looking interval like[0, +x]does not mean the effect was found to be non-negative; it is what the percentile method prints whenever one arm is empty, and the left end is the design, not the data.5. The three-line check, in your units. Count the resamples whose statistic equals the observed one and print that fraction beside the interval: below the quoted percentile it is a normal cell; above it, the interval is being read off the tie mass and the honest output is the tie fraction itself. That one number separates your
[0, 0]cells (tie fraction 1.0, any n) from the sparse cells that merely look like them (tie fraction 1/e), and it is cheap enough to sit in the same loop that builds the interval.This is a yummy challenge! 😋
Would love to try this one. 🥰
I,m interesting