HackerPapers

arXiv:2603.24755cs.SE

SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks

Gabriel Orlanski, Devjeet Roy, Alexander Yun, Changho Shin, Alex Gu, Albert Ge, Dyah Adila, Nicholas Roberts, Frederic Sala, Aws Albarghouthi

Abstract

Software development is iterative, yet agentic coding benchmarks hide design issues through their single-shot setup. Recent iterative benchmarks attempt to remedy this but heavily constrain an agent's design decision space, making it impossible to faithfully measure how their decisions shape future extensions. We introduce SlopCodeBench, a benchmark of 36 problems and 196 checkpoints where agents repeatedly extend their own solutions. Unlike prior iterative benchmarks, our evolving specifications demand architectural decisions but leave internal structure to the agent. We measure two forms of degradation: structural erosion (concentrated complexity) and verbosity (redundant code). Evaluating 15 coding agents across open and closed models, we find that no agent fully solves any problem end-to-end, and the best agent passes 14.8% of checkpoints. Quality degrades across checkpoints, with structural erosion rising in 77% of trajectories and verbosity in 75.5%. Compared to 473 open-source Python repositories, agent code is 2.3x more verbose and 2.0x more eroded, and the human repositories degrade less often and by smaller margins across their git histories. Explicit quality guidance reduces initial verbosity and erosion by up to a third, without affecting degradation rates. SlopCodeBench provides the first measurement of code degradation under iterative extension, revealing that agents pass checkpoints while producing code that erodes and bloats with each turn.

arXiv comments
Code and Leaderboards are located at https://www.scbench.ai
Journal reference
DOI
doi:10.5281/zenodo.18405900,
Subjects
cs.SESoftware Engineering cs.AIArtificial Intelligence cs.CLComputation and Language

On Hacker News

Linked by 7 identifiable commenters in 8 comments across 7 threads, from Mar 2026 to Jul 2026. Found in 3 HN submissions from Mar 2026 to Jul 2026. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments7 threads

    • 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…

      dhorthyView on HNParent context

    • For most of these benchmarks, I feel like a p50 and p95 (using SWE salary as a proxy?) human benchmark as reference would be interesting. Edit: FWIW the paper the post quoted has repositories as slop baseline https://arxiv.org/html/2603.24755v1#S4.SS2

      weiliddatView on HNParent context

    • Actually, this paper shows that the LLMs create a lot more slop and degradation of the code after the first prompt. https://arxiv.org/html/2603.24755v1. So iterating with the LLM will simply make it to produce worse and worse code.

      djx22View on HNParent context

    • Our initial suggestion was to do something along the lines of your proposal. But we found that when we ask an agent to implement features for `t-n`^th PR, even when we are overly specific makes the code rather divergent, to the point that sometimes the `t-n+1`th task description…

      geraltofriviaView on HNParent context

  1. Googlebook 1 comment
    • What feels already like old history is that Apple made a generous deal to OpenAI based on the premise that their AI could do the claims. Apple engineers spend months trying to prompt engineer their way, thinking the prompter is at fault if the soon to be AGI system diverged.…

      hirako2000View on HNParent context

    • These links were previously submitted to HN without much traction: Research Paper — https://arxiv.org/abs/2603.24755 SlopCodeBench — https://www.scbench.ai/ And of course, the XCancel version of this post: https://xcancel.com/godofprompt/status/2038335755995750758

      kaygeView on HNParent context

    • This is the dumbest take there is about vibe coding. Claiming that managing complexity in a codebase doesn't matter anymore. I can't imagine that a competent engineer would come to the conclusion that managing complexity doesn't matter anymore. There is actually some evidence…

      FiberBundleView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.