The Competence Trap: When a Team Stops Doing the Work

The most uncomfortable thing we noticed during a week of AI training with a client's technical team had nothing to do with the technology working badly. It worked well. That was the problem.

By day three the senior people were visibly faster. And the two most junior members of the team had gone quiet, because everything they would normally have been given to do was now being done in front of them in four seconds.

The trap, stated plainly

Routine work is not overhead. It is how competence is manufactured.

Nobody became good at debugging by reading about debugging. They became good by spending two hours on something that turned out to be a typo, and the next time recognising the shape of it in ten minutes. Nobody learned to write a safe migration from a document. They learned it by writing an unsafe one in a staging environment and watching what happened. The tedium was not a tax on the learning; the tedium was the learning, arriving in a form nobody enjoys.

When a team hands all of that to a machine, the work still gets done — better, faster, for a while. What stops is the manufacture of the judgement that lets anyone tell whether it was done correctly. And because the output stays good the entire time, there is no signal. The capability drains out of the team over eighteen months and the first hard evidence arrives on the day something breaks that the tool cannot handle.

You do not notice a skill you are not building. You notice it the first time you need it, which is always the worst possible occasion.

Two versions of the same problem

It shows up differently depending on where someone is in their career, and the two versions need different responses.

For juniors, it is a growth problem. The tasks that used to be theirs — the small fixes, the boilerplate, the first draft of the report, the ticket nobody senior wanted — were never valuable because of their output. They were valuable because they were a graduated syllabus that happened to also be useful. Remove the syllabus and you have a person who can prompt competently and has never once sat with a problem long enough to develop instinct about it. They will be pleasant to work with and dangerous to promote.

For seniors, it is an atrophy problem. It is slower, quieter and more comfortable. You have the judgement, so you use the tool well; and because you use it for everything, the muscles that produced the judgement stop being exercised. Two years on, you are still the person who signs off — but you are reviewing a domain you have not personally worked in for a while, and your reviews are getting shallower in a way you cannot feel from the inside.

What the team decided to do about it

We did not bring this rule to the course. They wrote it on the last afternoon, and we have since repeated it to every other client, with attribution.

That third clause is the one with teeth. It converts a vague worry about skills into something you can audit, and the audit is uncomfortable in a useful way: pick your five most critical routine operations and ask, for each, who could do this without the tool. If the answer for any of them is nobody, you have found a risk that no monitoring system is watching. It is technical debt in a form that does not live in the code.

Practice has to be chosen, because it will not happen by accident

Under deadline pressure, nobody voluntarily does something the slow way. That is not a character flaw, it is arithmetic, and it means deliberate practice has to be scheduled by someone with the authority to protect it.

The versions we have seen work are unremarkable. One task a week done unaided, chosen by the person doing it, no justification required. Juniors get first refusal on work that is small enough to fail safely, with a senior reviewing rather than pre-empting. A rotation through the unglamorous operations — the restore, the month-end, the manual reconciliation — so that the knowledge sits in more than one head.

The last one is worth doing regardless of AI. A restore that only one person has ever performed is not a backup strategy, it is a hope, and that was true long before any of this. What has changed is that the tools now make it much easier to avoid finding out — a very fluent assistant will walk you through a procedure convincingly enough that you will feel prepared without ever having been.

The manager's version of the mistake

There is a specific error we have watched several capable managers make, and it is worth naming because it feels like diligence.

It is the belief that reviewing output is equivalent to knowing how. It is not. Reviewing tells you whether something looks right against a standard you already hold; it does very little to maintain that standard, and nothing at all to build it. A manager who has spent three years exclusively reviewing AI-assisted work has a decaying model of what the work involves — and will underestimate how long things take, misjudge which parts are risky, and be unable to tell a genuinely difficult problem from a badly framed one.

The correction is small: stay technical in a narrow, deliberate way. One real piece of work a month, done properly, start to finish. Not to be useful — you will not be, at that volume — but to keep the model current. The same instinct that says a good steering committee needs people who know the detail applies to your own head.

The counterargument, taken seriously

There is a real objection to all of this, and it deserves better than a dismissal: we do not mourn the skills that previous automation took. Very few developers can hand-optimise assembly, and the industry is not worse for it. Nobody proposes that accountants return to ledger paper to keep their arithmetic sharp. Insisting that people keep doing things the hard way for its own sake is nostalgia in a lab coat, and it is a real risk of an argument like this one.

The distinction we would draw is about who checks. Automation is safe to fully absorb a skill when the automation is deterministic and its failures are loud — a compiler is more reliable than you are, and when it is wrong you find out immediately. It is not safe to fully absorb a skill when the tool is probabilistic and its failures are quiet and confident. In that arrangement, human competence is not nostalgia. It is the verification layer, and the system does not work without it.

So the question for any given skill is not is this drudgery. It is: if the tool is subtly wrong here, what notices? Where the answer is a test suite or a reconciliation, let the skill go. Where the answer is a person's judgement, keep making that person.

What this means for hiring in the next few years

One last observation, offered tentatively, because it is a prediction rather than something we watched happen.

If entry-level technical work largely disappears into tooling, the pipeline that produces senior people disappears with it — and the shortage arrives four or five years later, at every company simultaneously, for reasons no individual company will feel responsible for. The organisations that come out of that period well will be the ones that treated junior development as an investment they chose to keep making while it was cheaper not to. It is the same logic as maintenance: entirely optional right up until it is not, and by then unavailable at any price.

That is not a reason to slow down on AI. It is a reason to be explicit that learning is the standing requirement of this period — for the people coming up, and for the people signing off on their work.

The honest summary

Use the tools. They are good, they are not going away, and refusing them on principle is a way of being slower without being safer. But notice that competence has a supply chain, that routine work was most of it, and that nothing is currently replacing it. Keep some practice on purpose. Give the small work to the people who still need it. Ask, once a quarter, who on this team could do the critical things unaided — and treat any answer of nobody as the operational risk it is, rather than the efficiency it looks like.