[adamtaylor_13]

I may be crucified for asking this but: is there any proof that slop matters beyond our sensibilities as developers?

If the code is ugly, but defects are low—does it matter?

If the code is hard to read, but clients are happy—should I care?

Genuinely asking. Weird times we live in.

[bodeadly]

Like anything in coding, it depends. LLMs are good at following conventions. If what you're doing has been done a 1000 times before and there is a good bias, it will produce good results. This is why LLMs are so good at the leafy parts and even the branches the leaves are connected to. But there's always something unconventional about a codebase. If there weren't, it wouldn't be worth writing.

[jdm2212]

It's the eternal question with any kind of tech debt -- is it worth a little more velocity now in return for medium-to-long term slowdown? And there's no general right answer.

[dhorthy]

agree, i think the implication is that low quality code is harder to change in the future

[paffdragon]

> is there any proof that slop matters beyond our sensibilities as developers?

I've seen a few papers recently on the topic in terms of LLM, here is two I found by quick googling

* "Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study" https://arxiv.org/abs/2605.20049

"Our findings suggest that traditional maintainability principles remain highly relevant in the era of AI-driven development, shaping the computational cost and navigational efficiency of coding agents."

* "Code for Machines, Not Just Humans: Quantifying AI-Friendliness with Code Health Metrics" https://arxiv.org/abs/2601.02200

"Our findings confirm that human-friendly code is also more compatible with AI tooling."

"Investing in maintainability not only helps humans; it also prepares for large-scale AI adoption."

> If the code is ugly, but defects are low—does it matter? > If the code is hard to read, but clients are happy—should I care?

For you who wrote it and are the sole developer, maybe not. But if you want to have other contributors or hand it off, then it can be a problem. New devs joining the project may not want to work with it and will push for a rewrite that will cost money or need to spend extra time on working with code that is hard to work with for them which will cost money. And from the papers above it seems this also affects LLMs as well as they seem to work more efficiently with "cleaner" code.

[Majromax]

> I may be crucified for asking this but: is there any proof that slop matters beyond our sensibilities as developers?

That's precisely what this benchmark tries to quantify. Since the benchmark incrementally expands the scope of each problem, 'sloppy' code is code that is hard to later modify.

I know this firsthand: the dumbest coder I've ever worked with was 'myself six months ago'. That jackass never keeps the documentation up to date and hard-codes things that ought to be exposed as configuration.

The SlopCodeBench is an important but early-stage probe in this direction.