> And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just another iteration of it.
Assembler replacing direct machine coding or C replacing assembler was a new higher level ruleset replacing an existing lower level ruleset. But that change was largely static, meaning that you could learn a concept of a mapping of C syntax -> generated assembler and rely on it being predictive of the outcome of your program with relative ease. This is what enabled you to "forget about" assembler and move on with C only.
With libraries and frameworks, we introduced another level of abstraction that introduced an element of dynamism since the underlying framework could change at any time. This caused a lot of frustration with many developers already.
Now, with AI, another layer of dynamism and an additional layer of "lack of precision" is introduced. What the machine figures out as a solution may change in each run, the AI itself may change, the libraries, frameworks and programming language that it uses may change - all at the same time.
This raises the question how any human being should afford the time to train themselves in all the underlying components and the AI so as to be a meaningful expert in the field. Given the speed of development in the AI field, this seems like a losing proposition for anyone to invest their time in. Much different from the direct machine coding to assembler analogy that you mentioned initially.
Assembler replacing direct machine coding or C replacing assembler was a new higher level ruleset replacing an existing lower level ruleset. But that change was largely static, meaning that you could learn a concept of a mapping of C syntax -> generated assembler and rely on it being predictive of the outcome of your program with relative ease. This is what enabled you to "forget about" assembler and move on with C only.
With libraries and frameworks, we introduced another level of abstraction that introduced an element of dynamism since the underlying framework could change at any time. This caused a lot of frustration with many developers already.
Now, with AI, another layer of dynamism and an additional layer of "lack of precision" is introduced. What the machine figures out as a solution may change in each run, the AI itself may change, the libraries, frameworks and programming language that it uses may change - all at the same time.
This raises the question how any human being should afford the time to train themselves in all the underlying components and the AI so as to be a meaningful expert in the field. Given the speed of development in the AI field, this seems like a losing proposition for anyone to invest their time in. Much different from the direct machine coding to assembler analogy that you mentioned initially.