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.
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.
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.