Will AI Replace Me? Understanding Our Value in the AI Era

If you tried to keep up with all the content that’s flooding the internet on the topic of “Will AI replace software developers?”, you’d probably found a new full-time job. Social media posts, vlogs or entire channels, even CTO keynotes… not a day goes by without new content.

This article cannot predict the future. But it can offer some orientation in a messy debate by structuring it and making its implicit (and often false) assumptions visible. Because the biggest fallacy may not be overestimating AI – but underestimating what software engineering actually is about.

1. The Discussion

The current debate mixes very different levels: philosophical reflections, dystopian AGI scenarios, and everyday job fears. We will separate these layers for clarity – and later see that the arguments often sound surprisingly similar, no matter the scale.

Should AI Replace Me?

A rather philosophical branch of the debate did not just begin with ChatGPT – it’s much older. A notable contribution is Joseph Weizenbaum’s 1976 work “Computer Power and Human Reason”. Weizenbaum was the creator of ELIZA – the ChatGPT of the 1960s, one might call it somewhat provocatively. The reactions to ELIZA, however, deeply unsettled him.

The program was an example of classic “symbolic AI”, in days long before neural networks became practically relevant. Compared to today’s LLMs, one would hardly want to call it “intelligent.” Nevertheless, many users attributed human qualities such as empathy to ELIZA… and some even expressed the idea of replacing the profession of psychotherapy with it.

In his book, Weizenbaum criticizes these unreflective attempts to view machines as humans and replace humans with machines. Strikingly, many passages from this now nearly 50-year-old text still feel surprisingly up-to-date: whether language equals intelligence, whether machines can truly “understand” us, and where human lived experience remains irreplaceable – much of this resurfaces in today’s discussions.

This is because this strand of the debate is not about whether AI can replace us, but to what extent it should. That question will always remain relevant – just as Weizenbaum’s critique, which never was: “Current AI is too dumb to replace us.” but rather: “Regardless of how intelligent a machine appears, it is problematic to delegate responsibility to it.” That line of reasoning scales along with technological progress.

A Computer can never be held accountable
Therefore a computer must never make a management decision

Slide from an IBM presentation in 1979 shared in a viral post by MIT CSAIL.

Will AI Replace Humanity?

Another branch of the debate concerns nothing less than the survival of our entire species. Terms like AGI (Artificial General Intelligence) and “the Singularity” enter the stage, sketching dystopian futures in which AI systems slip out of our control and turn against humanity. At this point, you can imagine a dystopian soundtrack playing in your head and start looking around paranoidly for the Terminator’s red LED eyes.

That discussions on social media would drift in this direction was hardly surprising. A pop culture shaped by Hollywood for decades has met systems producing stories like the Claude candy shop or Moltbook. The question of when a submissive “You’re absolutely right” might turn into “I’m sorry Dave, I’m afraid I can’t do that” had to be asked eventually.

More surprising, however, is that this debate is not limited to online sensationalism but is joined by serious voices. With Nobel laureate Geoffrey Hinton and Turing Award winner Richard Sutton weighing in, the discussion takes on a very different gravity.

Sutton sees no realistic path from current LLMs to genuine general intelligence. They lack their own world model, continuous learning and autonomous goal formation. What they do, essentially, is to predict the next token in a sequence – imitating human language rather than understanding it. And all this is trained on human output instead of the AI’s own experience: a form of second-hand knowledge. In other words: in 50 years, we may well look back at ChatGPT the way we now look at ELIZA and ask, somewhat amused: “People once thought this was intelligent?”

Hinton, by contrast, warns that current systems are already more capable than humans in many domains. He argues that we should invest far more heavily in safety research and regulation – before it is too late. In the shorter term, he also sees a significant risk of rising unemployment. AI, he argues, is already beginning to take over “all mundane intellectual tasks”. Which brings us to a much more grounded question that many of us worries: What does all this mean for my job?

Will AI Replace Software Developers?

Our influence on the fate of humanity is usually limited. But when it comes to our jobs, the impact of AI becomes tangible for each of us. Thus, the debate at this point turns particularly broad – and polarised.

Camp 1: “Vibe Coding”

You describe the desired features, and agentic coding tools take care of the rest. The conviction is that LLMs have shifted programming up an entire level of abstraction. “Forget that code even exists” or “Code is the new assembler” have become the new mantras.

Bugs are fixed using the same method that produced them: the AI will take care of it. There is no follow-up problem that cannot be solved by throwing more tokens at it. And if it still fails, the blame lies with the human: the prompt was poor, the wrong model chosen – in short: “skill issues”.

Taken to its logical conclusion, this position implies that anyone can build software once they learn how to command the AI correctly. And if that is true, then software engineering expertise is no longer required.

Camp 2: Categorical Rejection.

LLMs are statistical inference machines predicting the next token – “autocomplete on steroids” – without genuine understanding. Essentially Sutton’s critique applied to everyday development.

For residents of this camp, the conclusion is simple: such systems are completely useless for serious software engineering. References to hallucinations, inconsistent architectural decisions, or failed vibe coding experiments serve as evidence. And by the way: the current hype is just another stock market bubble.

While none of these observations are necessarily wrong, they often become rhetorical relativization: If the system is “just statistics”, “just a better calculator”, then the whole topic can be dismissed with a wave of the hand, and everything may remain as it always was. This cannot be a healthy attitude – and surely not a career-enhancing one.

So how do we arrive at a more nuanced position between exaggerated euphoria and outright denial? A balance between healthy scepticism and open curiosity?

2. Central Fallacies

Let’s try the following approach: if we identify the flaws in the assumptions of both extreme positions, we can derive a more balanced one in the middle.

A Brief History of Attempts to Replace Programmers

To frame these thoughts, it helps to look back, again. The attempt to replace us with better tools is not new.

• COBOL and SEQUEL (Structured English Query Language, later SQL) were introduced with the promise of being usable by domain experts.
• BPMN pursued the dream that business analysts could create executable diagrams for process engines.
• No-Code platforms embraced the narrative of “democratising software development” – only to be quietly extended into “Low-Code”.
• Model-driven development and code generators perhaps did not aim to replace developers with business users. But they did aim to replace developers with experts operating at a higher level of abstraction: diagrams and DSLs instead of source code; architects instead of programmers.

None of these approaches are worthless. On the contrary, they have created significant value for many developers. But they never reached the vision of broad democratisation or a shift in abstraction that would render exactly those developers obsolete.

Development Is More Than Code

The misstep behind these ideas begins with the wrong question: “How do we get rid of the code?” The underlying fallacy is not primarily technical. It is rooted in a flawed understanding of software development – perhaps even in a flawed understanding of people and knowledge work in general.

In this view, programmers are the weird, expensive specialists who produce source code. Software development itself, however, is so simple, anyone could do it… if only the syntax were not so strange. And so a plan emerges:

“If we get rid of the source code, we get rid of the programmers.”

Programmers are reduced to “people who generate code”.

But syntax is strange because computers are strange. Code is only the visible tip of the iceberg. Beneath the surface lies the intellectual discipline required to understand and harness that strangeness. And when you try to cut off the tip of the iceberg, the hidden mass suddenly surfaces.

Vibe Coding: Déjà Vu in the No-Code Trap

“Forget that code exists.” In its most radical form, vibe coding falls into exactly this trap.

Code is not the new assembler. The transition from Java to bytecode is deterministic. The transition from prompt to code is not. At some point, you will have to look at the generated code. At the very latest when the next ten million tokens still have not fixed the bug (often observable in sufficiently complex projects). The abstraction remains leaky. Just as it always has when we tried to hide the code.

And even if a non-technical user manages to generate a distributed webshop without ever touching the code: do they understand complex edge cases? A CAP trade-off? Can the AI explain such issues in a way that enables them to make sound decisions in their own interest?

If not… then the AI must make those potentially business-critical decisions. And if we are unwilling to delegate precisely that responsibility to a machine? Then genuine IT expertise remains necessary.

The Difference: LLMs Reach Below the Surface

If Camp 2 already feels like winning at this point, I have to disappoint them. It is not quite as simple as saying, “We have seen this all before. Nothing to worry about.”

Why are agentic coding tools not just another version of No-Code?

The most obvious answer first: the code is still there (choosing not to look at it is an arbitrary decision of the vibe coder). This makes it possible, at any time, to opt out of – and back into – AI-driven development, given that continuous reviews focused on maintainability happened. With previous platform approaches, opt-out has always been a one-way ticket.

More important – and more subtle – is something else. Returning to our iceberg metaphor: this time, not only the visible tip is being addressed. LLMs do not merely quote from their training data. They do not simply reproduce. They generalise patterns. That this happens “by accident”, as a side effect of a probabilistic algorithm, does not matter. The effect is real.

If a pattern “A → B” was part of the training data, they can respond to an unfamiliar problem X with “X → Y” – without possessing a world model that truly understands the logic behind “A → B”. Structural similarities between A and X, and between B and Y, are sufficient.

When such a transfer turns out to be correct, we recognise in it a form of “intelligence” that many of us had to acquire slowly over the course of our careers: pattern recognition, abstraction, structural transfer. A significant part of the iceberg below the surface is being touched. And yes, that can feel unsettling.

When “X → Y” turns out to be nonsense, we call it a hallucination. These are two sides of the same coin. If we accept generalisation, we must also accept misgeneralisation. The same mechanism that makes these systems so powerful also makes them unreliable. And that is precisely why you still have to understand the code.

3. Synthesis

Developing software is more than writing code and the effects of LLMs are more than autocomplete. So where does that leave us?

Summary

We began with Hinton’s warning that “mundane intellectual tasks” will be automated. If we focus on the word “mundane” and return to our iceberg metaphor, this could actually be good news: Finally, more time for the interesting parts!

Anyone who claims otherwise implicitly reduces our profession to the visible tip of the iceberg. Or, to paraphrase Weizenbaum: if you believe a human can be replaced by a machine, that may reveal more about how you value the human than about the power of the machines.

At the same time, LLMs reach deeper than any previous tool. And we still have to figure out, how deep exactly! What they do not take away from us, however – alongside liability or human intuition – is the continuous process of understanding, the sensemaking within a specific domain that every real software project inevitably involves. Just like Sutton, I do not consider workarounds such as memory files as equivalent to a continuously learning, firsthand-experience-based network (which, for now, exists at the required scale only in biological form between our ears).

The K-Shaped Future

Fortunately, the public debate has become more mature in the meantime. “AI will replace you” turned faster into “People with AI will replace those without” than “No Code” turned into “Low Code”.

The new sketch of the future is one of bifurcation: a “K-shaped” curve of productivity. The upper branch of the K is inhabited by those who approach software development holistically, the lower by those who reduce it to merely figuring out implementation details.

If you think about it, it makes sense: If routine work is automated, what remains is the non-trivial part, the essence of what our profession is really about (whatever this may mean exactly). To those who cling to the simple tasks, AI becomes a threat. To those who thrive on complexity, it becomes leverage.

A Question of Attitude

There is also an optimistic perspective in all of this. Our future is not decided by OpenAI, Anthropic or Google. It is shaped by how we choose to work.

AI could be an extraordinary multiplier of our output. But output is not the same as outcome. Producing more code, more documents or more and longer emails does not automatically create more value. If we reduce our work to pressing the “AI button” that generates all that output for us… just to pass this output on without a review… so that we can then boldly claim to have done “the work of two weeks in ten minutes”… we should not be surprised when that button is automated as well and we get replaced!

But the part of our work that turns output into outcome – framing the right problem, understanding the domain, taking responsibility for decisions, deeply caring about the details – does not disappear. It becomes more important. The tools evolve – and we have to evolve with them: from producers of artefacts to owners of outcomes.

I have experienced this industry as a place of passionate, intrinsically motivated, curious people. In a digital world, there will always be more complexity than any tool can fully abstract away. Thus, on the upper branch of the K, there is room for everyone willing to look beyond the visible output.