Permission Was Never the Slow Clock.

Two weeks ago at Claud in Manhattan, David Fischer of Engineer Access opened the evening's discussion by introducing Bob Matsuoka, CTO of Duetto, as one of the rare leaders who has run large engineering organizations and still works hands-on with AI every day. Someone asked how much of his current output he could have produced before AI. His answer: zero.

Six days before that dinner, Bob had published the finding that should matter to every leader at that table: industry surveys put 90 percent of developers on AI coding agents at least weekly. In his own organization: "Nearly all of my engineers use AI in some form. About one in five use it at anything like the depth the work allows." He had done everything the playbook asks: "I have provisioned accounts, removed gatekeeping, and actively encouraged the tools." His own conclusion is the most honest sentence I have read on the subject: "Being a leader-practitioner is necessary at most, and not sufficient."

I read that from the other end of the same problem. My organization's AI roadmap took eight months to clear its review boards, and by the time it did, the models in the original case had been superseded twice. Bob owns his approvals and set that wait to zero. Adoption in his organization still sits at one in five.

The standard playbook treats adoption as a permission and enthusiasm problem. Buy the licenses, remove the gates, have leaders model the tools, and usage follows. When it does not, add training, a usage dashboard, or a mandate. Almost every technical leader has sent the rollout email, watched usage climb for two weeks, and watched it flatten.

At the table, Bob said the hard part is the mechanics: the workflow and the review process. He also said that more and more, each person will represent a shadow army of agents behind them. I pointed out that consulting has worked that way for decades. Years ago I was a consultant at Travelers in Hartford with a team in India behind me, and my velocity in that room came from a loop.

Setting their work for the next day was the last thing I did each evening: exactly what I expected, nothing left vague. They worked while I slept. We talked during our overlap, I reviewed what they had built, and I raised pull requests only for the pieces I approved. It was great to contribute that to a room of peers and have it taken into consideration.

Here is what I would add to Bob's finding. The loop has two ends. Whether the work comes from an offshore team or an agent, output quality is tied to input quality: the instructions, the context, and the experience or training behind whoever does the work. Output quality decides how fast anyone can verify it, and verification decides whether a team relies on the work at all.

Most teams were handed the tool without either end. Engineers write thin prompts with no shared context, the output comes back uneven, and checking it costs more than writing it. So they keep AI on the work that is cheap to check, which is a rational choice, and that is the eighty percent. The twenty percent built the loop for themselves, so the review load and the know-how pool in them, and they become the bottleneck.

Two clocks are running at speeds that will not match. The tools change weekly, and a team's trusted practice changes only as fast as it can verify a new way of working, which is closer to quarterly. That distance is what I call Clock Drift. Permission does not close it, because permission was never the slow clock.

Token spend shows which loop an organization has built. A token leaderboard measures volume going in and nothing about verified output coming back, and Bob cites leaderboards at large companies producing gaming rather than adoption. That is technology for its own sake. The dashboard he cites from another engineering leader worked for the opposite reason: it gave engineers a peer reference to check their own use against.

Coding is cheaper than ever. Meeting what the market actually demands has become the real expense and the real bottleneck, and the only measure that matters is the business result the work moves, whether a person wrote it or an agent did with a person reviewing it.

The leaders who close this gap do not have better tools or more enthusiastic teams. They stopped counting usage and started building the loop.

So measure adoption by verified business output. Give the whole team the loop the twenty percent built for themselves. On the input end, that means shared context, an exact expectation for each task, and reference material the agents can reach; on the review end, a named owner and a standard to check against. Aim the loop at the business result, and token spend becomes an investment you can read: spend per verified change that reached a customer. The usage chart will look slower while the business moves faster.

Pull the last ten AI-assisted changes your team shipped. For each one, write down who reviewed it and what they checked it against, and which business result it moved. Count the changes that have both. That count, not your usage number, is your real adoption rate. If the reviewer column keeps showing the same two or three names, you have found your twenty percent, and the loop you have not built yet.

The Edge Case walks through Clock Drift in full: why two systems running at incompatible speeds drift apart quietly, and how to design the interface between them instead of fighting it: http://TheEdgeCaseBook.com