I suppose the question is if we need to understand the concepts deeply. I'm not sure many of us did to begin with and we have shipped a lot of code.

I see a lot of junior engineers, or more senior engineers who are outside their areas of expertise try to prioritize making progress without taking the time to understand. They will copy examples very closely, following best practices blindly, or get someone else to make the critical design decisions. This can get you surprisingly far, but it’s also dangerous because the further past your understanding you are operating, the more you might have to learn all at once in order to fix something when it breaks. Debugging challenges all your assumptions, and if you don’t have models of what the pieces are and how they interact, it’s incredibly hard to start building them when something is already broken. Even then, some engineers don’t learn the models when debugging and resort to defensive and superstitious behaviors based on whatever solution they stumbled on last time. This is a pretty normal part of the learning process, but some engineers don’t seem to get past this stage. Some don’t even want to.

Well, cargo cult programming is definitely a thing, and has been for a long time. It may “deliver value”, but it is not guaranteed. I believe entrepreneurs have an easier time having AI do the work for them because their value assessment framework is decoupled from code generation proper.