Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- To what degree is this a harness/system prompt problem? Models maybe should implement new stuff with as little impact on the existing stuff as possible by default? A simple system prompt for it to always check the code after task completion for proper simplifications, abstractions and cleanups before returning to the user? Instructions to retain "story like" readability of the code.by ajwin
- Clearly the first step of slopbench2 should be to have the agent first write its own harness!by lostdog
- I agree this is an option, and the next thing on my radar is to try with a more realistic "factory-shaped" harness where you have feedback from linters and other models after each coding episode that refines the architecture.
For readability specifically, I've found it hard to get the models to do this with prompting. If you've talked to opus/fable for a long time on prose writing you probably felt this too
by dhorthy - At least for Claude Code, putting "run /simplify at the end" in an "implement the plan" skill helps a little. It still often leaves new code in bizarre places, and/or with bad/alien-sounding names and comments.by igregoryca
- Did you not benchmark latest GPT 5.6 or GLM 5.1/Kimi K3 because of cost? I can run them if you share how you ran them
- no i'm spinning those up at some point this week. here's the first few prompts I used (claude opus 5 as the research orchestrator), (these were interspersed with lots of tools and assistant messages but it should get you kicked off.
> fetch this article for slopcodebench and help me run an eval on a subset of problems with opus 5 https://arxiv.org/html/2603.24755v1 > Get all the context, fetch any mentioned repos, and then propose a plan to me.
> i have an anthropic API key in .... > Let's do the three challenges with Opus 4.8 and Opus 5 and Fable please. I like your minimal set. Let's try it. What do you need from me?
> Actually I changed my mind. I want to do two of the easy ones you picked and then I want you to pick the one with more checkpoints, maybe one of the harder ones, not the very hardest one but one with a higher number of checkpoints.
> Actually let's do one easy, one medium, and one hard problem please. If we have a hard problem I'd like to see that.
> lets rock - i think lets just do opus 4.8 and sonnet 5 and opus 5 since we our ZDR will block fable
by dhorthy - Great writeup. The excessive function thing has always driven me crazy; I guard against this explicitly in Claude.md.
I have found that models are generally poor at managing refactors / complexity while also implementing new features. But I’ve had some success with a semi-lights-off approach where you decompose it and prompt the model adversarially in a second pass to look for new rough edges and areas of complexity or refactors that might simplify the codebase.
So I’d be very curious to see this benchmark but with something like a periodic “refactor turn” interleaved in.
Also eager to see Fable benchmarked; anecdotally that was the only model whose code I felt I could actually trust to not review closely.
by piazz - I always have Claude recite a pledge before starting coding to fix redundant code it notices over time. It does seem to find redundancies, but only when I point out bugs, that's when it goes into fixing mode and actually applies my Don't Repeat Yourself preference from the CLAUDE.md.
The original paper cited by this post does try to see if improved prompting will make a big difference in the end using a `plan_first` prompt variant, but find no influence on pass rate at the end of the benchmark. The `plan_first` seems to assume coding agents will just refactor once they finish features, but I don't think they tend to refactor significantly unless they are told to fix bugs rather than build features. The benchmark leaves tests hidden with no fail-to-pass feedback, so that may be why degradation is monotonic.
by dmrivers - This is just superstition.by try-working
- This is nice, but would be really useful measured against human performance, and yes - I understand that is likely a difficult challenge.
Many people though are going to read the headline figures and think it means - say - Opus 5 is only a quarter the strength of a human coder.
by mellosouls - I'd be curious to see the raw test results.
I have a suspicion that most models will miss the `database_migration` Checkpoint 2 test that includes a `default_value` because it could be interpreted as either a JSON-literal or a SQL-expression.
There might be other tests as well that are prone to failure for reasons other than the reasons cited in the paper.
I think a cool experiment would be to adjust the order of the features implemented (e.g. checkpoint 3 then 2 then 5 then 4) where dependencies allow it. Then one could account for some checkpoints being more difficult than others.
by 4by4by4 - oh i really like the idea of flipping around the order of checkpoints and comparing results. Could be an interesting way to increase/decrease difficulty even
i will look into how easy it would be to zip up some subset of the results without leaking anything...probably doable
by dhorthy - The author of the original paper did not include error bars on the cost and quality results, which is a bit alarming. They did include a +/-, but did not list explicitly if that means standard deviation, range, or 95% CI, etc. Another table is listed as that being one standard deviation. If we take those results to be a standard deviation as well, I think we can conclude that there is no statistical difference between the outcomes of all models in terms of quality and cost, as the error bars are all overlapping.by jrflo
- I haven't joined your chats in a while but glad to see you put this together, I truly feel as though opus 5 is not much of an improvement. The only time i ever felt a wow factor was opus 4, 4.6 and fable pre trump admin lobotimizingby Johnny_Bonk
- yeah this was just a start - the fastest cheapest thing we could try for a brand new model.
I'm hoping to do some more work with sol/fable in the mix as well as exploring more languages and curating the problem set to include more of the benchmark
I also kinda felt like opus4.5 was dumber than 4.1 personally, maybe a little biased since 4.5 was 2.5x faster and 2.5x cheaper seems to indicate its a smaller model
by dhorthy - This matches my experience of Opus 5 being a nice improvement over Opus 4.8, but not being revolutionary like Fable felt.
I’ve now replaced my use of Opus 4.8 xhigh with Opus 5 medium, and I’m using less tokens and it’s quicker. I can understand people being annoyed by its writing style but for getting work done that really doesn’t bother me. I’ve been really enjoying using it.
by sothatsit - Medium vs High? Why? From all the charts I've seen the performance jump is pretty large from med -> high (not as noticeable from high -> xhigh).by fastball
- Can you elaborate on what felt revolutionary to you about Fable?by Balinares
- I think they neutered Fable. When it first came out it was indeed revolutionary. But what we have today, is not what we had before the ban.by rubicon33
- Nice! I actually ran across this paper+benchmark recently, too. It's the first I've found that start to aim at some of the non-functional and longitudinal requirements that I think have always been an important part of writing production code.
It's especially relevant now that models are good enough to solve ~most point-in-time problems.
Some relevant but disconnected thoughts:
- deterministic scores are so nice
- what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is
- another signal I've been thinking about and I'm seeing increasingly get brought up is the state space of a system; I'm seeing formal methods pop up a lot recently
by Vgoose - > what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is
Maybe, but "maintainable" has a simple definition: minimising the effort to incrementally grow a software system as its size grows to infinity (while maintaining some defect ratio). Humans (called senior software engineers) figure this out over decades by working on a number of large software systems.
So far models haven't figured the same thing out. I can only guess why. All their learning comes from examining code on the internet. Somehow whatever the patterns are that make large software projects like the OSs maintainable by large groups of people working independently has escaped them. Maybe the bulk of code they look at is in the small so they miss it, maybe the patterns are just hard to discern in big systems.
My theory is there are anti-patterns which the larger projects somehow manage to keep to a minimum. It's hard to learn something that's not there. Instead, you learn these anti-patterns by doing them, and watching a system all fall apart over the course of years, and if you're good you manage to pin the blame on the right thing.
If you want to wrap it up neatly in a package, models have learnt how to program, but programming is not the same as design. Design requires very different skills to using a programming language. At a very high level, big systems are sets of interconnected modules. The things that matter are narrow APIs with minimal coupling, and where coupling is unavoidable making it explicit and easy to reason about. Concrete examples of the anti-patterns to be avoided are global variables, leaky abstractions and APIs that require complex sequences of interconnected calls.
Those things don't bite hard until you program in the large. The current crop of LLM's seem to be useless at all of them. If you've got a big context window and you are only writing 100s of kloc, a budget of kilowatts to understand the complexity, it doesn't matter. But humans don't have a budget like that, and so far everyone I've seen who reads large chunks of vibe coded software recoils in horror, gives up, and walks away.
Even with that budget, the models fail anyway once the size gets way beyond their context window - it's just that they fail much later than humans. Which I guess makes learning the lesson so much harder - perhaps near impossible as your "they need labeled examples" hints at. Oddly the solution would be to train with smaller context windows (a less powerful model in some ways), so the failures become apparent much earlier.
It looks like they have been going with your solution for now - giving engineers cheap tokens via flat-rate plans, and watching how they do things. I don't think that will work. Engineers who chew through the billions of tokens offered by these plans are vibe coding. The code they produce is so poor it can't cross the threshold from small to large. There is nothing to see there about programming in the large.
:( what a rant - it looks like an LLMs CoT as it thinks through things. Which is what I was doing, I guess.
by rstuart4133 - I’ve been thinking about this too.
There’s this notion of variety popularized by cybernetics folks a long time ago. Variety is like the state space of the system. Then there’s a law that says “only variety absorbs variety”.
So if a method has high variety then it must have an equally complex implementation to handle the variety.
When there is a mismatch it means that either the method has parameters that aren’t useful, or that the body of the method isn’t covering cases it should.
https://fffej.substack.com/p/only-variety-can-absorb-variety was my attempt to write it up more fully.
by jefffoster - > - what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is
this is a nicely succinct way to put this - a multi-dimensional space where no single metric is really useful
state space of the system is interesting too. I would guess that for any production software with dependencies like databases/third parties that might be too hard to measure, but if you can silo off parts of your system into bounded state machines, it may be a value metric on some module behind a clean interface.
I think the kubernetes control loop model is a great instance of this, a handful of scoped components that own a control loop across a well-defined state machine, that can operate / recover in the face of most network partitions or downtime - the promise of CRDTs but rather more a pragmatic approach to it
by dhorthy - > another signal I've been thinking about and I'm seeing increasingly get brought up is the state space of a system
State space of a system AND the way to make it accessible / visible to a model. Many times a model can work magic if it can "see" the state of a system in a way that suits it. That's why sometimes having a cli added to the environment seems like such a big unlock. Because that cli usually takes a complex state and allows visibility into it, and possible manipulation in a structured way.
- I hope the big labs will start using this benchmark in their RL pipelines. Reducing complexity in generated code should be the number 1 priority, in my opinion. The holy grail for me is models implementing features while reducing LoC (i.e., choosing the right abstractions).
What is also nice about this benchmark is that it can be used to iterate on prompts/skills for reducing code complexity.
by WilcoKruijer - I would at least consider the possibility that they already are, and this is how it is going. It could be a fundamental architecture problem for LLMs. It's not like "slop" is a new problem and I'm sure they'd love to announce a new model that generates much less "slop". The fact they've never so much as mentioned it suggests to me that it's not something they've been able to fix.by jerf
- > I hope the big labs will start using this benchmark in their RL pipelines.
Labs do not train on benchmark data (allegedly). They can train on similar problems, but benchmarks have specific strings in them that labs are supposed to be aggressive in filtering out of their training corpora.
by stbenjam - It's just as easy to go too far in the direction of shoving too much logic on a single line in the name of reducing lines of code.
- I call out specifically in my agent/claude file that I want and prefer simpler solutions over complex enterprise pattern usage and overuse of abstractions. It tends to help a bit, but often I have to give feedback in my review step.
My typical workflow when AI assisted is what I call human gatekeeping... I'll plan out next steps with the agent, updating a TODO.md file with what needs to be done, then a fresh context to implement the next step(s), and review the code before committing to git. I may iterate/stash or even reset a few times before it's "good enough"... it is rarely close to what I would do myself, but often as good as what I've gotten from other developers IRL on projects.
This includes updating the documentation area(s) of a project as well as testing. I also tend to lean on ./run/* for scripts that will run/test various portions of the project... getting the agent to use these is sometimes harder than it should be, as I want it to specifically exercise a lot of things through the process... there are also times where it will try to change a valid test that's failing instead of fixing the code. That's the most irritating part. Some models are annoying, some feel like pure magic at times.
by tracker1 - SCB is definitely an underrated benchmark. For me the unique selling point is that it more closely mirrors software development by not stopping after a single task. The agent has to keep code clean. The only disadvantage is all the problems are greenfield and not git inited so the agents don’t make use of git diffs.
I’ve used SCB as part of my assessment of agent skills (superpowers, GSD etc) https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
There is a small but growing community on discord for discussing SCB so if interested please join https://discord.gg/BrC4BA9sVj
by robbomacrae