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.

But how long can I realistically keep this up? Living like this will make me the assembly programmer when folks are writing in C. You don't need to make everything beautiful anymore w/ docs/explanation. Or understand 100%. '95%' is ok now. People can just ask their agents. That's the sad truth.

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!)

Do people care? End users certainly don't. Developers- if it works, optimally, who's gonna touch it? (No matter how ugly- have you touched Hash algorithms before?) All that matters is a human verified it to be correct, and they don't believe they can come up with a better solution.

But then, coming up with 'better solutions' requires critical thinking and getting your head stuck in. This is experience *you can't* get if you let the LLM write the code for you. Reviewing is not a substitute, as verifying a solution and creating one are different problem tiers.

So you can't know there's better ways unless you try. Is working collaboratively with an LLM to scrutinize every bit of code for potential better solutions an alternative way? I don't know. Gives you the knowledge, but not the critical thinking.