How Microsoft sees engineering bottlenecks changing with AI

Engineering Enablement by DX

0:00

-39:24

How Microsoft sees engineering bottlenecks changing with AI

Tim Bozarth, Microsoft CoreAI CVP, explains how AI is changing engineering productivity, why outcomes matter more than output, and what engineering leaders should measure instead.

Brian Houck

Aug 07, 2026

Listen and watch now on YouTube, Apple, and Spotify.

In this episode of Engineering Enablement, I sit down with Tim Bozarth, Corporate Vice President in Microsoft CoreAI and leader of Microsoft’s Engineering Thrive initiative. We discuss Engineering Thrive, Microsoft’s framework for measuring and improving engineering productivity, and why AI makes outcome-based metrics more important than ever.

Tim shares how AI is reshaping the software development lifecycle, where new bottlenecks are emerging, and why verification and confidence may become more valuable than code generation itself. We also explore why the purpose of engineering remains the same despite rising levels of abstraction, the skills that remain durable in an AI-driven world, and why engineering leaders should focus on outcomes rather than activity metrics.

Some takeaways:

Engineering Thrive gives Microsoft a common language for improving productivity

Engineering Thrive defines productivity through speed, ease, and quality. Its goal is to make it fast and easy to do great work by identifying friction across the developer experience rather than optimizing isolated activities.
Speed, ease, and quality should not be treated as opposing goals. Engineering Thrive applies a “do no harm” principle: an improvement in one dimension should not be celebrated if it makes another materially worse.
The framework helps Microsoft identify bottlenecks and invest where they will have the greatest impact. Tim argues that developer time is one of the company’s most valuable resources, making productivity improvements a strategic investment.

AI makes outcome-based metrics more important, not obsolete

The industry is returning to activity metrics it rejected years ago. Tim sees renewed attention to lines of code, pull request counts, and similar measures as a search for easy answers to how AI is affecting productivity.
More engineering activity does not necessarily mean more value. Engineering Thrive instead measures outcomes such as product quality, end-to-end speed, and the amount of time engineers can devote to innovation.
A web of outcome metrics is harder to game than any individual measure. Looking across speed, ease, quality, and innovation time creates a more durable picture of whether an organization is actually improving.

Planning and validation are becoming the new bottlenecks

Before AI, most engineering time was spent creating and operating software. Tim estimates that those phases historically accounted for more than 90% of engineering time, with operations alone consuming roughly 70% to 80%.
On frontier teams, the bottlenecks have already shifted to planning and validation. Code creation is taking dramatically less time, while deciding what to build and determining whether the result is trustworthy are consuming a greater share of the work.
The create phase may continue to shrink as models and agent harnesses improve. Tim expects planning and validation to remain durable constraints over the next several years, even as other parts of the software development lifecycle become increasingly automated.

The code review bottleneck is really a confidence bottleneck

Higher PR throughput has increased the amount of change humans must evaluate. Enterprise software still requires a level of trust that teams cannot achieve by simply accepting AI-generated code without review.
Code review is only one way to establish confidence. Testing, continuous rollouts, feature flags, canaries, and deployment practices all contribute signals about whether a change is reliable.
The next generation of verification should help humans ask higher-level questions. Rather than inspecting every branch or class, engineers should be able to assess the scope, complexity, impact, and fundamental purpose of a change.

More abstraction does not change the purpose of engineering

AI will reduce the time engineers spend on low-level implementation details. Tim sees that as another step in the long history of abstractions that allow engineers to spend more time describing system behavior and intended outcomes.
Great engineers have never been defined by their ability to write a line of code. Their value comes from systems thinking, understanding objectives, and expressing functional and nonfunctional requirements coherently.
Producing more software increases the need for strong engineering judgment. The faster organizations can build, the more important it becomes to ensure that their systems remain coherent, valid, and reliable.

A maker’s mindset and ability to experiment effectively remain durable advantages

The maker’s mindset is relentlessly oriented toward producing a valuable final outcome. It combines a clear vision of what should be built with the ability to understand the needs of the customer using it.
Engineers will need to continuously experiment and evaluate changes in outcomes. Tim argues that this discipline is no longer limited to model trainers; everyone using AI tools must determine whether a new approach actually improves the result.
Using AI is not itself the goal. The goal is to accomplish more, and sometimes the best way to do that will be not to use AI at all.

Engineering leaders should measure idea-to-value, not PR velocity

PR velocity says little about the success of an engineering organization. Tim urges leaders to stop evaluating teams through activity measures the industry already recognized as inadequate years ago.
Idea-to-value connects engineering work to meaningful outcomes. Leaders should also examine how much time engineers spend innovating compared with keeping the lights on or handling corporate overhead.
Product quality and business results should remain the ultimate measures of success. Focusing on outcomes can improve developer happiness, productivity, margins, and the value delivered by the organization.