Slop Debt

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

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