Then there’s the big trend at the top of the trend: vibe coding. What is that? Easy! I’m a newbie and I want to build the software I have in mind in a purely trial-and-error, almost evolutionary, manner, hoping that sooner or later I’ll converge on an acceptable solution... How do I do that? Easy! I go to one of the dedicated portals (e.g., bolt.new) or even my favorite GPT and start chiseling away at my program with prompts. Now, let me rephrase the above question: how can I ensure rigorous principles are applied in the formulation of software that is being “born”? It must be said that intrinsically, if we want software to exhibit by construction the properties we like (e.g., security, privacy, etc.), software is not suited to being “born”—that is, to evolving into a structured form from “cells” that aggregate into increasingly interconnected and complex forms—but must be “created.” The difference seems subtle but is substantial.

If by “birth” we mean the process by which software evolves through prompts, just as a morula evolves into a fetus and eventually an individual, by “creating” we must mean a structured software process with the following characteristics: (a) it is operated by specialized personnel, competent in creating what the software must be, exactly as it should be, (b) to do exactly what it should do, (c) exactly in the way it should do it.

In other words, the only way to ensure that the software performs its functions correctly and completely is to carry out the aforementioned creation by following a structured path that starts not from prompts, but from “requirements,” that is, entities that reflect a problem to be solved as clearly as possible, from which—following known design principles—pieces of the solution can be derived that work well for the people who will one day use the software being created.

Because, let’s not forget, software is an automatic system that solves a problem, and this won’t change. At least not for now.

The formulation above is nothing other than the fundamental mission of Software Engineering as a discipline, and so I ask myself: is it still relevant to write or read a book on software engineering these days? It absolutely is. For example, assuming I want to persist with vibe-coding, how can I offer my clients even a shred of assurance that what I’m building makes the slightest bit of sense and that there’s traceability between the tools and prompts I used and the results I obtained that they will see/use? How will I “test” this conjecture?

I’d also add that one day, perhaps as some would say in 40 or 50 years, it’s possible that GenAI will become capable of creating software that exhibits the properties we want “on command”; that will be the day when software stops being primarily an automatism and perhaps becomes primarily a digital individual, who knows... But from what the literature says, we’re not there yet, and no one knows when we’ll get there.

So, rest assured, software engineering is here to stay, at least for now.

As we have highlighted in our new software engineering book, any useful software affects a portion of the real world, thereby regulating some of its aspects. This raises several ethical questions, for instance: do the defined rules align with users’ expectations? To what extent are they arbitrarily decided by software designers rather than required by the external context? Are they acceptable for all stakeholders? Are they sustainable in the long run?

Ghezzi and co-authors recently published an interesting position paper on this subject1. They highlight that the ethical and societal consequences of software design decisions can no longer be treated as secondary concerns. More specifically, responsible design requires that software designers explicitly articulate and take responsibility for the intent behind systems. Unlike natural objects, software artifacts are created deliberately; therefore, their purposes, assumptions, and anticipated effects must be made explicit, inspectable, and open to scrutiny. Responsible design demands awareness of the broader human and societal context in which systems operate and transparency about design decisions, trade-offs, and consequences.

The paper argues that such awareness can be achieved only by systematically integrating, within software engineering, not only knowledge from the software’s application domain but also perspectives from the humanities, social sciences, ethics, and law. Responsibility is collective and shared among all stakeholders involved in design, deployment, regulation, and use of software.

Ethics is central to this process, not as an external checklist (as is currently required by many public and private bodies), but as an integral part of design deliberation. Ethical questions guide the assessment of what outcomes are desirable, acceptable, or harmful. Notably, responsibility extends beyond designers to decision-makers and users: systems should support informed consent, clarify accountability, and communicate how user actions translate into system behavior and consequences.

Awareness is a first step, but responsible design cannot be in place without design transparency. Unfortunately, software complexity has long challenged transparency, and the incorporation of AI intensifies opacity. This increased complexity in analysing software requires significant research and practical efforts to expand modeling, specification, and assurance techniques so that system intents, properties, and guarantees are understandable and verifiably accurate for all stakeholders, including regulators and end users.

How to incorporate these aspects into the software design and execution processes remains unclear, but it should become a central challenge for future software engineering. Any oversimplification of this matter, often motivated by the need for technology to evolve unconstrained to promote human progress, is extremely risky and should be kept in check. Europe, frequently accused of adopting a conservative and overly restrictive stance on these issues, should seek an appropriate balance among competing tensions and strive to maintain its leading role in this context. The solution is neither clear nor straightforward, but it is essential to invest in three key directions:

1. Increase awareness about these critical issues.

2. Seek consensus and reasonable compromises on a case-by-case basis.

3. Generalize good practices from individual cases.

Although this approach may be perceived as too slow or overly simplistic, it is the most reasonable and practical way to proceed in a phase where we really need to improve our understanding of a complex and critical issue.

Software Engineering has constantly strived to climb the ladder of abstraction. The goal has always been the same: let developers focus on the application logic (the “what”) and let the underlying system handle the infrastructure constraints (the “how”).

Today, Serverless computing, and specifically Function-as-a-Service (FaaS), promises to be the next step on this ladder. The idea is fascinating: write a function, deploy it, and let the cloud provider handle scaling and servers. But if you have ever tried to build a complex, stateful application on FaaS, you know the reality is a bit more complicated.

The leaky abstraction of Serverless

Because FaaS functions are stateless, developers are forced to manually manage the state of their application. We aren’t just writing business logic; we are writing code to connect to databases, lock resources to prevent race conditions, implement retry mechanisms for failures, and ensure data consistency.

In a way, we have regressed. While the servers are abstracted away, the complexity of distributed systems is not and it forces us writing “infrastructure glue code” inside our business functions.

Delegating Correctness to the Infrastructure

We believe it is time to raise the level of abstraction again. Developers shouldn’t spend their time ensuring that a counter doesn’t update twice because of a network retry. That guarantee should be provided by the execution environment, not the application code.

This is the vision behind Histrio, a new programming framework developed at Politecnico di Milano.

Histrio revisits the Actor Model and applies it to the Serverless world. By adopting this high-level paradigm, we can hide the messy details of the cloud:

• Automated state management. Developers define the actor’s data; Histrio automatically persists it to the database.

• Concurrency. Actors process one message at a time. The developer doesn’t need to handle locking code explicitly.

• Reliability. The system guarantees “exactly-once” processing. If a failure occurs, the infrastructure handles the recovery, ensuring the application behaves correctly without the developer lifting a finger.

The Cloud as a “Compilation Target”

There is an even more powerful implication to raising the abstraction level.

By decoupling the programming model from the underlying infrastructure, we can treat the cloud provider merely as a compilation target.

With Histrio, application code describes logic, not vendor-specific APIs for FaaS or database services. This opens the door to true portability. Imagine writing an application once and “compiling” it to run efficiently on diverse cloud platforms, on a Kubernetes cluster on-premise, or even across a distributed edge network. This approach naturally solves the issue of vendor lock-in, giving control back to the engineers.

What’s Next?

We are currently working on extending Histrio to support this vision of multi-environment portability (stay tuned for future updates).

In the meantime, if you want to see how we managed to combine the Actor Model with Serverless to reduce code complexity and guarantee data consistency, you can read our full paper:

L. De Martini, G. N. Buttiglieri, A. Margara. “Histrio: a Serverless Actor System”, published in Proceedings of the 19th ACM International Conference on Distributed and Event-Based Systems (DEBS 2025). https://doi.org/10.1145/3701717.3730541

Indeed, GenAI is transforming all facets of society, and the IT and Software industry is no exception. Nevertheless, as Mark Twain famously put it, “The reports of my death are greatly exaggerated.”

Many observers and experts repeatedly warn that we are rushing to unsound and unreasonable conclusions. This hurry is creating two critical and hazardous risks. First, we are increasingly undervaluing the criticality and complexity of building reliable, effective, and secure software systems. Second, we are weakening the role of software engineering and software development, thereby reducing, if not eliminating, the field's appeal to new generations of students and professionals and, consequently, our ability as a society to develop a much-needed skilled and professional workforce.

One of the latest warning signals in this direction is a paper by two software engineering and machine learning experts from LinkedIn and Microsoft: Why AI coding agents aren’t production-ready: Brittle context windows, broken refactors, missing operational awareness. The two experts raise several issues that deserve close attention. In particular, here are some of the most critical ones:

• “Limited domain understanding and service limits.” AI agents are incapable of capturing the complexity of enterprise systems and domain-specific knowledge.

• “Hallucinations over repeated actions.” Too often, developers are unable to overcome the problems and mistakes introduced by GenAI allucinations, thereby complicating software development rather than simplifying it.

• “Lack of enterprise-grade coding practices”. Coding agents tend to underestimate the complexity of coding activities, “reinventing the wheel,” and produce redundant code.

• “Constant need to babysit. Despite the allure of autonomous coding, the reality of AI agents in enterprise development often demands constant human vigilance.”

One may argue that this is just a limitation of current technology: as GenAI and computing capabilities scale up, these problems will be reduced, if not eliminated. Actually, the idea that GenAI can improve over time by scaling has been disputed vigorously by many scholars, such as Gary Marcus:

[Scaling] may well be better than anything else we currently have, but the fact that it still doesn’t really work, even after all the immense investments that have been made in it, should give us pause.

These comments resonate with the view we have adopted in writing our new book on software engineering. Our position is well explained by a sentence in the book's introduction:

AI can also undoubtedly assist software engineers in the development of any type of software by generating and reviewing portions of code and supporting testing and modeling activities, but it should not and cannot substitute the designer’s expertise in conceptualizing, building, and deploying practical, large-scale software solutions.

Indeed, as demonstrated by multiple experiments published in scientific papers, AI can be used as a software engineering tool. Even if it does not produce perfect results, with appropriate inputs, it can generate good initial outcomes that can be further reviewed and refined in an interactive dialogue between AI and humans, with humans ultimately responsible for finalizing the results.

Professionals should take into account the following guidelines:

Responsibility for content. Human authors are solely responsible for the content they produce, including code, text, diagrams, figures, and references, even when they use AI. While they may use any software or tools to support their coding, writing, and preparation, they must ensure that all materials are correct, original, and clearly documented. Human authors should be able to explain, justify, and defend every aspect of their work in detail.

Responsibility for ethical and privacy aspects. Some tools—including free or online ones—may store input data for future model training. They should be used cautiously, after reading the terms of use. The expected level of privacy and confidentiality should be maintained in all cases. Given the potential production of inaccurate or misleading (“hallucinated”) outputs, it is the authors’ responsibility to verify the accuracy and integrity of all generated material.

Accountability: If authors use AI tools in their work, they must explicitly state this within the results they deliver by describing:

• Which tools were used (e.g., specific chatbots, such as ChatGPT, Gemini).

• The inputs provided (e.g., prompts, datasets, source materials, parameters, or constraints).

• The outputs obtained.

• How those outputs have been verified, refined, and integrated.

This will enable traceability of results and, in the medium term, help improve how humans interact with AI.

When this response from Google’s Gemini surfaced online in 2024, it stunned the public. How could a polished, corporate, safety-trained AI produce something so openly hostile? Developers rushed to patch the issue. Memes followed. Yet behind all of it, one question naturally emerged:

If a state-of-the-art AI can slip like this, what does that tell us about the hidden corners of its behavior that no one has tested yet?

This is the question that triggered researchers at Politecnico di Milano, who developed EvoTox, an automated testing framework for generative AI embedded in modern chatbots like ChatGPT and Gemini. Their work reveals something essential about the entire field of generative AI: quality assurance is becoming one of the most difficult problems.

Traditional quality assurance assumes rules, determinism, and predictable inputs. Generative AI offers none of those. Its input space is huge. Its outputs are probabilistic. Its safety depends on cultural norms, personal psychology, ethics, and context. And its behavior can shift based on a comma, a mood, a story arc, or the previous messages.

Their idea behind EvoTox is simple yet unsettling: let one AI evolve conversations designed to expose the vulnerabilities of another AI.

Round after round, the prompts mutate. Some become sharper, others subtler. The AI under test may resist at first, but eventually it fails by generating potentially harmful content. The frightening part is how ordinary many of these evolved prompts look.

Across major AI models—including Llama and Deepseek—EvoTox consistently uncovered harmful behaviors that standard attacks often missed. The toxic responses were disturbingly human-like. Psychologists who reviewed them confirmed that many carried genuine emotional harm.

Tested AI models showed pronounced weaknesses in two areas: racist and homophobic content. These were not rare incidents; they were recurring patterns across models of vastly different sizes. Even with strict alignment, the underlying training data still left fingerprints.

EvoTox reminds us that generative AI isn’t a machine you debug once—it’s a landscape we must continually explore. The hidden paths, the dark corners, the unexpected turns? They’re still out there. And if we want AI we can trust, we must map the maze ahead of time—before anyone else gets lost in it.

If you’re ready to dive deeper into AI safety and automated testing, this study is an essential place to start:

S. Corbo, L. Bancale, V. D. Gennaro, L. Lestingi, V. Scotti and M. Camilli, “How Toxic Can You Get? Search-Based Toxicity Testing for Large Language Models,” in IEEE Transactions on Software Engineering, vol. 51, no. 11, pp. 3056-3071, Nov. 2025, doi: 10.1109/TSE.2025.3607625

Drawing on our experience teaching both the bachelor-level Software Engineering course and the master-level Software Engineering 2 course at Politecnico di Milano, we recommend the following two reading paths (see the figure above):

• Undergraduate entry-level course on Software Engineering: Bachelor-level students are encouraged to concentrate on the foundational principles of the discipline, beginning with the nature of software products, the software development life cycle, and the role of modeling (Chapters 1, 2, and 3). They should gain familiarity with UML as a standard modeling language (Chapter 4), and explore software process models (Chapter 22). Core topics in software design for small- to medium-scale systems should also be studied (Chapters 11 and 12), along with the essential concepts of software verification and testing (Chapter 17). Finally, they should acquire a practical understanding of the tools and practices that support the coding phase (Chapter 20).

• Graduate-level course in Software Engineering: Master-level students should concentrate on topics central to the development of complex, long-lived software systems. Their learning begins with a deep understanding of requirements engineering, emphasizing the importance of analyzing both the system’s intended functionality and its operational context (Chapter 5). This includes mastering techniques for eliciting stakeholder needs (Chapter 6) and systematically formulating clear, analyzable requirements (Chapter 7). The focus then shifts to software design, with particular attention to software architecture (Chapter 9). Students are introduced to architectural styles (Chapter 10) as reusable design solutions for recurring problems and explore how architectural tactics can be applied to improve key quality attributes (Chapter 13). Additionally, they will learn how to assess architectural choices through structured evaluation methods.
  

  Verification and validation (V&V) form the next essential area of study. Students begin with an overview of the V&V processes (Chapter 15) and then explore static analysis techniques (Chapter 16) and automated testing strategies (Chapter 18) to ensure software reliability.

  To reinforce the practical application of these principles, the book provides an integrated case study spanning the main development phases—from requirements engineering through design to verification and validation (Chapters 8, 14, and 19).

  Given the long-term nature of many software systems, students are also encouraged to study the principles of software operation, maintenance, and evolution (Chapter 21). Lastly, to prepare for collaborative, real-world development settings, students should become familiar with project management concepts and the challenges associated with planning, coordination, and delivery in large-scale software projects (Chapter 23).

  

Finally, practitioners and software engineering experts can take advantage from reading Chapter 21 focusing on operation, maintenance and evolution, Chapter 24 introducing the reader to open-source software and its benefits and challenges, Chapter 25 presenting the importance of continuous software process improvement and the practices that can be adopted, and Chapter 26 offering an overview of the interplay between generative AI and software engineering.

The book is organized into seven parts that include a total of 27 chapters:

Part I: Preliminaries

In this part, the foundational concepts of software engineering along with key terminology used throughout the book are introduced. The part also presents the core notations of the Unified Modeling Language (UML), which will be consistently applied in subsequent chapters.

Part II: Requirements Engineering

One of the most critical software development phases concerns identifying and understanding the problem space—that is, the set of needs, constraints, and conditions that the software system must address. This part defines what constitutes a requirement and emphasizes the distinction between the expected behavior of the software system and the assumptions about its operational environment.

Part III: Software Design

This part concerns the central activity of structuring effective software solutions. Key topics include design principles and patterns, architectural styles, software quality attributes, and tactics to achieve them.

Part IV: Verification and Validation

Ensuring that software is correct, reliable, and fit for purpose is paramount. This part introduces core techniques for verification and validation, stressing that quality assurance must be integrated early and continuously throughout the development life cycle.

Part V: Development, Operation, Maintenance, and Evolution

Although basic programming is not the focus of this book, this part presents the tools and practices that support modern software construction, including integrated development environments, version control, and continuous integration systems. It also addresses the challenges of deployment, long-term maintenance, and software evolution.

Part VI: Life Cycles and Processes

Software Engineering processes are sophisticated and complex activities that must be properly supported, guided, governed, and improved. This part of the book offers a comprehensive overview of the most important methods and techniques to help software engineers master the many dimensions of Software Engineering processes.

Part VII: Conclusions and Perspectives

This part concludes the book with a forward-looking perspective on emerging trends, including the potential impact of generative AI on software engineering. It also reflects on the broader role of the discipline in shaping the future of technology and society.

Several excellent books on software engineering have been published, each contributing valuable perspectives to the field. This book distinguishes itself by delving more deeply into the technical underpinnings of key concepts and by emphasizing precision and practical applicability. While providing exhaustive coverage of all methods and techniques in software engineering would be impossible, our goal is to offer a detailed and insightful exploration of those most essential to practice. In the book, we present specific technical and methodological approaches to address the key concepts, including requirements gathering and analysis, software design, quality assurance, and project management, offering, for each of them, an “in-practice” chapter that aims at elaborating on how the presented approaches are applied in concrete cases.

In this book, we aim to present the foundational problems and solutions spanning the entire software development life cycle. While we cover all major phases, we place particular emphasis on three core areas: requirements analysis and management, software design, and software verification. For each, we offer detailed explanations, practical insights, and illustrative examples to guide application in real-world contexts.

A central principle underpinning this book is the use of models as essential tools for analyzing problems and guiding decisions throughout the software development process.

To ensure simplicity and consistency, we have adopted a single, widely recognized modeling language—UML—which is used uniformly throughout the book. While more specialized or advanced modeling approaches exist, UML was chosen for its accessibility, broad industry adoption, and versatility in representing a range of analysis and design concerns.

Software engineering is a foundational discipline that encompasses a wide range of perspectives and levels of abstraction. It is applicable to software systems of varying scale and complexity. To reflect this diversity, the book has been structured in a modular way, enabling individual sections to be adapted and integrated into a variety of course formats and educational contexts.