I think we're using two standards without naming the difference.
- "Responsible for the code", i.e. understands it, can explain it, can modify it on request, is the right bar for a working engineer using an LLM to go faster. But it's the wrong bar for a student, because in a course the deliverable isn't the point, the practice is.
I presume that as course like 'Parallel Computing' exists to build the habits of reasoning about decomposition, contention, race conditions, strategy tradeoffs. Those habits come from doing the reps, the same way you don't learn to write by reading good prose. Your two "successful" groups outsourced exactly the reps the course is (or should be) there to build.
Being able to follow and tweak a solution proves comprehension, but comprehension is a much lower bar than producing the solution.
Your students may understand this particular solution well enough to explain it. But did they learn enough that they could tackle a different problem with a different shape, without using an LLM?
- "Responsible for the code", i.e. understands it, can explain it, can modify it on request, is the right bar for a working engineer using an LLM to go faster. But it's the wrong bar for a student, because in a course the deliverable isn't the point, the practice is.
I presume that as course like 'Parallel Computing' exists to build the habits of reasoning about decomposition, contention, race conditions, strategy tradeoffs. Those habits come from doing the reps, the same way you don't learn to write by reading good prose. Your two "successful" groups outsourced exactly the reps the course is (or should be) there to build.
Being able to follow and tweak a solution proves comprehension, but comprehension is a much lower bar than producing the solution.
Your students may understand this particular solution well enough to explain it. But did they learn enough that they could tackle a different problem with a different shape, without using an LLM?