| I have seen it firsthand in the CS department here at Dartmouth. It is bad. We're currently designing a new intro systems curriculum, and we're thinking of it as an adversarial problem. That is, we're designing the course to ensure that a student optimizing for the best grade per unit work still meets our learning objectives. That means, as everyone else is saying, paper exams, but also 1-on-1 interviews to check that students understand each assignment they turn in. These interviews feature both factual questions ("You're using this macro from that library. What does it do?", "Please describe what this function does and how it works.") and conceptual questions ("Why is this code structured this way instead of $whatever?", "How else did you try solving this?", etc.) This doesn't stop students from generating code, but at least they have to understand that code in detail. This is not as good as writing the code yourself, but how much worse is it? For math classes, this gap is gigantic. Obviously, understanding someone else's proof is much easier than writing your own. For programming classes, I think (without evidence) that the gap is somewhat smaller. My experience from the past is that when this kind of evaluation is made clear up front, the students know what to expect and either do fine or drop the class in the first week. If you start with take-home exams and then spring paper exams on them halfway through the course, then half the class is cheating and won't be able to recover, as we read in the article. In general, our students are somewhat motivated by an abstract desire to learn, but are much more motivated by grades. If there exists a straightforward path through your course that leads to a good grade without doing much work, most students will take it. (Our undergrads' course review website is literally called "Layup List." They are actually this shameless.) It's our job as instructors to ensure that all paths leading to a good grade either require learning the material or are more difficult to pull off than just learning the material. It's best not to blame the students. They are good at optimizing metrics; that's how they ended up here in the first place. We just need to better align the evaluation metrics with the outcomes that we're looking for. |
Unrelated, but once you get to a more mature level, say grad school and above, I can say this is not always the case! Just like it's easier sometimes to Roll Your Own Damn X in programming, so too are some expositions of proof so dense (necessarily or unnecessarily so) that it is a less taxing affair to simply figure it out yourself, or at least figure out 90% of it, consulting a suggestive sentence or two in the proof in order to get at that last 10%.
Maybe this observation of mine is not so unrelated after all. I don't regret many of the times that I've thrown up my hands at the rococo explanations or solutions given to me by LLMs and simply did my own work. The Socratic method with AI is sometimes more effort than it's worth.