An AI workshop for technical staff should not open with what a language model is. Your engineers have been using these tools daily for two years. The three hours worth paying for teach something narrower: when not to reach for the tool, how to check what it produced, and how to feed it context from your own system.
That is a smaller purchase than the one most vendors quote. The published engineering syllabus (model basics, prompt engineering, retrieval, agents, fine-tuning) sits free on Microsoft Learn and DeepLearning.AI, and this room reads documentation for a living. Reselling it to them in a conference room at per-seat prices is the most common way an AI enablement budget gets wasted on a technical team.
What is missing is harder to buy, and nobody is selling it, because selling it means admitting the tools sometimes cost time.
What your engineers already have
Start with the adoption numbers, because they rule out most of the curriculum you will be quoted.
DORA’s 2025 State of AI-assisted Software Development report, built on close to 5,000 technology professionals, found 90% using AI at work and over 80% saying it raised their output. Stack Overflow’s 2025 Developer Survey, with more than 49,000 respondents in 177 countries, put 84% using or planning to use AI tools, up from 76% a year earlier, and 51% of professional developers using them every day.
Now look at trust, which is where the gap lives. Stack Overflow found 33% trust the accuracy of what comes back, 46% distrust it, and 3.1% trust it highly. The top frustration, at 66%, was “AI solutions that are almost right, but not quite”, and 45.2% said debugging generated code took longer than they expected. DORA put 30% at little or no trust in AI-generated code.
So the room is fluent and unconvinced. They are not short on access or vocabulary. They are short on a way to tell, in the moment, whether this task is one the tool will help with, and a habit for checking the parts of the output that fail quietly.
The split that should write your curriculum
Two published trials point in opposite directions, and the distance between them is the lesson.
METR ran a randomized trial in July 2025 with 16 experienced open-source developers across 246 real issues in large repositories they knew well. They forecast a 24% speedup. They came out 19% slower when allowed AI tools, and still believed afterward that they had been 20% faster. The caveats are the authors’ own: this was a snapshot of the coding assistants available in early 2025, the sample is small, and METR states plainly that it does not claim to cover most software work and that the result is out of date.
Set that against the result everyone quotes. Peng and colleagues at Microsoft Research, GitHub and MIT Sloan ran a controlled experiment in which recruited developers built an HTTP server in JavaScript as fast as they could. The group with an assistant finished 55.8% faster, and the gains skewed toward the less experienced.
Both are real and they do not conflict. One measured a bounded greenfield task. The other measured senior people making careful changes inside systems they already hold in their heads.
| Task shape | Likely effect | Why |
|---|---|---|
| New, self-contained, conventional stack | Large gain | Thousands of near-identical examples, almost no context to transfer |
| Test scaffolding, fixtures, data shaping, throwaway scripts | Large gain | Cheap to check, and wrong output shows up at once |
| Unfamiliar language, framework, or inherited service | Real gain | Explaining and orienting is what these tools do best |
| Careful change in a big system the engineer knows well | Often negative | Prompting, reading and repairing costs more than writing |
| Work where the hard part is deciding what to build | None | The limit is judgment, not typing |
Teaching someone to apply that table to their own repository, on their own tickets, is a skill. It is the highest-value hour in a technical session, and it appears on no vendor syllabus we have seen, because it argues for using the tool less often.
The three hours nobody sells
We run these sessions, so this part is observation rather than theory.
Hour one: calibration on their own backlog. Each engineer brings three tickets they will work this sprint and sorts them against the categories above before touching any of them. Then they run two: one they expected to go well, one they expected to go badly. The point is not speed. It is the instinct to notice, 10 minutes in, that a task is going sideways and to stop. The METR result exists because competent people kept going.
Hour two: checking, taught inside the task. Veracode’s 2025 GenAI Code Security Report ran 80 curated tasks across more than 100 models. Where there was a secure and an insecure way to write something, the models picked the insecure one 45% of the time. Java came out worst at a 72% failure rate, and cross-site scripting went undefended in 86% of the samples where it applied. The useful version of that is not a slide. It is each engineer running their own tests, linter and scanner against something the model just wrote, and seeing what review caught that reading did not. The same hour covers what never goes into a prompt: customer records, credentials, anything a contract forbids.
Hour three: supplying context. Most disappointing output is a context problem wearing a prompt problem’s clothes. This hour goes on plumbing: repository instruction files, a short house style for generated code, which internal documents a tool can see, the three sentences of domain background that belong in every prompt because they are nowhere in the training data. DORA’s finding that AI amplifies whatever a team already has, and that internal platform quality tracks directly with getting value out of AI, is mostly about this.
Then stop. A fourth hour of new material is worth less than a 90-minute clinic three weeks later, where the real questions appear: the prompt that worked twice and failed the third time, the generated test that asserted the wrong thing and passed anyway. Book the clinic before the first session runs, because it never gets booked afterward. The design mechanics behind both appointments are their own craft.
The half of an engineering week that is not code
Here is the part every technical quote skips, and it is usually where your existing licenses sit idle.
Engineers write specs, tickets, design docs, review comments, incident write-ups, migration plans, release notes, and replies to account managers who want a date. For many senior engineers that is more than half the week. They hold a general assistant license, bought in the same rollout as everyone else’s, and they rarely use it for any of it, partly because the coding tool in the editor feels like the AI tool, partly because nobody showed them the second one on their own documents.
This is plain LLM fluency training, the same work we do with a finance or operations group, pointed at engineering artifacts. A two-page incident write-up drafted from a transcript and a timeline, then checked line by line against the log, is a 20-minute job this way and a Friday afternoon the other way. Turning a rambling stakeholder thread into a ticket with real acceptance criteria is the same move. None of it is technically hard, which is why no engineering vendor sells it, and the exercises end up looking much like the formats that work for non-technical teams.
Hold that next to another Stack Overflow number: 75.3% of developers would still take a question to a human when they do not trust the answer. Fluency here is not about replacing the colleague. It is about arriving at the colleague with a draft.
What the catalog sells a technical team
Published prices, checked this month, for what a buyer meets first.
| Option | Published format | Published price |
|---|---|---|
| Microsoft Learn GitHub Copilot Fundamentals | Self-paced, 9 modules, product-scoped | Free |
| DeepLearning.AI short courses | 1 to 3 hours each, notebooks included, practitioner-taught | Free course access during the platform beta; graded work and certificates need the paid membership |
| Certstaffix live online titles | Half-day and one-day classes, general business audience | $350 per person per title; self-paced bundles $150 to $375 |
| Private facilitated session | Half or full day, your repositories and your backlog | Not published by any vendor on page one; market rates run about $2,000 to $15,000 |
Two things follow. The free tier is good and your engineers can self-serve the syllabus, so any paid session has to earn its fee on correction and context rather than content. And no vendor publishes a group rate, so the comparison you most need is the one the websites refuse to give. Reading a quote against that gap has its own method, covered in how to read a workshop proposal.
There is also a purchase to decline. If you want engineers who can ship a retrieval system, an evaluation harness or a tuned model into production, a facilitated fluency session is the wrong instrument, and so is a five-day catalog course at a few thousand dollars a seat. That is a build project with specialist courses attached and code review from someone who has done it. Fluency and production ML engineering are different products, and a vendor selling you one as the other is the first thing to screen for. Market rates for that automation work run roughly $25,000 to $150,000, which is a different budget line.
Room composition decides the outcome
Do not put your engineers in the all-staff session, and do not put the whole engineering group in one room either.
The evidence on who gains is consistent. Peng found the larger speedups among less experienced developers. The pattern repeats outside software: Brynjolfsson, Li and Raymond, studying 5,172 customer support agents, found a 15% average rise in resolutions per hour, concentrated among less experienced staff, while the most experienced saw small speed gains and small quality declines.
A junior engineer needs scaffolding, review discipline, and a hard rule about never shipping code they cannot explain. A senior engineer needs calibration, the review standard the juniors will be held to, and a say in the house instructions the team inherits. Run them apart, or run one room where the seniors are there to set rules rather than learn the tool.
Two mechanics decide the rest. Cap the room near 15 per facilitator, because what you are buying is individual correction and past that nobody gets any. And build every exercise on their repositories, tickets and documents rather than sample material, which is the information-gain case for custom curriculum at its most literal: a generic exercise teaches a generic lesson.
Measure rework and stability, not acceptance
Suggestion acceptance rate is the metric your tooling hands you and it means close to nothing. Accepting more generated code is not the goal, and the METR developers accepted plenty while losing time.
Measure four things for the trained group, before and three months after:
- Rework. Share of merged changes reverted or patched within a short window. This is where “almost right, but not quite” turns into cost.
- Change failure rate and time to restore. DORA found AI adoption related positively to throughput and product performance, and negatively to delivery stability. More code arriving faster through the same review and release process is a known failure mode, so watch stability directly.
- Review load. Time from pull request to first substantive comment, and reviewer hours per merged change. Training that shifts work onto two senior reviewers has not made the team faster.
- One named non-code task. Hours to produce the incident write-up or the spec draft. The easiest real gain to show a CFO, and the one nobody measures.
Set the baseline before the session. BCG’s AI at Work 2026 survey of close to 12,000 workers found 36% feel adequately upskilled and 66% get limited or no guidance on what to do with the time AI saves them, which is how a genuine gain vanishes before it reaches any number you report. Saying out loud what the recovered hours are for is a 10-minute agenda item, and the difference between training and enablement that shows up in the business.
Five questions for a vendor pitching a technical session
- Will the exercises run in our repositories, on our open tickets? A vendor who has not asked for access, or a redacted sample, has one curriculum for everyone.
- What will you teach us not to use this for? A credible answer names task types where the tool costs time. Anyone claiming it helps everywhere has not worked in a large codebase.
- Who is teaching, and what did they ship last month? Engineers audit a facilitator inside 10 minutes, and practitioners and professional trainers transfer different things. This room needs the former.
- How much of the time is hands-on, and what is the cap per facilitator? Under two thirds practice and you have bought a presentation at session prices.
- What is included after the day, and what does it cost? No second appointment in the quote means you are buying attendance.
Frequently asked questions
What should an AI workshop for technical staff cover?
Three things a general session skips: calibration, meaning which tasks the tools help with and which they slow down, practiced on the team’s own backlog; checking, meaning their own tests, linters and scanners run against generated output, plus rules on what data never goes into a prompt; and context, meaning repository instruction files, house style for generated code, and the domain background a model cannot know. Model basics and prompt technique are free and already read.
Do engineers need AI training if they already use these tools daily?
Yes, but not an introduction. DORA found 90% of technology professionals using AI at work while 30% report little or no trust in generated code, and Stack Overflow found 46% distrust its accuracy. Daily use without a checking habit or a sense of when to stop is the expensive state, not the trained one.
How is a technical AI workshop different from a general one?
The audience arrives fluent, so the hours go into judgment rather than capability demos. Exercises run on real repositories and tickets instead of sample documents, the facilitator has to be a practitioner the room respects, and a good share of the value sits in non-code work: specs, tickets, incident write-ups, review comments.
How long should it be?
Three to three and a half hours of hands-on work, plus a 90-minute clinic two to three weeks later. BCG’s 2025 AI at Work survey found regular use much higher among people with at least five hours of training plus in-person sessions and coaching, which that shape delivers. A full day of new material for this audience mostly buys reading.
Should engineers train in the same session as everyone else?
No. A mixed room makes every example wrong for most people in it. Split engineering out, and consider splitting juniors from seniors too: published evidence puts the larger gains among less experienced staff, while seniors mainly need calibration and a review standard they help write.
How much does an AI workshop for an engineering team cost?
Per-seat catalog classes publish $350 a person for a live day, with self-paced bundles at $150 to $375 and strong free material on Microsoft Learn and DeepLearning.AI. Private sessions are not published by anyone; market rates run about $2,000 to $15,000 depending on how many groups need their own material and whether follow-up is included.
Can this teach our engineers to build production AI systems?
No, and a vendor who says otherwise is selling the wrong thing. Fluency training makes a team effective with assistants on their existing work. Shipping a retrieval system or an evaluation harness is a build project with specialist courses and code review attached, and market rates for that work start around $25,000.
What should we measure afterward?
Rework rate on merged changes, change failure rate and time to restore, review load per merged change, and hours on one named non-code task such as the incident write-up. Skip suggestion acceptance rate. DORA’s negative relationship between AI adoption and delivery stability is the specific risk to watch while throughput rises.
Our engineers resist training. How do we get them to turn up?
Give them a session that respects what they know. Ask for their open tickets in advance, let a senior engineer help set the agenda, and open with the calibration exercise rather than a tool tour. Resistance here is usually accurate pattern-matching from the last vendor session, not reluctance to learn.
Key takeaways
- Buy calibration, checking and context, not an introduction. With 90% of technology professionals already using AI at work, the syllabus you will be quoted is the part they can read free.
- The METR and Peng results differ because they measured different work: 19% slower for experienced developers on real issues in large repos they knew, 55.8% faster on a bounded greenfield task. Teaching people to tell those apart in their own backlog is the best hour in the room.
- Teach checking inside the exercise. Veracode found models choosing the insecure option in 45% of relevant tasks, and 72% in Java. That is a habit problem, not a policy slide.
- Half an engineering week is specs, tickets and write-ups. That is where the general assistant license goes unused and where the fastest honest gain sits.
- Measure rework, change failure rate, review load, and one named non-code task. Acceptance rate measures nothing, and DORA’s negative stability relationship is the risk to watch.
Pick the two sprints coming up, pull five tickets you would bet on and five you would not, and you have the first hour of the session. A free AI-readiness call will tell you whether your engineering team needs a session at all, and where the budget should go instead if not.
Dirk Jan van Veen, PhD
