which the programmer can fully rely on.

Most of the time, today. Mid 90s I was constantly checking compiler output for bugs, and finding them. Early 90s the compiler bugs were finding me, particularly in Borland Turbo C++. I turned off the linker optimizer in 1992 and couldn't turn it back on until 2008 without getting difficult to identify bugs.

Added to this is the prevalence of people thinking that LLMs can allow them to do anything, whether or not they understand it

1971, Willy Wonka and the Chocolate Factory depicted a computer which could (but was refusing to for comedic effect) predict the location of the remaining golden tickets. There were, and probably still are, a shocking number of people who believe that was a realistic scene.

I have an operations manager thinking he can make pages for our Intranet - where does it store the data? How is access controlled? So many basic questions that an actual programmer would know to think of.

Option 1: hold his hand and educate him on what he lacks

Option 2: let him flounder and make fun of his mistakes (the making fun part should be done anonymously if you value your job)

Option 3: he's bright enough to ask the important questions to you or the LLM and get reasonable answers

Option 3 has a very realistic chance of working, if 1) you have documentation for how you do these things today - even informal documentation, anything the LLM can read and extract the relevant patterns from, 2) the LLM must have access to that documentation, and 3) your manager needs the patience and perseverence to work the discovery process until it's viable and sustainable.

Odds are, your operations manager is going to fall short on the patience and perseverence dimensions and offload the boring parts to you, after all why did he become a manager in the first place?

maybe better to just ask a pilot to do it.

Yeah, except you can't make nightly backups of the plane's passenger manifest. If you're not making nightly backups, you're already in catchup territory LLM or no.

it’s benefit to us (and the world) is nowhere near worth the monetary and environmental cost.

I suggest doing a little research into what exactly the monetary and environmental cost of YOUR usage is. People engaged in low-value usages (too many to even begin to imagine, Rule 34 needs expansion to start to cover them) are burning a lot of un-necessary tokens.

What I have read, consistently from various sources, is that my $20/month Claude code subscription burns $11 to 12 in electricity to serve my responses. My house burns over $13 in electricity per day in the summer, mostly for the air conditioning.

instead of writing what you want directly you are writing tests for it.

LLMs write pretty good requirements, specifications, code, and automated tests from chat sessions. You do need to keep an eye on what it's writing to make sure it's not hallucinating, but hallucinations have been reducing in practice rather dramatically across the last 12-18 months of model development. They still happen, you will always need to guard against them, but usually a quick read of what is written followed by a quick test of the product will find the worst offenders. In the end, you need to check the final product to be sure it does EXACTLY what you want, just like you always did. And, it's still a good idea (and as possible as ever) to keep the product modularized and also check every module to ensure it works as you want. How small you make those modules has always been a matter of preference / dictated by levels of concern, etc.

But you really should be writing those tests regardless of whether or not you or an LLM ends up writing the actual code. That helps ensure that the code actually does what you think it does, and prevents bugs or unintended changes in behavior from sneaking in later when something changes

Indeed, my code has never been more rich in unit tests now that coding assistants make them so easy to add

Me as well. A year ago there was significant trouble with those unit tests not adding much value but that has improved a lot over the past several model updates. The unit tests aren't 100% as good as they could or even should be (neither are human generated unit tests that take 10x as long to add) - but in terms of time invested vs value derived, they're excellent value for effort.

If the coding assistant subsequently does something weird that changes program behaviour it knows immediately.

About 90% of the time for me now, in Opus 5.5.

What do the tests do?