> in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal.

You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster).

There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing.

Perhaps more productively, you treat the slop as a black box and build something understandable around it.

This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.