I'd like to try a few counter arguments (and forward some comments).
“Deep learning AIs will never really be able to move beyond boilerplate, because deep learning models are only capable of picking up on recurring patterns and relationships (even if they are very complex patterns and relationships), and the patterns in the code are the boilerplate.”
I think you're thinking about the architecture of ChatGPT. It was not built up for the purpose of writing code, but it is conceivable to me that a different architecture could be used to create a coding AI. For example, with a reinforcement learning setup that directs the machine to come up with code (that it runs) that achieves the requirement specified by the prompt. That is, not merely find a pattern in coding scripts, but be forced to compose code that achieves a goal. (Besides, what does our human mind do beyond picking up patterns and relationships?)
You're right that were such an AI used to write code, its employment would essentially be merely a higher-level programming language, like Python is higher-level than C is higher level than binary. You trade off one thing (efficiency, execution speed, specificity) for another (speed of programming, maintainability, readability). And with great power comes great responsibility: 40 years ago a programmer would have been expected to produce less than today, given the lack of Stack Overflow, immediately downloadable packages, APIs and so forth. The question would be if at some point the power is unnecessary excessive such that, as you muse on the last paragraph, you can do away with the software developer altogether.
Which is not to say that English, or any natural language, per se could be the medium between the programmer/ manager and the AI. As you say, it's messy and ambiguous, which is why technical language had developed way before any machine coding appeared in the world. A well written complicated mathematical equation can express clearly and tersely what English couldn't. The question, as I see it, is whether such a technical language to interface man and AI will be developed that will be simple enough to learn that it would be more convenient for a manager to learn and use it than to hire a programmer and explain to her in English what he wants. (But here's a thought: will AI replace managers?)
You're surely right about what the average bulk of a developer's work is. You scarcely need a manager to tell you what to do with a bug, but somebody needs to write the code that runs the packages you use, and even if many are programmer-driven, still there's code that is directed by managers, in English. My own experience has been exclusively with smaller, start-uppy companies with much to program de novo, and I can say that managers can be as hair-pull-inducing finicky as computers. Or even more. I've seen on the side, sandwiched between world-building questions and can a ranger with the amulet of darkness use level 3 mage spells, links to “workplace stack overflow” threads, but I imagine that copy-pasting advice from there is even less advisable.
By the way, I wonder why you think it's in unit tests where AI might shine (so to speak). It seems to me that if anything exactly there using an AI would be an overkill. With a template you can write them up faster than you could compose the English sentence to describe them. No?
You make a good point about RL models, personally I am still skeptical, but I can at least conceive of this being possible.
Right, the question is always going to be whether you can develop a "technical language" that can interface between man and computer better than a programming language. If so, then you have something that can replace a programming language. Personally I doubt it because of the reasons I gave in the essay. Take a look at SQL as another example. It was supposed to be so easy that non-technical professionals could use it. This is nothing short of comical now. But even if you could replace programming languages, what then? You have a technical language that's something like a programming language... would you really be able to use it without having expertise in that technical language? Isn't that what it means for a language to be "technical"? This is what I was trying to get at with the prompt engineering argument. The fact that "prompt engineering" exists as an ostensible domain of expertise means that you haven't replaced the programmer, you've just changed the programming language--and it's a much worse programming language! Maybe there is some intermediary that's like in between english and python, or something, but, is that really going to be better than python? The way I see it, python is already pushing the limits on how flexible we want a programming language to ever be. I am skeptical that there is anything "easier" to use that would actually make software development more productive.
Your penultimate paragraph reminds me of Office Space, how it comes out that all that guy does is act as the intermediary between the programmers and the stakeholders, and he is promptly fired... that scene is hilarious. But there's a good point here too, that certainly part of a programmer's job is listening to the manager/stakeholder-speak and translating it into something actionable.
As for your question about unit tests, I think it depends on the test. I've worked on test suites that were a lot more complicated than you describe, and I expect would be impossible for a LLM to write. I think a good amount of them fall in the middle, where they are beyond complete boilerplate, but still at a problem-solving level far below that of the rest of software development. But yes in principle you're absolutely right: "you can write them up faster than you could compose the English sentence to describe them" and in fact I think this actually applies to a lot of programming--because describing it in english is so much harder than it might sound--and it's another reason AIs are unlikely to take over.
I'd say that SQL /is/ a simple language, but I can imagine that managerial staff would want to avoid it. Why do it if there are programmers to do it instead? Just like you might prefer to let a mechanic change a bike's tyre, even if you could manage it yourself. I don't think one needs to be particularly smart in order to learn SQL in a day or two. As for using it, the challenge is rather in figuring out what it is you want the computer to do (take the average of which aggregated columns and so on) rather than in putting that wish into SQL words. It's technical, but you don't need too much traininig to accomplish that, you merely need to think.
This reminds me now the reoccurring assumption of a boss of mine that just because he can put into a couple of simple sentences what it is he wants from our data sets, we (the tech team) should be able to do it in "a couple of lines of code."
As far as extracting information from data tables, I now wonder if, indeed, a ChatGPT like AI wouldn't be able to do the job. Asking (perhaps with speech recognition to boot?) to get " the customers info of those who have not made a purchase in the last month, ordered by their last login date" would be easier than writing the equivalent SQL command.
Which leads me to the next thought. You mentioned how as a programmer what you've done is suturing together discrepant pieces of software rather than writing much new code. The space of potential software is wide, but most programs/ apps out there are not revolutionary pieces of art, making the space of actually realized software rather narrow. I can imagine AI being able to bring together the components to create the customized but mostly standard software that you bespeak. It's not trivial, but if there's potential I can imagine packages being written in such a way that it could be done more easily, perhaps also by providing meta-data whose intended audience is an AI. This scenario is not necessarily around the corner, but perhaps it is not beyond the horizon either.
Strictly speaking, you are right that this will not eliminate programmers, but simply change the nature of what a programmer does. But less strictly speaking I'd say it's a semantic distinction. My picture of 18th century transportation is of carriages being driven by chauffeurs. There are professional drivers today as well, but their relative number is decreased. Have drivers disappeared? No (at least not yet). It's simply that the passenger became the driver. Here too was a technological change: manufacturing of vehicles became cheaper, people who can now afford a car cannot necessarily afford a driver, and even if they could they see the cost-benefit balance unfavourably, opting to invest in learning to drive themselves. Also coming to my mind now is Charlemagne who, despite all of his promotion of scholarship, as far as I understand, could barely write his own name. An illiterate president nowadays is unimaginable. So while programmers will not vanish, perhaps a point will come where /programming/ wouldn't be a specialized occupation.
I'd like to try a few counter arguments (and forward some comments).
“Deep learning AIs will never really be able to move beyond boilerplate, because deep learning models are only capable of picking up on recurring patterns and relationships (even if they are very complex patterns and relationships), and the patterns in the code are the boilerplate.”
I think you're thinking about the architecture of ChatGPT. It was not built up for the purpose of writing code, but it is conceivable to me that a different architecture could be used to create a coding AI. For example, with a reinforcement learning setup that directs the machine to come up with code (that it runs) that achieves the requirement specified by the prompt. That is, not merely find a pattern in coding scripts, but be forced to compose code that achieves a goal. (Besides, what does our human mind do beyond picking up patterns and relationships?)
You're right that were such an AI used to write code, its employment would essentially be merely a higher-level programming language, like Python is higher-level than C is higher level than binary. You trade off one thing (efficiency, execution speed, specificity) for another (speed of programming, maintainability, readability). And with great power comes great responsibility: 40 years ago a programmer would have been expected to produce less than today, given the lack of Stack Overflow, immediately downloadable packages, APIs and so forth. The question would be if at some point the power is unnecessary excessive such that, as you muse on the last paragraph, you can do away with the software developer altogether.
Which is not to say that English, or any natural language, per se could be the medium between the programmer/ manager and the AI. As you say, it's messy and ambiguous, which is why technical language had developed way before any machine coding appeared in the world. A well written complicated mathematical equation can express clearly and tersely what English couldn't. The question, as I see it, is whether such a technical language to interface man and AI will be developed that will be simple enough to learn that it would be more convenient for a manager to learn and use it than to hire a programmer and explain to her in English what he wants. (But here's a thought: will AI replace managers?)
You're surely right about what the average bulk of a developer's work is. You scarcely need a manager to tell you what to do with a bug, but somebody needs to write the code that runs the packages you use, and even if many are programmer-driven, still there's code that is directed by managers, in English. My own experience has been exclusively with smaller, start-uppy companies with much to program de novo, and I can say that managers can be as hair-pull-inducing finicky as computers. Or even more. I've seen on the side, sandwiched between world-building questions and can a ranger with the amulet of darkness use level 3 mage spells, links to “workplace stack overflow” threads, but I imagine that copy-pasting advice from there is even less advisable.
By the way, I wonder why you think it's in unit tests where AI might shine (so to speak). It seems to me that if anything exactly there using an AI would be an overkill. With a template you can write them up faster than you could compose the English sentence to describe them. No?
You make a good point about RL models, personally I am still skeptical, but I can at least conceive of this being possible.
Right, the question is always going to be whether you can develop a "technical language" that can interface between man and computer better than a programming language. If so, then you have something that can replace a programming language. Personally I doubt it because of the reasons I gave in the essay. Take a look at SQL as another example. It was supposed to be so easy that non-technical professionals could use it. This is nothing short of comical now. But even if you could replace programming languages, what then? You have a technical language that's something like a programming language... would you really be able to use it without having expertise in that technical language? Isn't that what it means for a language to be "technical"? This is what I was trying to get at with the prompt engineering argument. The fact that "prompt engineering" exists as an ostensible domain of expertise means that you haven't replaced the programmer, you've just changed the programming language--and it's a much worse programming language! Maybe there is some intermediary that's like in between english and python, or something, but, is that really going to be better than python? The way I see it, python is already pushing the limits on how flexible we want a programming language to ever be. I am skeptical that there is anything "easier" to use that would actually make software development more productive.
Your penultimate paragraph reminds me of Office Space, how it comes out that all that guy does is act as the intermediary between the programmers and the stakeholders, and he is promptly fired... that scene is hilarious. But there's a good point here too, that certainly part of a programmer's job is listening to the manager/stakeholder-speak and translating it into something actionable.
As for your question about unit tests, I think it depends on the test. I've worked on test suites that were a lot more complicated than you describe, and I expect would be impossible for a LLM to write. I think a good amount of them fall in the middle, where they are beyond complete boilerplate, but still at a problem-solving level far below that of the rest of software development. But yes in principle you're absolutely right: "you can write them up faster than you could compose the English sentence to describe them" and in fact I think this actually applies to a lot of programming--because describing it in english is so much harder than it might sound--and it's another reason AIs are unlikely to take over.
I'd say that SQL /is/ a simple language, but I can imagine that managerial staff would want to avoid it. Why do it if there are programmers to do it instead? Just like you might prefer to let a mechanic change a bike's tyre, even if you could manage it yourself. I don't think one needs to be particularly smart in order to learn SQL in a day or two. As for using it, the challenge is rather in figuring out what it is you want the computer to do (take the average of which aggregated columns and so on) rather than in putting that wish into SQL words. It's technical, but you don't need too much traininig to accomplish that, you merely need to think.
This reminds me now the reoccurring assumption of a boss of mine that just because he can put into a couple of simple sentences what it is he wants from our data sets, we (the tech team) should be able to do it in "a couple of lines of code."
As far as extracting information from data tables, I now wonder if, indeed, a ChatGPT like AI wouldn't be able to do the job. Asking (perhaps with speech recognition to boot?) to get " the customers info of those who have not made a purchase in the last month, ordered by their last login date" would be easier than writing the equivalent SQL command.
Which leads me to the next thought. You mentioned how as a programmer what you've done is suturing together discrepant pieces of software rather than writing much new code. The space of potential software is wide, but most programs/ apps out there are not revolutionary pieces of art, making the space of actually realized software rather narrow. I can imagine AI being able to bring together the components to create the customized but mostly standard software that you bespeak. It's not trivial, but if there's potential I can imagine packages being written in such a way that it could be done more easily, perhaps also by providing meta-data whose intended audience is an AI. This scenario is not necessarily around the corner, but perhaps it is not beyond the horizon either.
Strictly speaking, you are right that this will not eliminate programmers, but simply change the nature of what a programmer does. But less strictly speaking I'd say it's a semantic distinction. My picture of 18th century transportation is of carriages being driven by chauffeurs. There are professional drivers today as well, but their relative number is decreased. Have drivers disappeared? No (at least not yet). It's simply that the passenger became the driver. Here too was a technological change: manufacturing of vehicles became cheaper, people who can now afford a car cannot necessarily afford a driver, and even if they could they see the cost-benefit balance unfavourably, opting to invest in learning to drive themselves. Also coming to my mind now is Charlemagne who, despite all of his promotion of scholarship, as far as I understand, could barely write his own name. An illiterate president nowadays is unimaginable. So while programmers will not vanish, perhaps a point will come where /programming/ wouldn't be a specialized occupation.
I haven't seen Office Space, but now I'm curious!
Cheers,