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

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.

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.

And so does the risk that with new technologies, and new topics, I might not be able to know all of these low level tricks. For instance, if all I ever used for Rust was LLMs, there's no chance I'd know about the default hasher situation for HashTable(s).

It's all, such a difficult scenario. My pride and perfectionism have kept me on the artisan side, insofar. But I don't know how long it'll be till that same pride/perfectionism will make me insignificant, as folks could eventually get 95+% as good in <18% of the effort.

All the stages of grief... alright.