What a manager actually needs from this
Most AI coding workshops for non-technical managers are pitched as a gentle introduction to programming. That is the wrong product. You do not need to write a for loop. You need to answer questions your board is already asking: is the team faster, is the code still safe to ship, and what happened to code review.
Those are operational questions. They have concrete answers, and the answers are visible in your existing tooling if you know where to look.
The metrics that mislead
Line count goes up when a team adopts agents. It always does. Managers see the graph, declare a productivity win, and miss what is happening underneath. We have sat with teams whose throughput chart looked excellent while their pull requests grew from 80 lines to 900 and review became rubber-stamping.
Things worth watching instead:
- Median pull request size. If it triples, review quality has already collapsed, whatever the review-time metric says.
- Time from PR open to first substantive comment. Not approval. Comment.
- Revert and hotfix rate over a rolling month, compared against the same window before adoption.
- Whether the author of a change can explain it in a design discussion. This one is qualitative and it is the most predictive.
A single question in your next one-on-one does more than a dashboard: walk me through why this change is correct. Ask it about an agent-written PR. The answer tells you everything.
What good AI coding workshops for non-technical managers include
You should see the tools run live, on a real repository, with the failures left in. If the demo never breaks, it was rehearsed and you learned nothing. You should leave with a policy draft: what your team is allowed to delegate, what needs a human author, and what the review standard is now.
You should also leave able to spot a specific failure mode. Agents are confident when they are wrong. A change that looks complete and passes tests can still have quietly dropped an edge case the tests never covered. Managers who have seen this happen once ask much better questions afterwards.
Being honest about the limits
A half-day session will not make you technical. You will not be able to review code yourself, and you should not try. What you get is the vocabulary to run the conversation and the judgement to know when your engineers are giving you a real answer.
If your engineering team has not adopted agents yet, a manager workshop is premature. Train the engineers first. Then come back for the operating model.
Do this next
Before you book anything, pull the last twenty merged pull requests in your main service and look at two numbers: size and time to first comment. Compare against six months ago. Bring that comparison to any vendor you talk to. A workshop that cannot engage with your actual numbers is a lecture, not training.