Why is everyone trying to replace Software Engineers?
At this point it is safe to say that software engineers are not in any immediate danger of being replaced by AI. So why do people keep trying to do just that?
Andreas Møller
February 12, 2025
If you have spent any serious time building software applications this probably come as no surprise to you. While large language models (LLMs) have shown in recent years to be surprisingly adept at generating code, as soon as they encounter a problem that does not look like anything in their training set they are pretty much entirely useless.
There is no reason to think that this will change in the near future. The most recent generation of LLMs are already trained on all the code ever written. And even if somehow OpenAI were to magically drum up some more data it probably isn’t going to make that much of a difference. Not all programming problems can be solved with pattern matching and contrary to what the name suggests the new generation of reasoning models aren’t actually capable of real reasoning.
But why is it that even though almost every software engineer I have talked to shares this exact same opinion, everyone is still talking about how AI will replace software engineers? Why are people so easily fooled into thinking that this new technology means the end of our profession?
Why is it that everyone is so desperate to replace us with AI?
Wielders of Syntax and Sorcery
Software engineering is a really strange profession. It would be wrong to say that it is harder than most other professions but it does have an unusually steep learning curve. This means that if you are working in a software company you are surrounded by people who either know quite a lot about programming or almost nothing at all. When talking to colleagues in the past I have often been shocked by just how little they understand about the software that they are supposed to be selling.
It is perfectly normal to hear phrases like:
I have no idea what any of those letters and symbols on your screen means, but surely it can’t take more than two days to build this thing?
As we are all collectively discovering at the moment. Our colleagues also have almost no idea what we actually do all day. The most common conception seems to be that software engineers translate English into code. This is also the worst definition of software development I have ever heard as it literally ignores everything that is challenging about our profession. The problem is that from their point of view, everything we do is a black box. They do not get to hear the analysis of the problem, the discussions around the suggested solutions or strategies for migration and release, they just see the cryptic drawings on the white board afterwards.
This problem is then further exacerbated by the fact that engineers are usually incredibly bad at explaining technical concepts to non-technical people. Most of the time we simply avoid talking to the rest of the business at all. We are perfectly comfortable just hanging out with the other engineers. When we are asked to explain some aspect of our system we tend to go into so much detail that anyone who hasn’t worked on that exact piece of code will have no way of following what we are saying.This often leads to the person asking leaving with the feeling that they understand the system less than before they asked.
So maybe we should not be so surprised that our colleagues are looking to replace us. They have little understanding of what we actually do and every time they have a question we make them feel stupid for asking.
It’s Business Time
The current AI hype might not actually pose a real threat to engineers but the fact that most of our colleagues do not understand the value that we bring is a serious problem that we need to address.
We need to start meeting our colleagues where they are and explain what we do in ways that make sense to them. The goal is not to turn them into engineers but to help them get a high level understanding of what it takes to build a software product.
Everybody wins if we can help level up their technical understanding. They will have a better knowledge of the product which will help them better market it and sell it to potential customers. We will have a much easier time explaining why some feature requests require more time than others, and why some features might not work as well as they seem on the surface.
If you are a mid to senior level engineer the best skill set you can acquire is to learn to communicate well with your non-technical colleagues. If you are the person that can explain complex concepts in a simple way then you are the person they will go to and you will stand out.
We need to start paying attention to the business we are working for. Many software engineers find it much too easy to just ignore the business around them and focus exclusively on the technical domain. The world of computers makes sense. It is rational. When you introduce users into it everything gets complicated so it can be tempting to just blame the users or to think that we know better. Users DO complicate everything, but they are also the point of all this. Your job was never to write code, it is to solve problems for your users. They are why we have a job. You need to talk with the users, empathize with them, understand their problems and feel their pains. This is much too important to be left exclusively in the hands of product managers and designers. You are the problem solver, so you need to fully understand the problem.
When we start changing our self image to be problem solvers rather than coders, then we can start getting other people to see us that way too. Then and only then will our colleagues start to understand that the software engineers, along with our design colleagues, are not a cost center for a company, but the very heart where the company's true value is generated.