Yes. An LLM certainly doesn't know this. Most of the input data to the LLM will not be "good tests" as these are quite rare in practice. The median test in the input data is not good, so the output of a LLM generating more tests won't be either. Most human oversight won't even recognise this either.

> only change when you change that specific behaviour.

Correct, as Kent Beck observed: "Tests should be coupled to the behaviour of code and decoupled from the structure of code"

bad tests "need constant updates" because they reverse this.

As you've pointed out, the problem is literally a skill issue - the OP never really "got into" testing, they don't understand the usefulness, or what makes a test good or bad. This is like hiring a contractor, telling them vaguely "build me a house" and then complaining afterwards that the house they built isn't what you wanted. If you give ai no feedback, you'll get code (and tests) which are the median of what's publically visible in your field. If you want good results, you have to be prepared to teach the agent what you want, which includes feedback about how things should be done, and, ideally, _good examples in your code-base_. So I'd say it's easier for someone without testing fundamentals to get into the "tests are bad" state - they don't know what they did wrong, they don't know how to fix it, and they (boldly, and incorrectly) assume that the ai _does_ know. It knows _nothing_. It's a tool, and you'll spend at least some of your time correcting it.

I couldn't imagine feeling any sense of security without a healthy unit test suite. In particular, when adding a new feature, or updating something somewhere else, having some kind of automation that can tell me I didn't break stuff that wasn't broken before is invaluable.

Where the OP does have a point (albeit by implication) is that: WHEN TESTS RUN SLOWLY, EVENTUALLY, NO-ONE RUNS THEM.

When I joined the company I'm at now, they had about 2k tests on their main product - they couldn't be run reliably as a suite, so no-one did. They were indeed pointless. Now we have 15k tests on that project, and they run on every push, and before every deployment. The reason? My primary task was getting testing working reliably (which also included trying to get other devs to opt into proper testing - which had variable results - some people will push against what they see as "more work" for "no purpose" simply because they don't understand the purpose. The point is: now that they all run within about 5-10 minutes (depending on the host machine), they're run all the time, and they provide useful feedback when dev in one area has unintended side-effects in another area.