Will AI replace software engineers?
Short answer: No.
AI Generated Summary:
This essay argues that while AI tools, particularly large language models (LLMs), can assist with coding and improve productivity, they will not replace software engineers. The author contends that coding is only a small part of a software engineer's job, which also involves problem-solving, understanding user needs, designing systems, writing documentation, testing, and collaboration. Drawing on the history of programming, the essay shows that past advancements, like assembly language, higher-level languages, and object-oriented programming, simplified coding but increased the demand for engineers. The author believes AI will be another tool to streamline tasks, but the essential human skills needed to create and maintain complex software systems will remain indispensable.
(Above paragraph was generated by Google’s Gemini, everything below is hand written.)
Introduction
Everyone is talking about how AI systems will replace software engineers. In my opinion this is not going to happen any time soon. Fundamentally those who say this misunderstand what the job of a software engineer is. Writing code, which the LLMs can do to some degree, is just a small part of the job.
Since the dawn of the computer there were always technologies and tools that claimed to allow “anyone to program” (today’s “vibe programming”). However despite the rise of such tools, the number of software developers has been steadily increasing, as more and more software is needed to run the world.
I believe that this situation will persist and we will continue to need people to solve problems using computers.
Little Bit of History
Modern history of programming began with Alan Turing, who in 1936 published a paper that described a theoretical computing machine which could be programmed to perform any computation - we now call it a Turing Machine. In his paper Turing showed that one could build a Universal Machine that could emulate any other machine - given the other machine’s configuration. Today we would call this configuration a “program’.
Actual physical computers were built some years later. In the US the first was the ENIAC, completed at University of Pennsylvania in 1945. ENIAC was “programmed” by physically wiring components of the computer together to solve a specific problem and had to be re-wired for different tasks. Initially ENIAC was programmed by six young women, who became the first software engineers in the world.
To make programming easier, John Von Neuman (a Hungarian-American mathematician) came up with the idea of storing the program in the computer's memory and having part of the computer fetch and execute the instructions. He called this part a Central Processing Unit (CPU). Today we call this arrangement of CPU and memory, with programs stored in memory, von Neuman architecture.
Now all the programmers had to do was to enter binary numbers representing the instructions into the machine. For example, the hexadecimal number 0xFF1A0100FF could mean to add 1 to memory location 255.
While easier than rewiring hardware, people are not good at memorizing strings of arbitrary numbers. Furthermore, trying to understand an existing code turned out to be pretty difficult.
However translating from more meaningful symbols to numbers is a great job for the computer, so Assembly Language was invented. In assembly instructions are represented by mnemonics that are understandable to humans. For example, the instruction to add one to memory location 255 might be written as: ADD 1, #255. A computer program, called “the assembler” would take these mnemonics and translate them into appropriate machine instructions. Now, programmers no longer need to know machine code.
Assembly Language was just the first step to higher programming languages. First computers were often used by scientists who were good at math, but not at programming. So a higher level language was invented to allow scientists to write formulas they understood and have the computer translate that language to machine code. This language was called FORTRAN, for “FORmula TRANslation”, and it first appeared in 1956.
As the use of computers grew, the trend of creating new languages to make it easier for people to program computers continued. The next big one was called COBOL, for “COmmon Business Oriented Language”. COBOL was designed to mimic the English language so that “even managers could code”.
As more and more programmers were needed, more and more languages were invented to make it easier to build new systems. Some new products promised to make writing software easy. In 1981 a book, titled “Application Development without Programmers”, introduced the “high-level, non-procedural, specification languages” and so the 4GL (Fourth Generation Language) era was born. 4GL tools proved somewhat useful in building systems, but they certainly did not eliminate the need for programmers.
In the 1990s we went through the introduction and adoption of Object Oriented Programming (OOP). While OOP provided better ways to think about designing software, it did not remove the need for engineers.
A lot of the ideas from structured design, 4GL and Object Oriented programming live in today’s software tools. SQL (Structured Query Language) is descended from 4GL, our common programming languages incorporate a lot of features pioneered by the Object Oriented approach. Although the idea of objects and classes originated with the Smalltalk programming language and environment invented at XEROX Parc in the late 1960s.
Which brings us to today and the hype about generative AI - LLMs and such.
Since the need for more software is still growing, as more and more computers are built (eg. our smart phone), we still need more engineers. The new AI tools will likely improve the productivity of tomorrow's software engineers, but I don’t think they will ever replace them.
To understand why I think that, let’s consider the actual job of a software engineer.
What does a software engineer do?
While everyone talks about coding, coding is just a part of a software engineer’s job. Even when you are a junior engineer, you may be assigned a task by someone more senior, but you still need to figure out what to write.
For example, to fix a bug in a piece of software you need to have some understanding of what the software does, you need to reproduce the problem (not always easy) and then fix the code. But, you are not done yet.
In any modern software shop you will be required to write an automated unit test to verify your fix and maybe an integration test to make sure your change works with the rest of the system.
You might have to write, or at least update documentation, and then shepard your change into a production release.
All this, while other people are making changes to the same piece of software.
As you advance in your career, you find yourself coding less and writing documents more. These may be designs of proposed systems, or proposals to develop something new. You will work with other people, who try to understand the problem your software is supposed to solve.
The users of your system may not themselves understand what they need, and may change their mind as your project goes along. As you advance in your career you’ll find yourself spending more and more time talking to other people.
There is an old joke that says: “Walking on water and writing software from requirements is easy, as long as they are both frozen.” Except in real life, requirements are never frozen. You will be lucky if they are formally stated.
Consider this data point. In the past 12 years in my job at Google, I submitted about 210,000 lines of file changes into the code repository. About 100,000 of those changes were documentation files. 100,000 was code, where about one half of that was test code. This comes up to roughly 600 lines of code per month. So, as you can see, writing code is a small part of the actual job.
How does AI fit in?
To me generative AI is just another tool that can help me with some parts of the software engineer job. Today’s software systems contain many, what Fred Brooks called, “accidental complexities”, and AI coding assistants can help relieve the tedium of having to deal with these.
For example, I wanted to write a small Android app to help me manipulate a remote switch by sending text messages. I haven’t done any Android development in a long time, and I was not familiar with the current way of building these apps. With help of an LLM I was able to generate most of the code and configuration files needed and after a bit of debugging I now have an app I can use. However, my app is definitely not production quality - I would hesitate to put it on anyone’s phone - and it is very ugly. But it solved my problem.
So by all means, use the AI tools available, but think of it as “creating with AI” and not as “created by AI”.
References
Future of Programming - Robert Martin talk.
https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html - notes on number of developers in the world.
“Proving Ground” - book about the first software engineers.
https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b