Post

The best 'halfway-compromise' there is that I accept ugly LLM code. And I focus on maxxing out end user experience above all. Maximize for correctness+performance- at expense of code style/quality. Because otherwise... feels like am just cooked. Really might not be room for us artisans anymore...

Because there's only so much time I can spend making the code itself beautiful. Time others never bothered to put in. Even pre-LLM days. And all most end users care about is how well something runs; not the process behind the creation or maintainability. We'll be very much a niche.

Older days, you could make code beautiful as you wrote it, was part of the process. Was cheap. You typed your thoughts. But now, 'generating' code is 'cheap', and making it beautiful is expensive. Now, all you need to know is the higher level construction to build something (with some exceptions).

It's kind of like going ASM->C. Instead of building function bodies, you build the high level architecture. i.e. The APIs (contracts), how project is structured, how components form together. etc. LLM just fills the method bodies in. See something wrong in low level detail? Ask for refinement.

I for one have never been satisfied with it. I'm still *not*. LLM code *is* ugly, and hard to understand. I always rework it so it can be understood easier by others. I also refuse to have any code where I don't understand *every* line exactly 💯%. My pride doesn't allow it.

You just need to know what code should & shouldn't be there, rather than scrutinize every line. Understand what code needs to have. For example, if optimising for performance, you might want to use branchless programming to optimise for CPU pipelining.

Or, knowing that the default Rust HashTable uses a DoS resistant algorithm for the hasher, and is thus wasting cycles if not doing networked stuff where you need that randomisation. (Because LLM will output a default HashMap/HashSet every time- human will always need to know this fix!)

Or, suppose you're doing code translation for x86. You would want to know that you want to get rid of x87 ASAP and lift it to C. (x87 is expensive to emulate) And all that matters, is that it's *correct* and performant... It really becomes a matter of 'knowledge'. Of knowing where the issue lies.