Imo slop debt stops at the source. Sure when you finally get everything working it's a huge pain and the last thing you want to do, but you have to continue working until that pull request is crisp, minimal, and has razor sharp clarity.
Ultimately it has to be well-written, well-engineered code, and LLMs are good at working with you on getting to that state. But when you finally get all the cases working, you have another significant step in getting it to a reviewable, acceptable request. And this means you need to have a quick, understandable, effective test suite.
Any other way and you're going to throw your codebase, product, and culture in the trash bin.
I think the only way out of a fully slop codebase is to basically "Clean-room design" it by encoding all of the desired behaviors of what you build into a spec and then start again from fresh.
I think constrained slopping is kind of ideal in some ways (although thats not what this article is describing). Constrained slopping would be you slop out a request, iterate on behaviors, look at what code/architecture changes were required to get there, then redo the plan with field lessons learned and start that section from scratch again.
This loop is kind of what I'm recommending its just going to have to be everything all at once and not a nice meal sized slice.
Traditionally the answer was rarely rebuild from scratch because the bad code was usually "needed decisions poorly abstracted", but in the slop era bad code may be 60% completely unnecessary code. In that way I foresee many more rebuilds than prior eras.
Sooo… Big Upfront Design then. We already know why that didn’t work; nothing to do with the dev, this didn’t work because the users wants evolve and so code needs to be written to allow for flexible continuous improvement.
No I'm talking about after its already been slopped out. The whole article is centered around what do you do after a big slop mess has already been created. I'm presuming that a decent amount of user wants have been figured out at that point.
This is the reason why I made the decision to quit my job and start my own company, because AI was being shoved down my throat and I couldn’t take it anymore.
I was a tech lead leading a team that was given aggressive deadlines without our input and was measured and evaluated by MR count. My team started vibe coding and put the burden on me (or AI) to do all the reviewing while they sat there telling Claude “ok” all day and making sure tests passed.
The MRs grew to minimum 800 lines, multiple per day per person. No one could explain how it really worked, and it took me 2 hours to read and understand the code, even though AI provided a very long and thorough description with paragraphs of comments everywhere. My brain just wanted to shut off.
When I had any negative feedback or constructive criticism, team members grew worried they would look bad for going any slower than 3x speed, and for any chance of jeopardizing a deadline we didn’t have any input on. There just wasn’t any time for learning or mentorship, and MRs couldn’t be held up for too long. And of course, me spending the entire day reading MRs made my metrics look bad because I wasn’t writing any code.
Eventually I realized that the slop debt was so bad that when it breaks, I wouldn’t be able to explain how any of it worked. And that was my job to do so! We basically wrote two years of tech debt in two months. So I did myself a favor and walked out on my own terms.
Since then, I’ve slowly been reeling back from full agentic programming to doing things by hand. And even if it’s slower, I prefer it 100%. I understand what’s going on. The code follows patterns I can standardize around and has been stripped away of what’s unnecessary, so that I can understand how it works at a glance. Consistent naming, patterns and architecture allow me to reduce the amount of context I have to hold in my working memory.
When I’m verifying slop debt, my brain gets so exhausted, it really isn’t worth the feeling that I’m saving time and not coding anymore in exchange for reviewing slop all day. Even if I make the agent do exactly what I ask, it always does something in a way I don’t want it, so then it’s either me prompting all day to get it just right, or just moving on with something that’s “good enough”. And I’ve found that waiting for a response makes my mind wander and either get more exhausted context switching on another session or stumbling on some form of entertainment that makes me lose the time I would have “saved”.
Ultimately I feel like becoming a code reviewer as my profession is not worth it and just saying “I’ll fix it later if it breaks” is not worth it either. I prefer to have full comprehension of how the system works than to rely on AI to do it for me while the slop debt keeps growing endlessly.
I don't know. We've managed to avoid most of this, I think. We have tech debt, but it feels more like regular tech debt than sloppy engineering practices. What's worked for us:
- Very strict linting, type checking, and so on.
- An opinionated flow of data and clear layers in the codebase.
- Good code review workflows with multiple AI code reviewers, along with a pretty opinionated SDLC.
- Agents that look for duplication and opportunities to simplify.
- Strong opinions about our core data model.
I really think that the companies that are struggling with slop probably struggled with slop before. It just moved slow enough that things could be fixed.
I don't understand this slop debt either. I make lots of small changes, as I did before, alongside self-reviews. This time, the AI puts together the PR and helps with reviews.
> Slop debt comes from a lack of decision. Nobody chose the variable names, the error handling pattern, or the layer of indirection that does nothing.
Ofc people agreed on these things (and avoided the last one) because our teams do proper objective reviews.
> You open a file to fix a bug and find three different retry strategies, two different logging conventions, and a helper function that duplicates a standard library method for no discoverable reason.
Our team literally used AI to remove this duplication. It's very good at it.
> Slop debt resists this because it is everywhere at once, at low intensity. There is no single module you can point to and say, this is where the debt lives. It is smeared evenly across the whole codebase, a little bit of incoherence in every file.
This is pure FUD. Automated consistency will out perform manual consistency at scale and over a long period of time. This is statistically relevant and one of the many things AI is helpful with.
I still don't understand what the "debt" here is supposed to mean and this seems like the same anti-AI hand waving I've been seeing all year. Probably aimed at people who are vibe coding entire projects or modules, I assume.
Imo slop debt stops at the source. Sure when you finally get everything working it's a huge pain and the last thing you want to do, but you have to continue working until that pull request is crisp, minimal, and has razor sharp clarity.
Ultimately it has to be well-written, well-engineered code, and LLMs are good at working with you on getting to that state. But when you finally get all the cases working, you have another significant step in getting it to a reviewable, acceptable request. And this means you need to have a quick, understandable, effective test suite.
Any other way and you're going to throw your codebase, product, and culture in the trash bin.
I think the only way out of a fully slop codebase is to basically "Clean-room design" it by encoding all of the desired behaviors of what you build into a spec and then start again from fresh.
I think constrained slopping is kind of ideal in some ways (although thats not what this article is describing). Constrained slopping would be you slop out a request, iterate on behaviors, look at what code/architecture changes were required to get there, then redo the plan with field lessons learned and start that section from scratch again.
This loop is kind of what I'm recommending its just going to have to be everything all at once and not a nice meal sized slice.
Traditionally the answer was rarely rebuild from scratch because the bad code was usually "needed decisions poorly abstracted", but in the slop era bad code may be 60% completely unnecessary code. In that way I foresee many more rebuilds than prior eras.
Sooo… Big Upfront Design then. We already know why that didn’t work; nothing to do with the dev, this didn’t work because the users wants evolve and so code needs to be written to allow for flexible continuous improvement.
No I'm talking about after its already been slopped out. The whole article is centered around what do you do after a big slop mess has already been created. I'm presuming that a decent amount of user wants have been figured out at that point.
This is the reason why I made the decision to quit my job and start my own company, because AI was being shoved down my throat and I couldn’t take it anymore.
I was a tech lead leading a team that was given aggressive deadlines without our input and was measured and evaluated by MR count. My team started vibe coding and put the burden on me (or AI) to do all the reviewing while they sat there telling Claude “ok” all day and making sure tests passed.
The MRs grew to minimum 800 lines, multiple per day per person. No one could explain how it really worked, and it took me 2 hours to read and understand the code, even though AI provided a very long and thorough description with paragraphs of comments everywhere. My brain just wanted to shut off.
When I had any negative feedback or constructive criticism, team members grew worried they would look bad for going any slower than 3x speed, and for any chance of jeopardizing a deadline we didn’t have any input on. There just wasn’t any time for learning or mentorship, and MRs couldn’t be held up for too long. And of course, me spending the entire day reading MRs made my metrics look bad because I wasn’t writing any code.
Eventually I realized that the slop debt was so bad that when it breaks, I wouldn’t be able to explain how any of it worked. And that was my job to do so! We basically wrote two years of tech debt in two months. So I did myself a favor and walked out on my own terms.
Since then, I’ve slowly been reeling back from full agentic programming to doing things by hand. And even if it’s slower, I prefer it 100%. I understand what’s going on. The code follows patterns I can standardize around and has been stripped away of what’s unnecessary, so that I can understand how it works at a glance. Consistent naming, patterns and architecture allow me to reduce the amount of context I have to hold in my working memory.
When I’m verifying slop debt, my brain gets so exhausted, it really isn’t worth the feeling that I’m saving time and not coding anymore in exchange for reviewing slop all day. Even if I make the agent do exactly what I ask, it always does something in a way I don’t want it, so then it’s either me prompting all day to get it just right, or just moving on with something that’s “good enough”. And I’ve found that waiting for a response makes my mind wander and either get more exhausted context switching on another session or stumbling on some form of entertainment that makes me lose the time I would have “saved”.
Ultimately I feel like becoming a code reviewer as my profession is not worth it and just saying “I’ll fix it later if it breaks” is not worth it either. I prefer to have full comprehension of how the system works than to rely on AI to do it for me while the slop debt keeps growing endlessly.
I don't know. We've managed to avoid most of this, I think. We have tech debt, but it feels more like regular tech debt than sloppy engineering practices. What's worked for us:
- Very strict linting, type checking, and so on.
- An opinionated flow of data and clear layers in the codebase.
- Good code review workflows with multiple AI code reviewers, along with a pretty opinionated SDLC.
- Agents that look for duplication and opportunities to simplify.
- Strong opinions about our core data model.
I really think that the companies that are struggling with slop probably struggled with slop before. It just moved slow enough that things could be fixed.
I don't understand this slop debt either. I make lots of small changes, as I did before, alongside self-reviews. This time, the AI puts together the PR and helps with reviews.
> Slop debt comes from a lack of decision. Nobody chose the variable names, the error handling pattern, or the layer of indirection that does nothing.
Ofc people agreed on these things (and avoided the last one) because our teams do proper objective reviews.
> You open a file to fix a bug and find three different retry strategies, two different logging conventions, and a helper function that duplicates a standard library method for no discoverable reason.
Our team literally used AI to remove this duplication. It's very good at it.
> Slop debt resists this because it is everywhere at once, at low intensity. There is no single module you can point to and say, this is where the debt lives. It is smeared evenly across the whole codebase, a little bit of incoherence in every file.
This is pure FUD. Automated consistency will out perform manual consistency at scale and over a long period of time. This is statistically relevant and one of the many things AI is helpful with.
I still don't understand what the "debt" here is supposed to mean and this seems like the same anti-AI hand waving I've been seeing all year. Probably aimed at people who are vibe coding entire projects or modules, I assume.
We’ve avoided nothing. This warning is literally coming before the debt has come due. The timeless warning of unpaid debt.
Watch the movie Two Hands for but one example.