I'm sure you do. I run a very large engineering team of a very large software company as well has having built most of their principal product initially. That is on top of spending a decade as an EE / embedded engineer designing things that left the planet. While I respect that automation is a noble goal and I support that, but one has to consider determinism and idempotent behaviour, neither of which an LLM delivers.
Specifically in context to software engineering, there are two sides to this argument: science versus faith. We must err on the side of science which means that anything we do must be objective, repeatable, documented and reproducible. And that means it must reach a certain standard of evidence, which an LLM or an engineer using one cannot ever meet.
A fine example is the queue consumer problem. How does one reliably consume a message from a queue i.e. ensure that a message is delivered at least once (exactly once is even more difficult!). The context of the question is extremely difficult to reason about even by seasoned professionals because it depends on many aspects including the consumer's durability as well. Of course the lazy developer will get ChatGPT or whatever to write a queue consumer and make the assumption that it works. Eventually that becomes the de facto standard and the brain drain begins. We already have problems recruiting people who can solve this problem effectively and we have to do that or the SEC will ream us. While not reamed yet, the problem was discovered and the root cause turned out to be a first monkey using a piece of generated code which guaranteed delivery exactly 0-3 times depending on the weather, approved by a second monkey who used an automated review tool to review it and a third monkey using an automated test generator to fail to test it. Of course because these tools were specified, trusted purely on faith without verification and implemented in faith, there was no one ultimately responsible of course.
It only takes a dead body for that to turn into a $50,000,000 problem where EVERYONE is responsible.
There is too much faith and little to no verification. To make parallels to the hard engineering disciplines we are still in the 1800s in software.