Over the past three weeks, I ran four AI sessions with client teams. In those rooms, the laptops had GitHub Copilot, Claude Code, and Codex open. Not one of the questions worth answering was about any of those three products.
The questions were: how much of this should I trust? How do I know when it’s wrong? What does it need to see before it can help me? Who owns the code that ends up in the pull request?
None of those have a vendor-specific answer. Which is exactly why I stopped building tool training and started building concept training.
The tool your team learns today is not the tool they’ll use next year
I don’t think anyone in this field seriously expects stability. Copilot’s pricing model changed underneath everyone who had budgeted for it. The frontier models get replaced every few months, and the replacement behaves differently enough that habits have to be relearned. Agentic command-line tooling went from curiosity to default in about a year. The interface itself moved from tab-completion to chat to an agent that edits twelve files while you watch.
A team trained on a product has to be retrained every time one of those things shifts, and the retraining happens on the vendor’s schedule, not yours. A team that understands why the tooling behaves the way it does adapts on its own, usually in an afternoon.
Most corporate AI enablement I see is a license rollout with a lunch-and-learn stapled to the end. Someone demonstrates the autocomplete, everyone nods, adoption sits at eleven percent three months later, and the conclusion drawn is that the team wasn’t ready. The team was fine. They were shown which buttons exist, not how the thing thinks.
What I actually teach
Five ideas, roughly, and I teach them in whatever tool the client already has in front of them.
Context is the whole game. The model answers using what you have shown it and nothing else. Once a developer can picture the context window, what’s in it, what silently fell out of it, and why a long session degrades, most of their frustration becomes tractable. This one concept resolves more complaints than any feature I could demonstrate.
The model has read code like yours. It has not read your code. That’s why it confidently produces plausible code matching nobody’s conventions. It also explains why the effort you put into making your conventions explicit pays back immediately, which is the bridge into the whole codebase onboarding conversation.
Your job moves from writing to reading. Generation stops being the constraint almost instantly. Review becomes the constraint. A developer who generates quickly and reviews slowly has moved their bottleneck, not removed it.
Scope work into units you can genuinely review. If you can’t read the diff properly, you can’t own it. So keep the diff small enough to read. This sounds obvious, and it’s the single discipline I see teams abandon first.
Responsibility doesn’t transfer. Whoever opens the pull request owns what’s in it, regardless of who or what typed it. I say this in every session because it separates teams that use AI well from teams that quietly accumulate code nobody understands.
Five ideas, no vendor names, all of them still true after the next model release.
The roundtable paid off more than the demo
The last of the four sessions was a team-building workshop. I planned a round-table discussion on how LLMs actually work, followed by a walkthrough of what the tooling can do in a real application. I expected the second half to be the part people took home.
It was the round table.
Once developers understand next-token prediction, tokenization, why a context window has a hard edge, and what temperature is doing, “the AI is being stupid today” turns into something diagnosable. Bad output stops being a mood and becomes a symptom with a cause: not enough context, an ambiguous instruction, or a question the model can’t answer from patterns at all. That’s a debugging loop, and developers are already excellent at debugging loops.
Developers who understand the machine steer it. Developers who treat it as a black box swing between over-trusting it and dismissing it, sometimes within the same afternoon. The gap between those two groups isn’t product experience. It’s a mental model.
Why teams are asking for this now
The people I met over these three weeks weren’t skeptics. They were curious, capable developers who wanted to work this way properly and had no intention of diving in head first.
Most of them had watched someone on their team merge something they didn’t fully understand. That’s hard to forget. It leaves you wanting a guided path rather than an experiment on your own production system, and it leaves you wanting the path from someone who already made the expensive mistakes.
I’ve been working this way for close to three years. Very little of what I teach is clever technique. Most of it is the accumulated cost of finding the edges, which is worth more to a team than another feature tour.
That caution deserves respect, not enthusiasm. A developer who has maintained a system for eight years has good reason to be careful about a tool that produces code faster than they can read it. The answer isn’t to talk them out of the caution. It’s to give them the concepts that make the caution actionable instead of paralyzing.
A test you can run on your own material
Open whatever AI onboarding material your team has. Imagine you switch vendors next quarter.
If most of it would need rewriting, you wrote product documentation. That has its uses, but it isn’t training, and it expires on someone else’s timeline.
The parts that survive the vendor change are the parts that were worth teaching in the first place. Start there, and the tool becomes a detail your team can swap out without a retraining budget.
