Why one shipped workflow beats a training day
The AI training day is a familiar format. A facilitator, a deck, some exercises, a lot of nodding. Everyone leaves with new vocabulary and a feeling of momentum. Three weeks later the vocabulary is intact and the work is being done exactly as it was before.
This is not a criticism of the facilitators. It is how learning works. People retain what they do, not what they hear. So we stopped running training days and started running buildcamps, where the only agenda item is that the team ships something real before the end.
The format
One to three days, on-site or remote. Your tools, your codebase, your actual work. Before the camp, we learn your stack and choose, with the team lead, a workflow that matters and fits the time: small enough to finish, real enough that finishing it changes something.
We also set up the tooling in advance, configured for your repositories and conventions, so the first morning is not spent on installation. The days are for building.
During the camp we work alongside the team. Pairing, unblocking, and teaching the habits as they come up: how to write a story an assistant can act on, how to check the assistant's work, when to trust it and when to stop it. The habits land because they are attached to the thing the team is building rather than to a slide.
By the end, something is running. Not a demo. A workflow the team uses, built by the team, with the tooling left in place.
Why the thing built matters more than the thing taught
Two reasons.
Confidence is specific. A team that has watched a demo believes AI-assisted work is possible in general. A team that has shipped a workflow believes it is possible for them, on their code, with their constraints. Only the second belief changes behaviour on Monday.
And a shipped thing keeps teaching. The workflow is there the next week. Someone extends it. Someone else notices it could apply to a second process. The tooling is configured and waiting. A training day leaves a deck. A buildcamp leaves a working example and the means to make another.
The 30-day check-in is not optional
The part of the format we would never drop is the check-in a month later. We come back, look at what the team kept using, what fell away, and what got in the way, and we help clear it.
This is where the value is decided. In the first weeks after a camp, the new habits compete with the old ones, and the old ones have years of practice behind them. Small obstacles, a permissions issue, a reviewer who does not trust assistant-written code, a story template that never got updated, are enough to tip the team back. Most of those obstacles take an hour to remove once someone looks. Without the check-in, nobody looks, and the camp becomes a fond memory.
The check-in also tells us whether the team is ready for more. Often they are, and the natural next step is a delivery process installation or a Pilot Build. Sometimes they are not, and the honest answer is a second camp on a second workflow.
Who it is for
Teams that learn by doing. Teams whose leaders want a first win rather than a roadmap. Teams that have had the training day and are wondering why nothing changed.
It is not for organizations that need a strategy first, or for teams whose delivery process is so tangled that no workflow could be shipped in three days. For those, the honest recommendation is an audit, and we say so.
One shipped workflow, the tooling left behind, the habits taught on real work, and a check-in that makes it stick. That is the whole method. It is not complicated. It is just a different thing to optimize for.