Slop Debt

Fun story: I’m an electronics engineer and have been working as a manufacturing engineer for the last 15 years. The company I’m with right now is basically forced me into software development. I learned c++ and python in school but never really did much with them professionally, work on a bunch of side projects at home but software development has never been a part of my career until the last year and a half. I’ve been asked to start developing production tests and other production applications in our electronics assembly department. Mostly this is creating small python applications that program and test pcbas, nothing large maybe a half a dozen files and a couple thousand lines of code. But now they’ve asked me to start developing an integration with our erp and they want it to real time push production data from each bench, operator scans a PCB loads it into a jig presses a button it gets programmed and tested, “my” software reads the erp and pushes all of this information back into the erp slowly moving jobs forward eventually closing them out as operators hit counts. My new manufacturing execution software was written entirely with cloud code and is now two dozen files and almost 100,000 lines of code. No one at work cares. But it all works, we haven’t found any real problems yet. I’ve been encountering bugs as operators use the mes but it’s dumb stuff like not understanding operator behavior and trying to code around that, ie I didn’t log out I didn’t scan a unit I forgot to do x y or z… I am both incredibly impressed and insanely worried. This new system changes money in our erp, and no one who actually knows software development has ever looked at this ever.

Agreed that the solution to metastasized slop debt is to just rewrite it. That’s kind of another way of saying that your entire codebase was written at prototype quality, except worse because of all the hidden decisions no one made.

I think the solution is a radical shift in how we test and review code. If your coworkers weren’t thorough at testing and code review before 2026, then you are probably suffering right now.

I’m guessing LLM advocates want to solve this problem by throwing more LLMs at it, I.e.adversarial review bots, harness engineering, etc. And those are probably good ideas to raise the competency of LLMs, but I don’t think they can replace the better judgement of humans anytime soon.

If your workplace culture already had strong testing and code review standards, then a sloppy PR is going to fail the smell test quickly.

And the biggest problem I see is simply with lazy people who don’t review their own slop but expect others to review it. It’s infuriating and completely unacceptable.

Assuming everyone is trying their best, there is really no substitute for getting your hands dirty and making sure you at least understand all of the code you submit and take the time to interrogate the surrounding code as well. I don’t think there is a hard rule to know that you’ve adequately “digested” and refined the LLM output. But even before LLMs, I used to review my own code and iterate to make it more readable. It’s like writing prose: you read, edit, re-read, until it’s good.

Yeah, I find it really tricky, because LLMs excel at adding yet another implementation to the side, whereas they will barely ever introduce an abstraction to cover both requirements.

And the humans often don’t really read the code anymore either. They ask the LLM to make a suggestion, then check the diff for plausibility and that’s it. They don’t have to solve it themselves, so they never properly dig into the surrounding context and therefore cannot notice the missing abstraction either.

And in the end, it’s not just that the humans don’t know the code, it’s also that it becomes near-impossible to refactor, because it’s just too much code to fit into a brain at a time.

You can’t anymore realize that one part of the codebase should’ve been solved by an already-existing abstraction.
Instead, you find five places in the codebase that really look like they should’ve been solved with a shared abstraction and then good luck figuring out what the common denominator is and how each of those places should be adjusted to fit this common abstraction, oh and also you didn’t see two more places that really should also be solved that way, but for them your chosen abstraction doesn’t make sense anymore, and then you ask the others and they tell you, oh man, that never made sense, we never really thought about it, because it was so easy to just tell the LLM to build it, and now that feature has to be removed in its entirety, so you just wasted two weeks trying to understand code that never made any sense in the first place.

Ask me how I know. 😑

Yep.

I expect that in small codebases the effect will be manageable but anything beyond that… It’s just a matter of time.