In the AI Era, is Software Engineering obsolete?

TL;DR

I disagree.

Complexity

If I had to summarize software engineering in one objective, it would be to build a system whose complexity is the minimum necessary to solve a problem, the complexity already inherent in it. Most failures stem from excessive complexity, and failures are what we want to avoid.

In the end, there are infinite ways to implement a system, and usually the challenge isn’t finding any one of these (feasibility), almost everyone succeeds in one way or another, but finding the best one (quality). Typically, the simplest among the correct solutions is also the best, or at least one of the best.

Complexity is today the great enemy of AI applied to software development. It operates on two different fronts:

• AI struggles to understand complex systems and contribute correctly to them
• AI tends to produce systems that are more complex than necessary because it has poor synthesis, abstraction, and refactoring capabilities

So when applied without methodology, AI produces systems that it itself struggles to understand. For this reason, I believe that applying software engineering principles is important, I would say fundamental, to harness AI’s multiplicative potential in development. If you want to achieve good results not just on prototypes and POCs, this is exactly the path to follow.

Modularity

Among all software engineering principles, the one that I believe gains the most importance in the AI era is modularity (high cohesion and low coupling). This is what allows us to apply divide and conquer to a system, through which we can decompose a complex monolith into a set of simpler and decoupled components. This has several major advantages:

• We can use AI to work on small, simple modules with limited context that is less expensive and less prone to LLM hallucinations
• We can limit the side effects of an AI-generated modification, in which we have less confidence, to the perimeter of a module
• If we can identify common patterns, we can have AI work from examples and obtain more accurate results
• It facilitates refactoring and replacement of system parts, which will be more frequent in a much more dynamic context

AI Forces Us to Be Better Engineers

In every classic software engineering course, we were taught that implementation is just one of many steps in the development process. Then in many cases (I hope not all, but don’t lie to yourselves saying it never happened) we found ourselves developing features or entire software where:

• Requirements were partial, fragmented and uncertain
• Analysis and design were reduced to a minimum and we replicated recipes we were comfortable with without asking whether they were suitable for the problem
• Implementation was 90% of the effort
• We would do testing later…
• Deployment and releases, for now it takes so little time to do them manually

Today we discover that with AI we can speed up, perhaps even automate, implementation. We immediately have the illusion of drastically reducing that 90%. But it’s an illusion, precisely because to do it effectively, we need exactly those other process steps:

• Clear, complete, and formalized written requirements
• Analysis capable of decomposing the problem and reducing its complexity, and design of solid and modular architectures
• Extensive test coverage that allows us to catch errors in code not written by us and gain confidence in it
• CI/CD pipelines to support more frequent development and release cycles

This is fantastic! It’s a great opportunity to convince ourselves and our stakeholders that “peripheral” activities are not useless decorations, but rather those with true added value. Implementation, too often perceived as the main activity of a software engineer, becomes a pure formality. Who knows, maybe the only process step truly 100% automated.

AI Everywhere

The question I’ve already been asked is: couldn’t an AI agent also handle these other process steps, in addition to implementation?

What it will be able to do in the future is difficult to predict, especially in the long term. I maintain that if it reaches a level of accuracy capable of competing with an engineer on analysis, design, and stakeholder communication activities, then perhaps it will be able to directly solve the problem for which we’re trying to create software, and the activity itself will no longer be necessary a priori. I believe it’s a possible future, but certainly not a near one.

Today, AI certainly has much lower effectiveness in activities involving human interaction (understanding and analyzing requirements) and abstraction, which is the foundation of design. These remain activities where engineers have great added value, in my opinion.

This doesn’t mean AI stays completely out of it, quite the opposite. It’s an extremely useful tool for increasing speed and precision, but not autonomous. Here are some examples:

• The analysis phase often involves information research, and AI makes it faster and more accurate (think of tools like Perplexity)
• I find it very useful to ask an LLM for feedback on architectural decisions because it often lists considerations or options I had missed
• Summarizing, schematizing, and formalizing requirements written in natural language are activities it does very well and that improve the accuracy of downstream processes

Conclusions

In summary, I firmly believe that proper application of software engineering principles is a necessary condition to enable effective and valuable use of AI in development. I flatly reject the idea that because AI will be able to automate system production and maintenance, their quality will not be a stringent requirement.

I remember a quote from Leslie Lamport: “People confuse programming with coding. Coding is to programming what typing is to writing.”

I would like us to remember that we are software engineers and not just coders. We should use much of the time saved to build better products with better processes.