Our Take
McKinsey's framing (productivity hack to role reinvention) is sound, but without numbers or customer cases, this reads as taxonomy, not evidence of value capture.
Why it matters
Software leadership is betting on AI to change output per engineer. Understanding the actual patterns (individual tool adoption vs. workflow change vs. staffing shifts) is the only way to budget and hire correctly.
Do this week
Engineering leadership: audit your team's AI spend this week against these three buckets (tools, process, headcount), then identify which one has zero adoption—that's your quick win.
McKinsey maps three layers of AI adoption in software development
McKinsey Insights published a framework distinguishing three ways AI affects how code gets built: individual productivity enhancements (developers using GitHub Copilot or Claude for specific tasks), full workflow redesign (integrating AI into QA, testing, or code review pipelines), and role reinvention (changing what engineers do or how many you need).
The piece centers on a central claim: some companies are capturing real value from this shift while others are not, and the difference lies in how intentionally they move through these three layers. The authors position the progression as a maturity model, moving from ad-hoc tool adoption to systemic change.
No customer case studies, benchmarks, or financial outcomes are disclosed in the available excerpt.
The catch: taxonomy without proof of value
Three-layer frameworks are useful for teaching. They are less useful for budgeting. McKinsey's distinction between "individual hacks" and "role reinvention" correctly identifies that AI adoption is not a monolith, but the piece does not show which layer drives ROI, how long each transition takes, or what percentage of engineering orgs have moved beyond layer one.
For software leaders, this matters immediately. If your team is stuck in layer one (Copilot licenses and nothing else), knowing what layer two looks like is worthless without evidence that layer two actually improves velocity, quality, or cost. The framework assumes value flows from layering; it does not prove it.
This is the recurring gap in AI productivity discourse: everyone agrees AI is changing development. Few sources show what productivity actually changed, by how much, and under what conditions.
What to do now
Do not treat this as a deployment roadmap. Treat it as an audit template. Map your current AI spend and activity against the three buckets: Which tools are engineers using? Which workflows have you redesigned? Which roles have you redefined or eliminated? If you have zero activity in layer two or three, ask why. If you have activity but no comparable metrics (deployment speed, code review time, defect rate), you cannot claim value capture yet.
The separation between companies "capturing value" and those that are not almost certainly comes down to measurement discipline, not framework sophistication. Start there.