ConcurrentCrab

I think this is pretty insightful, and I might add this as another reason LLM code looks so revolting. It's basically writing prose in a different language, which make sense - it's a _language_ model, it has no structural comprehension to speak of.

Whereas I write code (and expect good code to be written) such that most information is represented structurally: in types, truth tables, shape of interfaces and control flow, etc.

Cool terminology, but I don't think this really applies to LLM-generated code.

"Based on a fundamentally incorrect model" is what I would call code by a new coworker or intern who didn't stop to ask questions. The model being fundamentally wrong means it's cognitively taxing to refactor, but you can at least reason about it, and put band-aid fixes if it somehow flows to prod.

With LLM code you're lucky if there's any sort of ostensibly identifiable model underlying the cryptic 10,000 lines PR corresponding to the statistically extrapolated token stream flowing out the matrix multiplication brick. And the person raising that PR tries to create that mental model, instead of taking the easy way out.

As another one of your quiet readers, more specifically a soon-to-be uni grad who's at a crossroads about choosing to pursue my interests in either game engineering or systems engineering as a career path in this hellfire of a world we live in, I ADORE both your books. I think your writing consistently does an amazing job of motivating a practical yet elegant design from first principles.

And yeah, as someone who's trying to start writing a blog on ~technical topics, I get what you mean. Not every explanation can be linearized perfectly, because sometimes two concepts are coupled, motivating and influencing each other's design. Sometimes there are just, so to say, dependency cycles in the "knowledge graph". Can't turn that into a directed acyclic graph no matter how hard you try. The most prudent solution probably is just resolving the cycle iteratively by starting somewhere.