> My reason: code can be checked objectively. I can run it and confirm it works.

Running the code only confirms that it works with the precise input, in the precise environment, under the precise circumstances you run it under. It doesn’t ensure that the code is correct. Thinking through the code, on the other hand, lets you consider all possible cases. It’s the difference between experiment and (mathematical) proof.

For an objective correctness proof, using a formal language is indispensable.

I understand the distinction you're drawing, but in my experience, it gets a lot blurrier as a project evolves. Caveat that I use LLMs all day and have for quite some time, so I'm coming from a positive perspective.

The danger for me in LLM code is the same as in writing, it's just that I'm not typically writing at the same scale as when I'm building something. The final piece when I'm writing is usually a message or a 1,000 word article at most. So I'm naturally going to analyze it quite intensely, because I can afford to. And I don't really use LLMs for this at all. I use them for things around writing (research, interrogating ideas, situationally specific stuff, mapping, visuals, publishing, etc.) And the code equivalent to an essay or message would probably be something like a single script, or the sort of thing I'd write as example code when I'm teaching. In those settings, again, LLMs can be helpful, but I'm still going to be really opinionated at a highly detailed resolution.

But a codebase is more comparable to a novel than an essay. Or more directly, the writing in a codebase is usually the documentation, which grows commensurately with the codebase. And the real LLM risk here is the drift that can happen over the course of many epics or "chapters" as the LLM writes "code that works but is imprecise and probably shouldn't work this way" or introduces weird new terminology that neither of us can precisely define. Worse, this usually becomes obvious down the line, and I have to parse through the verbose constructed world the agent has created to trace the issue back. That's a big cognitive tax, because I'm holding these weird parallel worlds of "How did the LLM's alien brain get here within the bounds of the contracts" and "What do I really want this to look like".

So I think it's fundamentally the same phenomenon, and we're all developing our skills around working with it in real time.

Programs must be written for people to read, and only incidentally for machines to execute. -- Hal Abelson

> I don't feel pride in it (even when I write it by hand).

Hard for me to imagine. You feel no pride in using a tool to accomplish a goal?

> Code has no such personality. I don't tie my identity or ego to code the same way I would an essay

Code certainly does have a personality. When working with teams for a while you can absolutely get a sense for which person wrote what code in a codebase, just by subtle little tells.

You may not tie your identity or ego to it, bully for you, but for me I take a lot of pride in writing clear and maintainable code that contributes to big projects in meaningful ways.

Maybe the problem with software is there's too many people who treat writing code as a mere means to an end, instead of a very important part of the process.