Teaching software engineering when AI writes the code: a UNAM syllabus reviewed and a curriculum proposal

In three earlier articles we described the same situation from different angles. With AI, a team produces software faster than it can verify it, and the gap piles up as verification debt. That is why human work is shifting toward scoping, specifying and auditing. If the work changes, education has to change with it. This article asks a concrete question: how should a curriculum adapt?

To keep it grounded, we analyze a real, public document: the syllabus for Software Engineering (course 0575) in the Computer Science undergraduate program at the School of Sciences of the National Autonomous University of Mexico (UNAM), the country's largest public university. We compare it with what AI can do today, according to measurements rather than promises, and with what is known about how AI affects learning. We then propose what the course and the degree should look like, and answer whether the degree should get longer or shorter.

A note on the document: course 0575 is not the syllabus of a whole degree but of one mandatory course in the sixth semester, 112 hours long. To discuss the degree we also use the program's official curriculum. We analyze the official documents, not what each instructor teaches in class, which is often ahead of the written syllabus.

What AI can do today, and what it cannot

A curriculum should not be designed around what AI might do someday, nor around what it did three years ago. This is what has been measured:

The implication for education is direct. AI already does well much of what a traditional course spends time teaching: writing an implementation from a description. What it does not do, or does poorly, is decide what to build, specify without ambiguity, verify independently and take responsibility for the result. That is what education has to strengthen.

What AI does to learning

Before proposing to "use AI in class," it is worth looking at the evidence on learning with it.

• Without guardrails, AI can harm learning. In an experiment with nearly a thousand high school students, those who practiced with unrestricted ChatGPT improved 48% during practice, but once the tool was removed they scored 17% lower on the exam than students who never had it. A tutor with guardrails, which gave hints instead of answers, removed almost all of the harm (Bastani et al., PNAS, 2025).
• AI gives beginners an illusion of progress. In a study of 21 programming students, AI worsened known metacognitive difficulties and created three new ones: constant interruptions from suggestions, suggestions that lead astray, and a false sense of progress. Of ten students who struggled, nine reached a solution using AI, and most believed they understood more than they did (Prather et al., ICER, 2024).

Both findings have limits: they are short-term studies and, in the second case, a small sample. But they point the same way. Allowing or banning AI is not enough: what matters is when and how it enters a student's education.

The current syllabus: what it has and what it lacks

Course 0575 has 112 hours (48 of lectures and 64 of practice) across seven units:

What it already has, and it is valuable

Much of what this new situation demands is already in the syllabus, though with little weight:

• Requirements formalization and traceability (IV.1, IV.3, IV.7): the foundation of specifying.
• Test-driven development (VI.7) and design for testability (VI.3).
• Continuous integration (VI.5) and regression testing (VII.3).
• Risk and impact analysis (VII.2), refactoring and reengineering (VII.5, VII.6).
• Validation of non-code artifacts (VI.8), a topic many syllabi leave out.
• Evans's Domain-Driven Design in the supplementary reading.

The degree as a whole also has an advantage that is far from minor: a strong foundation in logic, discrete mathematics, automata, complexity and algorithms. That formal reasoning is exactly what verification requires.

What it lacks

1. Proportion. Requirements and verification, the two units that gain the most value, add up to 28 of 112 hours (25%). Processes, which covers waterfall and plan-driven methods, has 21 hours.
2. AI does not appear. Not as a development tool, not as a source of errors with its own patterns, not as something to audit.
3. No independent verification. Common-cause failure (code and tests sharing the same mistake), mutation testing, property-based testing, code review and sampling audits are all absent.
4. No application security. Threat modeling is not in the course, and the Cryptography and Security course does not come until the eighth semester.
5. No operations. Gradual rollout, rollback and observability are missing. The SWEBOK v4 guide (IEEE, 2024) added precisely three new areas: architecture, operations and security.
6. Professional responsibility is not explicit. With AI, "who answers for this code?" stops being a philosophical question.
7. Assessment loses validity. The syllabus assesses with exams and "the development of an application." Today a working application no longer shows that the person submitting it knows how to build it or judge it.
8. Age. The degree's curriculum was last revised in 2011, and the core reading list dates from
9. Weight in the degree. It is the only mandatory software engineering course: 10 of 376 credits (2.7%). Software Engineering II, Software Architecture and Design, and Software Testing exist, but as electives.

The proposal for the course

The proposal keeps the 112 hours and the split of 48 lecture and 64 practice hours. What changes is the allocation: specification and verification grow from 28 to 48 hours, while processes and the introduction are condensed.

What each unit covers

I. Introduction: software development with AI (8 h). Life cycle and disciplines, as today. Added: the new division of roles (scope, specify, audit, operate), verification debt, the measured capabilities and limits of AI, and professional responsibility: one person answers for what gets merged, whoever wrote it. The historical tour of development models is shortened.

II. Component design and contracts (14 h). Components, API qualities, API design and patterns stay. Added: versioned contracts (OpenAPI, JSON Schema) as the source of truth between components, and dependency verification, since AI sometimes suggests packages that do not exist or are not from whom they appear to be. Patterns are narrowed to those students will need to recognize when auditing.

III. Process and change control (12 h). Waterfall and plan-driven methods remain as context, without disappearing. Strengthened: version control, small pull requests, risk-based review, continuous integration with gates, and work-in-progress limits. The topic of rapid application development tools (IV.8) goes: AI agents have taken its place.

IV. Requirements and executable specification (22 h). The unit that grows most. Classification, formalization, acceptable uncertainty and traceability stay. Added: user stories with verifiable acceptance criteria, Gherkin or EARS, properties and invariants, and specifying for an agent: an agent implements literally, so every ambiguity ends up as a defect. Traceability is carried all the way to the test that checks each requirement. Use cases stay, with less weight.

V. Architecture and boundaries (16 h). Layers, components, views, systemic qualities and patterns stay. Added: architecture decision records (ADRs), modularity and coupling as what decides whether debt grows linearly or exponentially, and boundaries that restrict what an agent may touch. Traditional architecture design methods are shortened.

VI. Independent verification (26 h). The core of the proposal. The difference between validation and verification, test types, design for testability, error handling, continuous integration, test-driven development and validation of non-code artifacts all stay. Added:

• Tests written before the code and frozen, so the agent cannot edit them.
• Common-cause failure: why more tests from the same AI do not lower the risk (Knight and Leveson, 1986).
• Mutation testing and property-based testing: measuring whether tests catch bugs.
• Static and security analysis.
• STRIDE threat modeling, with one test per threat.
• Risk-based code review and sampling audits.

VII. Evolution, risk and debt (14 h). Maintainability, risk and impact analysis, regression, reuse, reengineering and refactoring stay. Added: measuring verification debt, gradual rollout with rollback, observability, and modernizing legacy systems with AI, one of its most common uses today.

How AI enters during the semester

The evidence on learning suggests AI should not arrive all at once:

How to assess

Reading list to update

• SWEBOK Guide v4 (IEEE Computer Society, 2024): the discipline's reference framework.
• ACM/IEEE-CS/AAAI, Computer Science Curricula 2023: weaves society, ethics and the profession into most knowledge areas.
• Sommerville, Software Engineering, 10th edition (2015), instead of the 9th.
• Winters, Manshreck and Wright, Software Engineering at Google (O'Reilly, 2020): software engineering at scale, code review and testing.
• Shostack, Threat Modeling: Designing for Security (Wiley, 2014).
• Evans (Domain-Driven Design) and Boehm and Turner remain relevant and stay.

The proposal for the degree

The course alone is not enough: it arrives in the sixth semester and nothing before it prepares students for the new role. The proposal touches ten of the 34 mandatory courses and keeps the 8 semesters and 376 credits.

What stays: the entire mathematical and theoretical foundation. Algebra, calculus, automata, complexity, compilers and algorithms do not lose value with AI; they gain it. Judging whether a result is correct requires understanding why it works, and that ability is built on fundamentals.

The cost: Software Engineering II takes the place of an elective, so electives drop from 6 to 5 and mandatory courses rise from 34 to 35. Flexibility, one of the current curriculum's strengths, is reduced. In exchange, mandatory software engineering doubles from 10 to 20 credits (from 2.7% to 5.3% of the degree).

Recommended electives for industry-bound students: Semantics and Verification, Software Testing and Configuration Management, Software Architecture and Design, Software Metrics, Technological Risk and Human-Computer Interaction. All of them already exist in the curriculum.

Social service and professional practice workshops as supervised apprenticeship. The degree already requires 480 hours of social service (a mandatory community-service internship in Mexican universities) and offers two professional practice workshops. Steering them toward supervised auditing and specification on real projects builds the judgment the market asks for without adding time to the degree.

Longer or shorter?

This is the most tempting question: if AI writes the code, shouldn't the degree be shorter? There are three reasonable options:

Recommendation: keep the 8 semesters and change the content and the assessment. There is no evidence that justifies shortening the degree, and there is evidence that learning with poorly integrated AI can leave students worse off. Extending it is not necessary either, because the curriculum already has room (electives, social service, workshops) that can be redirected.

The same holds for the course: 112 hours are enough, provided they are reallocated and Software Engineering II becomes mandatory. Mandatory software engineering then goes from 112 to 224 hours without lengthening the degree.

What must change is the pace of revision. The curriculum has gone fifteen years without a revision, while the length of tasks AI can complete doubles every seven months. The proposal separates two layers:

• A stable core, written into the formal curriculum: specifying, verifying, designing boundaries, formal reasoning and taking responsibility for results. This does not change every year.
• Concrete tools and practices, reviewed by the faculty every year without a formal curriculum reform: which agents are used, which mutation or analysis tools, which usage policies.

What could go wrong

1. Faculty. The syllabus asks for instructors with "extensive programming experience." This proposal also needs experience in verification and AI-assisted development, which requires faculty training before any change on paper.
2. Equity. If the course depends on paid tools, students who cannot pay are at a disadvantage. The institution has to provide access or design the practice so it works with free options.
3. Scale. One oral defense per student works for a class of 30, not 120. Assessments must scale, such as the seeded-defect audit, which can be graded automatically.
4. Chasing trends. AI capabilities change fast. That is why the proposal bets on principles (specify, verify, take responsibility) and keeps tools out of the formal curriculum.
5. The evidence is still short. Studies on AI and learning are short-term, and several use small samples. No cohort has yet graduated from a curriculum designed this way. It should be measured: compare groups, follow graduates and adjust.

What this article does not claim

• It does not claim the current syllabus is bad. It has a solid theoretical foundation and already contains, with little weight, much of what this situation demands. The problem is proportion and age, not direction.
• It does not claim programming should no longer be taught. Quite the opposite: the AI-free first semester exists so students truly learn to program, because without that foundation auditing is impossible.
• It is not an official proposal. It is an independent analysis meant to open the discussion, based on public documents rather than on what happens in each classroom.
• It does not claim this allocation of hours is the only right one. It is a reasoned proposal that should be tried, measured and corrected.

Sources

• UNAM, School of Sciences, syllabus for Ingeniería de Software (course 0575), Computer Science undergraduate program.
• UNAM, curriculum of the Computer Science undergraduate program (in-person), revised in 2011.
• Bastani, Bastani, Sungu, Ge, Kabakcı and Mariman, Generative AI without guardrails can harm learning: Evidence from high school mathematics, PNAS 122(26) (2025).
• Prather et al., The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers, ICER (2024).
• Kwa et al., Measuring AI Ability to Complete Long Software Tasks, METR (2025).
• Becker, Rush, Barnes and Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR (2025).
• Brynjolfsson, Chandar and Chen, Canaries in the Coal Mine?, Stanford Digital Economy Lab, August 2026 version.
• DORA, Accelerate State of DevOps Report (2024).
• Leu et al., ESEM (2026); Knight and Leveson, IEEE Transactions on Software Engineering 12(1) (1986).
• IEEE Computer Society, SWEBOK Guide v4 (2024).
• ACM/IEEE-CS/AAAI, Computer Science Curricula 2023 (2024).
• Lee et al., Reshaping Undergraduate Computer Science Education in the Generative AI Era, arXiv (2026): a workshop report that also recommends shifting teaching toward understanding and verifying what AI generates.
• Dixi-Project: Verification debt and Scope, specify, audit (2026).