I disagree, but I agree that this is the wider perception.
> In this context, unless you can write code faster than a machine, you have no choice
This is the main misconception. Speed isn't as valuable as reliability and correctness. Is it better to code something that takes 2 hours but constantly breaks or something that takes 5 days but never breaks? The problem is that it's hard to quantify whether the 2 hour unreliable code is a good tradeoff. How many hours of fixing will there be, and what other things is it going to cause as a result of breaking the code? It could be simple bug fixes but it could also be production downtime. In order to avoid all of that you can simply code something with strong guarantees it will work, and it will work well.
Unfortunately I think the industry has spoken, and they are willing to go down that path of doing it as quickly as possible at whatever the cost. After all most companies will hire many mid-level engineers, and that's easier than finding a few really good ones. So I guess my point is that while this is changing across the industry, either things will start breaking and AI will become less used as everyone realizes you really want reliability over speed, OR AI does get better and better and then engineers are truly replaced. Nobody has to think of coding ever again. Right now we're in this limbo phase where we pretend AI has changed things but engineers are still needed. I don't think there is an in-between here.
The point is that it is hard to prove that that 5 days code will never break. In the eyes of a customer a feature ready in one morning and in production before evening is a truly great thing and they know that even before AIs developers were shipping a lot of bugs. Some of them were evident only weeks, months or even years after the commit that added them. A customer of mine got a few hours of downtime a few Saturdays ago because some code from 2021 did some potentially long operation in the threads serving requests instead of doing them in a background job.
So what can one do when they expect that you use an AI to speed up development and they manually check features before they are deployed? You develop with an AI, check that it works, deploy to preprod, let the customer do its tests, business as usual.
> In this context, unless you can write code faster than a machine, you have no choice
This is the main misconception. Speed isn't as valuable as reliability and correctness. Is it better to code something that takes 2 hours but constantly breaks or something that takes 5 days but never breaks? The problem is that it's hard to quantify whether the 2 hour unreliable code is a good tradeoff. How many hours of fixing will there be, and what other things is it going to cause as a result of breaking the code? It could be simple bug fixes but it could also be production downtime. In order to avoid all of that you can simply code something with strong guarantees it will work, and it will work well.
Unfortunately I think the industry has spoken, and they are willing to go down that path of doing it as quickly as possible at whatever the cost. After all most companies will hire many mid-level engineers, and that's easier than finding a few really good ones. So I guess my point is that while this is changing across the industry, either things will start breaking and AI will become less used as everyone realizes you really want reliability over speed, OR AI does get better and better and then engineers are truly replaced. Nobody has to think of coding ever again. Right now we're in this limbo phase where we pretend AI has changed things but engineers are still needed. I don't think there is an in-between here.
So what can one do when they expect that you use an AI to speed up development and they manually check features before they are deployed? You develop with an AI, check that it works, deploy to preprod, let the customer do its tests, business as usual.