I've seen a different kind of usage pattern recently, which is to find a problem that the LLM is good at, something which is very local in reasoning, and do it at big scale across the whole codebase.
I've used it to add test coverage. Granted it wasn't for new major features but small features that still necessitated having tests.
IME so far that's what it's best at. As long as there exists tests in the codebase that provide enough of the basic skeleton (i.e. if they already test part of a controller or code that interacts with a DB) to guess what's needed then it can do a decent job. It's still not perfect though and when it comes to inventing bespoke tests that are uniquely different from other tests it needs much more of a helping hand.
A big Bay Area data company recently refactored their old JS codebase from var to let and const. It was done at a scale that is way beyond "senior engineer double-checks LLM to see if code is good."
LLMs are terrible at that in my experience. In what world is refactoring "very local in reasoning"?
Switching libraries/frameworks or switching piecemeal to a new language for a codebase that's already well structured seems like it would be noticeably less costly though.
In a situation where the transformations are explicit and can almost be mechanical with little to no involved reasoning. With those requirements, the LLM just has to recognize the patterns and "translate" them to the new pattern. Which is almost exactly what they were designed to do.
See, using AI as the equivalet of super-IDE snippets or to generate things in isolation is probably really good! It's also categorically not the same thing as what all of the AI hypemen (including the OP) are describing, with it replacing wide swathes of software developers. It devolves into a motte and bailey argument where it is actually possible for AI to be a useful tool in a programmer's toolbox, and make people more productive in isolated ways, without also agreeing with frankly anything the OP thread is saying.