82% of enterprise leaders say their organization offers some form of AI training. 59% still report an AI skills gap. Same leaders, same survey: 517 of them, companies with 500+ employees, fielded between December 2025 and February 2026.
Read that pair again, because it is the whole story. Training provision is close to universal. The gap it was bought to close is still there.
The standard reading is that the training wasn’t good enough. Wrong vendor, wrong curriculum, wrong length, needs to be more hands-on, needs a 60-day roadmap and a capstone. I’ve sat through that meeting. I’ve been handed that roadmap.
Here is the reading I’d defend instead: the training worked exactly as designed. It put knowledge into people. Knowledge was never the missing input.
The fair objection: maybe the problem is dosage, not mechanism. Zapier surveyed 542 executives at companies with 1,000+ employees and found formal AI training reaches only 51% of IT and engineering teams, while 94% of those organizations already use AI and 77% call the need urgent. So yes: roughly half of engineering hasn’t had the class yet.
Fine. Then the useful question is what happened to the half that did. We have an unusually good answer, and it comes from a discipline that has been running this experiment for far longer than we have.
Security ran this experiment for twenty years and published the result#
We are about to spend a lot of money relearning something another discipline already paid for.
The largest study of anti-phishing training ever run covered 19,500 employees at UC San Diego Health over eight months, across ten phishing campaigns, published at IEEE Security and Privacy in 2025. The researchers looked for a relationship between recently completing the annual mandated training and the likelihood of falling for a phishing email.
They found no significant relationship. Embedded just-in-time training, the kind that fires the moment you click, moved the click rate by about two percentage points.
Two decades of mandatory annual security awareness training. Compliance dashboards at 100%. Completion certificates in every HR system on earth. Effect size: roughly nothing.
Phishing is not code review, and I’m not going to pretend the whole analogy transfers. But look at the failure mechanism, because that part does. Training delivers knowledge at time T. The decision happens at time T plus ninety days, under deadline pressure, at 4:40 PM on a Thursday, with a green build and a product manager asking when it ships. Knowledge decays on a calendar. Pressure does not.
We are now running that same experiment on engineering judgment, at higher speed, with the results going straight into production.
The AI version of that failure is already sitting in the data#
You do not have to model this. It has been measured.
Apiiro tracked more than 7,000 developers across 62,000 repositories. Developers using AI assistants produced three to four times more commits. By June 2025 those repositories were generating more than 10,000 new security findings per month, a tenfold increase in six months. Credentials and keys were exposed nearly twice as often by AI-assisted developers as by their unassisted colleagues.
The commits also consolidated into fewer, larger pull requests, which is the part that should worry you most, because it means the review surface got bigger at exactly the moment the review queue got longer.
On the generation side, Veracode ran 80 curated coding tasks across more than 100 models. In 45% of cases the models introduced an OWASP Top 10 vulnerability. Java failed above 70%. Cross-site scripting and log injection failed 86% and 88% of the time. Bigger models did not do meaningfully better, which tells you this is structural, not a scaling problem you can wait out.
And then there is the case everyone cites. Moltbook launched in January 2026, built by a founder who said publicly he hadn’t written a single line of code. Wiz found the entire production database exposed: 1.5 million API authentication tokens, 35,000 email addresses, private messages. The cause was a Supabase key shipped in client-side JavaScript with row-level security never enabled.
Now hold those three findings next to the training thesis and watch what breaks.
The Apiiro finding is not a knowledge failure.
Every engineer in the Apiiro dataset already knew not to commit a credential. They committed credentials twice as often anyway, because the system let them and the pace rewarded it. You cannot lecture a behavior into a team and then hand them a system that punishes it.
Exposed secrets, permissive CORS, string-concatenated SQL. None of this is obscure. It’s the first slide of every secure-coding deck ever built. The engineers shipping it are not uninformed. They are moving at four times their old commit rate through a pipeline that was designed for a slower human and has no opinion about any of it.
The Veracode finding cuts deeper. The author of the vulnerability is the model, and the model doesn’t attend your workshop. Its statistical preference for insecure patterns does not change when your engineers get smarter. It changes when the context you feed it forbids the pattern and the gate refuses the diff.
And Moltbook? Sure, call that one a knowledge gap. The founder didn’t know what row-level security was. He was also never going to be in anyone’s curriculum, because he isn’t a developer, and the next hundred like him won’t be either. The population shipping production software now includes people, and models, that no training program will ever reach. A control that only works on trained employees is no longer a control.
AI is an amplifier, and amplifiers have no opinion about your curriculum#
The 2025 DORA report is the most useful thing published on this, and its central finding is one sentence: AI amplifies whatever foundation you give it. I broke the report down when it landed, in Ship Faster Without Breaking Things, and a year of watching it hold up has only sharpened the point.
DORA’s AI Capabilities Model names seven things that determine whether AI makes an organization better or just faster at being broken. Go down the list. Healthy data ecosystems. AI-accessible internal data. Strong version control. Working in small batches. User-centric focus. Quality internal platforms. A clear, communicated AI stance.
Six of those seven are properties of a system. One is a memo. Zero are courses.
The platform finding is the blunt one. Around 90% of organizations now have internal platform capabilities and 76% have dedicated platform teams, and platform quality is what decides whether AI adoption produces organizational gains or nothing at all. Paved paths, guardrails, automated tests, easy rollback: those turn AI into leverage. A half-built platform turns AI into a faster mess.
Faros telemetry from 2026 puts numbers on the faster mess. Tasks completed per developer up 33.7%. Epics up 66.2%. And on the other side of the same ledger: pull request size up 51.3%, median review time up 441%, bugs per developer up 54%, incidents per pull request up 242.7%.
That is not a team that needs a class. That is a team whose delivery system is being asked to absorb four times the throughput with the same gates it had in 2023.
Training does work. It just has to live inside the system.#
I’m not arguing against learning. I’d be arguing against my own last two years if I were. I’m arguing about where capability is installed.
Anthropic ran the cleanest experiment I’ve seen on this. 52 engineers, mostly junior, learning the Trio library for async Python, randomized into AI-assisted and hand-coded groups. The AI group scored 17 percentage points lower on a quiz about concepts they had used minutes earlier. The worst gap was in debugging, which is precisely the skill you need when generated code breaks. The speed advantage didn’t reach statistical significance.
Then comes the finding that actually matters, and almost nobody quotes it. Using AI did not guarantee a lower score. The participants who retained the material were the ones who asked follow-up questions, requested explanations, and interrogated what came back.
Same tool. Same task. Same sitting. The variable was behavior, not curriculum.
That’s the crux. You cannot teach that behavior in a workshop, because the behavior is a choice made hundreds of times a week under time pressure, and the workshop is a Tuesday. What you can do is make it the path of least resistance. Attach the learning to the artifact.
The one form of security training with a real effect size is the kind that fires inside the pull request, against the actual vulnerable line, in the developer’s own diff. Secure Code Warrior claims up to 53% vulnerability reduction from secure-by-design programs built that way, and while that’s a vendor’s number about a vendor’s product, the shape of it matches the UCSD result: the training that works isn’t a calendar event, it’s a property of the pipeline.
Same reason the paved-road model works. Engineers stay on the paved road not because a policy told them to, but because it is genuinely the easiest way to ship. Design the fast path and the safe path to be the same path, and you stop needing to win an argument every Thursday afternoon.
I made the individual version of this argument in The End of Courses: the 40-hour prerequisite is dead, and learning is now just-in-time, experiential, and on the job. This is the organizational version. If learning is just-in-time, then the delivery mechanism is the toolchain. Not the LMS.
What I’d fund instead of a curriculum#
If you handed me the AI enablement budget tomorrow, close to none of it would go to seats in a course.
Close to none, not none. A small group has to design the paved road: the platform engineers, the people who own the gates, whoever builds the context layer. They need deep, expensive, genuine fluency, because every constraint everyone else operates inside is a judgment call they made. Train those people properly and keep training them. The mistake is funding that depth for five hundred engineers instead of the fifteen who are building what the five hundred will walk on.
Here is where the rest goes.
Put the standards where the agent reads them. Your architecture decisions, conventions, approved libraries, and forbidden patterns need to live in the repository as machine-readable context, not in a slide deck and not in three senior engineers’ heads. An agent that can read your ADRs stops inventing its own architecture. This is the single highest-leverage thing most orgs haven’t done, and I wrote the build guide for it in Your AI Agents Are Flying Blind. A rule that isn’t in the context window is a rule that doesn’t exist.
Move the gate to the diff. Every constraint you currently teach should be a check that fails. Secret scanning, dependency policy, authorization test coverage, row-level security assertions in the migration pipeline. If it matters and it’s mechanically verifiable, a human should never be the primary detector. Humans are the wrong instrument for repetitive verification, and at 4x commit volume they are also now the bottleneck. That’s the argument behind Stop Reviewing Code, Start Reviewing Evidence. Every agent I run in production ships through gates like this. The gates are why they get to ship.
Review the spec, not just the output. The most valuable document in an agentic workflow is the one written before generation: acceptance criteria, boundary conditions, threat model, explicit non-goals. Teaching an engineer to write a rigorous specification compounds. Teaching them prompt phrasing depreciates the moment the next model ships with better intent recognition.
Attach the learning to the artifact. Every review comment an agent or a linter leaves should carry the why, in context, on the line. That’s your curriculum. It’s delivered a hundred times a week to the person who needs it, about code they wrote ten minutes ago, and it costs you no calendar time at all.
Fund the platform before the program. DORA’s finding is not subtle. If your internal platform is inconsistent, AI adoption returns approximately nothing, and no amount of enablement changes that. A quarter of platform work beats a quarter of workshops, every time.
Measure the system, not the seat. Course completion and license utilization are activity metrics, and activity metrics are what you report when you can’t report outcomes. I’d track rework rate, change failure rate, review latency, and verification coverage, the fraction of agent output that passes through a check capable of catching it being wrong. If those four move, the capability is real. If only completions move, you bought a certificate.
Notice what’s common to all six. Not one of them depends on a specific engineer remembering a specific thing on a specific Thursday.
The line item is the tell#
Here’s the uncomfortable part, and then I’ll stop.
“AI training” survives as a budget line because it is beautifully easy to buy. It has a price, a duration, a completion percentage, and a slide. It converts an unbounded organizational problem into a bounded procurement decision. You can finish it. You can report it. You can put the completion rate on a board deck and nobody in the room will ask what changed in production.
Capability doesn’t work like that. It isn’t completable. It’s the accumulated shape of your platform, your gates, your context layer, and your definition of done, and it has to be maintained the way you maintain any production system, because that’s what it is.
And notice who publishes the ROI numbers on training. The 4x to 6x return figures making the rounds in AI-training decks trace back, almost without exception, to companies that sell AI training. That doesn’t make them false. It does mean nobody in that chain is incentivized to tell you the intervention is the wrong shape.
Engineering leaders are being sold a syllabus for a systems problem. AI made code cheap to produce and not cheap to own, and ownership is not a thing you can teach into an individual. It’s a thing you build into the path. Supervision is the architecture, which is the whole argument of Agentic Overwatch, and architecture is not a course you graduate from.
So my challenge for anyone with an AI enablement line in their 2026 budget. Take the number and split it. How much is buying knowledge that has to survive ninety days and a deadline, and how much is buying constraints that hold at 2 AM without anyone remembering anything?
If the first number is bigger, you already know what the survey is going to say next year.
And if you’ve run a training program that actually moved rework rate or change failure rate, not completion rate, I want the details. The bar: same teams, measured before and after, platform maturity held roughly constant. Or a traceable line from a thing you taught to a decision someone made differently under deadline. Show me one of those and I’ll change how I spend money. That’s the case I’d most like to be wrong about. Find me on LinkedIn, X, or Telegram.