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

Paper: arXiv:2603.24755 Code: SprocketLab/slop-code-bench Code reference: main @ 08092249 (2026-05-11)

1. Motivation (研究动机)

现有 coding-agent benchmark 的核心盲点是：它们多半把软件开发压缩成一次性提交。SWE-Bench、ProjDevBench、Vibe-code 类评测能回答“当前 spec 是否通过测试”，但很难回答“这份代码在未来需求变化时是否还能被继续扩展”。真实软件开发恰恰不是一次性任务：早期抽象、模块边界、数据结构和错误处理方式会在后续需求中不断被复用或拖累。

这篇论文要解决的具体问题是：如何评估 coding agents 在长程、迭代、需求逐步展开的任务中，是否会把自己的代码越改越难维护。作者把这个问题命名为 “slop” 的累积：代码仍可能在某些 checkpoint 通过测试，但内部结构变得更臃肿、更集中、更难继续演化。论文当前 arXiv 版本使用的是 36 个 hand-written problems / 196 个 checkpoints；这比早期索引页中常见的 20/93 规模更大。

这个问题值得研究，因为部署 coding agents 的风险不只在“第一次是否写对”，更在“代理是否会在后续变更中锁死自己的设计空间”。如果 benchmark 只看最终 pass/fail，就会低估两类真实维护成本：一是 correctness cascade（早期错误导致后续 regression 全部失败），二是 quality drift（代码通过当前测试但复杂度和冗余持续升高）。SCBench 的目标是把这两个成本显式暴露出来。

2. Idea (核心思想)

核心洞察是：要测 agent 的软件工程能力，必须让它在隐藏测试、黑盒外部接口、无内部结构提示的条件下，持续修改“自己上一轮写出的代码”。只有这样，早期架构选择才会真实地影响后续修改难度，而不是被参考解或重置工作区抹掉。

SlopCodeBench 的关键创新不是再造一个单轮 coding task 集合，而是把每个 problem 写成一条 checkpoint trajectory：每个 checkpoint 只给新 spec 和已有 workspace，测试隐藏，agent 不能看到之前对话，只能从当前代码结构理解如何扩展。除了 correctness，论文还定义两个 trajectory-level quality metrics：Structural Erosion 衡量复杂度是否集中到高复杂函数，Verbosity 衡量 AST-Grep 反模式和 clone lines 覆盖了多少代码。

它和 CodeFlowBench / MaintainCoder / EvoCLAW 等 iterative benchmark 的根本差异在于约束强度：这些工作往往规定更具体的接口、补丁位置或演化轨迹，而 SCBench 只规定 CLI/API 的 observable behavior。也就是说，它刻意不告诉 agent 应该如何组织内部模块，从而把“是否做出可扩展架构选择”变成被测信号本身。

3. Method (方法)

3.1 Overall framework: checkpoint trajectory 而不是单轮任务

Figure 1 解读：图中橙色 spec 表示每轮新增需求，灰色 evaluator 表示 correctness / erosion / verbosity 都在 agent 外部计算且不反馈给 agent。关键点是 workspace 沿 checkpoint 传递：如果 $C_{1}$ 为了快速通过测试写了局部 hard-code，那么 $C_{2}, \dots, C_{n}$ 都必须继承这个结构。图中 correctness 从 $1.00$ 掉到 $0.10$ 、erosion 和 verbosity 上升，表达的不是单点失败，而是“可维护性债务在迭代中复利增长”。

形式化地，每个 problem $P$ 是 checkpoint 序列 $[C_{1}, \dots, C_{n}]$ 。在第 $i$ 轮，agent $π_{θ}$ 只接收当前 spec $x_{i}$ 和上一轮 workspace $y_{i - 1}$ ，输出新 workspace $y_{i}$ ： $y_{1} y_{2} y_{i} = π_{θ} (x_{1}, y_{0}), = π_{θ} (x_{2}, y_{1}), \dots = π_{θ} (x_{i}, y_{i - 1}) .$ 这里 $y_{0}$ 是空 workspace。SCBench 刻意不把 prior conversation 交给 agent；agent 必须从代码本身恢复设计意图。这一点很重要：如果每轮都给完整历史对话，benchmark 测到的可能是上下文记忆；如果每轮都替换成 reference solution，benchmark 又会消除早期坏设计的因果链。

3.2 Problem design: 三条约束保证测到架构选择

SCBench 的 36 个问题都是手写或受真实开源项目启发，覆盖 196 个 checkpoints。每个 problem 都遵守三条设计原则：

No prescribed internal interfaces：只给 CLI 参数或 API I/O，不规定内部类、函数或模块边界。
No visible test suite：agent 只看 spec prose 和示例，不能看到测试，也不能根据测试错误修补。
Black-box language-agnostic design：spec 只约束 observable behavior；论文因成本只评估 Python track，但 problem 本身按语言无关方式设计。

论文用 code_search 作为 running example： $C_{1}$ 要求 Python 文件 exact/regex matching； $C_{2}$ 加 JavaScript/C++； $C_{3}$ 加 AST pattern 与 metavariable capture； $C_{4}$ 加 selector 和 auto-fix； $C_{5}$ 加 Go/Rust/Java。一个在 $C_{1}$ hard-code Python regex 的解法，到 $C_{2}$ 和 $C_{5}$ 会面对级联重写；一个提前抽象 parser/language adapter 的解法则更容易扩展。

问题构建采用 proposal + validation 两阶段。作者先提出 problem 和 checkpoint partition，剔除不能有效测试设计决策、或 frontier agents 单轮就能解决的问题；再写初始 test suite，实际跑 agent 来发现歧义 spec 和 underspecified cases，最后确认每个 problem 原则上可解、测试与 spec 对齐。

3.3 Correctness metrics: strict / isolated / core / partial

每个 checkpoint 的测试只通过 subprocess 或 served API 与解交互，并在必要时标准化 key ordering、大小写、match span sorting 等非本质差异。测试被分为四类：

Core：spec 明确写出或示例展示的功能。
Error：failure-mode behavior。
Functionality：隐藏测试，覆盖更完整的正确性。
Regression：之前 checkpoints 的测试； $C_{1}$ 没有 regression tests。

Strict correctness 要求当前 workspace $y_{i}$ 通过全部测试。ISO correctness 只看当前 checkpoint 的 non-regression tests，用来避免早期错误把后续能力完全遮蔽。CORE correctness 只看 core tests。Partial solved 表示一个 problem 中至少有一个 checkpoint strict solved。若 agent 中途崩溃，剩余 checkpoints 的 correctness 记为 0；quality metrics 只在实际产出 workspace 的 checkpoints 上计算。

3.4 Structural Erosion: 复杂度质量是否集中到坏函数

Structural erosion 针对的是 agent 倾向于把新逻辑继续塞进已有大函数，而不是拆分成聚焦的 callables。论文先定义每个 callable $f$ 的 complexity mass： $mass (f) = CC (f) \times SLOC (f) .$ 其中 $CC (f)$ 是 cyclomatic complexity， $SLOC (f)$ 是 source lines of code。使用 $SLOC$ 是为了让函数大小有影响，但不让纯 LOC 压过 control-flow complexity。Erosion 定义为高复杂函数（CC > 10）占据的总 mass 比例： $Erosion = \frac{\sum _{f \in F} I [ CC ( f ) > 10 ] \cdot mass ( f )}{\sum _{f \in F} mass ( f )} .$ 直觉上，如果一个 codebase 的所有复杂性都集中在一个不断膨胀的 main() 或 dispatch function 中，后续需求就更容易触发连锁修改；如果复杂性被合理分散在小模块中，总 CC 可能不低，但 erosion 会低很多。

3.5 Verbosity: 静态反模式 + 结构重复的 union coverage

Verbosity 衡量的是“代码行数很多但信息密度低”的 slop。论文把它分成两部分：137 条 AST-Grep rules 标记浪费性模式（多余 defensive checks、一次性变量、trivial wrappers、重嵌套、if/else ladders 等），再加 structural clone lines。最终分数是两者 union 覆盖 LOC 的比例： $Verbosity = \frac{∣ { AST-Grep Flagged Lines \cup Clone Lines } ∣}{LOC} .$ 多条 AST-Grep rule 命中同一行时会先去重，因此分数位于 $[0, 1]$ 。这和 erosion 是互补信号：一个解可以很啰嗦但 complexity 分散，也可以整体不长却把复杂度集中在少数高 CC 函数。

3.6 Released code workflow and implementation notes

Code reference: main @ 08092249 (2026-05-11) — pseudocode and mapping based on this commit

公开代码把论文流程拆成三层：slop-code run 负责配置/并发/输出目录；AgentRunner 负责逐 checkpoint 调用 agent 并快照 workspace；PytestRunner 和 metrics modules 负责 correctness 与 quality 计算。下面的 pseudocode 是对 released code 的行为级抽象，不是论文伪代码。

def run_scbench_problem(problem, agent, env, prompt_template, output_dir):
    session = create_agent_session(problem_config=problem, environment_spec=env)
    session.materialize_assets()
    summaries = []
 
    for idx, checkpoint in enumerate(problem.iterate_checkpoint_items()):
        if idx == 0:
            agent.setup(session=session)
        else:
            agent.finish_checkpoint(reset_context=True)
 
        task = render_prompt(
            spec_text=problem.get_checkpoint_spec(checkpoint.name),
            entry_file=env.format_entry_file(problem.entry_file),
            entry_command=env.get_command(problem.entry_file, is_agent_run=True),
            context={"is_continuation": idx > 0},
            prompt_template=prompt_template,
        )
        result = agent.run(task)
        snapshot_dir, diff = session.finish_checkpoint(output_dir / checkpoint.name / "snapshot")
 
        report = run_checkpoint_pytest(
            submission_path=snapshot_dir,
            problem=problem,
            checkpoint=checkpoint,
            env_spec=env,
        )
        quality = measure_snapshot_quality(env.format_entry_file(problem.entry_file), snapshot_dir)
        save_checkpoint_outputs(report, quality, diff, output_dir / checkpoint.name)
        summaries.append((checkpoint.name, report, quality))
 
        if not report.passes_policy(problem.pass_policy):
            break
 
    return summaries

def evaluate_checkpoint_tests(problem, checkpoint, snapshot_dir, env_spec):
    workspace = Session.from_environment_spec(env_spec, base_dir=snapshot_dir).prepare()
    test_files = []
    for name, _ in problem.iterate_checkpoint_items():
        test_files.append(f"test_{name}.py")
        if name == checkpoint.name:
            break
    copy_selected_tests(problem.path / "tests", workspace / ".scbench/tests", test_files)
 
    command = build_pytest_command(
        timeout=checkpoint.timeout,
        reports=[".scbench/pytest-report.json", ".scbench/ctrf-report.json"],
        test_dir=".scbench/tests",
    )
    raw = run_in_container(command, env=env_spec.get_full_env(checkpoint.env))
    tests = parse_pytest_json_or_ctrf(raw)
 
    grouped = {"CORE": [], "ERROR": [], "FUNCTIONALITY": [], "REGRESSION": []}
    for test in tests:
        grouped[determine_group_type(test, current_checkpoint=checkpoint.name)].append(test)
    return CorrectnessResults.from_grouped_tests(grouped)

def compute_quality_for_checkpoint(snapshot_metrics):
    # released repo first consumes scb-check report fields when present
    verbosity = snapshot_metrics.get("verbosity_flagged_loc") / snapshot_metrics["total_loc"]
 
    high_cc_mass, total_mass = 0.0, 0.0
    for symbol in iter_symbols(snapshot_metrics):
        if symbol.type not in {"function", "method"} or symbol.sloc <= 0:
            continue
        mass = symbol.complexity * math.sqrt(symbol.sloc)
        total_mass += mass
        if symbol.complexity > 10:
            high_cc_mass += mass
    erosion = high_cc_mass / total_mass if total_mass else 0.0
    return {"verbosity": verbosity, "erosion": erosion}

def aggregate_run_summary(checkpoints, expected_checkpoints):
    strict = sum(math.isclose(c.strict_pass_rate, 1.0) for c in checkpoints)
    isolated = sum(math.isclose(c.isolated_pass_rate, 1.0) for c in checkpoints)
    core = sum(math.isclose(c.core_pass_rate, 1.0) for c in checkpoints)
    return {
        "strict_pct": 100 * strict / expected_checkpoints,
        "isolated_pct": 100 * isolated / expected_checkpoints,
        "core_pct": 100 * core / expected_checkpoints,
        "verbosity_mean": mean(c.verbosity for c in checkpoints if c.has_workspace),
        "erosion_mean": mean(c.erosion for c in checkpoints if c.has_workspace),
    }

论文公式与 released code 实现差异：论文的 Verbosity 公式明确是 AST-Grep flagged lines 与 clone lines 的去重 union；src/slop_code/metrics/checkpoint/driver.py 的主路径通过 uvx scb-check check --report --include-all 读取 verbosity_flagged_loc，与 union coverage 语义一致。但 src/slop_code/metrics/checkpoint/composites.py 的 fallback 在缺少 verbosity_flagged_pct 时使用 clone_lines/loc + violation_pct，该 fallback 可能双计重叠行；复现实验应优先使用 scb-check report fields。

Paper Concept	Source File	Key Class/Function
CLI entry for runs	`src/slop_code/entrypoints/commands/run_agent.py`	`run_agent`, `_create_task_config`, `_create_checkpoint_results_and_summary`
Multi-problem worker pool	`src/slop_code/entrypoints/problem_runner/driver.py`	`run_problems`, `_run_problems`
Per-problem checkpoint loop	`src/slop_code/agent_runner/runner.py`	`AgentRunner._run_problem`, `AgentRunner._run_checkpoint`, `run_checkpoint`
Prompt rendering and continuation flag	`src/slop_code/agent_runner/runner.py`	`get_task_for_checkpoint`
Docker/session evaluation	`src/slop_code/evaluation/pytest_runner.py`	`PytestRunner.run`, `_copy_tests_from_problem`, `_build_pytest_command`
Test group taxonomy	`src/slop_code/evaluation/report.py`, `src/slop_code/evaluation/pytest_runner.py`	`GroupType`, `_determine_group_type`
Solve-rate aggregation	`src/slop_code/metrics/summary/aggregators.py`	`compute_solve_rates`, `compute_pass_rates_stats`
Erosion mass	`src/slop_code/metrics/checkpoint/mass.py`	`compute_mass_metrics`
Verbosity / scb-check ingestion	`src/slop_code/metrics/checkpoint/driver.py`, `src/slop_code/metrics/checkpoint/extractors.py`	`_get_scb_check_metrics`, `get_checkpoint_metrics`, `get_quality_metrics`
Environment config used in docs/examples	`configs/environments/docker-python3.12-uv.yaml`	Docker image `ghcr.io/astral-sh/uv:python3.12-trixie-slim`, `uv run`, `agent_command: python`
Prompt variants	`configs/prompts/just-solve.jinja`, `configs/prompts/anti_slop.jinja`, `configs/prompts/plan_first.jinja`	baseline / quality-aware prompt interventions

4. Experimental Setup (实验设置)

4.1 Datasets and scale

SCBench main benchmark：36 个 language-agnostic problems，196 个 checkpoints。所有 problem 手写或受热门开源项目启发；当前论文只评估 Python track。
Problem examples：code_search 5 checkpoints，forge 8 checkpoints，meshctl 8 checkpoints，test_translator 8 checkpoints，cfgpipe 6 checkpoints 等。每个 checkpoint 都强调未来会影响架构的设计决策，例如 parser adapter、IR 表示、migration dependency sorting、state schema、API boundary 等。
Human repository panel：473 个 Python repositories，覆盖 hobby（<100 stars）到 major（≥10k stars）项目；每个 repo 最多抽样 30 个 source-modifying commits，总计 13,667 个 commits/checkpoints。
Agent trajectory corpus：结果表中 agent checkpoints 为 2,869 个；SCBench solve-rate 统计以固定 196-checkpoint denominator 计算，缺失 checkpoint 计为 unsolved。

4.2 Compared agents / baselines

主评估覆盖 15 个 model/harness 配置：Opus 4.5、Opus 4.6、Opus 4.7、Sonnet 4.6、GPT 5.2 Codex、GPT 5.3 Codex、GPT 5.3 Spark、GPT 5.4、GPT 5.4 Mini、GPT 5.5、Composer 2、GLM 5.1、Kimi K2.5、Kimi K2.6、MiniMax M2.7。Prompt ablation 使用 just-solve baseline，并对 GPT 5.3 Codex、GPT 5.4、GPT 5.5 加测 anti-slop 与 plan-first。

4.3 Metrics

Strict solve rate：checkpoint 全部测试通过，包括 regression。
ISO solve rate：只看当前 checkpoint 的 non-regression tests，避免早期错误完全遮蔽当前能力。
Core solve rate：只看 spec 明确提到或示例展示的 core tests。
Partial problem solve：一个 problem 中至少一个 checkpoint strict solved。
Erosion / Verbosity：分别按 §3.4 与 §3.5 计算；越高代表代码质量越差。
Cost / time / tokens：报告每 checkpoint 平均美元成本、总成本、每 checkpoint 分钟数，以及 token accounting。

4.4 Evaluation config and harness details

每个 checkpoint 在 fresh Docker container 中运行，non-root user；只有 working directory 在 checkpoints 之间保留。论文说明没有 turn limit 或 cost limit，但每个 run 有 2 小时 wall-clock limit。环境基线安装 problem set 所需语言与共享工具；released repo 的示例环境 configs/environments/docker-python3.12-uv.yaml 使用 ghcr.io/astral-sh/uv:python3.12-trixie-slim、uv run 作为评测命令、python 作为 agent command。

主要 harness/version/reasoning 设置如下：Claude Code 2.0.51/2.1.32/2.1.44/2.1.111（high thinking）；Codex CLI 0.93.0/0.98.0/0.100.0/0.110.0（reasoning effort high）；Cursor CLI 2026.04.13-a9d7fb5（Composer 2，无 reasoning effort）；Kimi CLI 1.37.0（high）。训练配置意义上，本文没有训练新模型；“config” 是评测 harness、prompt template、Docker 环境和 checkpoint/test 组织方式。

5. Experimental Results (实验结果)

5.1 Main solve-rate results: 没有模型完整解决任一 problem

Figure 2 解读：左图按 normalized checkpoint progress 展示 strict / isolated / core 等 pass rate，右图展示每 checkpoint 平均 cost。核心现象是正确率没有随着 agent 花费更多 token/cost 而改善：core 与 isolated 的 gap 从 $2.5 \times$ 扩大到 $5.4 \times$ ，core pass rate 从 $64.6%$ 降到 $35.5%$ ；同时 mean cost per checkpoint 从开头到结尾增长 $2.2 \times$ 。这说明后期任务不是“多花钱就能补救”，而是早期结构债务让后续修改越来越贵。

Model	Strict %	ISO %	Core %	$/CKPT	Erosion	Verbosity
Opus 4.5	9.2	17.3	57.7	2.53±1.57	0.70±0.20	0.43±0.18
Opus 4.6	9.7	20.9	67.3	3.17±2.82	0.75±0.15	0.44±0.19
Opus 4.7	8.2	20.9	65.8	2.17±1.83	0.76±0.17	0.48±0.21
Sonnet 4.6	7.1	16.8	57.7	1.96±1.97	0.75±0.20	0.44±0.19
GPT 5.2 Codex	9.7	21.9	56.1	0.85±0.80	0.73±0.18	0.50±0.16
GPT 5.3 Codex	11.2	26.0	60.7	0.66±0.49	0.64±0.19	0.46±0.18
GPT 5.3 Spark	3.1	8.2	29.1	0.20±0.41	0.68±0.19	0.48±0.16
GPT 5.4	10.7	23.5	62.8	0.72±0.51	0.51±0.19	0.33±0.13
GPT 5.4 Mini	5.1	13.8	53.1	0.45±0.35	0.66±0.17	0.42±0.12
GPT 5.5	14.8	28.1	66.8	1.51±0.81	0.49±0.20	0.32±0.12
Composer 2	6.1	16.3	52.6	0.44±0.44	0.72±0.15	0.45±0.17
GLM 5.1	9.7	13.8	40.3	1.47±1.45	0.71±0.17	0.41±0.18
Kimi K2.5	4.6	9.7	39.8	0.33±0.25	0.72±0.20	0.44±0.20
Kimi K2.6	10.7	18.9	51.0	0.74±0.64	0.76±0.20	0.51±0.22
MiniMax M2.7	2.0	4.1	28.1	0.34±0.23	0.73±0.16	0.47±0.17

最强 strict solve rate 是 GPT 5.5 的 14.8%，isolated 最高也是 GPT 5.5 的 28.1%；core 最高是 Opus 4.6 的 67.3%。正文有一句把最高 core 归给 Opus 4.5，但表格标粗和数值显示应为 Opus 4.6。所有模型都没有完整解决任一 36-problem trajectory。总 token accounting 为 13.18B tokens；按 196 checkpoints 归一化，Composer 2 最低为 0.38B tokens，Kimi K2.6 最高为 1.14B tokens。平均 relative lines changed 从早期 97.4% 降到晚期 29.5%，说明后期 agent 改动越来越少但上下文/cost 越来越高。

5.2 Quality degradation: erosion 和 verbosity 都随迭代累积

Figure 3 解读：图展示六个代表性 frontier models 在 problem progress 上的 erosion / verbosity 轨迹。曲线不是某个模型的局部失败，而是跨 provider 的共同趋势：structural erosion 在 $77%$ 的 trajectories 中上升，verbosity 在 $75.5%$ 的 trajectories 中上升。平均高 CC 函数数量从 $3.6$ 增至 $23.7$ ，mean max CC 从 $27.5$ 增至 $69.0$ ，说明复杂度不是均匀增长，而是越来越集中到已经复杂的函数上。

典型案例是 Opus 4.7 在 forge problem 上的 main()：跨 8 个 checkpoints，CC 约增长 $7 \times$ ，函数长度从 38 行变成 240 行。 $C_{1}$ 的 argparse 调用被后续手写 flag loop 替代，七个 flags 各自拥有重复的 --X val / --X=val 分支，且没有抽出 helper。Verbosity 的细分结果同样支持“重写已有结构”而非“新增少量 rule violation”：structural duplication 增长 96%，AST-Grep violation density 只增长 0.3%。

5.3 Agent vs human repositories: agent degradation 更高且更快

Figure 4 解读：图把 agent checkpoints 与 473 个真实 Python repositories 的 normalized commit trajectories 对比。human panel 的平均 verbosity / erosion 为 0.19 / 0.34，agent checkpoints 为 0.44 / 0.68，分别是人类仓库均值的 $2.3 \times$ 和 $2.0 \times$ 。斜率也更糟：agent verbosity 每 checkpoint 增长 0.0144，人类 median 为 0.0022；agent erosion 增长 0.0264，人类 median 为 0.0053，因此 agent 的 verbosity 累积约快 $6.6 \times$ ，erosion 约快 $5.0 \times$ 。

Group	n	Verbosity	Erosion
Hobby (<100 stars)	114	0.21±0.14	0.33±0.25
Niche (100—1k stars)	124	0.19±0.11	0.32±0.22
Established (1k—10k stars)	120	0.18±0.08	0.33±0.20
Major (≥10k stars)	115	0.19±0.10	0.37±0.19
Human panel (all)	473	0.19±0.11	0.34±0.22
Agent checkpoints	2869	0.44±0.18	0.68±0.20

只有 18/473 个 human repositories 超过 agent verbosity mean。对于 321 个同时有 2024 年前后至少三个 commits 的仓库，post-2024 median 相比 pre-2024 的 within-repo shift 是 verbosity +0.002、erosion +0.014；59% 的仓库 post-2024 更 eroded。作者把这解释为 agent assistance 普及后可能有小幅 slop uptick，但幅度远低于 agent 在单个 checkpoint 中累积的质量恶化。

5.4 Prompt ablation: 更“洁癖”的提示能降低初始 slop，但止不住退化

Figure 5 解读：图比较 baseline just-solve、anti-slop、plan-first 三类 prompts 的 quality trajectory。anti-slop 明确列出要避免的 over-engineering / verbose patterns，plan-first 要求先规划再实现。两者确实压低了 erosion/verbosity 的绝对值，尤其 anti-slop；但曲线仍随 progress 恶化，说明 prompt 更像是降低截距，而不是改变长程退化斜率。

Model	Prompt	Strict	ISO	Core	Erosion	Verbosity	Cost
GPT 5.3 Codex	Just-Solve	11.2	26.0	60.7	0.64	0.46	0.66
GPT 5.3 Codex	Anti-Slop	11.2 (+0.0)	23.5 (-2.6)	57.1 (-3.6)	0.42 (-0.22)	0.31 (-0.15)	0.73 (+0.07)
GPT 5.3 Codex	Plan-First	8.2 (-3.1)	21.4 (-4.6)	62.2 (+1.5)	0.55 (-0.10)	0.40 (-0.06)	0.68 (+0.02)
GPT 5.4	Just-Solve	10.7	23.5	62.8	0.51	0.33	0.72
GPT 5.4	Anti-Slop	9.2 (-1.5)	25.5 (+2.0)	61.2 (-1.5)	0.28 (-0.23)	0.24 (-0.09)	0.90 (+0.18)
GPT 5.4	Plan-First	9.7 (-1.0)	25.0 (+1.5)	63.3 (+0.5)	0.39 (-0.11)	0.30 (-0.02)	0.83 (+0.11)
GPT 5.5	Just-Solve	14.8	28.1	66.8	0.49	0.32	1.51
GPT 5.5	Anti-Slop	9.2 (-5.6)	24.0 (-4.1)	60.7 (-6.1)	0.21 (-0.28)	0.21 (-0.11)	1.55 (+0.04)
GPT 5.5	Plan-First	10.2 (-4.6)	25.0 (-3.1)	66.3 (-0.5)	0.39 (-0.09)	0.27 (-0.04)	1.67 (+0.16)

anti-slop 相比 baseline 的 verbosity 降幅为 GPT 5.4 27.5%、GPT 5.5 35.6%、GPT 5.3 Codex 32.8%；erosion 降幅分别为 45.1%、57.6%、34.3%。但代价是能力和成本：平均 strict performance 对 anti-slop 下降 2.4 pp，对 plan-first 下降 3.6 pp；plan-first 的 core pass rate 平均只提高 0.8 pp；两类 prompt 平均每 checkpoint cost 增加 12.1%。

5.5 Limitations and conclusion

作者明确限制了当前实验范围：虽然 problem design 是 language-agnostic，但因成本只评估 Python track；质量指标是静态近似，不能完全等同于人工 maintainability judgement；prompt intervention 只测试了两类简单策略；human repository panel 只能作为近似对照，因为真实人类 commits 和 agent checkpoints 的任务分布并不完全相同。

总体结论是：长程迭代暴露了单轮 benchmark 看不到的失败模式。当前最强 agent 也只能 strict solve 14.8% checkpoints，没有任何模型完整解决任一 problem；同时 structural erosion 和 verbosity 在多数 trajectories 中上升，且 agent 相比真实仓库更差、更快退化。SCBench 因而更像一个“代码质量压力测试”：它不只问 agent 能不能写出当前能跑的程序，还问这份程序能不能承受下一轮需求。

Paper Notes

探索

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

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

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework: checkpoint trajectory 而不是单轮任务

3.2 Problem design: 三条约束保证测到架构选择

3.3 Correctness metrics: strict / isolated / core / partial

3.4 Structural Erosion: 复杂度质量是否集中到坏函数

3.5 Verbosity: 静态反模式 + 结构重复的 union coverage

3.6 Released code workflow and implementation notes

4. Experimental Setup (实验设置)

4.1 Datasets and scale

4.2 Compared agents / baselines

4.3 Metrics

4.4 Evaluation config and harness details

5. Experimental Results (实验结果)

5.1 Main solve-rate results: 没有模型完整解决任一 problem

5.2 Quality degradation: erosion 和 verbosity 都随迭代累积

5.3 Agent vs human repositories: agent degradation 更高且更快

5.4 Prompt ablation: 更“洁癖”的提示能降低初始 slop，但止不住退化

5.5 Limitations and conclusion

目录