Half a year after the big Copilot rollout, I sat in a retrospective where a senior developer admitted he had never once opened the tool. Two seats over, a junior confessed she shipped its output without reading it. Same team, same tool, two opposite problems. The adoption dashboard only flagged the first one.
These are the two ways AI adoption goes wrong, and they always show up together. Some people trust the tool too much: once something usually works, we stop checking it. Psychologists call this automation bias. Others trust it too little: they quietly avoid the tool because being good at their craft is part of who they are, and the tool threatens exactly that.
Neither problem is solved with training or usage targets, because neither is an individual failing. The organization's design produces both. If code reviews wave through anything that passes the tests, you are teaching people to stop checking. If the career ladder still rewards the amount of code someone writes, you are teaching them to avoid the tool that writes it for them. The real goal is calibrated trust: a team that knows when to lean on AI and when to doubt it. I'll show what that requires from role design, review practices, and the way we grow junior developers.
We'll do one exercise together: you'll see a set of real code-review comments and judge, in pairs, whether the reviewer was genuinely checking the work or just waving it through. It's harder than it sounds.