I have sat through a lot of "AI tools lunch-and-learn" sessions, on both sides of the room.
They are usually well run. Someone demos a coding agent, shows a few impressive examples, answers questions, and the room leaves with a decent understanding of what the tool can do.
Three months later, adoption looks almost exactly like it did before the session.
The gap between watching and doing
Watching a demo teaches you what a tool can do in someone else's hands, on someone else's codebase, on a task chosen because it demos well.
It does not teach you how to use it on your own work, with your own deadline pressure, on a task that was not picked for its demo value. That gap is where most of the value of a lunch-and-learn evaporates.
An engineer who watched a great demo and then goes back to their desk still has to figure out, alone, how to apply it to whatever they are actually working on. Most people do not do that transfer work unprompted. They go back to what they already know.
Why this keeps happening anyway
Lunch-and-learns are easy to run and easy to point to as evidence that "we did AI training." They check a box. They generate goodwill. Nobody walks out unhappy.
They are also low-risk for the organizer. A workshop has a clear start and end. A real workflow rollout requires follow-up, requires someone owning adoption past the kickoff, and requires admitting a few weeks later whether it actually worked. That is a harder thing to commit to than booking a room for an hour.
So teams default to the lower-commitment option and hope it does more than it can.
What actually builds the habit
The habit forms when an engineer uses the tool on their own real work, repeatedly, on a task type they will encounter again. That requires:
- a specific workflow, not a general capability demo. "Use Claude Code to draft your next PR description" beats "here's what Claude Code can do."
- doing it on the engineer's actual current work, not a curated example
- enough repetition that it becomes the default instead of a special occasion
- a standard for what good output looks like, so the engineer knows if they are doing it right
None of this happens in a single session. It happens over a few weeks of the workflow being the expected way to do a specific task, with someone checking whether it is actually catching on.
A better use for the lunch-and-learn
The session itself is not the problem. Used correctly, it is a reasonable kickoff: it builds shared awareness and answers the obvious questions before people start using the tool for real.
The mistake is stopping there. A useful sequence looks like:
- A short session that shows the specific workflow the team is adopting, not a general tour of features.
- Real use on real work for a few weeks, with the review standard already agreed on.
- A follow-up that checks who adopted it, who didn't, and why, then adjusts.
That third step is the one teams skip most often, and it is the one that actually determines whether the rollout worked.
What good looks like
A team that has moved past lunch-and-learns can point to a specific workflow that most of the team uses consistently, not a session everyone attended once. If your team's AI rollout consisted of a training session and nothing structured after it, that is very likely why adoption has stalled.
If you want help building the follow-through a workshop can't provide, book a call. If I'm not the right person, I'll say so.