What makes a hHands-on agentic AI workshop with real projects different
Most AI coding training uses a toy repo. A clean to-do app, no legacy, no flaky tests, no undocumented service boundary. The agent looks brilliant. Everyone leaves impressed. Nothing changes, because the thing that makes their real work hard was never in the room.
We do the opposite. Teams bring their own repository and a real ticket from their backlog. The agent hits their actual test suite, their actual build times, their actual half-documented internal library. It gets things wrong in the specific ways it will get things wrong next week. That is the lesson.
What the team prepares before day one
Preparation decides whether the first hour is training or IT support. Ask for this in advance:
- A repo everyone can clone and build, verified by someone the day before. Not "should work".
- Tool access already granted. Licence approvals eat entire mornings otherwise.
- Three to five real tickets, sized at roughly half a day of human work each.
- One ticket nobody wants, in a part of the codebase people avoid. This is the most valuable exercise of the day.
- A written answer to: what does done look like here, and who reviews it.
If a team cannot produce the fourth item, the agent is not their problem. Their code ownership is.
The structure that works
Short teaching blocks, then long stretches of people working with a trainer moving between screens. Roughly twenty minutes of explanation, then an hour of doing. We keep two trainers in the room for groups above eight, because the useful moments are individual and they happen simultaneously.
One exercise we always run: a deliberately underspecified prompt against a real module, then a rewrite. People see their own vague instruction produce a confident, wrong diff. Then they see a precise one, with the test command and the file boundary stated, produce something mergeable. Nobody argues about prompt quality after that.
Another: write the repo instruction file together. On a real codebase this turns into an argument about conventions that the team has been avoiding for a year. Let it run. It is worth the time.
Where this approach falls down
Real repos are unpredictable, and we say so up front. Sometimes the build breaks for reasons unrelated to anything being taught. Sometimes the chosen ticket turns out to need a decision from someone who is not in the room. We plan for that with spare tickets, but a day on a live codebase is messier than a day on a curated one.
It also does not suit a hundred person audience. Above roughly twelve people, individual attention disappears and you are running a lecture with laptops open. If the goal is broad awareness, a talk is cheaper and more honest.
What to do next
Pick the repo before you pick the trainer. Then ask any vendor a single question: will my team be working in that repo, or in yours? If the answer involves a prepared sample project, you are buying a demo.
We run these for engineering teams as full days on their own code, remote or on site. Bring the ticket nobody wants.