I have a lot of sympathy for the "AI can't write code" crowd. When you're using it on something you understand deeply, watching it solve for situations that don't matter, or stepping in to make a small change and realizing it has coupled ideas which turn the small change into a large change damages trust in it's ability to do anything at all.
You find yourself changing your intended implementation strategy to correspond to what will be easiest - or rerolling entirely. This creates the "slot machine" type of workflow a lot of people are concerned about.
I still think this is largely a skill and discretion issue. It can be easy to delegate to the machine entirely and forget you have agency in the process because it's a tool - these are the rerolls, the "No, wrong, do it again" frustration prompts, the lack of context "but it should be obvious" prompts.
Software engineers expect software to work and so the idea of collaborating with their tools, or treating it as a talented coworker in a pair programming experience is foreign. Many of them tend to hate pair programming entirely, anyway, and so why would they use a tool that just forces them to work in a way they already disliked? Why would they spend time explaining to their tools how they should work and what they should be doing when they can make it work themselves without all of that labor?
When I first got into software a common way of explaining code was to say that its the worlds smartest, most literal person who will do exactly what you tell it to. The onus for software not working is entirely on you and the decisions you made in writing it - it makes for a fantastic microcosm of personal accountability and tremendous respect when you encounter errors designed to save you from exactly the issue you yourself are in the process of creating.
I think that way of thinking is still relevant, but widened.
It's a lot like teaching kids - you can't just expect them to know all the inferential steps between your ask and expected result. Try asking a 5 year old to put their shoes on and just sit back and wait. If they ever get there, there will be some interesting side quests along the way.
But at the same time, once they get the shoes you can't start yelling at them for not doing it the way you wanted. "We don't use bunny ears for knotting our shoes! We loop, swoop, and pull!"
You weren't trying to teach them the tying method, you were trying to teach them to get them on and you have to quiet the voice in the back of your head that screams it isn't how you would have done it and just accept the output.
That doesn't mean you have to accept genuinely bad outputs, but it means you're now responsible for tuning your request, adjusting the context, building the guardrails so that the outputs - even when not how you'd do it - meet the standard you expect for "it works."
The shoes are on and they're tied and they're not causing issues? Good job, buddy. Nailed it.