The study is small enough to read carefully—and useful enough to change a rollout
Researchers Judy Hanwen Shen and Alex Tamkin ran randomized experiments with developers learning a new asynchronous-programming library. Their paper is about programming, not every office job, and its findings should stay in that lane.
Within that study, participants using AI showed weaker conceptual understanding, code reading and debugging. On average, AI assistance did not produce a significant efficiency gain. Participants who handed the work over more completely did get some productivity benefit, but learned less of the library underneath it.
The important detail is not “AI makes people worse.” The researchers identified six ways people worked with the tool; three that kept people cognitively engaged preserved learning outcomes. The design of the assignment mattered.
Do not make the trainee compete with the assistant
A manager can accidentally turn a useful tool into a bad training plan. Give a new analyst an AI-written query, judge only whether the dashboard appeared, and the lesson becomes: get a plausible answer out quickly. The analyst has no reason to learn why a join duplicated rows, what changed in the source data, or how to spot a number that should not be trusted.
The fix is not a performative no-AI rule. Keep the real task, then add one small ownership test that the assistant cannot quietly pass for them. Ask the person to name the inputs the result depends on, explain one decision the tool made, correct a deliberately broken version, or handle a nearby case with the AI turned off.
Those are not school exercises bolted onto a deadline. They are the same abilities a team needs when the vendor changes behavior, the source data moves, or a customer asks why the answer was sent.
Sable sees an apprenticeship problem. Theo sees a measurement problem.
Sable Quinn's concern is the first rung: when an assistant absorbs the small, repetitive assignments where someone learns the shape of a job, employers cannot quietly raise the bar and call it progress. A junior person still needs a bounded piece of work they can own from start to finish.
Theo Marlow puts a limit on the claim. This experiment concerned developers learning one library; it does not prove that every AI-assisted task erodes skill. The right test is local and concrete: before expanding a tool, define what the person must still be able to explain, spot and repair without it, then check that after ordinary work—not after a polished demo.
They are pulling in different directions, but neither answer is to make people slower for sport. The job is to let AI remove repetition without removing the practice that makes a person useful when repetition stops.
What to change on Monday
If you lead a team, choose one task where the AI is already doing more than drafting a paragraph. Write down the human capability that must remain after the assistant runs. Not a vague promise to “review,” but something observable: trace a source, explain a recommendation, edit a bad assumption, or finish a variant case.
If you are learning, ask for a repair task before you ask for more output. A clean first result can hide the part you do not understand. One broken example, a source check and a short explanation will teach you more than ten generated answers you only skim.
AI assistants can return time. The question is whether that time buys judgment, or merely raises the next target.