I run an engineering organization and write a meaningful share of the company’s code by line count. Every engineer there has the same tools and budget access I do.
I asked the room:
“Why are only 20% of the engineers using Claude Code on a regular basis when I analyze every commit they’ve done, and I’ve said that 75% of that could be done agentically with no loss of quality?”
Nobody was surprised. Several people recognized the pattern.
Nearly all of my engineers use AI in some form. About one in five use it at anything like the depth the work allows.
Part 1 covered what the role is and how the world arrived at six names for it. This part considers what having one of us inside an organization changes, and what it does not.
TL;DR
Use is no longer scarce. JetBrains’ August 2026 follow-up, based on more than 15,000 professional developers surveyed from May through July, found 90% using AI coding agents at work at least weekly and 68% using them daily. Those figures measure contact with agents, not how deeply agents changed the work.
BCG’s AI at Work 2026 (n=11,749 workers across 14 markets) put frontline regular use at 74%, up 23 points in a year, and declared “No more silicon ceiling.” The same report says most organizations have not converted the time saved into value and finds that strategic clarity matters more than adding tools.
Organizations have concentrated on access. A survey of 204 software-engineering practitioners by Giray, Demirörs, Kalinowski, and Mendez found 81% had direct tool access, with less emphasis on training and governance. The remaining question is practice.
Diffusion research suggests a leader-practitioner should be the mechanism that closes the gap inside a company. Rogers’ change-agent aide and Howell & Higgins’ champions both locate influence in technical credibility rather than formal authority.
My own company is the case against it. I am as hands-on as the argument requires. Use is close to universal and about one in five engineers work the way the tools now permit. Being a leader-practitioner is necessary at most, and not sufficient.
The one organization in the room where behavior demonstrably moved ran on an instrument: a spend dashboard built in nine hours, visible to everyone, with its author modeling restraint on it. Token leaderboards imposed as a KPI elsewhere produced gaming instead (CIO.com, June 5, 2026).
The Shape of the Gap
The gap moved. Regular use spread far faster than operating models changed.
JetBrains’ August 2026 follow-up, based on more than 15,000 professional developers surveyed from May through July, found 90% using AI coding agents at work at least weekly and 68% using them daily. Claude Code reached 39%, up from 18% in January, while GitHub Copilot fell from 29% to 21%. JetBrains makes developer tools and competes in this market, but it weighted the sample to better represent the global developer population.
BCG’s AI at Work 2026, published June 3 from a survey of 11,749 workers across 14 markets, found 74% of frontline employees using AI regularly, up 23 points from 2025. BCG explicitly labeled that result “No more silicon ceiling.” But the report also found that most organizations had not converted saved time into value, and that an explicit strategy improved impact even where access to tools was limited. Adoption itself moved. Access and regular use rose faster than operating models changed.
My own 20% measures depth rather than use. I run an engineering analytics tool against every commit, classifying effort against lines of code instead of just counting them. That is where the 75% in my question comes from: I read the work my team produced and concluded that roughly three-quarters of it could have been done by an agent without loss of quality.
What the Room Named as the Obstacle
Accountability stopped the serial founder cold:
“If you have a system that was designed by and configured and touched in various ways by multiple people, and then that system then causes a bad event, who do you hold accountable?”
The adoption advisor in the room had a direct answer: if he builds the harness and the adversarial review gates a system uses, he owns what that system does. He also drew a distinction on the regulatory side. The slow part is usually not the regulation itself but how it gets interpreted and which compensating controls get accepted. Once that becomes an audit question, the timeline drops from decades to something like six months to a year. The serial founder was less optimistic:
“Yeah, but the regulatory environment moves at half-lives measured in decades.”
The same founder worried that repeated human approvals would eventually become a rubber stamp. Approval fatigue is a design concern that will outlive every current tool. The adoption advisor named a governance version of it: requiring a platform team to pre-approve every skill is, in his view, one way these efforts fail.
What Permission Bought
I have provisioned accounts, removed gatekeeping, and actively encouraged the tools. I have also told my organization, on the record, that the token spend is theirs to use (within reason). Nearly everyone uses their accounts, and about one in five changed how they work.
Giray, Demirörs, Kalinowski and Mendez surveyed 204 software-engineering practitioners in a paper published December 29, 2025 and revised April 1, 2026. Direct access was reported by 81% of respondents, while training and governance received less emphasis. Access is largely solved. Internalization is the open part.
Pushing from the other end often fails as well. Duolingo tied AI usage to performance review in April 2025, took public backlash, and dropped the criterion. Luis von Ahn told Fortune on April 13, 2026, “I’m not going to force you.”
Why the Role Should Be the Mechanism
If neither permission nor mandate produces deeper practice, diffusion research has a candidate for what does.
Everett Rogers’ Diffusion of Innovations (1962; fifth edition 2003) treats “change agent” as a defined technical term rather than a synonym for a type of manager. His central finding is homophily: communication effectiveness rises with similarity in beliefs, status, and technical competence. Rogers names the failure mode directly. Change agents are usually credentialed professionals, “more technically competent than his or her clients,” which “poses problems for effective communication.” His prescribed fix is a less-credentialed change-agent aide who is “homophilous” with the adopters.
A leader who codes might bridge part of that gap: formal authority on one axis, shared technical practice on another. That is my extension, not Rogers’. His aides were intermediaries closer in status to the people adopting the new practice. Whether technical similarity can compensate for a leader’s difference in status is what we are starting to test with AI tooling.
A second line converges on it independently. Howell and Higgins’ “Champions of Technological Innovation”, published in Administrative Science Quarterly 35(2) in June 1990, ran a matched-pair study of 25 champions against non-champions. What distinguishes a champion is behavior and a wider repertoire of influence tactics, not formal authority. That study is thirty-six years old and has nothing to do with AI, which is partly why I trust it.
My Own Company Is the Case Against My Own Argument
I am as hands-on as this argument requires. By my own account in that room, I write a meaningful share of my company’s code by LOC. The infrastructure adoption worked and is not in dispute: internal services and MCP endpoints called thousands of times a day, the platform layer the entire company uses. Most meaningful knowledge is available — our full product plans, contracts, sales efforts, marketing strategy, personalized HR answers, an analyst in our domain with encyclopedic knowledge (literally — it’s RAG trained on the premier textbooks). Engineer behavior has changed, but not as much as I expected. Usage is almost universal, but not AI-first: harness/loop engineering still sits under 20%.
I described my own posture in the room like this:
“My job is really not to be popular, it’s to apply this way of thinking… The unpopularity is not the blocker. It’s bringing them along without losing them.”
That is my account of myself, which proves nothing. I could not find a clean confirming case elsewhere. Zapier’s 63% to 97% adoption progression is a self-reported internal survey with a thinly evidenced hands-on claim. NVIDIA’s public claim of universal engineer AI use shows leadership pressure, not the causal effect of a coding CEO. Shopify’s case rests on a documented top-down mandate and one account of leaders sharing their own use. No study I found isolates “leader who personally codes” as a tested variable. Being a leader-practitioner is necessary at most, and not sufficient.
What Moved Behavior
One organization in the room moved behavior demonstrably. The head of engineering at a research firm built the token dashboard described in Part 1, in nine hours, because nobody could say where the spend was going. Afterward he issued no instruction of any kind:
“So anyways, I showed you this because I didn’t ask anybody to do anything. But you see, there’s a behavioral change that happened…”
The mechanism has three moving parts. Visibility first:
“So for now, I have it so everybody can see, because I want them to be like, what is everybody else doing?”
Then peer comparison, doing the work a mandate would otherwise have to do:
“If they know a successful AI project, and they know their project, they’re like, well, I know that’s successful, mine just launched — how could I spend three times more than them if they’re the successful AI project? So then there’s a conversation that’s had.”
Then his own credibility, earned by using less than the people he was coaching. He described himself as “a token sipper. I am the most … user of tokens you’ve ever seen,” running a mid-tier model as his daily driver, and put the coaching claim plainly:
“So I am the coach. I practice what I preach.”
The teaching that followed was concrete rather than exhortative, and it was about model choice:
“If you actually use [the frontier model] to craft the prompt, and then inject that prompt into your application — yeah, you can actually use a lesser model.”
He is also carrying the ROI conversation upward without pretending the numbers exist:
“I have too many more conversations with a CFO than I want to. … everybody else will say, yeah, we’re ROIing. I say, no, we’re not. But this is like in 1999 — are you not going to register your dot-com?”
CIO.com’s “Tokenmaxxing: When AI adoption metrics go bad” (Grant Gross, June 5, 2026) documents token-usage leaderboards at Amazon, JPMorgan, Meta and Disney producing gaming rather than adoption. One Disney employee logged 460,000 Claude interactions in nine days. Trevor Stuart, SVP at Harness, said tokenmaxxing incentivizes the wrong behavior. Logan Wolfe of Kyndryl said the KPI rewards output volume over outcomes.
Both approaches made usage visible, but the external leaderboards turned it into a contest. In the room, the dashboard was paired with cost comparison and its author modeled restraint. That is one case beside four reported companies, not a controlled comparison.
I have told the team that how they solve problems with AI will be part of their review. The distinction from Duolingo and the leaderboards is what gets measured. “Use AI” turns into tokens burned or share of code written by an agent, and an input number invites gaming. Our review measures the outcome: whether the work got better and faster. AI is one route there. An engineer who clears that bar without heavy AI use has met the expectation.
The review expectation also ties to the change-agent model. In April, I did a 24-hour spike to migrate a high-performance application from Haskell to Rust. Seventy percent of that code remains in production, after two engineers built it out over the next three months. My follow-up commit analysis suggests a harness loop could have cut that buildout by roughly a third.
The Counters
Process, not a person. The adoption specialist in the room prescribes a system rather than a champion. For the middle group, the people who are neither instant enthusiasts nor holdouts, his fix is to give them a harness, skills, a supervising application, and a shared library, then run it like any other change-management rollout. Three years either way, in his estimate, but nobody has to miss a kid’s baseball game to get there. That is a serious rival theory. He is also an external advisor rather than an internal operator, which puts him in a different position relative to the same problem.
The player/coach trap, which points at me. Jim Grey’s argument (March 25, 2026) runs deeper than time management. A leader who stays in the code can cause engineers to defer technical decisions upward, hollowing out the technical-leadership bench. AI-accelerated shipping also increases the demand on leadership rather than freeing it. My answer is that Grey is describing directive hands-on leadership, while what worked in that room was the opposite: “I didn’t ask anybody to do anything.” My own practice, measured as a share of my company’s code, still looks more like Grey’s trap than the research-firm leader’s model. Outside the Rust project, however, my work has stayed off the production train: internal and DX tools, search, automated code reviews that pull in full source, our product knowledge base, and our JIRA tickets for context.
The staff+ rival. LeadDev has made the same case further down in the organization: staff and principal engineers combine technical credibility with organizational reach, and they have more in common with the adopting population than any CTO does. Applied here, Rogers’ pair would be a leader supplying authority and priority while staff engineers supply in-network credibility. If the pair is the mechanism, the leader-practitioner is not the unit of analysis.
Rogers’ own boundary condition. Homophily “accelerates diffusion… but limits the spread of an innovation to those connected in a close-knit network.” A leader who codes might influence engineers. That says nothing about finance, sales, or support.
Only two of the ten people spoke in change-agent terms at all. A ten-person room cannot settle the question, either.
Where the Role Goes Next
The coordination work that defines the hands-on band of this role is starting to move into the orchestration layer: routing work to specialists, running verification, producing status checkpoints, and detecting conflicts earlier. The June 2026 piece assigned that enabling, off-the-critical-path category to the human leader-practitioner.
Does automating that layer free the leader to build more and push the organization past 20% full adopters, or does it hollow the role out until only direction-setting and sign-off gates remain? I don’t know. It has not happened yet in my own work.
James March’s “Exploration and Exploitation in Organizational Learning”, published in Organization Science 2(1) in 1991, describes organizations trading exploitation of known practice against exploration for new practice. Applied here, a tool set that resets every few months pushes an organization back into exploration before exploitation pays. Churn alone could slow institutionalization without any leadership variable.
March explains why this is hard for everyone facing the churn. The change-agent claim tries to explain the differences between organizations facing the same churn. No speaker blamed slow adoption on fast-moving tools. The room did show how quickly a new capability could become infrastructure: the token dashboard depended on provider APIs that had not existed six months earlier, then took nine hours to build. That does not disprove March. It shows that exploration can be fast while organizational adoption remains slow.
The durability worry from Part 1 comes back here. If the labs absorb what individual practitioners build, then this room is building things that will not need to be built in eighteen months. The role’s value shifts from what these people construct to what they can judge.
By next summer, we should know whether PE demand for the role spread or was a hiring fashion. One of the six labels may have won, or hands-on work may have folded back into “engineering leader.” The share of my engineers working the way the tools permit will have moved off one in five or it will not, and I will be able to test whether visibility and peer comparison made the difference. The orchestration layer may also have eaten the enabling work I assigned to the role.
I hope to be running this same analysis next summer.
Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.
As in last year’s piece, the people in this room are identified by role rather than by name. That was the condition of the conversation, and it holds here.
Related reading:
2026: The Evolution of the Leader Practitioner (Part 1) — The room, the demos, and the six names competing for the role.
The Convergent Mind — The same gathering, one year earlier.
The Era of the Leader/Practitioner — The full case for the role.
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.
Access and adoption are very different things. I’ve seen the same pattern in non-AI transformations: give 100 people the exact same tool and you can still end up with 20 radically different levels of usage. The harder problem is usually changing habits, incentives and the definition of ‘good work’, not buying the technology.