Tim Bozarth, Microsoft's CVP of CoreAI and leader of the Engineering Thrive initiative, discusses how AI is reshaping engineering productivity measurement and where new bottlenecks are emerging. Engineering Thrive defines productivity through speed, ease, and quality, rejecting activity metrics like PR counts in favor of outcome-based measures. As AI accelerates code creation, planning and validation are becoming the dominant constraints on frontier teams. Bozarth argues that verification and confidence in AI-generated code matter more than raw throughput, and that durable engineering skills — systems thinking, judgment, and a maker's mindset — remain essential regardless of abstraction level. Engineering leaders are urged to measure idea-to-value rather than PR velocity.
Questions this post answers
Where are the new engineering bottlenecks when AI handles most code generation?
On frontier teams, the bottlenecks have shifted to planning and validation. Before AI, creating and operating software consumed over 90% of engineering time, with operations alone taking 70–80%. As AI dramatically reduces time spent on code creation, deciding what to build and verifying that the result is trustworthy now consume a growing share of engineering effort, and these constraints are expected to remain durable even as automation advances. Engineering leaders navigating this shift track emerging patterns on daily.dev.
Why are activity metrics like PR count or lines of code inadequate for measuring AI-era engineering productivity?
More engineering activity does not necessarily mean more value delivered. PR velocity and similar measures are easy to game individually and say little about organizational success. A web of outcome metrics — covering product quality, end-to-end speed, innovation time, and developer ease — creates a more durable picture of whether an organization is actually improving, and is harder to manipulate than any single activity measure. Teams rethinking how they measure engineering output find relevant perspectives on daily.dev.