Will AI put me out of the job market?
Even though I am a programmer
by Raffaella Ventaglio
Credits by Andrzej Rembowski — Pixabay
Spoiler: no. Not yet.
In recent months we witnessed an explosion of articles glorifying the capabilities of Large Language Models, like ChatGPT. Basically, they can write code autonomously from a plain description of the desired features.
In many of these articles, the gist is more or less “are programmers shooting themselves in the foot by creating a tool that will eventually throw them out of the job market?”.
A simple and concise answer I agree with is summarized in the following meme you can find all over the Internet in many different nuances:
“To replace programmers with AI, clients will need to accurately describe what they want.
We are safe!”
It means that programmers are not just coders. In effect, to be a “programmer” does not mean to be able to write Java or Python code. Not just that, anyway.
Programming is first and foremost – according to my own encyclopedia – “defining in a precise and not ambiguous way the result you want to achieve starting from a certain initial state and some defined inputs”.
So, if you are able to specify exactly what you need then, in a certain sense, you are already a programmer… of humans, if not of machines!
Back in 1986
I wrote my first code in the Autumn of 1986 in the memorable Basic language (yes, it was named exactly so) on a Commodore 64:
10 PRINT “Insert your name: ”: INPUT N$
20 PRINT “Hello, “ N$
It was the usual, simplest code example every developer starts their career with. Did I suddenly become a programmer? Of course not.
I just followed, bit by bit, the instructions I found in the legendary C64 Programmer’s Reference Guide. That did not turn me magically into a programmer any more than blindly following the instructions in a recipe allows me to call myself a chef.
I kept on studying and eventually I learnt to analyze problems and to figure out how to “solve” them by writing code. It truly felt like magic to me.
Then, compilers evolved. New programming languages appeared (and sometimes disappeared). New techniques came into the scene. New tools and frameworks were introduced to facilitate the developers’ work.
At some point, writing the line numbers manually was not needed anymore.
And guess what? I never missed that.
Incidentally, in the beginning things were even worse: think about writing programs on punched cards or having to catch actual bugs inside your system.
Why am I leading you on this journey inside my old memories? Just to be sure we are on the same track.
Technical jobs have been continuously evolving since their very beginning, at an increasingly rapid pace, and they will probably continue to do so for the foreseeable future.
In the long run “programming” could possibly become a trivial task, not requiring any particular education to begin with.
Take long-distance communication for comparison. When Morse invented the telegraph it was a great innovation, but transmitting messages between distant places required dedicated training. Someone had to code the desired message and send it to another operator, who needed the necessary skills to decode and finally deliver it to the final recipient.
Nowadays almost everyone is able to pick up a smartphone and communicate with very distant people without having to go through a difficult training.
The long-distance communication activity did not disappear. It just democratized.
An LLM-based copilot is yet another evolutionary leap for the developers of today, probably as big as the shift from inserting punched cards into a gigantic machine to a small laptop where writing and executing code is just a matter of a few keystrokes.
From the perspective of an experienced programmer such a copilot is like having on your side a junior freshman eager to assist you (and perhaps to learn from your experience?) in completing boring and repetitive tasks, giving you more time to focus on what matters more.
You have to pay attention to supervise their work, stopping them from taking dangerous shortcuts or wrong paths. They can help you, but ultimately you are responsible for the final outcome.
Credits by AltumCode — Unsplash
Nowadays
I must admit that in the beginning I was a bit skeptical about the usefulness of these tools – at the current stage of their evolution – for a programmer with almost twenty years of experience.
Then I spent a couple of days in pair programming with a younger colleague who is in love with them. I had the opportunity to witness some interesting behaviors, even if not all things went right at the first try.
For example, while we were writing a Java program, we asked the Copilot to write for us the equal method of a class. It is not a particularly difficult task, however it still requires paying attention to a certain number of details. The proposed code was quite good, but it failed taking into account all the possible edge cases. Only when we pointed out the error it came up with the right implementation.
The tool was useful to speed up the writing, but the human experience avoided leaving behind an insidious bug that could have remained undetected for quite a long time.
On another occasion, an experienced colleague asked me for input on how to design a complex architecture involving a legacy product. What could be the best way to integrate new AI-based components making them interoperate seamlessly with the existing ones?
In this case there is not a single “correct” answer: finding a solution that is good enough is not only a matter of Software Architecture skills. It also requires a deep understanding of the existing system that would be very difficult, if not impossible (or not advisable for privacy concerns), to inject as a prompt inside an external AI tool.
This is where I have to grab paper and pencil, literally, and start thinking with my hands.
Writing the actual code is not the most delightful aspect of our job. It is an (often) boring, but inevitable activity I will not miss more than I miss having to write the old Basic line code numbers. I am more than happy to delegate these less attractive tasks in order to have more room for the more interesting and challenging ones.
As Nadella said in his Opening Keynote at Microsoft Build this year, these tools are bringing back the joy of programming, the ability to be able to stay on task… the real magic!
Disclaimer: no AI has been harmed during the writing of this post