AI adoption is table stakes, but leverage is the differentiator
Angie Jones (Agentic AI Foundation), Balaji Srinivasan (LinkedIn), and Rebecca Murphey (Honeycomb) on what differentiates the teams pulling ahead
Almost every engineering org has AI switched on. Far fewer have the productivity gains to show for it. That distance is the real story of 2026, and it’s widening.
In LinearB’s refreshed engineering benchmarks, high AI usage correlates with a 1.7 to 2.2x lift in PR merge rate. A typical mixed team should expect closer to 1.5x. Light or no AI usage shows no distinguishable lift. The teams that got the lift are pulling away from the teams that turned AI on and stopped, and the ones left behind cannot see the gap opening because the number they watch is adoption.
Adoption is the wrong metric, and the leaders closing the gap have already stopped watching it. They do two things instead:
Measure where AI creates leverage, and
Replicate best practices across the organization.
See what your adoption number is hiding
“The adoption number helped us establish that access wasn’t the main problem,” says Angie Jones, VP of DevEx at the Agentic AI Foundation, when reflecting on her work at Block.
“Around 95% of our engineers were already using AI regularly, so we could stop spending all our energy trying to convince people to try it. But what that number hid was the huge difference in how they were using it. One engineer might use AI to generate a snippet. Another might run several agents, create reusable workflows, and assign complete tickets to them. Both count as adopted, but they’re getting very different results.”
Balaji Srinivasan, who leads quality, automation, and developer enablement as Senior Director of Engineering at LinkedIn, draws the same distinction. LinkedIn tracks adoption as the use of AI development tools on days people are coding, and by that measure it has seen more than 80% adoption across its R&D teams. A strong signal, and not the answer.
“Adoption has many layers to it,” Balaji says. “The depth and effectiveness of the adoption is something we are constantly evaluating.” His teams put their energy into making their harnesses work with LinkedIn’s internal systems and knowledge, and the payoff shows up in what he calls “the velocity of quality development,” a gain the adoption number never captures.
For Angie the number hides how differently people use the same tools. For Balaji it’s a floor, the point where the real work starts. The refreshed benchmarks show why that variance matters. Even in elite orgs, only 13% of developers use AI on at least 75% of their coding days. So if adoption doesn’t give you leverage, then what does?
How to spot the engineers who turn AI into leverage
Comparing your strongest AI-leveraged engineer to an enthusiastic adopter starts to paint this picture. After all, they’ve both cleared the hurdle of adoption. The difference between them is actually observable, and a leader can spot it.
For example, the enthusiast uses AI often, Angie says, “but mostly task by task. They generate code, ask questions, and move on once the immediate problem is solved.” The engineer works one level up: “They improve the workflow around those tasks. They add context to the repo, create reusable skills, and break larger work into tasks agents can complete. When the agent fails, they figure out why and adjust the instructions, tooling, or codebase so the same failure is less likely next time.”
It’s observable because “other engineers begin benefitting from what that person created.”
Balaji draws the same line by scope. The enthusiast has real curiosity and energy but a narrow focus, centered on what the tools do for the task in hand. The leveraged engineer “will use AI for all aspects of development, including specifications, design, implementation, operations, and maintenance.” That breadth turns into a kind of leadership. It frees up time to channel toward ambitious work and lets the engineer “proactively drive forward new projects with business potential or team benefit.”
Rebecca Murphey, Principal AI Operations Lead at Honeycomb, adds a caution worth holding. The most AI-leveraged engineers tend to generate a lot of code, and she’s “not clear that’s the best way for them to be spending their time.” At Honeycomb the move is to pull those engineers left, into the design conversations that used to happen on the PR, “not least so they don’t overwhelm teammates with their solo contributions.” Raw volume is a false tell. The real signal is whether the strong engineer lifts the people around them.
Leverage doesn’t always show up as raw speed, and the obvious metrics can point the wrong way. AI-assisted PRs run about 2.6x larger than unassisted ones at P75, per LinearB’s 2026 Software Engineering Benchmarks Report, so reviews feel slower even when the team is getting more done. The leverage lives upstream of the PR size, in the reusable skills, the context, and the workflow the strong engineer built. You see it in whose work makes other people faster.
Fix the ownership bottleneck stalling your agent PRs
More AI code hasn’t meant more delivered code. Agentic PRs move through the pipeline poorly, and the pattern points at ownership rather than at the tooling. When an agent opens a PR that no one owns, it tends to stall, because a developer weighs whether it matters to them and whether they get credit for shepherding it home.
Angie’s fix moves past the reflex of forcing a human owner onto every PR. “Assigning every agent PR to a human doesn’t scale. Agents produce code faster than people can review it, so we’ve just created a bigger review queue,” she says.
“We need to stop treating human review as the only way to establish confidence. Let automated checks catch the obvious problems. Let review agents challenge the coding agent and send fixes back before a person ever sees the PR. Bring humans in when the change is risky, the intent is unclear, or the system isn’t confident.”
Ownership still lands on a person: “A person or team should still own the outcome, and their name should be on the PR. But the record should also show what the agent did, what reviewed it, and why the change was allowed to move forward.”
Balaji splits LinkedIn’s PRs by type:
Large-scale maintenance work, refactors and dependency updates, runs largely automated, and some delay in merging is fine to him, because overall merge rates are still rising.
Human-initiated, AI-assisted PRs are the ones he carries through, since “the name on each PR and its accountability still lies with the human who initiated it.”
He also names the same wall as Angie. “Time to merge has also gone up due to the increase in the number of PRs,” Balaji says, “which hints at the need for balancing the speed of generating new code through agents and human code reviewing capacity.” This matches up with our latest benchmarks update, as well.
Put the two together and the bottleneck is unmasked as review capacity, with ownership as a major blocker. AI code review is an immediate way teams can address the problem.
Teams that turn on AI code review see up to about 5% more PRs merged, and it rolls out across an org with low effort. It runs the pattern Angie describes, where the review agent challenges the coding agent and sends fixes back before a person is in the loop, so human attention goes to the changes that need it. Framed that way, AI code review is what makes agentic volume survivable, and it is the fastest, lowest-effort velocity win on the board today.
How to replicate your best teams
Every org has an outlier team or developer running ahead on AI. The standard playbook says find them and copy their patterns, and most attempts fail. Two leaders explain why, from opposite sides of the same wall.
Angie ran the version most orgs will recognize. “At Block, we gave 50 AI Champions 30% of their time to work on AI enablement inside their own repos. They created context files, reusable skills, review automation, and working examples for their teams. We then ran demos, office hours, agent battles, and broad training.”
The result was honest and incomplete. The Champions had the three things that make a new skill stick: dedicated time, permission to spend it, and their own production code to practice on. Everyone else “mostly got exposure,” in Angie’s words, watching what was possible without doing it on work that mattered to them.
Her diagnosis gets to the heart of it: “Watching someone automate a migration is very different from restructuring your own work to do it.” The fix she arrived at is team-based workshops that use the team’s actual repo and backlog.
Balaji reaches the same place from LinkedIn’s AI rollout:
“Before you can hope to replicate or scale how a technology is implemented, you really have to do your homework on understanding the people you intend to support with that technology.”
LinkedIn did that homework first. It learned from the teams expected to use the tools, piloted deeply with a couple of them to find and fill the gaps, and only then trained leaders and surfaced the power users in each org.
Ultimately, exposure does not replicate leverage, but team-specific enablement on real work does. There is a halo effect worth chasing, wherein a strong agentic developer pulls the teammates around them up, but it doesn’t happen unless the environment is suitable.
Engineering that environment starts with seeing it. Replication fails when it runs on gut feel instead of evidence, so you need a tool to provide that evidence that AI is having an impact. With a context layer on your SDLC that maps every team to leverage metrics like merge rate, PR yield, and how much AI-assisted work reaches production, you can find the teams genuinely pulling ahead and the practices that set them apart. You replicate what you can now see, and improve what you can now measure.
Your choice: measure leverage, then replicate… or just keep guessing
To leave no stone unturned, we also asked each leader which metric they would delete from everyone’s AI dashboard, and which metric they would add in its place.
Balaji would cut the counts that masquerade as output. “I would delete the number of PRs merged or LOCs as a measure of productivity,” he says. “Instead, we should all be focused on actual value delivered to our users and customers.”
Angie would cut token usage, the number the last edition of this newsletter was written against. “Burning more tokens doesn’t mean you’re getting more work done,” she says. “I’d replace it with the cost per successfully completed engineering task. That could be a merged PR, a resolved incident, or a completed migration.” The merge rate stays the comparative signal that exposes the gap between teams, and what these leaders want on the dashboard is a measure of what the merged work delivered.
Rebecca Murphey would delete adoption outright, then name the harder part. “What we really need to understand, especially as frontier models move to usage-based pricing, is cost, and whether the AI money we’re spending is producing good results,” she says. “What’s the metric? I have no idea. It’s the same problem that ‘developer productivity’ has always faced.”
All three leaders make it abundantly clear: stop counting activity, and start measuring delivered value.
For the full benchmark story and more strategies on replicating leverage, join our hands-on workshop later this month (Thursday, July 30 at 10am PT) where we dive into the data, uncover the breakaway strategies, and help you navigate your org’s agentic engineering journey.
