Is Software Engineering really dead in the Artificial Intelligence (AI) era? This question is both provocative and widely debated. It is generating a great deal of discussion on social media and among software developers in general. In this post, I share my perspective on the issue.
Let’s start at the beginning.
The prediction
If you work as a software engineer and regularly browse social media platforms such as LinkedIn or X, you will most likely come across an unsettling prediction:
Software Engineering will be dead in less than one year.
It is a harsh statement, but it reflects a belief that is in fact widespread. If you think about it for a moment, there is some logic to it. State-of-the-art AI coding assistants, such as Claude Code, are incredibly powerful. They have reached a level of capability that would have been hard to believe just a few months ago.
This technological reality has led many people to believe that we no longer need programming languages. We can describe software behavior in plain English, and, if the result is not what we expect, we can simply refine our words until the software behaves as we want. In this view, we do not need software engineers. Anyone can build software because coding is automated. AI has raised the level of abstraction to a point where natural language is enough to tell computers what to do.
Where, in my opinion, the prediction goes wrong
The prediction rests on two premises:
From natural language, AI coding assistants can generate source code (in a high-level language such as Python, Kotlin or C++).
From source code, compilers can generate assembly code (or a binary executable representation).
While these two statements are true, a subtle detail causes the prediction to break down: the first premise is not a deterministic transformation. Given the same sentences in natural language, there is no guarantee that we will obtain the same source code. This is because AI coding assistants do not follow a fixed procedure. They rely on probability distributions: they make choices based on what seems most likely to be correct according to patterns learned from millions of examples in their training data.
This is more relevant than it may seem. It means that we lose control of the software that we are building. Let’s illustrate it by means of an example.
A realistic example
Imagine a team that is responsible for a live production system. None of the team members are software engineers, so they lack technical knowledge. Instead, they maintain the system exclusively using AI. Suddenly, the system starts malfunctioning due to a critical bug. The team tries to fix it using natural language, but every attempt fails. What can the team do? The only option is to dig into the source code, but they can’t because they are not software engineers.
The takeaway is that a probabilistic tool cannot be held responsible for a live system, especially if it is safety-critical. There will be times when we need control: moments that demand certainty, not probability.
Those who claim that software engineering is dead would not trust the software that runs their company entirely to AI. They’d put humans who deeply know the system in charge.
Building a throwaway app quickly is one thing. Maintenance of a product with long-term profitability is another.
When software must stand the test of time, it must be built in a way that others can maintain it long after you are gone. It must be built with quality attributes (such as testability and code readability) in mind, and these attributes remain primarily the responsibility of humans, not machines.
An understandable trend
While there is no evidence that source code will lose its relevance or that professional software can be entirely developed and maintained by AI, I find the trend understandable.
My impression is that, in the software industry, many developers (and even more non-technical roles such as managers or salespeople) have never cared much about code and its quality. Technical practices such as the ones proposed by eXtreme Programming (XP) are the exception, not the norm. Any software engineer with a few years of experience has likely worked on a legacy codebase that is difficult to understand and change, or on a team that is unwilling to pair-program, write automated tests, or refactor code.
These are the people who claim that Software Engineering is dead. They have never been enthusiastic about code quality, so why would they start now? This is the perfect opportunity to ignore engineering practices without guilt.
In the era of AI, the challenge for us, software engineers, is to show that code quality (and the practices that enable it) matter today as much as they ever have, and perhaps even more.
The two audiences of code
Many people argue that we should stop paying attention to AI-generated code. After all, software engineering is dead, right?
I strongly advice the opposite.
In the age of AI, machines not only execute code; they care about meaning and intent, which makes readability relevant for machines as well. Does it make sense to stop reading code and caring about its quality now that code has two audiences: humans and machines?
AI agents do not inherently produce well-crafted code. They are not optimized for craftsmanship during their training. They may miss abstractions, introduce duplication, or choose inappropriate variable names, for example. It is our responsibility to address these issues. Continuous refactoring is the only way to improve code quality over time, and higher-quality code reduces the likelihood that AI agents misinterpret your intentions when reading code, making AI agents less likely to make mistakes.
Continuous refactoring is also crucial at the level of system architecture. There is a limit to how much a person can hold in mind at once, and the same applies to AI agents. The more you ask an AI agent to focus on, the less attention it can give to any individual part. Context should be minimized to make code easier for AI agents to understand. This is why separation of concerns is such an important design principle. Just as higher modularity reduces cognitive load for humans, it also reduces contexts for AI agents.
The problem is that AI agents tend to struggle at larger scales because they are better suited to local context, not global reasoning. This leaves software architecture primarily a human-driven activity.
Engineering practices
The relevance of software quality strongly suggests that Software Engineering is far from dead, but we can make the argument even stronger. Software Engineering is not only about code. It encompasses all the engineering practices that enable quality and sustainable delivery of value to customers. Unsurprisingly, the engineering practices that have proven effective for decades seem to be the perfect fit for this new era of AI-assisted development.
What role do these practices play?
AI agents have undoubtedly increased coding speed, but this does not necessarily translate into delivering more value to users in less time. Ultimately, it depends on the team.
In a team where code is not frequently integrated into the main branch, increasing coding speed will lead to more merge conflicts, and will make these conflicts bigger and harder to resolve.
In a team where deployments are not automated, increasing coding speed will create more work for operation teams.
In a team where testing is treated as an after-development phase, increasing coding speed will create more work for QA teams and more bugs to address later, when they are more expensive to fix.
In a team where collaboration is weak, increasing coding speed will result in more rework and misalignment.
In such a team, coding is not the bottleneck; the way the team works is. Optimizing a non-bottleneck in a system that has real bottlenecks will not make the system more efficient. It will probably make it less so.
The key to being effective with AI coding assistants is to be effective without them [1]. A team that works in small batches and follows time-tested practices such as refactoring and continuous delivery will benefit from a huge boost in productivity when using AI tools. A team that lacks discipline may feel an initial surge in coding speed, but it will lose traction with each passing day, as technical and comprehension debts accumulate.
Healthy and productive teams
In addition to engineering practices, the composition of teams within a software company can also affect how effectively the company leverages AI.
In a company where teams are organized around specific skill sets (such as QA, front-end, business-analysts, DevOps, etc.), customers will not receive value any faster because delivering software requires extensive inter-team communication. In this context, coding is clearly not the bottleneck, so accelerating it will have little positive impact.
Note that the same bottlenecks can arise within a team if members are overly specialized. To fully benefit from AI, teams need to be cross-functional and team members must maintain healthy and effective communication.
Last but not least, the team requires autonomy. In command-and-control hierarchies, where decision-making is slow and managers do not trust the team, increasing coding speed will have little effect because the team will spend most of its time waiting for approvals. The team must be empowered to make decisions on the spot, as they are needed, in the same way as continuous activities such as code integration, testing, or refactoring.
Conclusions
Contrary to what many believe, Software Engineering is far from dead. Coding is not fully automated, and even if it were, Software Engineering is not only about code. Teams must be effective without AI to fully benefit from AI coding assistants. Engineering practices such as continuous integration and refactoring, which promote clean and readable code, are essential to ensuring that AI adds value, rather than becoming a source of technical and comprehension debts.
There is no denying that state-of-the-art AI coding assistants are remarkably capable today, but the main implication is simply that software engineers have an incredibly powerful tool at their disposal.
Coding has changed forever. Software engineers must adapt to this new era, just as they have countless times before, at historical milestones such as the introduction of the first compilers and high-level languages, or the rise of the World Wide Web. This time is no different.
References
[1] Jason Gorman, The AI-Ready Software Developer (2025)
