In a previous post I gave a software engineering perspective on the most recent developments in AI. The post listed different technological developments we need to consider when trying to predict the future of software engineering:

1. the advancement of AI from Machine Learning (ML) to Deep Learning (DL) to GenAI, especially Large Language Models (LLMs);
2. the fact that most software systems now contain an AI-component, such that software engineers need to know how to deal with these components (“How to build and maintain production-ready AI/LLM-based systems?”, SE4AI);
3. the enormous growth in AI-based tooling (mostly LLM-based) to assist the software engineer in the development, maintenance and monitoring of software systems (“How to use AI tools to build production-ready systems?”, AI4SE);
4. the rise of agentic solutions, both as a type of software system to be built (SE4AI) and as a tool for the software engineer (AI4SE).

As none of these developments have reached a “stable state” it is very hard to draw conclusions other than high-level ones like that AI technology is “reshaping the software engineering field” (Abrahão et al., 2025). This is a feeling we all share, but a big challenge for the education institutes, who are educating the software engineers of the future. What will the software engineering field look like four years from now? What does this mean for the education of our first-year students? In my previous post, I also included a section on the impact on humans of these recent AI-related developments. In this post, I will zoom in on the specific question what all this means for competences of what I like to call AI-Augmented Software Engineers. Also on this question, the jury is still out there. But the least I can try is to give an overview of the different studies and opinions and what they mean for education. In this post I deliberately talk about competences as they refer to the ability to do something well, based on both knowledge and skills. This combination of knowledge and skills is essential for educating software engineers that can perform in industry practice.

AI-Augmented Software Engineer

Let us start by defining the type of engineer we would like to educate. An AI-augmented Software Engineer is a software engineer that knows:

SE & AI: How to solve complex problems using production-ready (AI-enabled) software systems
This includes both SE4AI: How to build production-ready AI systems?
as well as AI4SE: How to use AI tools to build production-ready systems?

So, in our definition the software engineer is not just a programmer, but an end-to-end problem solver; working directly with the stakeholders to understand their domain and ensure their problem is solved in the right way. AI-augmented points to the fact that they use AI-tools as a companion in their SE activities, but also that they know how to deal with AI-components in the systems they build. I would like to stress these two sides of the same coin (AI & SE) because in the discussion about the future of SE the focus tends to lay on “what if all code can be generated by GenAI?” (AI4SE), but we must also answer questions like “what if all software systems will be agentic?” (SE4AI). For the first type of question, we would need to teach new ways of working. For the latter type of question, we would need to teach new technical frameworks and concepts.

Figure 1. What is an AI-augmented Software Engineer? (MS Copilot)

Competences for the AI Engineer: MLOps, DataOps, LLMOps, AgentOps

According to Menzies (2019) all software engineers should learn how to build systems that contain AI components. In my earlier post I already discussed the discipline of AI engineering and what this adds to rule-based software engineering.  We could summarize the implications for the competences of AI engineers by saying that they should master MLOps as an extension of DevOps to treat also AI models and datasets as first-class citizens. My earlier posts lists tools and best practices for this. In an early paper on how to educate AI engineers (Heck and Schouten, 2021) we also concluded this and add some more detailed guidance. We think that software engineers should focus on how to apply existing AI models to practical problems (AI engineering), not on training new AI models (Data Science).

Because of this, the software engineer should focus even more on the data than on the model. In a recent publication (Heck et al., 2025) and another post I also argue that DataOps (as part of or as foundation for MLOps) deserves particular attention when building AI-enabled systems. DataOps is not just about the data used for training models, but even more importantly about the data that is fed to the trained model in production. The post lists tools and best practices for data engineering and DataOps.

My post on LLM engineering adds some more specifics for building LLM-based systems. These types of systems also add “prompts” as first-class citizen. So, for that, software engineers need to know how to write good prompts and how to test them. The post also describes the extension of MLOps to LLMOps, which includes practices and tools specific to building trustworthy LLM-based systems.

My latest post takes even one step further with the introduction of AgentOps. Agent-based systems extend prompt-engineering to context-engineering. Furthermore, agent-based systems have memory mechanisms and tool calls that need to be managed. They introduce all new kinds of architecture patterns, tools and frameworks that software engineers need to be familiar with.

Competences for the Software Engineer: Dev(Sec)Ops, Requirements, V&V, Systems Thinking

Gröpler et al. (2025) describe lessons learned from a big research project on GenAI in the Software Development Lifecycle (SDLC). They conclude that although time spent on writing code decreases, time spent on writing prompts and reviewing code increases. According to them, agent-based approaches could lead to a shift from an engineering perspective to an orchestration perspective; competences that are currently typical of, e.g., technical leads.

Although some shifts are being signaled already, the recurring pattern is that GenAI (taking over technical tasks) does not so much require new technical skills, but puts more emphasis on some of the existing engineering skills:

• Prompt engineering is in essence Requirements Engineering. In this case, you are not writing system requirements or user stories that you hand off to a developer; but prompts that you send to your code generator. Then it becomes even more important to be precise, such that the AI does not fill in the blanks for you, producing wrong output. You can even go into a live requirements engineering session with the stakeholders, prompting and validating the output together with them.
• DevOps (and its successors for AI) stays fundamental to control those assets being generated by GenAI tools; CI/CD with proper unit testing and static analysis is a failsafe for GenAI misbehavior, just as it was for human developers making mistakes. DevSecOps puts specific emphasis on security testing, to ensure use of GenAI does not generate new security risks.
• In general, Verification and Validation (V&V) become more important; software engineers should think of easy ways to test that GenAI is producing the right solution to the right problem; this can partly be solved by test automation (with GenAI or other tools), but also involves user acceptance testing and other forms of evaluating output together with the stakeholders. Note that an important shift in thinking about testing was already made with the introduction of AI-based systems: dealing with non-determinism.
• Code Comprehension might become even more important than coding itself; this skill is currently being used to review code written by others, but it will be a crucial skill when GenAI is writing all our code. The underlying skill for both reading and writing code is often called Computational Thinking.
• Another view on things is that we might not be looking at code anymore in the future (agents will do that for us); if software engineers become orchestrators of those agents, that would require them to have Architecting skills or System Thinking skills: how to break up a system or workflow in smaller components that can be evaluated and managed independently. This is crucial, both for the agents to not get lost in complexity, as well as for the humans overseeing them.

Overall, software engineers should not only be specialized in one technical domain (e.g., security, VR, UX) but should also know a bit about all technical domains. The same goes for engineering skills. Software engineers should be able to oversee the whole SDLC. Only then can they become true end-to-end problem solvers (with the help of GenAI).

Fig 2. Software engineering competences for GenAI (MS Copilot)

Competences for the AI/SE Engineer: Soft Skills

As we delegate many technical tasks to AI, we need different skills to do the remaining tasks; there will be more emphasis on social skills, creativity and agility, critical thinking and self-regulated learning.

We also need different skills to be able to oversee a team of AI agents working for us; instead of T-shaped professionals, being specialist in one area, we should become more M-shaped or X-shaped professionals: interdisciplinary integrators. These integrators are technically literate, human-centred and strategically aware.

Ebert et al. (2025) have conducted a virtual roundtable with six renowned experts from different backgrounds and regions discussing their insights and outlooks on future learning and relevant competencies for computing. They come to similar conclusions as pointed out above. Two of their statements that summarize this are: “success will emerge when individuals move from passive learners to active creators” and “engineers will need to emerge as context-aware cocreators”.

Educating AI-augmented AI/SE engineers

Although the above sources give us some pointers on what competences the software engineer of the future needs to possess, it does not translate directly to a curriculum or answer basic questions like what are the fundamentals that each student should possess: activities that they can execute without the help of AI, knowledge they internalize, etc.

As Ebert et al. (2025) point out, learning patterns are evolving from “Just-in-Case” to “Just-in-Time” learning: professionals now integrate learning directly into their workflow, consuming bite-sized information from tutorials, documentation, or quick searches to solve the immediate problem at hand. Furthermore, passively consuming information from books or videos is being replaced by interactive dialogue with AI agents. In the end, professionals must learn to construct their own learning paths.

This nicely aligns with the lessons we are learning on this topic (mostly based on the experiences at Fontys ICT):

• Programmatic Assessment (Programmatisch Toetsen) fits well with use of GenAI by students, since teachers do not grade end products, but the behavior (learning process) of the student.
• Related to that, grade students by talking to them about their products, not by looking at their products. Even better is when you are there with them while they are creating their products, even co-creating.
• Related to that, construct learning as a social activity; peer-learning and teamwork are essential for future jobs as well. You would want students to meet at campus, so that teachers are directly involved in their learning process.
• Project- or challenge-based learning helps to be able to incorporate new technologies quickly; it does however also require teachers to become “active creators”; they need to move from knowledge transfer to learning together with their students.
• Related to that, keep Learning Outcomes as high-level as possible; for example, in our higher SE semesters, we speak of “complex software systems”, such that students in their projects can work on, e.g., quantum, blockchain, RAG, agentic.
• Incorporate professional use of AI-tools in the learning outcomes where possible; for example, in our second-year SE semester we ask the students to “automate their software development process … utilizing industry-standard practices, possibly including use of generative AI”.
• Related to that, be clear on your expectations for the use of GenAI; not only in a general policy, but also per semester, per project or per course.
• Since most teachers have no prior experience in working with GenAI, professionalizing them is a prerequisite for successful adoption of GenAI in the SE semesters.
• Ensure a basic infrastructure where all students (and teachers) have equal access to trusted AI-tools.
• Scaffold both the complexity of the projects as well as the amount of SDLC-automation that you expect from students over the course of the curriculum.
• Experiment with task-specific AI-tutors that are instructed to guide students on those tasks, without giving them the answers to their questions directly.

As one of the experts interviewed by IEEE Computer (Ebert et al., 2025) puts it, we already made “a shift from a closed, static, passive, and one-time learning approach to an open, collaborative, dynamic, active, and lifelong learning model.” This is a bigger and more systemic change than just adding GenAI in each of our courses/semesters.

Figure 3. An AI-first education model (MS Copilot)

First-Year Education

In our educational model we already made the shift from “Just-in-Case” learning to “Just-in-Time” learning (Ebert et al., 20025), so we allow students from the first semester to use AI-tools for coding, as long as they can explain all code that has been generated (not really different from before, where students would also copy code from peers or StackOverflow). This is also possible because we will not grade the code itself, but the end-to-end software engineering that students do in real-life projects. In fact, looking at the prompt history of a student gives a very nice insight into the thinking process of that same student. Something we also learned is that any document that you would ask from students to describe what they have done or learnt (e.g., a reflection report or design document), can in turn be generated; so that is not a solution to ensure the student has learnt something.

I do feel that with the right educational model, we can allow students to learn programming “Just-in-Time”, which is a skill they will benefit from their entire career, as tools will become even more supportive. I had a nice conversation with Microsoft Copilot about this when I asked “How do I teach a student that cannot program AI-assisted software engineering?”. I will not paste the whole conversation here, but the one paragraph summary is as follows: “Teaching AI-assisted software engineering to a student who cannot program yet works best when you focus on engineering thinking before coding syntax: help the student learn how to define problems clearly, break them into smaller parts, use AI to generate and explain code, test whether the result works, and improve it through iteration. In this approach, the student is not expected to write everything from scratch at first; instead, they learn to act like the director of the work—deciding what needs to be built, checking whether it meets the goal, and using AI as a helper, tutor, and pair programmer. The main goal is to build skills in problem-solving, structure, testing, and judgment, so that over time the student becomes more confident not just in using AI, but in understanding the software they are creating.”

In another conversation with Microsoft Copilot, I asked for an AI-first curriculum. The answer also contained “The AI‑First Competency Ladder (Progressive Independence): Level 1 — Operator: can run, deploy, and demo AI-generated projects; Level 2 — Reviewer: can spot bugs, write tests, fix issues; Level 3 — Maintainer: can extend features, refactor, keep quality stable; Level 4 — Designer: can choose architecture, trade-offs, and constraints; Level 5 — Owner: can build reliable systems with or without AI help”. I feel that if we want our students to graduate as AI-augmented Engineers (level 5), that we cannot afford to wait to introduce them to AI-tools until the later years, as that will leave them too little time to master the necessary high-level engineering skills to handle those tools well.

Curriculum Design

My lesson here is that how to AI-proof your curriculum or first-year very much depends on your situation. It is valuable to discuss this with AI-tools (since they can much more easily synthesize everything that has been written about this) but be aware that you formulate prompts from multiple perspectives. My first question for a curriculum resulted in an answer based on the principle “You write first, AI second”; but then when I asked for an “AI-first” curriculum MS Copilot was just as happy to write that for me.  Choices are to be made here, tailored to your own educational model. AI-tools can just help you brainstorm on the options.

Conclusion

Although the jury is still out there on how and what, I do feel confident to say that when educating software engineers, we cannot afford to ignore or ban GenAI. GenAI, LLMs, agents will be part of their future jobs. In our experience an open, challenge-based curriculum works very well to keep education up-to-speed with the latest technological developments and to educate software engineers as end-to-end problem solvers. AI is just a tool. It has some peculiarities for us as software engineers that we also need to teach our students about, but they have always been learning-by-doing. So that remains the most important skill for AI-augmented software engineers: an engineering mindset and self-regulated learning. Because even after they graduate, they will continuously need to master new engineering paradigms and tools.

References

Silvia Abrahão, John Grundy, Mauro Pezzè, Margaret-Anne Storey, and Damian A. Tamburri (2025) Software Engineering by and for Humans in an AI Era. ACM Trans. Softw. Eng. Methodol. 34, 5, Article 129, 46 pages. https://doi.org/10.1145/3715111

Ebert et al. (2025) Beyond Code: Competences for the Future of Computing. Computer, vol. 58, no. 11, pp. 18-27. https://doi.org/10.1109/MC.2025.3600944

Google Cloud. (2020). MLOps: Continuous delivery and automation pipelines in machine learning. Retrieved from https://cloud.google.com/solutions/machine-learning/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

Gröpler et al., “The Future of Generative AI in Software Engineering: A Vision from Industry and Academia in the European Genius Project,” 2025 2nd IEEE/ACM International Conference on AI-powered Software (AIware), Seoul, Korea, Republic of, 2025, pp. 170-181, doi: 10.1109/AIware69974.2025.00026.

Petra Heck and Gerard Schouten. 2021. Lessons Learned from Educating AI Engineers. In 2021 IEEE/ACM 1st Workshop on AI Engineering – Software Engineering for AI (WAIN). IEEE Press, 1–4. https://doi.org/10.1109/WAIN52551.2021.00013

Petra Heck, Jacco Snoeren, Merel Veracx, and Manon Peeters. 2025. An Approach for Integrated Development of an MLOps Architecture. In Software Architecture: 19th European Conference, ECSA 2025, Limassol, Cyprus, September 15–19, 2025

Vind ik leuk