Slop is code that you can't effectively work with
">
🌙Dark
Slop is code<br>you can't work with
A working definition of slop, and what to do when you hit the slop wall.
By Gareth Dwyer · May 2026
People use the term 'slop' more and more. Originally, this was mainly for content like blog articles, but now it's often used for codebases too.
Like 'vibe coding', everyone has a slightly different definition of what it means.
Is all AI-generated code slop? Can human-written code be slop? Is it slop if it works?
I think it's fine for everyone to have their own definition of slop. After all, one man's slop is another man's $1M ARR business as the famous saying goes.
But shared definitions are also useful, so if I call something slop I probably mean something like
A (usually) LLM-generated codebase that no person or LLM understands well enough to work with effectively. Adding features takes more time and more tokens than you would expect. Fixing bugs takes more time and tokens than you would expect. Fixing bugs or adding features frequently introduces more bugs, and often ones that you wouldn't expect.
I put "usually" in brackets because I think the concept is useful for non-AI-generated code too. I really like this description of how hard it is to work on the 25 million lines of C that make up the Oracle Database, for example. While agents have made slop a lot more prevalent, I'm not convinced that how the slop came to be is a useful distinction.
It's not an objective definition. You can't look at a codebase, run some analysis tools, and decide if it's slop or not, but usually after trying to work with any given codebase it doesn't take me long to assign my own personal 'slop' label to it.
It's also based around expectation, and I think that's the bit that makes the LLM-generated part more important. If you want to add a feature to the 25-million-line Oracle database you know it's going to take a long time, and you can plan accordingly. But when you're working with slop, you can't plan because things break in places that you're not expecting.
'Perplexity' is an overloaded term in ML and AI, but it's the word I often think of when evaluating whether something is slop. How perplexed am I, and how often?
WTFs per minute while vibe coding
I like the idea that the only valid measure of code quality is WTFs per minute.
I don't think that's literally true, but I do think it's a useful heuristic.
It's also something I notice while vibe coding. The WTFs per minute aren't from reading the code, but from reading agent output while it works with the code.
Most people who have used LLMs to code are probably familiar with a pattern of going from a prototype to slop. You have an idea and you decide to see if the agents can build it. You start from a blank slate and your agent makes incredibly fast progress at the start. Within a few hours, you have a working prototype of a system that would have taken you days (or years) to code in the pre-LLM days.
You get to the 80% mark and you're already thinking about all the things you can do with this system that you've just conjured into existence while you polish out the few remaining issues.
Then, suddenly, it's 3 days later and you've gotten to 82%.
At some point, you're not sure exactly when, you hit the slop wall.
You just pushed out 8 features that you thought were 'medium complex' in 15 minutes, so you quickly line up another 8. The first one you think is 'easy'. You expect the agent to bash it out in 2 minutes and you barely look at the output while reaching for the next one to start working on.
And then you notice something strange. The agent hasn't actually completed yet. The token count is still spinning, you're up to 5 minutes. What is this thing doing?
You interrupt it to have a conversation but you don't understand what it's saying. You ask it to simplify, and it still makes no sense. You're up to 6 WTFs per minute and rising.
Eventually you let it continue. You just want to get this thing out the door so you can move on to the next one, which is more important anyway.
The agent did some big refactoring thing, so you decide to try to preview your Trello clone or whatever super unique and creative project you're working on, and it crashes.
Noticing that something is slop can be gradual
Because part of what makes a codebase slop is breaking expectations, it's hard to say exactly at which point a codebase becomes slop. Sometimes surprises are just a normal part of software engineering. And sometimes you can have an unlucky streak and find five or six surprising negative things in a row.
But by the time it becomes the default and you're not even that surprised anymore when the agent can't do something that "should be easy", then you know you're working with slop.
Slop can be surprisingly good when used as a spec
Engineers famously want to rewrite things, and it's famously almost always a bad idea. But now the calculus has changed! If it...