The short version
- The workshop is the default buy for a team that can't protect a month of one codebase area. If you can protect that month, an embedded consultant beats us, and I'll show you why below.
- The constraint isn't that your engineers can't write code with AI. It's that nobody can check the volume they're now producing. DORA's 2025 report found AI adoption correlates with higher delivery throughput and worse delivery stability across nearly 5,000 respondents. The bottleneck moved. It didn't leave.
- Internal training's real cost isn't the invoice. It's that the engineers who could build the curriculum are the same engineers who are already your review bottleneck.
- All training decays. Across 150 organizations, 62% of employees applied training on the job immediately, 44% at six months, 34% at a year (Saks & Belcourt, 2006). That's true of ours too.
- Don't buy anything if you can't name what will be different in code review the Monday after. DORA's finding is that AI amplifies what's already there. A team with no review gate buys a faster way to produce code nobody reads.
Why an external workshop is the default, unless you can protect a month
A workshop puts a working standard in your team's hands in a day, against weeks for an embedded consultant, months for a course nobody finishes, and longer for a hire. Ours run $250 for two hours and $900 for a full day. That speed is the whole argument, and I'm going to be specific about where it does and doesn't win, because "we're faster" is the kind of claim that sounds like marketing until someone shows you the arithmetic.
Here's the problem you actually have.
Generation got free. Verification didn't. Your engineers can produce more code in a morning than your seniors can meaningfully review in a week, and the constraint on your team quietly relocated from "can we build it" to "can anyone tell whether it's right." DORA's 2025 report puts numbers on the relocation: AI adoption now correlates positively with delivery throughput and still correlates negatively with delivery stability. More change, landing faster, breaking more. Their own summary is the sharpest thing written about AI and engineering teams this year: "AI doesn't fix a team; it amplifies what's already there."
So the thing you're buying isn't "AI skills." Your engineers have those, or they'll have them by August without your help. What you're buying is verification capability, meaning your team's ability to check its own AI-assisted output without a senior reading every line. Three mechanisms make a workshop the default way to buy it.
It doesn't spend the thing you've already run out of. Verification capacity is senior attention, and senior attention is exactly what internal training consumes. Name the person who'd write your internal curriculum. I'll wait. That person is your review bottleneck, and internal training asks them to stop reviewing for three weeks to build the thing that will eventually help them review less. Maybe that trade works. But you're spending the constraint to fix the constraint, and you're spending it up front.
A day, against weeks or months. This is the mechanism that actually does the work, and it's checkable arithmetic rather than a claim about quality. $900 and one day against weeks of an embedded engagement. Nothing about a course or a hire lands inside a quarter.
An outside standard doesn't get relitigated by your other principal engineer. A standard written internally has exactly as much authority as its author's standing in the room. When your other staff engineer disagrees, it's a negotiation, and you've watched that negotiation before. An outsider arrives with no stake in it. And here's the cost of that same property, in the same breath: the outsider also arrives with no idea what your codebase looks like. That's real. It's the thing a workshop is structurally worst at, and it's why the fourth condition below exists.
Which of those actually discriminate, and against what
Two of those three mechanisms do nothing against a good consultant, and you should hear that from me rather than work it out yourself on the drive home.
| Mechanism | Internal training | Online course | Hire | Embedded consultant |
|---|---|---|---|---|
| Doesn't spend senior attention | Workshop wins | Tie | Workshop wins (mentoring load) | Tie, and I'm being generous to myself |
| Speed and price | Workshop wins | Workshop wins | Workshop wins | Workshop wins, but it buys a narrower thing |
| Outside standard, no internal politics | Workshop wins | Tie | Workshop wins | Consultant wins |
Against an embedded consultant, only speed and price survive. The consultant's standard is just as external as ours and it knows your codebase. That's not a tie, that's a loss, and it's a loss on the mechanism I just spent a paragraph defending.
One more piece of honesty on the speed row, because it's the one holding everything up. "We're faster" invites you to hear "same result, sooner." That's not what's on offer. A workshop teaches against exercises. An embedded consultant works inside your actual review queue. The workshop buys a narrower thing, faster and cheaper. For most teams that narrower thing is what they want and the price difference is a factor of ten. But it isn't the same thing, and anyone telling you it is, is selling.
The five options, described the way their advocates describe them
You've already considered all five. If my description of the one you're leaning toward doesn't match what you know it to be, you should stop trusting the rest of this, so I've written each one the way its own vendor would.
| Option | The case for it, at full strength | My honest counter | Verdict |
|---|---|---|---|
| External workshop | An outsider's standard, landing in a day, without touching the seniors who are already the bottleneck. $250 to $900 | Generic by default. Decays like all training. Knows nothing about your codebase | Default buy for a team that can't protect a month |
| Internal training | Your staff engineers know your codebase, your deploys, and your real failure modes. No outsider learns that in a day. The standard sticks because the people who wrote it are the people enforcing it in review, every day, forever. And it's the cheapest line on the invoice | The invoice isn't the cost. The engineers who can build it are the engineers who are already your constraint, and you pay them before you get anything back | Right when you already have the capability (see the first condition) |
| Online course | Cheapest per head. Scales to 50 engineers as easily as 5. Self-paced, so nobody loses a day. And it's the only option still standing there when someone joins in November. Cohort courses with graded submissions put a human on your engineers' real work | Self-paced video teaches the tool, and the tool is the part your engineers close on their own. Cohort courses do get eyes on the work, but on exercises, not on your code | Right for tool mechanics. See the blend question below |
| Consultant | Two shapes, and the strong one isn't "they do it for you". An embedded capability-transfer engagement puts an expert inside your review queue for weeks, on your code, contracted on your team standing on its own at the end. It matches the workshop's two best mechanisms and beats it on the one thing a workshop can't do | Price and speed. Weeks of an embedded expert against $900 for a day. That's my entire argument | The strongest competitor here, and it wins outright under the fourth condition. If you can protect a month and the money covers weeks, buy this instead of us |
| Hire | Permanent, compounding, in the room for every future decision. The only option that adds capacity instead of redistributing it. If you have four engineers and need six, no amount of training fixes that | Slow. And one strong hire doesn't distribute anything. You've created a new single point of review and called it a solution | Right when it's a hiring gap (see the second condition) |
What about a course for mechanics and a workshop for judgement
Fair question, and it's the one blend that isn't confusion. Those genuinely are different problems, and if the budget covers both, buying both isn't a mistake.
But if you're buying one thing this quarter, buy the workshop, because the two gaps don't decay the same way. The tool-mechanics gap closes on its own. Your engineers will work out Cursor's keybindings whether or not you pay for it. The judgement gap doesn't close on its own, and nothing in your team's normal week closes it either.
There's a study worth knowing here. METR ran a randomized trial in 2025 with 16 experienced open-source developers across 246 real issues. The developers expected AI to make them 24% faster. It made them 19% slower. Afterwards, having just been slowed down, they still believed it had sped them up by 20%.
Read the caveats before you quote that at anyone, because I'm about to argue for measurement discipline and I'm not going to cheat on the way there: METR themselves label the result historical, and a follow-up estimated −18% for returning developers and −4% for newly recruited ones. The effect size is unstable. The perception gap is the durable part, and it's the part that matters here. Your engineers closed the mechanics gap and couldn't tell you which gap they'd closed. That's the one to spend money on.
Four times I'd tell you not to buy a workshop
Three of these mean don't buy a workshop at all, and I'd route you elsewhere. One means not yet, and it's the weakest of the four, so I've said which is which rather than letting them all wear the same clothes. Each one has a test you can run this afternoon.
You already solved this and nobody wrote it down
The test: pull your last 30 pull requests. If the rework concentrates outside a small group whose PRs come through review clean, you don't have a skills gap. You have two or three people carrying a standard that only exists in their heads.
A workshop would import a generic standard to replace a better, codebase-specific one you already own. You'd be paying to overwrite your own asset.
Get those engineers to write it down instead. That's free. And it's not a soft option: DORA measures a "clear and communicated AI stance" as one of seven capabilities that amplify AI's impact, and the finding has a twist worth sitting with. The capability doesn't measure what your policy says. It measures whether the stance is clear and communicated at all. Your two good engineers already have the stance. It just isn't written anywhere.
It's a hiring gap, not a skills gap
The test, two questions, and a yes to either one means training isn't the instrument:
- Would this gap still be there if every engineer you have got twice as good tomorrow? If yes, you need engineer-hours, not better engineers. Four engineers trained perfectly are still four engineers.
- Is there nobody here with any foundation in the thing you need? If yes, there's no curve to move anyone along. Training moves people along a curve they're already on. It doesn't create a specialism from zero.
No workshop gives someone a foundation they don't have, and no workshop makes four people into six. Go and hire. I'm not going to pretend that's a worse decision than buying from me, because for that gap it isn't.
Not yet, because nothing changes in code review on Monday
The test: name the thing that will be different in code review the week after the workshop. One sentence. If you can't, you have your answer.
This is the weak one, and I'll say so plainly: it's a low bar, and any motivated buyer can clear it in about four seconds. But capability the surrounding system doesn't absorb is training theatre, and DORA's whole finding is that the value lives in the practices around the tools rather than in the tools. Buy capability into a system that won't use it and you've bought nothing.
Fix the gate first. This one is "not yet" rather than "not this", and I'm not going to dress that up as a reason to come back with a purchase order later. Right now, don't.
You can protect a month, and the money covers weeks
The test: could you protect one codebase area from interrupts for a month and put an outsider inside it? Not name the area, which is free. Protect it. If yes, and the budget covers weeks rather than a day, this isn't the buy.
An embedded capability-transfer consultant matches us on senior attention, beats us on the outside-standard mechanism, and beats us outright on the thing we're structurally worst at, which is knowing your codebase. A workshop teaches against exercises. An embedded engagement works inside your actual review queue for a month. When you can hand someone that queue, the only advantage I've got left is that I'm cheaper and faster, and you've just told me those aren't your binding constraints.
So buy that instead. An AI consultant embedded in your review cycle for a month will do more for your team than a day with me will.
And don't split the difference with "workshop now, consultant later." If you can protect a month and fund it today, a workshop first is money spent on a narrower version of the thing you're about to buy properly.
What a workshop doesn't do
It decays. Ours included.
Across 150 organizations, training professionals reported that 62% of employees applied training material on the job immediately, 44% at six months, and 34% a year out (Saks & Belcourt, 2006). Those are the good numbers, incidentally. They're the ones that corrected a widely repeated and badly sourced claim that only 10% of training ever transfers. But a third at twelve months is what buying a day of training gets you, and anyone selling you a workshop who doesn't tell you that is hoping you won't look it up.
What follows from that is a sequencing point rather than a reason not to buy. A workshop sets a standard. Whether the standard survives is decided by what your review gate does with it, and that's yours to build, not mine to sell you.
It also arrives generic. A day with an outsider is a day with someone who's never seen your monorepo. That's the trade you're making for the price and the speed, and it's the whole reason the fourth condition above routes some of you to a consultant instead.
How to decide in an afternoon
Run the four tests, in this order. Stop at the first yes.
- Pull your last 30 PRs. Does the rework concentrate outside a small clean group? Then it's a documentation job. Get them to write it down. Don't buy anything.
- Would the gap survive every engineer getting twice as good? Or is there nobody here with any foundation? Either yes, and it's a hire.
- Can you name what changes in code review on Monday? If not, fix the gate first. Buy nothing yet.
- Could you protect a month of one codebase area and fund weeks? Then buy an embedded consultant, not a workshop.
Four noes and you're the team a workshop is for.
If that's you: your engineers are shipping AI-assisted code faster than your seniors can read it, and the fastest way to change that is to put someone in the room for a day who has already watched other teams make the specific mistakes yours is about to make. That's the part you can't get from a course and can't build internally without stopping the exact people you can't afford to stop. AI workshops run from $250 for two hours to $900 for a full day, and you can tell us what your team needs in about five minutes. I read those myself.
Questions engineering leaders ask
How much should we budget for AI training for an engineering team?
Between $250 and $900 for a workshop, per session, not per seat. Ours are $250 for a two-hour fundamentals session, $500 for a half-day, and $900 for a full-day bootcamp. An embedded consultant is a different order of magnitude and buys a different thing. The number worth deciding first isn't the budget, it's whether you're buying a standard or buying the work done.
Can we just run AI training internally with our own staff engineers?
Yes, and you should if your team has already solved this and the gap is that nobody wrote it down. Pull your last 30 PRs; if a small group's work comes through review clean and everyone else's generates rework, the standard exists and just isn't documented. Buying a workshop then would overwrite something better than what you'd get. The case against doing it internally isn't quality, it's cost of a specific kind: the engineers who could build your curriculum are the ones already carrying your review load.
Is a team workshop better than one-to-one mentorship for every engineer?
For setting a shared standard, yes, and it's not close on price. The point of a standard is that everyone holds the same one, and ten separate mentoring relationships produce ten standards and a review queue nobody agrees on. One-to-one mentorship is the better buy for a different problem, which is the specific engineer who needs to get to a specific level. Those are different purchases and they're often both right.
What if we want something longer than a day?
MentorCruise runs one. It's a 90-day sprint, and it's at mentorcruise.com/teams/ai. I'm not going to describe what's in it here, or quote you a price, because this post is about how to choose and that would be me selling in the middle of an argument you're meant to be able to check. Go and read the page, and read the pricing on it rather than from me.
Does a workshop actually change how the team works, or is it training theatre?
It's theatre if nothing about your review gate changes afterwards, and that's the most common way this money gets wasted. Training decays regardless: 62% of employees apply it immediately, 34% a year later (Saks & Belcourt, 2006). What decides which side of that you land on isn't the workshop, it's whether the standard it sets gets enforced by something. Before you book anything, write down the one thing that will be different in code review the following week. If you can't, spend the money later.
