Literacy programmes teach people to use the tools. They do not produce teams who can judge whether the output is safe to ship. A field guide for L&D leaders on what to teach instead.
Most organisations have now run an AI literacy programme. Attendance was good, the feedback scores were fine, and a year later the engineering team is not meaningfully more capable of shipping AI than it was before.
This is not because the training was bad. It is because literacy and capability are different things, and the first does not compound into the second.
A typical programme covers what the models are, how to prompt them, which tools are approved, and what not to paste into them. All of that is worth knowing, and none of it is wasted.
But look at what it produces. It produces people who can use a tool that will be replaced within eighteen months. The half-life of that knowledge is short, and everyone in the room knows it, which is part of why the enthusiasm fades.
The deeper problem is that using AI and building with AI require almost entirely different judgment. A person who is excellent at prompting a chat assistant has learned nothing about retrieval quality, evaluation design, latency budgets, failure modes, or what happens when the model is confidently wrong in production at three in the morning.
The teams who ship AI reliably are not the ones with the best prompts. They are the ones who can answer four questions before they build anything.
The single strongest predictor of whether an AI project ships is whether the team defined success before they saw any output. Teams who skip this end up in an unwinnable argument about whether the demo felt impressive, which is not a question that can be settled.
Traditional software fails loudly. AI systems fail silently and plausibly — they keep returning well-formed answers that are increasingly wrong. A team that has not thought about detection will find out from a customer.
This is the question that separates a chatbot that suggests a document from a system that declines someone's application. Same technology, entirely different obligations. Teams that cannot reason about this build both the same way.
A great many promising prototypes are quietly abandoned when someone finally multiplies the per-request cost by the real request volume. That multiplication should happen in week one, not month six.
None of these four are about models. All of them are about systems. And none of them are taught in a literacy programme, because they are not knowledge — they are judgment, and judgment is built by making decisions and seeing the consequences.
Three shifts, in order of impact.
Teach the systems around the model, not the model. Retrieval, evaluation, guardrails, monitoring, cost. This is the material with a long half-life. The specific model your team uses will change; the discipline of evaluating one will not.
Make people ship something real and then live with it. A capability programme that ends at a demo has taught the same lesson as a literacy programme, more expensively. The learning is in operating the thing after it exists — watching it drift, finding the failure you did not anticipate, fixing it. Nothing else produces the instinct.
Teach the whole decision chain together, not by role. The most expensive failures happen in the gap between a product lead who does not know what an evaluation can and cannot prove, and an engineer who does not know which errors the business can absorb. Training those two separately preserves the gap. Put them in the same room and make them scope something together.
Literacy programmes are not useless, and this is not an argument for abandoning them. Broad literacy is genuinely worth having across a whole organisation, and it is cheap.
The mistake is treating it as the first rung of a ladder to capability. It is not a rung. It is a different ladder, and the people you need to ship AI have to climb the other one — which is longer, narrower, and mostly made of systems engineering rather than AI.
Budget accordingly. Broad and shallow for the organisation; narrow and deep for the teams who build.
