In a project where students develop code and calibrate economic labor market models, they are encouraged to use generative AI tools to develop code. During the project, students participate in critical, probing supervision and work with code that contains deliberately embedded economic errors, which they must identify and correct. These activities prepare them for the final oral exam, where they must explain and defend their models, choices, and results.
Previously, students spent a significant amount of time in the course writing code. This process forced them to think through the underlying mechanisms of economic models and helped them select the appropriate model for a given problem. With generative AI, students can now quickly produce code that runs and appears plausible. Coding can therefore no longer serve as a proxy for understanding the models. At the same time, my experience with the course showed that supervision sessions often focused on technical troubleshooting rather than conceptual questions.
Furthermore, the students wanted to learn how to use generative AI as a practical tool, but they also worried about producing results they could not explain. I therefore decided that students may use generative AI, but they must not delegate their academic judgment to the tool.
THE PROCESS | |||
Project development | Throughout the second half of the semester, the students develop an independent project. They choose one or more structural labor market models to address a research question and receive model code. I introduce generative AI tools as part of the method for generating code, checking implementations, and exploring model behavior. I make it clear that students will primarily be assessed on their ability to justify their choice of model, interpret the results economically, and discuss what the model captures and overlooks, rather than on their ability to write code. | ||
Critical supervision | Supervision sessions centre on direct questions about the student’s own work: What does this function do? Why does the wage distribution have this shape? Which assumption drives the result? What would change if this parameter moved? Students who had engaged carefully can answer these questions. Those who have simply just accepted the AI generated output will discover their lack of understanding at a point when there was still time to recover. | ||
Planted-error review | Some model code shared during the project phase contains deliberate economic errors. E.g. a wrong calibration target, an implausible parameter value, or a specification that converges to the wrong equilibrium. These are not syntax errors — the code runs. During the project phase, students must critically assess the implementation and results, identify the problem, and propose a correction. The task targets a skill that neither generative AI nor mechanical testing can substitute for: knowing what the output should look like and noticing when it does not. | ||
Oral examination | The oral examination is the summative endpoint of the course. It tests economic reasoning directly: students must explain, defend, and contextualise their model. | ||
In the course evaluation, 9 of 16 students responded. The course received an overall rating of 4.2 out of 5. The statement that students had ongoing opportunities to test their understanding received the highest score in the evaluation, at 4.6 out of 5. Among the questions specifically related to supervision, students rated support for choosing a topic, formulating a research question, and selecting theory and methods particularly highly.
The critical supervision sessions worked well as a diagnostic. Students who had used generative AI carefully and understood their parameter choices could explain the economics. Those who had leaned on generative AI without working through the model struggled and usually recognized the gap themselves — at a point when there was still time to recover.
The planted error task was harder than expected: several students initially reported the code as correct, then identified the economic problem only after closer inspection. This supports the central claim of the project: the bottleneck is economic judgement, not coding fluency.
Raising project ambition had a mixed reception. Some students engaged well with the higher expectations; others found the combination of a harder project and AI-assisted coding disorienting, partly because the familiar scaffold — getting the code to run — was no longer the main challenge.
Students who found the shift in expectations disorienting may have experienced supervision as less effective for project management than for substantive discussion. One open comment noted that “sometimes we went through the stuff pretty quickly,” which suggests that pace in supervision sessions is worth revisiting.
The activity is the assessment: If students can produce outputs without understanding them, the activity no longer matches the intended learning. Restoring alignment means changing what students do, not only how they are tested.
Pressure reveals understanding quickly: Asking students to explain and defend their work in real time gave a sharper signal than a written rubric. It also prepared them for the oral examination. In a class of 10–15 students, this is feasible and should be exploited.
Raising the bar is a legitimate response to cheaper production: If code is easy to generate, the intellectual contribution must come from elsewhere — from the research question, the interpretation, and the economic argument. It helped to tell students this directly and frame it as a shift in what counts, not as a penalty for using generative AI.
