I think I do agree with the central point but a point of order is that if you tell AI to fix the bug and then tell it to fix the next error you might still be building an important skill: learning how to make the AI get good results.

> And the consequences become particularly serious when something happens that the machine can't solve

Sadly the bot-gulled will always say "But the next model will be good enough to do that!".

I fall somewhere in the middle of the spectrum of developers the author describes. I use AI daily for limited code writing and lots of debugging. I agree with the author that things go off the rails when you stop truly reviewing its output and just click accept to get the thrill of productivity. I don’t think using AI for debugging means you have to do that though, it’s still a choice. As an AI-human team I have had the experience many times now of debugging an issue in a complex system that I simply don’t think I could have done alone or in a reasonable amount of time. I don’t think this is a reflection of my low abilities - it’s because the AI brings to the table skills that I’ll never have like reading through and correlating huge amounts of logs across many runs of the same system on different compute nodes in a cluster. Once it finds a needle in the haystack I can still take the time to understand and reason about what it found though.

In your closing thoughts, you don't mention what is this staying firmly in control? how do you stay firmly in control while reaping the benefit of the model while being more productive?

because if you start a curriculum over what the model wrote then, one can argue, you are better off writing it yourself in the first place.

The hardest part is knowing what you forgot. You can't check for gaps you don't know exist.