The situation in academia is dire. More students are failing than ever and, worse, others are passing without being able to apply the expected skills the following semester, only to find themselves unable to get a job after graduation. Classes are empty, morale is low, socialization is at its lowest, and no one knows what to do about AI.

Both MIT and, closer to our local reality, Coimbra¹ have released reports on AI in education and offered recommendations for action. Here, I present the recommendations I agree with, the one I do not, and a short list of the actions I consider most important.

Worrying Data Points

Success rates are decreasing. Each year, the number of failing students increases. Furthermore, grades no longer form a bimodal distribution: I have been awarding more 20s (out of 20) than ever, and more grades below 4 than ever. The difference between the two modes is larger than ever.

Attendance is decreasing. This is happening all over Portugal, but also at universities around the world, including MIT. Here in Lisbon, ever-increasing housing prices and a lack of dormitories prevent students from living closer to campus, leading to two-hour commutes each way.

Students are less social. This might still be a consequence of COVID, but students now socialize via Discord more than they do in person.

Companies are not hiring junior developers. The 100% employment rate for software engineers led many people to believe that a good job was guaranteed. This is no longer the case, and students do not know how to distinguish themselves in a more competitive market.

The Diagnosis

While we recommend against imposing a one-size-fits-all policy on AI use, students are anxious for clarity about AI use: in any given course, they want to feel sure about when, where, and why AI is prohibited, allowed, or required.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

Both the MIT and Coimbra reports identify students' uncertainty about how to apply AI in their education as a concern. I disagree. Students are better than we are at adopting new technology: Google and Stack Overflow were two earlier technologies that changed how software engineering was taught, and students were the first to understand how to take advantage of them. My evidence is that I have never awarded so many top grades as I did this past year.

Instead, I believe that the main problem is motivation. Since primary school, students are trained to see tests as the positive-reinforcement signal. If an activity does not count towards their grade, they simply do not do it. That has led us to allocate 10% of a grade to homework; top universities do the same thing. Students do not care about learning for learning's sake—or practising after they finish school. They care about passing courses because that will give them the degree they expect to earn and, they hope, a good life.

AI has exacerbated the issue. Students can drag and drop an assignment into Claude Code or ChatGPT, wait less than an hour, and receive a solution that scores 100%. Unlike some of my colleagues, I do not think this reflects students not knowing how to use AI to learn. They know that they are cheating themselves out of the opportunity to learn by doing. Engineering degrees have a strong practical component because people learn best by building from scratch, or from pre-approved foundations. For example, you learn more by writing your own compiler than by reading someone else's source code. The journey—finding problems and developing solutions—is what builds knowledge and expertise. Asking AI may give students enough knowledge to memorize for an exam the following day, but not enough for it to remain with them through the end of their degree and into their careers.

So I identify two main challenges: what skills will a software engineer need in three to five years, and how can we set up incentives that help students obtain those skills?

What skills will a software engineer need in three years?

This is the million-dollar question. AI is increasing the pace at which software is developed. Some argue that this increased pace comes at the cost of software quality. I am more positive about AI: I think the latest models and harnesses together produce software of higher quality than the average human team. This happens because those harnesses are built on the shoulders of giants: open-source compilers, linters, verifiers, and testing and validation frameworks.

I have come to the conclusion, over the last year, that the conventional university degree is obsolete. We have tools that can prove hard theorems and write thousands of lines of assembly in seconds. When Claude can produce something quite close to a PhD thesis in less than an hour, what are we even doing?

— Daniel Lemire

While I am not as negative as Daniel, I believe the required skills will be very different. I do not think people will need prompt or agentic engineering: the major labs will make these tools usable without much effort on our part. Instead, the work of software engineers will shift towards requirements, both functional and non-functional. My view is that we will need two types of developers. Product engineers will determine a product's requirements, use LLM-based tools to generate it, and ensure that it meets its quality requirements. These engineers will be better able to deal with ambiguity and people-focused work. Infrastructure and research engineers will work on the tools that product engineers use—LLMs, networks, distributed systems, and so on—and use AI to test new ideas and do more revolutionary work. They will require deeper technical expertise. To reflect this future, we should rethink our curriculum to cover product management, which is typically treated lightly, and the foundations of all major areas of computer science: networks, distributed systems, programming languages, databases, and AI, including neural networks. We also need to teach this last area earlier, rather than reserving it for advanced Master's-level topics.

But this is only my personal opinion. Others may have a different view of the future. The most important conclusion is that we need to become more agile in adapting curricula. We used to revise them every five years, with major revisions only every 10–15 years. We now need to be able to revise a degree from one semester to the next. Things are changing quickly, and the pace will only increase. We need to adapt not only course content, but also how teaching works.

You need to be able to change course and program content quickly. Most universities spent the last few decades adding layers of management and more committees. That machine is ill-suited to sudden change. Most universities will fail badly. They will look increasingly out-of-place.

— Daniel Lemire

In Portugal, we need to remove A3ES's role in approving individual degrees. A3ES should approve universities, schools, or departments and let them independently manage their offerings. Both the MIT and Coimbra reports support an iterative approach with continuous monitoring and feedback.

We urge MIT to revise its governance processes to promote more rapid curricular exploration, paired, of course, with thorough evaluation of the results. Departments need to be empowered to explore AI-aware substitutions and alterations to their curriculum on a regular basis without fixed, multi-committee, year-long review processes – or we will be left behind.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

What I think we do not do enough in Portugal is seek industry feedback on the right skill set for software engineering. Traditionally, we expected to hear only about C# and .NET developers, which is why we—not me!—started ignoring industry. But based on job postings and conversations with industry leaders, I believe the following skills are needed today.

• Systems thinking and engineering.
• Foundations of programming, including code-quality metrics and experience with functional programming and specification languages, including dependent types.
• Foundations of distributed systems, including the web, APIs, and message queues.
• Foundations of databases, including real-world scalability, different database engines and models, and graph and semantic databases.
• Foundations of AI, including neural networks and linear algebra, LLMs, agent harnesses, evals, and classical machine-learning and reasoning techniques.
• Foundations of user experience, including how to design interfaces and services.
• Product-management skills, including experience running a project and defining quality metrics.
• Architectural design, so that graduates can critique the architecture and code produced by LLM-based agents and manage source-code complexity.
• Foundations of software security and safety, which are particularly important when vulnerability discovery is accessible to a layperson.

Of course, there are other topics to explore. But if a student masters these topics, I believe they will become an excellent professional. How to help students master them is a far more difficult question.

The illusion of understanding

A fundamental danger, as we’ve discussed, is that AI can allow students to bypass learning. Equally concerning is that students may internalize a transactional model in which assignments are outputs, teachers are evaluators, peers are optional, and knowledge (or an MIT degree) is an optimizable commodity to be acquired or produced as efficiently as possible.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

Both the MIT and Coimbra reports conclude that students want clear, explicit rules about the kind of AI involvement expected in each learning activity. I disagree with that degree of micromanagement. Learning outcomes should state whether independent work is required, AI use is permitted, or effective AI use is required; assessment should, as far as possible, reflect those conditions. Outside assessment, students should be free to explore AI and reach their own conclusions. Instructors should communicate expectations, but should not dictate students' individual study practices.

But I do acknowledge the danger: students use completing an assignment or having the answer to a question as a proxy for success. The goal is not to obtain those particular answers, which could possibly be done by searching online, asking someone who took the course the previous year, or asking an LLM. The goal is to be able to solve a similar—or larger-scale—problem in the real world, where that particular question is only one small component. AI is fantastic for creating similar problems and giving feedback on a solution. It can be an excellent learning aid. So forbidding AI is not the solution; it is a shortcut that avoids what really matters: defining learning outcomes and robust methods for assessing whether those outcomes have been achieved.

When I taught functional programming, we had classes in which students came to the blackboard to share a solution so that we could discuss it. More often than not, students brought working solutions in their notebooks without knowing how they worked. Either they obtained them elsewhere or produced them through trial and error with the compiler. In either case, they had not achieved the intended learning outcome: they were supposed to be able to devise a readable, concise solution to any problem. Like machine-learning algorithms, students tend to overfit to the types of problems they encounter in class. Student representatives typically complain when exams contain types of questions they have not seen before. That is the opposite of what higher education should be. We are here to teach students how to handle the unknown using the foundations they have learned. The fact that many jobs over the last 50 years did not require a deep understanding of computer science cannot guarantee employment for the next generation.

All of us who teach at MIT will need to be prepared to help students understand both that the process of education is necessarily a productive struggle, and that the most important product of their education is not a GPA or a diploma but themselves: their personal growth and intellectual maturity and the development of their own imagination, insight, and judgment.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

Organizing the curriculum

These competing demands on their time drive students to prioritize efficiency – and nothing could be more efficient than automating work through AI. But if students give in to that tempting option, they cheat themselves of the cognitive friction and productive struggle necessary for actual learning.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

Curricula are typically structured in three stages: foundational courses, usually in the first year; scaling courses, usually in the second year; and applied courses, usually in the third and fourth years or at Master's level. Simas Kucinskas's Barbell approach for education with AI removes the middle of the degree.

One end of the barbell: courses that are deliberately non-AI. Work through proofs by hand. Read academic papers. Write essays without AI. It’s hard, but you build mental strength.

The other end of the barbell: embrace AI fully for applied projects. Attend vibecoding hackathons. Build apps with Cursor. Use Veo to create videos. Master these tools effectively.

— University education as we know it is over by Simas Kucinskas

The foundational courses that have existed for 40 years will still be relevant 40 years from now. We should keep them. According to Simas, the middle courses should disappear because they require too much effort to complete by hand, while completing them with AI does not lead to learning. While I agree with the latter point, I think whether they are worth the effort is debatable. Students need to spend time working by hand in order to understand what LLMs do on their own. Someone needs to, otherwise this is how they go rogue and destroy humanity.

In later, applied courses, students can use AI for all non-critical tasks. If they are implementing a Twitter clone, they should be able to use AI for all functional requirements and focus on the distributed-systems challenges. To this end, we should raise the bar for third-year courses, reaching the level of PhD research.

My instinct is that we need to raise the bar massively. A degree should conclude with work at the level of a 1995 PhD. That is doable in four years. Everything else should be short, doable in four months.

— Daniel Lemire

For this to happen, universities should invest more in giving students access to multiple LLM providers. The economic and environmental impact of doing so should be measured and communicated to students. This is also motivating: students get to build real products at university, see their ability to change the world, and build a portfolio for a market that increasingly looks only for senior developers.

Defining proper incentives

Most discussion of AI concerns student grading and assessment. That was the part of education we trusted and no longer do. I believe in starting from the foundations. For every course I teach this year, I will do the following:

First, I will rethink the skills that software engineers and computer scientists need within the relevant domain of expertise. For programming courses, I will write something like: "Students should be able to create, from scratch and without external assistance, any requested program in a familiar domain, using abstract data types, polymorphism, recursion, and higher-order functions." From this learning outcome, I will design an in-person method of assessment. For courses with 100 or more students, this might mean a written exam; for smaller courses, it might mean an in-person discussion. MIT recommends in-person discussions and states that departments should receive additional funding to support this costly form of assessment.

When designing an exam or in-person discussion, I will try to make the exercise as realistic as possible. For instance, instead of asking a student to write a recursive version of Fibonacci, as I did in the past, I can ask them to write a recursive function that determines which packages from a predefined list should be placed in a van with a weight limit to maximize a logistics company's profit. This is a real-world description of the knapsack problem. Students need to practise transferring foundational knowledge to concrete, real-world scenarios. Do not use the same exam format every year. Use a single problem in a distinct, unfamiliar real-world scenario each time. The more unfamiliar the assessment problem, the more prepared students need to be. Be clear about this from day one, so there are no surprises.

If I were designing an in-person discussion for a testing and validation course, I would discuss the challenges of testing AI chatbots and agents based on the foundations students had learned. This is a PhD-level challenge today, but students should be able to discuss it at this level after doing the work during the semester.

At the beginning of the semester, connections with industry professionals are important. They can help define a course's target skills, visit during the first two weeks to motivate students with real-world problems, and inspire exams and assignments based on those problems. A funny anecdote: in Software Construction, I always taught that Git commits should be granular and that students should not submit a project as a single commit. They ignored me. The following week, André Luis from GitLab told them exactly the same thing, and they adopted it. Industry participation is valuable even in the worst-case scenario, when professionals say nothing different—though that was certainly not the case with André.

How do you run classes throughout the semester to achieve the goals you have defined? MIT promotes continuous feedback, and Coimbra suggests active learning. I honestly do not have an answer. If students are motivated, many types of class can work. If they are not, active learning or continuous feedback alone will not help.

The recipe for motivation requires several ingredients. First, it requires everyone to be present in person. Those who cannot should register for online-only degrees, such as the Open University or, in Portugal, Universidade Aberta. The MIT report agrees:

Much of what our students gain from MIT is never spelled out in a syllabus or an assignment; it’s what they learn from living and working on our campus in each other’s company – the tacit expectations, habits, relationships, and values that inform how they learn to solve problems, exercise judgment, persevere through difficulty, and become members of an intellectual community. “Residential education” is powerful in part because it happens everywhere: in residence halls, living groups, sports teams, arts groups, clubs, and so on.

— The MIT Report on AI Use in Teaching, Learning, and Research Training

I have always been against mandatory attendance. However, I teach at a public university where students pay less than €1,000 in tuition, while my taxes cover the remaining €5,000 of the cost. We should fail students quickly and expel them sooner if they do not show the motivation and ability to learn, excluding health problems, parenthood, military service, and other protected circumstances. Right now, we can only bar them after three years of failure. In-person assessment functions as a form of mandatory attendance.

To boost morale and increase motivation, I would start by inviting someone from industry to talk about their daily work and the skills it requires. This should, of course, be adapted to each course. I would then cover the foundations, always connecting them to real-world applications. Even when teaching something as simple as if-then-else expressions, I can give a real-world example, such as home-automation workflow programming or checking whether a user is authenticated. In practical classes, students will use pen and paper. If it is up to me, they will throw that paper into the bin at the end of class, showing that getting the right answer to a particular problem is not the goal. The goal is for them to be able to solve the next problem by themselves. I will give students random and unusual problems; some might even be impossible. We have to exercise mental effort and critical thinking without offloading to AI and degrading our own skills.

Contrary to the MIT and Coimbra suggestions, I will not tell students how to use AI in their studies. That should be their decision. I will, however, specify in the learning outcomes whether independent work is required, AI use is permitted, or effective AI use is required. Ideally, students should be able to achieve all outcomes without AI, although perhaps not within the given time frame.

Recommendations for your course

1. Review learning outcomes every semester with industry professionals. Emphasize foundations early in the degree and real-world applications later. For each outcome, state whether independent work is required, AI use is permitted, or effective AI use is required.
2. Align grading with learning outcomes. Conduct assessment in person whenever practicable, ideally through oral and group settings that foster social interaction, while grading each student individually. Increase staffing and funding accordingly.
3. Make classes in person and interactive, with guest lecturers from industry or research labs from the first year onward.
4. Encourage students to explore agents and LLMs just as they explored IDEs and operating systems in the past. Curiosity is valuable, and students should decide how to use AI in their own studies.
5. Ensure that students build real-world projects with a positive social impact by the end of non-foundational courses.
6. Ensure that students work in teams that mirror real-world software-engineering projects.
7. Provide students with access to frontier models so they can prepare for the real world. Fund this transparently, and measure and communicate its economic and environmental impact.
8. Provide space for students to work in person and run their own clubs. Space is expensive at universities, but this is worth it.
9. Streamline curricular adjustments and reduce paperwork. Everyone, including instructors, is learning.