Will Artificial Intelligence Replace Software Engineers?

Is Software Engineering Still a Good Career Choice?

Back in the late 90's I collaborated on a project with the George Washington University Operations Research Department to develop a neural network (NN) to capture the relationship between power plant soot blowing and coal-fired boiler efficiency, to create a state-of-the-art optimizing controller. Those were the early days when neural networks, which have been around in concept since the 1940s and 1950s, first started to gain traction in practical applications. They worked well for those limited applications where there was plenty of numerical data, captured via real-time instrumentation, that could be used to train the NN.

Since then we've seen an inexorable march towards ever-more powerful and sophisticated use cases, including Natural Language Processing (NLP) applications. With the latest release of ChatGPT and its unsettling ability to write software, engineers are starting to ask "Should we be worried?". We can be sure that Tesla's AI autopilot and the like will someday replace human drivers, but that doesn't present much risk to software engineers. But what about ChatGPT, Github's CoPilot, Amazon's Code Whisperer, and so many similar others?

From time to time parents of new graduates, upon learning of my long career in software engineering, ask if I think it's still a good career choice. My answer is always the same: it's challenging, fascinating, and ever-changing, you'll be surrounded by very smart colleagues, and the pay is great. I've enjoyed every minute of it. There is no better choice, I say.

Lately, post-ChatGPT, I'm beginning to wonder if my historically rote answer needs an update. Because, in case you haven't noticed, ChatGPT writes pretty good code and it keeps getting better with every new release. Plus, there are now a whole host of similar tools, sometimes called "TuringBots", that can do even more. DeepMind's AlphaCode, for instance, can read a half-page of a well-defined technical problem specification and then write the associated code. It even ranked within the top 54% of participants in programming competitions — and the programmers that enter such competitions are typically best-in-class.

On the other hand, several informal surveys of software engineers suggest that most engineers — who are certainly in the know — are not yet overly concerned about losing their jobs to AI, and see AI as a mostly helpful peer-programmer. And, while AlphaCode can generate a solution from a small technical specification, we all know that a typical software application is defined by hundreds or even thousands of requirements. That's a much bigger fish to fry.

When I heard the early chatter about the first release of ChatGPT I assumed any conjecture about the threats it posed to software engineers were overblown. We software engineers spend years perfecting our skills — how could a machine possibly replace us? But when I tested it on some of my coding problems I discovered its answers are comprehensive and human-like and seem to pass the Turing test with flying colors. I wondered if there has been a recent breakthrough in the NN/NLP technology. I dug in, and a little research suggests the answer is both yes and no.

These new TuringBots incorporate recent advances like improved text embeddings (to reduce problem size), byte-pair and positional encodings (to capture semantic meaning), Transformer architecture to capture relationships across longer segments of text, larger and better training sets, and more. But they don't, even taken together, seem to represent a single "eureka" discovery. They are just part of that same inexorable technological march we've seen since the beginning of the Industrial Revolution. And that is simultaneously reassuring and worrisome. Assuming that technology continues to march along at its current pace, and given that a typical software engineering career lasts about 40 years, betting against AI as the next-generation software engineer might be dubious at best.

The Future of Software Development

Ask any software engineer what it's like to build software, and they will tell you it's an unusual beast — more like art than engineering. Unlike a physically engineered product, it does not obey the laws of physics, or any laws at all. In a new project, developers can write whatever they like so long as they follow the syntactic rules of their chosen programming language. And no matter how simple a typically vague requirement is, no two developers will follow the same path or create the same solution. They must make a huge interpretive leap to translate requirements into code because natural language leaves so much to interpretation. Moreover, it is impossible to fully specify the requirements for a product at the outset and the choices made early in the project will dictate and constrain downstream choices. While developers have unfettered freedom at the beginning, as the product advances they must build upon the work of others and the code becomes more complex and difficult to interpret. Any TuringBot, no matter how sophisticated, must operate within these same constraints.

These challenges are fundamental and haven't changed much since the invention of the programmable computer nearly 75 years ago. What has changed are the languages programmers use to encode and translate requirements into their ultimate destination — machine code — the binary language all modern computers understand. In the beginning, programmers wrote machine code itself (very difficult), then Assembly Language (mnemonics to represent binary instruction codes), then Fortran (the first truly high-level language), and 'C' and Java and all the rest. Today, there are thousands of powerful languages to choose from.

On top of that, today's programmers can leverage mountains of open-source libraries to handle much of the work needed for a typical application. In many ways, today's software engineers are like systems integrators, weaving together hundreds of open-source libraries to bootstrap their work, then adding the code necessary to connect it into a cohesive whole, and finally adding the custom logic needed for their particular problem. Computers are far more powerful today, but it's the advances in programming languages and open source that let us leverage that power.

Software Integrated Circuits (ICs)

Back in the 90's there was a nascent concept called "Software ICs", where the idea was that software could be composed of off-the-shelf components in the same way that electrical engineers use Integrated Circuits. The graphical Unified Modeling Language (UML) would be the primary "language" for designing such applications, and UML would be the most abstract and powerful language yet. Software engineers would create UML "blueprints", just like real architects, and the "compiler" would automatically implement the application with ready-made components. Draw some diagrams and voila, your application is ready to go.

This, of course, never really materialized. Software interfaces are far more semantically rich than integrated circuit interfaces, and there are no standards to constrain how they are designed, other than some loose idioms and shared best practices. Interface design is governed by things like convenience, coupling, separation of concerns, and so on. The techniques used to communicate across interfaces are also varied: parameters, global variables, dependency injection, static configuration, and more.

These same challenges also constrain how effective ChatGPT, CoPilot, and others can be at creating entire applications based on textual requirements. Natural language just isn't a great tool for describing a software application. It just happens to be the most convenient method we have today. But that doesn't mean that's what we'll use in the future.

Let's Predict the Future

We all know that predicting the future is a futile game — but it's still fun to try. My "Aha!" moment goes back to the idea of Software ICs. We can begin to define new, even higher-level languages, something in the spirit of UML, to provide ever more structured descriptions of the application we want to build, which can then in turn be more accurately interpreted by AI. AI becomes the "compiler" of the future, powered by a new kind of "10GL" programming language — a grand leap beyond today's 4GL/5GL languages.

Is that possible? There are already plenty of tools available today that can reverse engineer lines of code into UML diagrams, or something like it, which could then be used to train the next generation of TuringBots. That is, we can define new languages and reverse engineer existing code bases into those languages, and then train TuringBots to generate the code described by those languages. TuringBots become compilers.

Where does this leave the software engineers of the future? Engineers will still work with the business to create new applications based on requirements written in natural language, but the programming languages we use will be far more powerful than what we have today. AI won't be a peer programmer, but a new kind of compiler. So I think my advice for new grads endures. Software engineering is still a great career choice. But you better buckle up, because you're in for one helluva ride.