The Future of Software Engineering
From the Software Engineering school at FILS to the education of the software engineer in the age of platforms, DevOps, cloud, and generative artificial intelligence.
The text below starts from a personal concern, shaped by more than four decades of contact with Software Engineering in research, industry, and education. It is neither a prophecy nor an official curricular programme, but an essay-dialogue: an attempt to formulate the questions that trouble me and to answer them from the perspective of the current transformations of the field.
For roughly twenty years I had the opportunity to contribute decisively to the creation and evolution of a Software Engineering school at FILS, both at bachelor’s and master’s level, in the English and French streams. The question that remains is what can be preserved from that school in a world in which software is developed through platforms, services, ecosystems, automation, and artificial intelligence.
An old concern in a new world
Software Engineering entered my professional life before it became, in Romania, a recognizable university discipline. I first encountered it through concrete problems: program portability, compilers, intermediate codes, macroprocessors, and then through broader questions about design, intermediate forms, the abstract machine, integrated environments, and the software process as an object of study. In industry I encountered other constraints: deadlines, clients, contracts, maintenance, compromises, changing technologies, and programs that have to work even when theory no longer provides all the answers.
I have been involved in Software Engineering for more than forty-five years, in research, industry, and education. I have lived through several paradigms: structured programming, formal methods, CASE, object orientation, Java, UML, components, the web, Agile, DevOps, cloud, and now generative AI. What is happening to the field? Does Software Engineering still exist in the sense in which we understood it?
Software Engineering exists, but it no longer has the compact form it had when it struggled to detach itself from artisanal programming. It has spread into several practices: software architecture, agile development, DevOps, platform engineering, security, cloud, data engineering, AI engineering, governance, and continuous operation. Its classical image may be disappearing, but the need that created it is not: the control of software complexity.
This is the first clarification. Software is not disappearing. On the contrary, the world is increasingly built on software. What is changing is the professional and educational form through which we learn to build it, verify it, maintain it, and make it responsible.
What is happening to Software Engineering?
In the history of the field I have spoken about a possible crisis, or even about a decline of classical Software Engineering. Is that not too strong a statement? Can a field be in decline precisely when software is everywhere?
Software is not in decline. What is in decline is a particular historical image of Software Engineering: the normative, relatively stable discipline centred on life cycles, documentation, prescribed methods, modelling separated from implementation, and integrated tools that were meant to guide the development process rationally.
This image has been eroded by three successive waves. Agile reduced the prestige of heavyweight methodologies and shifted the focus toward feedback and adaptation. DevOps and cloud absorbed development into a continuous flow of delivery and operation. Generative artificial intelligence is now changing the very act of producing code, turning the programmer into a formulator of intentions, an evaluator, an integrator, and the person responsible for the result.
The new crisis of Software Engineering is no longer the crisis of delayed large projects, as in the 1960s. It is the crisis of intelligibility and responsibility in a world in which systems change continuously, depend on external infrastructures, are built on libraries, services, and fragile APIs, and may contain code generated by statistical models that produce plausible solutions, but not always conceptually justified ones.
Software Engineering should therefore not be abandoned, but rethought. It can no longer be merely the theory of producing a program; it must become the responsible theory and practice of evolutive, distributed, AI-assisted software systems embedded in real social processes.
What is the fate of former students?
My former students are now at the peak of their careers. Many learned Software Engineering in a form that emphasized object-oriented programming, Java, design, architectures, methodologies, distributed applications, and web development. What is their fate in a world dominated by cloud, microservices, DevOps, and generative AI?
Those who learned only technologies risk being overtaken, because technologies change quickly. Those who learned to think in engineering terms are at an advantage. They have precisely the reflexes required by the present moment: to understand architectures, read large systems, judge trade-offs, manage complexity, and ask questions about quality, security, maintainability, and the cost of change.
For former students who are now professionally mature, the challenge is not to compete with AI in writing code quickly. The challenge is to become the people who know how to use AI without abdicating understanding: to verify, integrate, reject, refactor, decide, and preserve the architectural memory of the system.
From this point of view, what was taught at FILS is not invalidated by technological change. Java has changed, frameworks have changed, some platforms have disappeared, others have become dominant. But the idea that software has architecture, that design precedes and exceeds code, that systems must be maintained, and that technical decisions have long-term consequences remains more relevant than ever.
What should today’s students be taught?
What should today’s Software Engineering student learn? Can we continue to teach the same courses, merely changing the examples and languages? Or must the core of the discipline be rebuilt?
The core must be preserved, but reorganized. The student should be trained neither as a mere coder, nor as an operator of AI tools, nor as a theorist detached from practice. He or she must be trained as an engineer capable of building real software systems in an unstable technological environment.
For this reason, current education in Software Engineering should combine five layers:
- Fundamentals: algorithms, data structures, languages, operating systems, databases, networks, models of computation, logic, and probability.
- Software construction: requirements, design, architecture, testing, verification, quality, maintenance, refactoring, documentation, and configuration management.
- Modern systems: web, cloud, microservices, APIs, containers, observability, security, infrastructure as code, and continuous delivery.
- AI for software: critical use of LLMs for code, tests, documentation, analysis, migration, refactoring, and vulnerability detection.
- Professional responsibility: ethics, security, data protection, social impact, sustainability, communication, and teamwork.
A good Software Engineering school should not chase every technological fashion. It should identify the knowledge that survives change: abstraction, modularity, separation of concerns, architecture, verification, quality, evolution, security, and responsibility.
Where should the emphasis be placed?
If the number of teaching hours is limited, where should the emphasis be placed? On programming? On architecture? On AI? On DevOps? On mathematics? On projects?
The emphasis should be placed on the competence to build and understand systems. Programming remains necessary, but it is not sufficient. Architecture is essential, but it cannot be taught without concrete projects. AI must be introduced, but not as a substitute for thinking. DevOps must be taught, but not as a mere set of tools. Mathematics must be preserved, but oriented toward modelling, analysis, probability, complexity, and reasoning.
If I had to reduce everything to a few axes, I would say that the student must learn:
- to formulate the problem, not merely receive a statement of it;
- to design the architecture, not merely write classes or functions;
- to understand the existing system, because most real work is done on systems already built;
- to test and verify, including AI-generated code;
- to work in a team, using real tools for collaboration, versioning, and delivery;
- to judge AI suggestions critically, without becoming dependent on them;
- to document important decisions, not only the final result;
- to assume responsibility for the system, including after delivery.
The emphasis should not be on “knowing a framework”, but on knowing what it means to build a system that can be changed, explained, tested, secured, and used by real people.
Should the name of the field be changed?
Is the name Software Engineering still appropriate? Or should it be changed? Perhaps we no longer build only software, but platforms, digital ecosystems, intelligent services, infrastructures, and socio-technical systems.
The name Software Engineering deserves to be preserved, but its meaning must be widened. It has a history, a professional identity, and a body of knowledge. Changing the name could create confusion and break continuity with an important tradition.
Nevertheless, within the field we must recognize that today’s software is rarely an isolated program. It is a service, an infrastructure, a platform, a digital product, an ecosystem, a component of an organizational process, or an element of an automated decision. Perhaps the general name remains Software Engineering, while the subtitles of the future will be: Digital Systems Engineering, AI-assisted Software Engineering, Platform Engineering, Secure Software Engineering, and Software Engineering for Socio-Technical Systems.
I would therefore keep the name, but change the way it is explained. Software Engineering should no longer be presented as the engineering of programs, but as the engineering of digital systems built through software.
Will program development still be necessary?
Will program development still be necessary? If AI can generate code, if platforms provide ready-made services, if many applications are built through configuration and integration, what remains of programming?
Yes, program development will remain necessary, but its weight will change. Less banal code will be written, and more code for integration, coordination, adaptation, verification, and control. Some code will be generated, but someone must say what should be generated, understand the result, test it, integrate it, and be accountable for the behaviour of the system.
Moreover, the more critical the software is, the less we can accept the idea of code produced without understanding. In medical, financial, industrial, military, legal, educational, or public infrastructure systems, the problem is not to generate code quickly, but to obtain guarantees, traceability, auditability, security, and explanations.
Programming does not disappear. What gradually disappears is programming as a profession isolated from the rest of the process. What remains is programming integrated into design, architecture, testing, security, operation, and governance.
The frontiers of AI-generated code
A recent meeting with a young American graduate of a master’s programme in Software Engineering gave me a concrete example that I had not sufficiently considered. I had asked him, almost provocatively, whether software development still has a future now that artificial intelligence can generate programs with increasing effectiveness. His answer was simple and, precisely for that reason, important: there are domains in which code automatically produced by AI cannot be accepted as such. He gave me the example of software for planning lunar robots.
I had not thought enough about such applications. If a program plans the actions of a lunar robot, this is not merely an application that can be corrected after release. An error can compromise a mission, destroy irreplaceable equipment, and render years of work useless. There are probably many other domains in which AI-generated code cannot be used directly.
The example is very good, because it shows the real limit of enthusiasm for automatic code generation. The question is not whether AI can produce a sequence of instructions that appears correct. The question is whether that code can be certified, explained, traced back to requirements, tested under extreme conditions, integrated into a verified architecture, and assumed by a responsible organization.
In critical domains, AI-generated code can be useful as support: for exploring a solution, generating tests, performing additional checks, producing documentation, or discovering edge cases. But it cannot be accepted as a final product without a rigorous process of engineering, verification, validation, and certification.
This may be the central distinction: in ordinary applications, an error can be corrected through an update; in critical applications, an error can produce irreversible losses. Therefore the frontier does not run between “code written by a human” and “code generated by AI”, but between code accepted through plausibility and code accepted through traceability, verification, responsibility, and certification.
Today, this frontier is visible in several domains:
- space software and extraterrestrial robotics, where corrections are difficult, costly, or impossible;
- avionics and flight control, where every software function must be linked to requirements, criticality levels, and verification evidence;
- autonomous vehicles and advanced assistance systems, where perception, decision, and control can directly affect human life;
- rail transport and signalling systems, where software must prevent collisions, conflicting commands, and unsafe states;
- medical devices and clinical systems, where a wrong recommendation or command can affect diagnosis, treatment, or intervention on the patient;
- energy, industry, and critical infrastructures, where control of physical processes does not allow careless experimentation;
- security, cryptography, and financial infrastructure, where a small error can become a systemic vulnerability;
- military or emergency-response systems, where software enters decision chains with irreversible consequences.
It is possible that, as AI becomes more powerful, the area of code that can be automatically generated and accepted with low risk will grow. But this evolution does not eliminate Software Engineering. On the contrary, it shifts the emphasis from merely writing code toward specification, risk analysis, formal or semi-formal verification, test generation, traceability, audit, certification, and governance. The niche of applications in which generated code cannot be accepted directly may narrow, but it will not disappear as long as software commands physical, medical, financial, legal, or military processes with irreversible effects.
This also has an educational consequence. The Software Engineering student should not be trained only as a competent user of generative AI, but as a professional capable of distinguishing between convenient code and acceptable code. In many applications, the question will not be “can AI write the program?”, but “can we demonstrate that the program, regardless of how it was produced, is safe, correct, traceable, and responsible?”.
For what kinds of projects will software engineers be needed?
For what kinds of projects will well-trained software engineers be needed? Will no-code and low-code platforms, cloud services, and AI not be enough?
No-code, low-code, and AI tools can cover simple applications, prototypes, local automations, and standardized interfaces. But the larger, more critical, more integrated, or more durable a project becomes, the more the need for Software Engineering proper returns.
Software engineers will be needed above all for:
- critical systems: health, transport, energy, defence, administration, finance;
- digital platforms: ecosystems with many users, services, APIs, and governance rules;
- legacy systems: modernization, migration, refactoring, and integration with new technologies;
- complex software products: applications that evolve for years and must be maintained by successive teams;
- AI-intensive systems: applications in which AI models must be integrated, monitored, explained, and controlled;
- cybersecurity and safety: systems where error, vulnerability, or attack has major consequences;
- cloud and edge infrastructures: distributed, observable, scalable, and resilient systems;
- digital twins and digital ecosystems: active representations of real processes in health, industry, cities, and administration.
It is precisely in these projects that the difference between producing code and doing engineering becomes visible.
Should the number of students be reduced?
If AI will take over part of programming activity, should the number of students in Software Engineering specializations be reduced?
I do not think the correct answer is a mechanical reduction in the number of students. What matters more is changing the training profile. If the specialization produces only routine programmers, it will have a problem. If it produces engineers capable of designing, integrating, verifying, working with AI, and taking responsibility for complex systems, demand will not disappear.
Still, a more careful selection and a clearer differentiation of pathways may be necessary. Not all students must become software architects or researchers. Some will be application developers, others DevOps engineers, security specialists, data engineers, AI engineers, product engineers, or platform integrators. But all should receive a common core of engineering thinking.
The risk is not that there will be too many students in Software Engineering. The risk is that they will be trained for a profession that is changing before our eyes. The first question should not be numbers, but the relevance of the training.
The Software Engineering school at FILS
For twenty years I had the opportunity to decide on the creation and evolution of a Software Engineering school at FILS, in the English and French streams. At bachelor’s level I built an innovative core of courses, unique in the country, and I introduced a master’s programme in Software Engineering intended to give students a solid preparation in the field. What will become of this school?
A university school does not survive by keeping its courses unchanged. It survives through people, intellectual reflexes, professional standards, and a way of asking questions. If the FILS school transmitted the idea that software must be designed, understood, verified, maintained, and assumed, then it has a chance to continue even when technologies change.
But in order to continue, it must update itself. It is not enough to add a course on AI or a lab on cloud. The relationship between fundamentals and tools must be rethought. AI must be introduced into all courses, but with clear rules: the student may use AI, but must demonstrate that he or she understands the problem, the solution, the tests, the limits, and the consequences.
The most important legacy of the FILS school is not a particular language, nor a particular framework, nor a particular tool. It is the conviction that software is not improvised. It is designed, built, verified, operated, changed, and handed on to others.
If this conviction remains alive, the school does not disappear. It transforms.
A possible curricular core
In its current form, a Software Engineering curriculum should preserve the balance between what is stable and what is changing. A programme of study cannot be built only on ephemeral technologies, but it cannot ignore the real environment in which the graduate will work either.
| Level | What should be preserved | What should be added or strengthened | Desired outcome |
|---|---|---|---|
| Bachelor’s – fundamentals | Programming, algorithms, data structures, databases, operating systems, networks, OOP. | Critical thinking about generated code, systematic testing, versioning, teamwork. | A student capable of writing, reading, and explaining programs, not merely producing them. |
| Bachelor’s – software construction | Requirements, design, architecture, UML or equivalent notations, design patterns, quality. | Cloud-native architectures, APIs, microservices, security by design, observability. | A student capable of thinking about the system, not only its components. |
| Master’s – modern systems | Software processes, project management, maturity models, agile methods, DevOps. | Platform engineering, SRE, DevSecOps, governance, cloud costs, sustainability. | A graduate capable of working in real software organizations and understanding the full flow. |
| Master’s – AI and software | AI fundamentals, machine learning, intelligent systems, data and models. | AI-assisted software engineering, technical prompt engineering, evaluation of generated code, AI security. | An engineer capable of using AI as a tool, not as an authority. |
| Integrating projects | Team projects, documentation, presentation, technical evaluation. | Projects with a real client, legacy systems, API integration, real data, responsibility regarding AI. | A graduate who has encountered complexity before entering industry. |
The curricular core should not be a list of technological fashions, but an educational architecture: solid fundamentals, systematic design, current technology, critically integrated AI, and real projects.
What remains?
If I had to formulate a personal conclusion, what remains of Software Engineering after all these transformations?
What remains is exactly what motivated the emergence of the field: the fight against software chaos. Only now, chaos has another form. It is no longer only the chaos of spaghetti code or delayed projects. It is the chaos of interdependent platforms, distributed services, external dependencies, generated code, vulnerabilities, unstable requirements, and systems that continue to change after they have been delivered.
In this world, Software Engineering is not less necessary, but harder to teach and harder to recognize. It can no longer be presented as a set of recipes. It must be taught as a professional culture of responsible construction.
Perhaps this is the simplest answer. The future of Software Engineering does not depend on preserving a terminology or a fixed set of courses, but on the survival of an attitude: not to confuse rapid code production with building a system; not to confuse an AI suggestion with a validated solution; not to confuse the platform with the architecture; not to confuse speed with progress.
If this attitude remains, then the Software Engineering school I tried to build does not end with one generation of courses or with the retirement of a professor. It continues in those who, having reached professional maturity, still know how to ask not only “how do we make it work?”, but also “why does it work, how long will it last, who is responsible, and what happens when it must be changed?”.
Indicative bibliographical landmarks
- ACM / IEEE Computer Society, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering.
- ACM / IEEE / AAAI, Computer Science Curricula 2023.
- IEEE Computer Society, Guide to the Software Engineering Body of Knowledge, SWEBOK, version 4.0.
- DORA, Accelerate State of DevOps Report, recent editions on DevOps, platform engineering, and the impact of AI.
- GitHub / Microsoft Research, studies on the impact of GitHub Copilot on developer productivity.
- NASA, Software Engineering Requirements, for the development and assurance of critical software in space missions.
- RTCA, DO-178C: Software Considerations in Airborne Systems and Equipment Certification, for avionics software.
- ISO 26262, Road vehicles — Functional safety, for electrical/electronic systems and safety-related automotive software.
- IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, as a basic standard for functional safety.
- FDA, recent materials on medical software and AI-based software functions in medical devices.
- Recent works on integrating generative AI into Software Engineering education and capstone projects.
Back to Software Engineering • Back to the History of Software Engineering • Back to Research