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

1. Het Probleem

Huidige benchmarks voor coderende AI-agenten (zoals SWE-bench) evalueren voornamelijk single-shot oplossingen: een agent krijgt een volledige specificatie en moet één keer correcte code genereren die door een testsuite gaat. Dit benadert softwareontwikkeling als een eenmalige gebeurtenis, terwijl softwareontwikkeling in de praktijk iteratief is.

Het paper identificeert een kritiek gat in de huidige evaluatie:

• Code kan een testsuite passeren, maar door gebrek aan goede architecturale keuzes in de vroege fasen, wordt de code steeds moeilijker uit te breiden bij latere specificaties.
• Bij herhaaldelijke bewerkingen door LLM's (Large Language Models) neigen agenten naar vervelende patronen: ze genereren verbaal overbodige code ("slop") en bouwen complexe logica op in bestaande functies in plaats van nieuwe, gestructureerde modules te maken.
• Bestaande iteratieve benchmarks falen vaak omdat ze de agent te veel structuur voorschrijven, de testsuite laten lekken (wat architecturale hints geeft), of de agent laten bouwen op "gouden" menselijke code in plaats van op zijn eigen eerdere fouten.

2. Methodologie: SlopCodeBench

De auteurs introduceren SlopCodeBench (SCBench), een taal-agnostische benchmark bestaande uit 20 problemen en 93 checkpoints.

Ontwerpprincipes:

1. Geen voorgeschreven interne interfaces: De agent moet alleen de externe contracten (CLI of API) volgen. De interne architectuur is vrij, waardoor de agent de volledige verantwoordelijkheid draagt voor ontwerpbeslissingen.
2. Verborgen testsuite: De agent ziet alleen de specificatie en voorbeelden, nooit de daadwerkelijke tests. Dit voorkomt dat de agent "leert" voor de tests in plaats van voor de specificatie.
3. Zelf-uitbreiding: De agent begint bij een lege werkplek en moet bij elke checkpoint zijn eigen eerdere code aanpassen en uitbreiden. Slechte architecturale keuzes in checkpoint 1 worden de basis voor checkpoint 2, waardoor de cumulatieve kosten van slecht ontwerp zichtbaar worden.
4. Zwartkoker-problemen: Problemen zijn taal-agnostisch ontworpen (in dit paper gefocust op Python), waarbij alleen de waarneembare gedragingen worden gespecificeerd.

Voorbeeld: Het code_search-probleem begint met zoeken in Python-bestanden. Later checkpoints vereisen ondersteuning voor JavaScript en C++, daarna AST-gebaseerde patronen, en uiteindelijk meer talen. Een agent die in checkpoint 1 taal-specifieke logica hardcodeert, faalt bij checkpoint 2 en vereist een volledige herschrijving.

Kwaliteitsmetrieken:
Naast correctheid (pass rate) meten de auteurs twee traject-niveau signalen:

• Verbosity (Verbaalheid): Het aandeel redundantie of gedupliceerde code. Gemeten via AST-Grep regels voor typische LLM-inefficiënties en clone-ratio's.
• Structural Erosion (Structurele Erosie): De concentratie van complexiteit in reeds complexe functies. Dit wordt berekend als het aandeel van de totale "complexiteitsmassa" (cyclomatic complexity × √SLOC) dat zich bevindt in functies met een hoge complexiteit (>10). Dit meet hoe code "instort" in enkele gigantische functies in plaats van modulair te blijven.

3. Belangrijkste Resultaten

De benchmark werd uitgevoerd op 11 verschillende modellen (waaronder GPT-5-varianten, Claude Sonnet/Opus, en GLM).

• Algehele Falen: Geen enkel agent loste een enkel probleem volledig op tot het einde (end-to-end). De hoogste "strict solve rate" (alle tests, inclusief regressie, doorlopen) was slechts 17,2% (Opus 4.6).
• Kwaliteitsdegradatie:
  • Erosie nam toe in 80% van de trajecten.
  • Verbaalheid nam toe in 89,8% van de trajecten.
  • De complexiteit van functies explodeerde: het gemiddelde aantal functies met hoge complexiteit steeg van 4,1 naar 37,0, en de maximale cyclomatic complexity steeg van 27,1 naar 68,2.
• Vergelijking met Menselijke Code:
  • Agent-code is 2,2x meer verbaal dan code uit 48 onderhouden menselijke Python-repositories.
  • Menselijke code blijft over de tijd relatief stabiel (vlakke lijn), terwijl agent-code bij elke iteratie verslechtert.
  • Menselijke repositories tonen slechts in 55% van de gevallen toenemende erosie, terwijl dit bij agenten 79% is.
• Kosten vs. Correctheid: De kosten per checkpoint stegen met een factor 2,9 naarmate het probleem vorderde, maar dit leidde niet tot betere correctheid.
• Prompt Interventie: Het gebruik van prompts die "anti-slop" gedrag eisen (bijv. "plan eerst", "vermijd over-engineering") verbeterde de initieel kwaliteit (lagere intercept), maar stopte de degradatie niet. De helling van de verslechtering bleef hetzelfde; de agent begon gewoon op een lagere, maar toch dalende lijn.

4. Bijdragen

1. SlopCodeBench: Een nieuwe benchmark die specifiek is ontworpen om de degradatie van codekwaliteit tijdens iteratieve taken te meten, in plaats van alleen de eindresultaten.
2. Nieuwe Metrieken: Introductie van Verbosity en Structural Erosion als kwantitatieve maatstaven voor "slop" en architecturale instorting.
3. Empirisch Bewijs: Het aantonen dat huidige state-of-the-art agenten systematisch falen in langdurige iteratieve taken en dat hun code fundamenteel verschilt van menselijk onderhouden code.
4. Beperking van Prompt Engineering: Het bewijs dat prompt-interventies alleen de startpositie verbeteren, maar de onderliggende dynamiek van degradatie niet kunnen stoppen.

5. Betekenis en Conclusie

De paper concludeert dat pass-rate benchmarks systematisch onderschatten hoe robuust code is voor uitbreiding. Het feit dat code tests kan doorlopen, betekent niet dat het goed ontworpen is voor toekomstige wijzigingen.

• Architecturale Discipline: Huidige agenten missen de discipline die nodig is voor iteratieve softwareontwikkeling. Ze kiezen voor lokale optimalisaties (code die nu werkt) ten koste van langetermijnonderhoud.
• Toekomstige Richting: Het probleem is niet op te lossen met alleen betere prompts. Er zijn ingrepen nodig op het niveau van training of tooling die agenten dwingen tot structurele discipline over meerdere checkpoints heen.
• Impact: Dit onderzoek waarschuwt voor het vertrouwen op AI-agenten voor complexe, langdurige softwareprojecten zonder menselijk toezicht op architecturale integriteit, aangezien de code na verloop van tijd onbeheersbaar ("slop") wordt.