Your team has coding agents now. Some engineers ship twice as fast with them. Others tried once, got a bad diff, and went back to doing it by hand. Most teams treat that split as a tooling problem and go shopping for a better model.
In my experience, it’s rarely the tool.
I’m not an Android developer, and I won’t pretend to be. I spent two decades in tech, including time as an automation testing engineer building acceptance tests into server manufacturing equipment, and I now work in cloud infrastructure program management for a global AI infrastructure supply chain organization. Over the past year I trained more than 200 program managers to hand parts of their governance work to AI tools and agents. The people, the skeptics, the early adopters and the quiet drop-offs looked a lot like what Android leads are describing with coding agents right now.
This session is about the human side of agent adoption: who picks it up and who doesn’t, why “everyone has access” isn’t adoption, and how to tell whether agents are changing how your team works or just getting opened. I’ll share what worked in my rollout, what failed, and a simple four-level way to measure adoption, adapted from the Kirkpatrick Model of training evaluation.

Key Takeaways
1. Access isn’t adoption. Why license counts and login data say almost nothing about whether agents are changing your team’s work, and what to track instead.
2. The four levels of agent adoption: reaction, capability, behavior change and results, and the questions to ask at each level.
3. Delegation is a skill, not a setting. How to teach people when to hand work to an agent, how to check what comes back, and when to take the keyboard back.
4. Spotting the quiet drop-off. The early signs someone has given up on an agent, and how to bring them back without a mandate.
5. Leveling up in an agent-heavy team. How individuals can become the person who makes agents work for everyone else, which is quickly becoming a career advantage.