6 ms·
I’ve been running a bunch of coding agents on benchmarks recently as part of consulting, and this is actually much more impressive than it seems at first glance
by gronky_ 1y ago
I’ve been running a bunch of coding agents on benchmarks recently as part of consulting, and this is actually much more impressive than it seems at first glance.
71.2% puts it at 5th, which is 4 points below the leader (four points is a lot) and just over 1% lower than Anthropic’s own submission for Claude Sonnet 4 - the same model these guys are running.
But the top rated submissions aren’t running production products. They generally have extensive scaffolding or harnesses that were built *specifically for SWE bench*, which kind of defeats the whole purpose of the benchmark.
Take for example Refact which is at #2 with 74.4%, they built a 2k lines of code framework around their agent specifically for SWE bench (https://github.com/smallcloudai/refact-bench/ https://github.com/smallcloudai/refact-bench/). It’s pretty elaborate, orchestrating multiple agents, with a debug agent that kicks in if the main agent fails. The debug agent analyzes the failure and gives insights to the main agent which tries again, so it’s effectively multiple attempts per problem.
If the results can be reproduced “out-of-the-box” with their coding agent like they claim, it puts it up there as one of the top 2-3 CLI agents available right now.
- energy123 1y agoWhat are the typical context lengths in SWE-bench problems? Does it partly measure performance in the 64-128k context range?
- dimitri-vs 1y agoIIRC the SWE bench dataset gives you the full repo snapshot + the issue text, the evaluation pipelines typically run some kind of retriever (eg. grep, BM25) to pick a subset of files to place in the model’s context. They provided context is usually limited up to ~50k tokens.
- whymauri 1y agoThis is what the rows look like: https://huggingface.co/datasets/princeton-nlp/SWE-bench_Verified https://huggingface.co/datasets/princeton-nlp/SWE-bench_Veri... Its up to your retrieval system/model to selectively hunt for relevant context. Here's a few critiques of the benchy: https://x.com/brhydon/status/1953648884309536958 https://x.com/brhydon/status/1953648884309536958
- szundi 1y agoAccording to your experience with this model, is it just trained for the benchmark or these points are actually representing the performance?
- deleted 1y ago[deleted]
- eddd-ddde 1y agoI think multiple attempts are completely understandable and even expected? How is that defeating the purpose of the benchmark?
- gronky_ 1y agoIt’s a pass@1 benchmark. When submitting you need to check a box that there was only 1 attempt per problem. See here for example: https://github.com/SWE-bench/experiments/pull/219 https://github.com/SWE-bench/experiments/pull/219 Building multiple attempts into your agent is stretching the rules, even if technically it’s acceptable
- terminalshort 1y agoFrom my perspective as a potential user the number of attempts is the number of times I have to tell it what to do. If you have an agent that makes a single attempt and is 60% accurate vs another that makes 5 attempts and is 80% accurate, why would you care that each individual attempt of the 2nd model is less accurate than the first?
- mcintyre1994 1y agoI think it depends on "But the top rated submissions aren’t running production products" It sounds like they're shipping a product without the debug agent/try-again logic, and that's just for the benchmark, so you wouldn't get the performance they get as a user.
- gronky_ 1y agoThis ok from your perspective then? def make_pass@1_agent(agent, n): def retry_agent(problem): for attempt in range(n): result = agent(problem) if result.success: return result return result return retry_agent
- gronky_ 1y agoKeep in mind that this isn’t about users - the top agents on the leaderboard aren’t running an actual product on the benchmark. If they are running their production product as is, then of course whatever is built into the product is fine.
- thinkingtoilet 1y agoThis is classic Goodhart's law. "When a measure becomes a target, it ceases to be a good measure" https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- ambicapter 1y agoIt's really not that hard to not build a custom bench setup to game the benchmark instead of just using your product straight out of the box, though.
- deleted 1y ago[deleted]
- jasonjmcghee 1y agoRight. Building a custom setup is blatant- that will wildly overfit. But let's say a group uses it as a metric as part of CI and each new idea / feature they create runs against SWE bench. Maybe they have parameterized bits and pieces they adjust, maybe they have multiple candidates datasets for fine tuning, maybe they're choosing between checkpoints. This will also end up overfitting - especially if done habitually. It might be a great metric and result in a more powerful overall model. Or it might not.
- VikingCoder 1y agoRight, other than financial pressure. Which is, of course, immense.
- clutchdude 1y agoAlso see the VW dieselgate and numerous other "gaming the system" examples.
- kelipso 1y agoA specific setup for the benchmark is just plain cheating, not Goodhart’s law.
- oblio 1y agohttps://github.com/auchenberg/volkswagen https://github.com/auchenberg/volkswagen
- Roritharr 1y agoFinally someone mentions Refact, I was in contact with the team, rooting for them really.
- bluelightning2k 1y agoJust looked them up. Their pricing is around buying "coins" with no transparency as to what that gets. Hard pass
- Roritharr 1y agoYou realize that you can self-host their stuff? https://github.com/smallcloudai/refact https://github.com/smallcloudai/refact
- terminalshort 1y agoIs there something in this multi-agent approach that makes the setup more specific to just the test at hand and less general to real engineering tasks? If not, then this multi-agent system will just become what you get out of the box in a future product. Multiple attempts per problem (as long as there's no human intervention or selection between them) is a perfectly fine approach for agents because that's not an issue from the perspective of an engineer using the product. A single agent is already a multi-step usage of LLMs and it sounds like this is just another meta level of that.
- ai-christianson 1y agoOne thing with SWE bench is making sure there's zero leakage of information into the LLM context. I.e. the agent cannot even know which tests are failing. It has to both fix the issue based just on the issue text and fix it in the specific way the unit test, which it cannot see, expects. For this reason I find the benchmark a little disconnected from the reality of software engineering.