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