Yes, if they are "responsible" for the code delivered, where responsible means they understand the code, the architecture, the decisions made, etc.
In this case, the students had to invent multiple strategies to solve a specific problem. The "successful" groups did a mix of generated and hand-crafted code (don't know percentages), implemented different strategies and knew their plus and minuses, could change the code in a timely manner to accommodate some of my requests, etc. The "unsuccessful" group couldn't do any of that.
I'm not anti-AI (and really, what could I do if I were?) since I use it myself, I'm just anti-slop, especially from my students.
But in reality I've been slowly transitioning from group projects (for a subset of the grade) to "practical tests", where they must implement a significant subset of a larger project in a 2h class. Still experimenting though.
It was fine.
This is a good principle to maintain, I think.
I'm not a professor, but I manage a team of about a dozen people. The maxim I have is: "You're responsible for anything that hits git."
Don't care if the LLM generated it, or the LLM told you if it's a good idea. If you commit it, you are endorsing it as a good idea - so you're the one I'm going to ask about it. I see the same principle at work in your pedagogy.
> I'm not anti-AI (and really, what could I do if I were?) since I use it myself, I'm just anti-slop, especially from my students.
This hits. Especially this part:
> and really, what could I do if I were?
My completely unsolicited opinion: you're doing a responsible thing by teaching these students how to use AI as a reference, and keeping them honest about not using it as a substitute for their own critical thinking.