We move engineering teams up the AI ladder.

No. The full-loop engineer compresses handoffs, doesn't eliminate roles. Your PM still owns the roadmap. Your designer still owns the system. Your QA still owns the harness. The engineer ships the first version of a feature without five handoffs to get there.

No. The workshop is tuned after a discovery call. Most teams that already use AI are at the surface 10% of what these tools can do.

That's the actual workshop. Most engineers top out at L3 because letting go is hard. We teach the diff-level review discipline that gets past it.

A 10-engineer team on Claude Code Max runs $1,500 to $3,000 a month at standard usage. We set up token observability on Day 1 so the bill never surprises you, and teach context economy so it goes down over time.

Both. We come to you for the 3-day intensive on-site (recommended), or run it fully remote. The 30-day practice tail is async with one or two sync calls.

It is the opposite, and the study everyone quotes for the worry is the same one that says so. Anthropic published How AI assistance impacts the formation of coding skills on 29 January 2026: 52 mostly junior engineers, all writing Python weekly for over a year, none of them familiar with Trio, split at random between working with an AI assistant that could produce correct code on demand and working without one. Afterwards both groups sat the same comprehension quiz with no AI available. The unassisted group averaged 67%, the assisted group 50%, and the steepest drop was in debugging, which the authors attribute to the assisted group simply never hitting the errors that teach it. That is the headline, and on its own it reads as an argument for using the tools less. The rest of the paper says otherwise. The interesting spread was inside the assisted group, not between the groups: six distinct interaction patterns were identified, three of which scored under 40% while three scored between 65% and 86%, at or above the people who had no assistant at all. The engineers in that upper band used the assistant to build understanding while it produced code, asking follow-up questions, requesting the reasoning behind an implementation, sending hybrid requests that come back with both. They were not the fastest in the session and they were the ones who still knew the material at the end of it. Same tool, same task, opposite outcome, decided by how the person worked with it. That is a habit, and habits are what a workshop installs. So it is a direct part of what we teach: what to delegate and what to read, how to ask for the reasoning rather than only the result, how to review a diff you did not type, and how to keep the debugging reps that build the judgment everything else depends on. It is the same discipline the ladder is built on, and the reason we teach letting go of writing every line alongside knowing exactly what you are approving.

No. It runs on your engineers at whatever level they are, on your own codebase, and the mix in the room is usually the point rather than a compromise: a senior who can already direct an agent well is where the rest of the team learns fastest, and the questions that surface in that room are the ones your review culture was going to hit anyway. Two things worth being straight about. The 2026 research on skill formation was run on mostly junior engineers learning an unfamiliar library, so we quote it for what it measured and do not stretch it into a claim about your principal engineers. And separately, we do not place juniors as engineers at all: our embedded engineers are mid-senior to senior, three years minimum and typically five or more. Training is a different service with a different shape. It upgrades your people rather than adding ours.

Partly, and the honest answer starts with the part that argues against selling you one. Article 4 of the AI Act has applied since 2 February 2025, it attaches to providers and deployers regardless of the risk tier of the system, and for most companies reading this the role is deployer, because you use AI systems rather than place them on the market. Then it got softer rather than harder. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was voted by Parliament on 16 June 2026, signed on 8 July, published in the Official Journal on 24 July and entered into force on 27 July 2026, and it rewrote Article 4 from a duty to ensure a level of AI literacy into a duty to take measures to support the development of one. That is a move from an outcome standard to an obligation of means: you take measures, you shape them to your own systems and people, and you are able to show that you did. National market surveillance authorities began supervising Article 4 from 2 August 2026. So the deadline urgency you will hear from vendors this quarter is mostly wrong, and we are not going to use it. The second thing worth knowing before you buy anything is what the Commission has already ruled out. Its AI literacy questions and answers, first published in May 2025 and maintained as a living document, says there is no need for a certificate and that organisations can keep an internal record of trainings and other guiding initiatives. No mandated curriculum, no fixed number of hours, no approved course that satisfies the obligation by being completed. Which puts the product the market is rushing to sell, a generic e-learning module ending in a completion certificate, in an awkward position: it is simultaneously the thing explicitly not required and the thing least likely to read as context-appropriate, because it has nothing to do with your systems or with anybody's actual job. What the standard does reward is role-specific and close to the work. Broad fundamentals and responsible use for a general workforce, and deeper technical, risk and governance depth for the people building, buying or overseeing AI systems. That second group is the one we are good at and usually the one where the gap is. Our workshop runs on your codebase, with the tools your engineers already have open, for named roles, and the room ships something real. The record of it is a by-product rather than a deliverable: who was there, what was covered, what they built, what standards they were taught to hold. That is the same evidence chain the factory already produces for an ISO 42001, NIST AI RMF or SOC 2 review, rather than a second parallel pile of paperwork. Where we stop. A workshop is one measure, and Article 4 reaches everyone operating or using AI on your behalf, which in most companies is a lot of people outside engineering we do not cover by default. Attendance is not literacy either: a register is a record that a measure happened, not evidence that anyone understood anything, so the thing worth looking at is what people do differently in their next pull request. And the boundaries are firm. We are not your counsel, we do not give legal advice, we do not determine whether the Act reaches your company or in which role, and we do not certify anyone or issue conformance statements. We teach, and we describe the mechanism. Your lawyer draws the conclusions.

Built on it, not around it, and the last six months are the whole argument. JetBrains ran its Developer Ecosystem Survey across more than 15,000 professional developers between May and July 2026 and published the agent findings in August 2026. Coding agents are used at least weekly by 90% of them and daily by 68%, so whether to adopt is a settled question. Which one is not. Claude Code went from 18% work adoption in January 2026 to roughly 39%, and is the single most-used tool for 31% of developers. Cursor moved the other way over the same window, 18% down to 12%. GitHub Copilot led in January and does not now. Nobody standardizing in January predicted that, and nobody standardizing this quarter should bet a training budget on the next two. So the part worth teaching is the part that survives a migration. What belongs in a context file and what does not. How to scope a task so an agent can finish it and a human can review it. How to read a diff you did not write, at the level where you catch the wrong thing rather than the ugly thing. When to stop a run instead of correcting it. Where a guard belongs so a mistake is caught by CI rather than by a colleague. Those transfer between engines because they are properties of your codebase and your review culture, and neither of those gets retired in a release note. A workshop held in the abstract teaches nothing, so we run on whatever you actually have installed, on your own repository, and what the room produces, the context files, the skills, the guards, is yours and is not written in anyone’s proprietary format. Switch engines next year and the method holds while the files move. Had we built the day around one vendor’s keyboard shortcuts, you would be buying it again. One honest limit. Tool-specific depth is real and we do teach it, because the gap between a team at the surface of a tool and a team using it properly is large. We put it after the method rather than instead of it, and we tell you on the day which parts have a shelf life.

Artifacts committed to your repository and one named owner, and it is worth being blunt about why, because the alternative has been measured. DX’s research across more than 400 companies puts the median gain in pull request throughput from AI coding tools at 7.76%, with a mean of 13.1% and most organizations landing between 5% and 15%. That is a real gain and it is nowhere near the one in the pitch, and the distance between them is almost entirely about whether anything structural changed or whether a group of people simply had a good day. The same research puts the hidden annual cost of a rollout, meaning codebase indexing, compliance work and enablement, at 50,000 to 250,000 dollars, which is to say the training line is already in your budget whether or not anybody planned it. There is also a measurement trap here, and it is why we do not send a satisfaction survey after a session. METR’s randomized trial, published 10 July 2025, had 16 experienced open source developers work 246 real issues in their own repositories. They were roughly 19% slower with AI, and afterwards estimated they had been roughly 20% faster. A post-workshop happiness score measures exactly the instinct that produced that thirty-nine point error. If the only evidence a workshop worked is that people enjoyed it and feel quicker, you have bought a good day and called it a capability. So the design is the opposite of an event. A session ends with things committed rather than slides handed out: the context file for the repository the team actually works in, one or two skills that encode a review comment that team keeps repeating, and at least one guard in their own CI that fails a run for a reason the room agreed on. Those survive the month because nothing about them depends on anyone remembering the session. Then one person owns them by name, with time allocated to maintain them, because a context file nobody owns rots inside a quarter and is then worse than having none: it is confidently wrong and the agent reads it anyway. The follow-up is a review of real merged pull requests from the weeks afterwards, not a refresher. Two places this argues against us. If nobody is going to be given that ownership, buy the shorter session, keep the artifacts and skip the follow-up, because otherwise we are billing you for a habit the organization has not agreed to hold. And if what you actually need is for a whole department to start merging rather than for one team to get better, a workshop is the right instrument at the wrong scale. That is a factory install, and we would rather say so than sell you four sessions that cannot reach it.