Good AI training changes the work

Most AI training I have seen stops at awareness. Somebody explains what large language models are, shows a few impressive demonstrations, hands out a list of prompt patterns, and the room leaves entertained. A week later almost nobody is working differently, and the organisation concludes that its people are resistant to change.

They are usually not resistant. They were shown a capability and sent back to a job that still has its own deadlines, systems and habits. Nothing in the session told them which of their tasks this applies to, or what to do when the output is nearly right, and the gap between a demonstration and a Tuesday afternoon is wider than it looks.

I have run training and workshops on this, and the part that changes outcomes is the least impressive part to watch. It is the hour spent on the participants' own work.

Enjoyment is not adoption

There is a distinction most training feedback avoids. One claim is that people enjoyed the workshop. Another is that people changed how they solve a recurring task. The first is easy to achieve and easy to measure. The second is the one I would defend as the point of the session, and it shows up in the work rather than on a form.

Held to that second standard, a lot of standard content falls away. A tour of the available models does not survive it. Neither does a list of prompts detached from any real task, because a prompt pattern only helps somebody who has already decided what they are trying to produce and how they will know it is good.

The progression that works

What has worked for me is a sequence, and the order is the content. Each step is unremarkable on its own. It starts with awareness, briefly, because people need a roughly accurate idea of what the tool is and where it fails. The step usually missing comes next: pick something you do regularly, describe it precisely, and decide which part of it is actually hard. Structured prompting is taught against that task rather than in the abstract, which is when the patterns stop feeling like tricks. Participants then work on realistic examples, using their own material, messy and incomplete as it is.

Checking the output is what separates useful training from a demonstration. People have to meet a confident, fluent, wrong answer in their own domain and find the error themselves. That one experience does more for judgment than any warning I can give, because it replaces trust in the tool with a method for interrogating it.

After that the work is about the workflow: deciding where in an existing process the tool sits, what the input is, who reviews the result and against what. Carrying the behaviour back needs a task that recurs soon, not once a quarter. Sharing what works comes last, because the fastest route to a second person adopting something is a colleague showing them a version that already survived contact with the real job.

The capabilities that turn out to be scarce

Follow that progression and it becomes obvious that prompting is not the skill. It is a small part of it, and the part that changes most with each model release. What people need, and what almost nobody teaches, is this:

• recognising which tasks are suitable at all, which is mostly a judgment about consequence and about how easily an error would be caught;
• decomposing work into steps, because a task described as one instruction usually cannot be checked and often cannot be done;
• supplying context, which is the difference between a generic answer and a useful one, and which means knowing what the model cannot know;
• evaluating output against something: a source, a calculation, a standard, or an experienced expectation;
• knowing when to verify harder, based on what happens if the answer is wrong and whether that can be undone;
• knowing when not to use it, which is a real skill and the one most training discourages;
• integrating the result into the work, so the output lands in the document, the system or the process where it is needed.

Each of those is a judgment about the work rather than a fact about the tool, which is why they survive a model upgrade and a prompt list does not.

Knowing when not to use it

The item people find most surprising is the one about not using it. A workshop that spends three hours on capability and no time on limits produces enthusiasm with no brakes, and the first serious mistake then costs more adoption than a careful session would have.

The cases worth naming are mundane. Work where checking the output costs more than doing the task. Work where the input cannot leave the organisation. Work where the person needs to build the understanding themselves, because they will be asked to defend it. Work where a deterministic tool already gives an exact answer and a language model can only approximate it. Naming these does not reduce use. In my experience it increases use, because people stop guessing where the boundary is.

What a good session leaves behind

What I try to leave with a team is not a set of prompts. It is a small number of tasks where they have already done the work once with the tool, met the failure modes, and agreed how the output gets checked.

That is portable. The prompt will change, the model will change, the interface will change. A team that has decided which of its recurring tasks AI helps with, and how the result is verified before anyone acts on it, keeps something through all of that. A team with a prompt library has a document that ages.

It also spreads differently. People rarely adopt a capability because it was presented to them. They adopt it when a colleague with the same job shows them a version that worked on the real thing, so training that produces two or three people who can do that has done more than a session that impressed a full room.

Training should build judgment, not dependence

The two possible outcomes of AI training look similar at first and diverge quickly. One is a group of people who can get a plausible answer out of a tool and have no way to tell whether it is right. That is a dependence, and it makes the organisation more fragile, because the work now moves faster in a direction nobody is checking.

The other is a group of people who know which of their tasks this is good for, what the output is worth, how to check it, and when to leave it alone. That is judgment, and it carries over to the next tool as well as this one.

Which outcome a session produces is almost entirely a matter of what it spent its time on. Capability demonstrations produce the first. Working on real tasks, and being made to find your own errors, produces the second.