The metric nobody has
Ask most CTOs how their AI coding investment is paying off, and you’ll get an adoption number. Seats provisioned. Daily active users. Engineers who’ll tell you, honestly, that they feel faster.
Ask for a throughput number instead, and the room gets quieter. Deployment frequency. Lead time. Defect-escape rate. The metrics that say whether the organization got faster, not just the individuals in it, usually haven’t moved much at all.
That gap isn’t a fluke, and it isn’t a measurement problem waiting on a better dashboard. It’s what happens when you speed up one stage of a pipeline and leave the rest of it exactly as it was.
What Microsoft’s own data shows
Microsoft put real numbers behind part of this earlier this year. Using direct telemetry from tens of thousands of its own engineers on its command-line coding agents — not a survey, not a lab exercise — the company measured a roughly 24% lift in merged pull requests (PRs). That’s a real, credible result, and their own researchers were careful about what it does and doesn’t show: a merged PR is an output measure, not the value it delivers, and the added output still must justify its cost. That distinction matters beyond this one study. Merged code is not the same thing as reviewed, tested, and deployed code. Most of what gets reported as “AI productivity” right now stops at the easier number.
Where the bottleneck moves
Here’s why that gap exists, and it isn’t specific to any one study or tool. Accelerate the fastest part of a pipeline, and the pipeline doesn’t get faster. The bottleneck just moves to whatever you didn’t touch.
In many organizations, the constraint moves downstream to code review, testing, security validation, or deployment approval. Coding agents can substantially accelerate code creation, especially for well-scoped engineering tasks. But they were not designed to govern everything that happens next: who approves the change, which standards it must meet, how it traces back to the requirement that justified it, and which gates it must clear before release. Without redesigning those stages, higher code output can simply create a larger downstream queue.
Why this is a platform problem, not a tool problem
This is where most AI coding strategies quietly stop being strategies and start being purchases. A team buys a tool, gives it to engineers, and calls the job done. But a coding assistant is a point solution. It solves for one stage of a much longer system, and a system only moves as fast as its slowest, least-governed link.
The better measure is whether the organization has stopped treating this as a tool decision and started treating it as a platform decision. An agentic engineering platform connects the full path from business intent and versioned specifications through architecture, code generation, review, testing, security validation, deployment, and operations. The coding agent remains important, but it becomes one component of a governed engineering system rather than the system itself.
This also changes the role of the engineer. In an agentic model, engineers spend less time producing every line manually and more time defining intent, reviewing outputs, applying judgment, and ensuring that what reaches production meets business and technical standards. But that operating model cannot depend on individual discipline alone. The specifications, controls, approval gates, and traceability must be built into the engineering platform. A complete platform brings together three connected layers: an agentic engineering factory that builds and maintains software from specifications; a production-grade runtime that provides workflows, rules, agents, integrations, security, and observability; and reusable technical and industry components that prevent every solution from starting from zero.
At Tavant, this is how we think about agentic engineering. Coding agents are the foundation, not the finished solution. The larger opportunity is to connect specifications, engineering agents, runtime services, reusable components, and enterprise governance so organizations can build, modernize, deploy, and maintain software as one continuous system. The objective is not to introduce another platform license or lock customers into a proprietary development environment. It is to deliver software faster while preserving customer ownership of their code, data, cloud, and technology choices.
That is a genuinely different question from “which AI tool should our engineers use?” Boards should ask whether the engineering system became faster end to end, while maintaining quality, security, and control.
Before you report this to your board
Before reporting AI adoption to the board, compare lead time from approved requirement to production, deployment frequency, average PR review time, defect-escape rate, and change-failure rate before and after the rollout. If code output increased but production throughput, quality, and recovery did not improve, the organization accelerated an activity rather than the engineering system. Bring those measures to the board instead of the adoption slide, and you will have a very different conversation.
¹ Murphy-Hill, Emerson, Jenna Butler, and Alexandra Savelieva. “Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft’s Early 2026 Rollout of Claude Code and GitHub Copilot CLI.” arXiv, 1 July 2026, arxiv.org/abs/2607.01418.