Group projects, slides, and code
Three situations that do not fit the essay-shaped advice so far, each with its own trap.
Group projects
The interesting problem with AI in group work is not integrity. It is that a group can produce a lot of plausible material very quickly, and end up with fifteen pages nobody has read, no shared understanding, and a presentation where three people contradict each other.
Two agreements, made in the first meeting, prevent nearly all of it.
Agree the AI rule out loud. Not because someone will cheat, but because people's assumptions differ enormously and discovering the difference the night before submission is unpleasant. Five minutes: what is fine, what needs flagging, what we do not do. Write it in the group chat.
Every section has a human owner who can defend it. Whatever produced the draft, one named person has read it, understands it, and can answer a question about it. This single rule kills the failure mode entirely, because it makes unread material somebody's problem before it is everybody's.
Where AI genuinely helps a group: reconciling voice across sections written by four people, which is a real task and tedious; producing a devil's-advocate critique of the whole thing before you submit; and turning a messy meeting into decisions and owners, which is the most reliably useful thing on this list.
Presentations
Slides are mostly a task. The argument is not.
Fine, and a real time-saver: turning a finished document into a slide outline, tightening a wordy slide, generating speaker notes from your own bullets, suggesting where a diagram would carry more than text.
Not fine, and it shows: generating the content of a presentation you then read out. Presentations are examined by questions afterwards, which is the most efficient detector of shallow understanding ever devised. There is no recovery from a good deck you cannot defend.
The genuinely valuable move is to rehearse against the assistant: "Here is my presentation. You are a sceptical examiner. Ask me the five hardest questions, one at a time." Then answer aloud. Ten minutes of this is worth an hour of redesigning slides, and it finds the soft spot every time.
Programming assignments
The specific danger here is different from an essay's, and it is worth naming precisely. An assistant will write working code for almost any undergraduate assignment. You will submit it, it will pass, and you will not be able to debug anything — including, six months later, your own project.
Programming is learned by being stuck and getting unstuck. Removing the stuck-ness removes the learning entirely, and unlike an essay you can fake, code that you cannot debug fails visibly the first time something breaks.
The rule that keeps this safe: never paste code you cannot explain line by line. Not roughly — line by line, including why that particular function, and what happens if the input is empty.
Uses that keep the learning intact and are genuinely excellent:
"I get this error and I don't understand what it's telling me. Explain the error, don't fix my code." Reading error messages is the actual skill, and it is teachable this way.
"Here is my function. It works. What would a more experienced programmer criticise?" Code review, which is how programmers actually improve and which students almost never get.
"Explain what this line does" on code you were given. Reading unfamiliar code is most of the job.
"I want to do X. What are two approaches, and what are the tradeoffs?" — then you implement the one you chose. The choosing and the implementing are the skill; the enumerating is a task.
And the honest version of the test: if you can write it after reading the explanation, with the tab closed, you learned it. If you can only paste it, you did not.
Do this today: if you have a group project running, put the AI rule and the section-owner rule in the group chat now. It is a two-minute message that prevents the most common way these go wrong.