Assistant, Not Replacement: Lessons From an AI Course

We spent a week recently with a client's technical team — nine people: four developers, two analysts, a systems administrator, and two support engineers who between them know more about that business than anyone in its management. The brief was ordinary enough. Teach them to use AI properly.

By the second morning it was obvious the course we had planned was not the course they needed. The problem was never which tool to open. It was what they were handing it.

Two wrong assumptions, sitting in the same room

The team split cleanly on day one, as they usually do.

Half had decided AI was coming for their jobs, and had responded by using it as little as possible — a quiet, entirely rational protest that mostly meant they were slower than colleagues who had made peace with it. The other half had gone the opposite way: paste in the ticket, take what comes out, ship it. That group was faster right up until the afternoon someone had to explain a change to a customer, and nobody in the room could.

Both halves had made the same mistake from opposite ends. They were both treating AI as something that does your job. One group feared it. One group hoped it. Neither had asked the more useful question, which is what a job is actually made of.

A job is not a task, and the difference is where the value is

Your job is an outcome you own. The invoicing run reconciles. The deployment does not take the site down. The customer's problem is actually solved rather than closed. You carry that outcome — it has your name on it, and if it goes wrong on a Friday, your phone rings.

A task is a step on the way there: gathering the data, writing the boilerplate, reading the log, drafting the note, formatting the report, checking the edge cases. Nobody's phone rings about a task.

That distinction sounds academic until you apply it, so we made the team apply it. The exercise takes twenty minutes and we now open every course with it.

Across nine people the answer was not close. Most of the working day was production, and much of it was a specific and unglamorous kind: turning something that existed in one form into the same thing in another form. A stack trace into a description of a problem. A spec into a checklist. A finding into an email a manager would read. Nobody in that room had been hired for their formatting.

Nobody's phone rings about a task. That is exactly why a task is the safe thing to delegate — and the judgement is not.

The demonstration that changed the room

On the second afternoon we ran the same problem two ways, on their own code, in front of everyone.

The first way was the way most of them had been working: write me the migration script for this table. It produced a migration script. It was plausible, well-commented, and quietly wrong about one nullable column in a way that would have surfaced three weeks later as a support ticket nobody could reproduce.

The second way used the same model, the same table, and about the same amount of typing: here is the schema, here are the three business rules that govern this data, and here is the migration I have drafted. List the edge cases you would expect me to have got wrong, and tell me how you would test each one.

It found the nullable column. It also raised two cases the senior developer had considered and consciously rejected, which is exactly what you want — a review that is occasionally wrong in ways you can dismiss in five seconds is enormously more valuable than a draft that is occasionally wrong in ways you find in production.

Same tool, same five minutes. In the first version the machine did the work and the human checked it. In the second the human did the work and the machine checked it. The second is not a prompting trick; it is a different distribution of responsibility, and it is the whole course in one example.

Ownership does not transfer, no matter how good the output is

This is the sentence we repeated until it became a joke in the room: you still sign the work.

Nobody has ever successfully told a customer that the AI wrote the bit that broke. Nobody has told an auditor that the reconciliation was assembled by a language model, so the variance is not really theirs. The professional accountability sits exactly where it always did, with the person whose name is on the commit, the report or the ticket.

Once a team internalises that, their behaviour changes without anyone having to police it. You stop pasting in things you cannot evaluate. You start asking for output in forms you can actually check. You get faster at the parts you were always going to be accountable for anyway, because the surrounding work stops eating your day. This is the same discipline that separates a useful assistant from an expensive one, and we have written about the judgement side of that skill before.

What the week actually taught us

We went in to teach and came out with three lessons worth more than the material we had prepared. Each of them turned into its own piece, because each of them changes what a competent team does on a Monday morning.

One: the value sits at the edges of a task, not in the middle. Every piece of work has a middle where the judgement lives, and edges made of setup, translation and checking. Aim at the edges and the gains are immediate and safe. Aim at the middle and you get something confident and unaccountable. That is the shape of the whole thing.

Two: time saved producing is only real if verifying is cheaper. The team found several tasks where the AI finished in a minute and the checking took the rest of the afternoon. That is not a saving; it is a transfer, usually to someone more senior. The verification tax is the single most useful idea we took away.

Three: routine work is how people become good. The seniors got noticeably faster during the week. The juniors got quieter — and that is a problem that compounds silently over a year. The competence trap is the one a manager has to actively design against.

The bits of the course that were not about AI at all

Two of the strongest sessions had nothing to do with the technology.

The first was about writing down what the team knows. Half the reason their AI output was mediocre was that the context it needed did not exist anywhere — not in a document, not in a README, only in the heads of two people who had been there since 2019. An assistant cannot use context nobody has written down, and neither can a new hire. Teams that keep documentation that is actually current get better AI output for free, which is a strange but genuine argument for doing the thing everybody already knew they should do.

The second was about what goes into the tool at all. Somebody asked, quite reasonably, whether they could paste a customer's data in to get help with a query. The honest answer depends on which tool, on which plan, with what retention — and it is a policy question rather than a technical one. If your organisation has not answered it, your team has already answered it for you, one paste at a time; that is the shadow AI conversation, and it is better to have it deliberately.

If you want to run this yourself

You do not need us to do it, and it works better with your own work in front of you. Book two hours. Do the Tuesday exercise on real diaries. Take one task everybody in the room does weekly and run it both ways — machine drafts and human checks, then human drafts and machine checks — and talk honestly about which output you would have been comfortable signing. Write down three tasks the team agrees are safe to delegate and one that is explicitly off-limits, and put that list somewhere people will see it.

Then leave it alone for a month and repeat. Adoption is not a memo, and it never has been; it is a set of habits people build while doing their actual work, which is the same reason good systems fail at go-live.

The honest summary

Nine people spent a week learning something they could have written on an index card: use AI to do your tasks, not your job. What made it land was doing it on their own work, with their own code, in front of colleagues who would notice if the answer was wrong. The team that came out the other end is not faster because they type better prompts. They are faster because they stopped handing over the part they are paid for, and started handing over the part that was never the point.