Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
🗓 Join DX’s live research panel on September 24 as Brian Houck introduces CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.
As reported in our Q2 AI Impact Report, time saved thanks to AI continues to increase, with developers reporting saving 6.1 hours per week in Q2 2026 compared to 3 hours in Q3 2025. However, it raises the question for engineering leaders:
What are developers doing with that time?
While AI is frequently positioned as a way to reclaim time for innovation, our data reveals a disconnect between AI-driven output and actual shifts in work composition. Organizations are investing in AI with the hope that the time AI saves will directly translate into faster roadmap execution and more innovation. DX tracks this using innovation ratio, the percent of engineering effort dedicated to new capabilities versus maintenance.
We used multivariate regression on a sample of 500+ DX customers to test the innovation ratio against 15 workflow metrics, including AI output, shipping velocity, and operational drag. We analyzed AI output according to how much AI-authored code, agent-delivered work, and PR throughput teams produce. Our analysis shows that while AI output has a powerful link to AI-driven time savings, it does not reliably translate into a higher innovation ratio.
Information-seeking may be the hidden barrier to innovation
While AI tools are delivering measurable speed, our data suggests that reclaiming capacity for new features requires clearing organizational friction, rather than assuming AI will lead to innovation.
AI is a lever for speed. The data confirms that AI does what it promises. AI output accounts for 63% of the variation in developer time savings, suggesting that developers with higher AI output save more time.
Speed doesn’t convert to innovation. Despite increased time savings, AI output suggests a weak link to innovation (p < 0.01, β=0.16). No single workflow metric emerged as a reliable predictor of innovation, indicating that dedicating more time for new features and capabilities is not a byproduct of moving faster.
The impact of operational friction. The clearest signal tied to lower innovation ratio is information-seeking, referring to time lost hunting for context, documentation, or answers (p < 0.01, β=-0.19). It is not a large effect and needs additional validation, but this developer-reported friction represents a significant hypothesis for engineering leaders. It suggests that reducing operational drag may be a more effective path to increasing innovation than AI (or AI alone).
Key takeaways for engineering leaders
Decouple AI strategy from innovation goals. AI delivers speed, but there is no evidence it automatically shifts teams toward new-feature work. Treat innovation as a separate objective requiring its own strategy
Test the operational friction hypothesis. Focus on reducing time lost to information-seeking. While not yet a proven driver of innovation, it is the most promising lead for improving developer conditions.
Use this as a diagnostic. Because our model accounted for only 13% of the differences in innovation ratio, much of what drives new-feature work remains unique to each company. The most valuable next step is running this analysis against your own team’s data; your strongest predictors might differ from the aggregate.
That’s it for this week. Thanks for reading.
-Grace
On the teams I’ve been working with, the time saved by using AI is being used to review more code rather than develop new features.
Developers are hesitating to approve and merge AI-generated PRs due to a lack of trust, even when the code has passed tests and follows the repository’s standards. This causes delays in the review process consuming work time that isn’t measured by current metrics.
Working with tier-1 banks and insurance companies, I learned that the pace of deliveries doesn’t depend only on developers' speed. There is significant portion of maintenance tasks involves legal requirements, audits, and rules from regulatory authorities that come with fixed deadlines and demands. When talking about regulated industries, delivering code faster will not reduce the amount of regulatory work because it is outside the scope of engineering.
One alternative would be to measure the average review time per approved PR as a productivity metric, along with the time spent searching for information.
Two things worth testing before treating the weak link as a fact about innovation.
First, the time-savings side is self-reported, and self-report on exactly this question has a measured bias. METR ran a randomised trial with 16 experienced developers working on their own repositories, screen recorded. They forecast 24% faster, came in 19% slower, and afterwards still reported a 20% speedup. If part of the 6.1 hours is belief rather than duration, then AI output explaining 63% of the variation is partly explaining variation in belief, and the failure to propagate into innovation ratio is what you would predict. The time was never freed.
Second, the ratio has a denominator problem. Maintenance load scales with merged change. Faros telemetry across 22,000 developers shows median time in review up 441.5% and incidents per pull request up 242.7% while merge rate per developer rose 16.2%. More output means more surface to maintain, so the ratio stays sticky even when absolute new-capability hours are rising. Reporting absolute new-capability hours next to the ratio would separate those two cases.
The 13% R squared is the most useful number in the piece.