The AI efficiency plateau
Tracking the trajectory of developer time savings from AI
Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
In “The SPACE Of AI”, we found that AI efficiency is a skill: as developers spend more time with these tools, their ability to extract value compounds. This is supported by another recent study which found that developers with higher usage were more likely to report AI making them more productive.
To explore this further, we looked at the trajectory of time savings from AI coding assistants: how quickly developers reach their peak gains, and whether those gains hold over time.
To explore this, we looked at a sample of DX data from over 500 companies over the last year (May 2025-April 2026). Our analysis focused on self-reported time savings, where developers estimated the number of hours per week they saved through the use of AI coding assistants. By tracking individual migration patterns between time-savings bands (categorized as low: <4 hrs/week and high: 6+ hrs/week), we could see how quickly gains are achieved and whether they are sustained.
What we’re seeing: Peak times savings are temporary
When we followed individual developers over four quarters to see how their time savings evolved, a few things stood out.
Low initial savings often lead to higher future gains. Nearly one in three developers (31.4%) who started in the lowest time-savings band climbed to the highest band during the study period, indicating that early AI gains are a starting point rather than a fixed ceiling. In “The AI Native Developer,” we found that AI fluency increases with use, which raises an open question: how does this ramp-up in time savings map to the stages of AI fluency we identified?
Time savings from AI ramp up quickly with continued use. Among developers who reached the highest time-savings band, roughly 7 in 10 (69.7%) got there in less than two quarters. This rapid progression is likely driven by a combination of factors, ranging from how quickly a developer adapts their workflow to how well their specific tasks align with AI capabilities.
Peak time-savings are temporary, and may fade. Of those developers who reached peak time savings, two-thirds (66.1%) reported lower time savings in the quarters that followed.
Gains achieved in one quarter are not sustained. Among developers who hit the highest time-savings band in one quarter or less, just over half (50.5%) did not report that level of savings in future quarters. While we don’t know the exact cause of these fluctuations, the speed of the initial spike may reflect a burst of enthusiasm or a concentration of easy-win tasks but it does not translate into a durable shift in productivity.
A longer ramp-up does not show staying power. For developers who took two quarters to reach peak savings, the drop-off is even steeper. 79% did not report high time savings in future quarters. This suggests that even a more gradual adoption path does not insulate developers from the plateau, and that time using the tool alone isn’t enough to sustain peak productivity gains.
What might be causing the plateau?
Before exploring potential causes, an important caveat to mention is that our study covers a limited number of quarters, so the patterns we’re seeing here are early observations rather than settled conclusions. As we gather more data, we’ll be able to test these patterns over longer time horizons and revise the picture accordingly.
With that in mind, we want to offer a few possible explanations for the plateau. We can’t yet say which of these are doing the most work, or whether there are other factors we haven’t yet considered, but each is consistent with what we’re seeing in the data and worth investigating further.
System-level constraints
Individual efficiency gains create secondary challenges at the system level. While task-level coding is accelerating, the time saved is frequently redistributed into areas that are currently under-measured, such as increased experimentation, deeper architectural exploration, and quality improvements. Our prior research found that the median engineering organization sees a 7.8% increase in PR throughput from AI. Real, but more modest than headline claims would suggest, and consistent with the idea that the surrounding system is absorbing much of the individual-level efficiency. We may be observing a shift where the bottleneck moves from code production to system coordination. In some cases, engineering teams appear to be shipping faster than the surrounding product management and verification processes can support.
The task ceiling
The plateau could also be tied to a task ceiling. Early gains often come from automating high-volume, low-complexity work. Once these are optimized, developers may struggle to apply AI to more complex areas like architectural design or legacy refactoring. We need more research into specific use cases to understand if the plateau is universal or if developers who move AI “upstream” into design or “downstream” into debugging sustain higher gains.
Shifting baseline of productivity
Even when developers reach high time savings quickly, sustaining that perceived impact is difficult. One possible explanation is a new normal effect: once a developer integrates AI into their workflow, the resulting efficiency gains become the baseline. When surveyed in subsequent quarters, developers are no longer comparing their performance to a pre-AI workflow, but to their newly optimized standard.
Why this matters for engineering leaders
Individual efficiency gains are fragile. While AI coding assistants can deliver meaningful gains for a significant share of adopters, the large share of developers falling back from their peak savings suggests that time with the tool alone isn’t enough to sustain those gains. As developers produce code faster, they often hit ceilings, like slower code reviews and architectural bottlenecks, that neutralize individual gains. This suggests that the plateau in time-savings may not be a failure of the tool or the user, but a sign that the bottleneck has shifted from individual code production to team-level coordination. It highlights a need for deeper research into whether certain use cases, like complex debugging or requirements drafting yield more durable gains than the high-volume, low-complexity tasks that typically drive initial adoption spikes.
This week’s featured DevProd job openings. See more open roles here.
Ashby is hiring an Staff Platform Engineer | Remote
BambooHR is hiring a VP of Engineering | Utah (Hybrid)
Cashea is hiring an Infrastructure & Developer Productivity Platform Engineering Manager | Remote
Figma is hiring a Staff Software Engineer, Developer Experience | Remote; US
Leidos is hiring a Platform Engineer | Remote; US
Morgan Stanely is hiring an AI Platform Engineer - Vice President | New York
Weave is hiring a Senior Platform Engineer, Data Infrastructure | Remote; US
That’s it for this week. Thanks for reading.
Interesting article, as usual.
I'm just unconvinced by a fundamental aspect of it:
> Our analysis focused on self-reported time savings, where developers estimated the number of hours per week they saved through the use of AI coding assistants.
You could argue that it's "old" in "AI terms" (I wouldn't agree); you can also argue with the exact findings, but one thing seemed to be pretty clear from the 2025 METR study on AI in OSS: humans are particularly bad and unreliable when self-reporting productivity gains.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
So, why are you still reporting that as a reliable indicator for the study?
Also, this conclusion
> This suggests that the plateau in time-savings may not be a failure of the tool or the user, but a sign that the bottleneck has shifted from individual code production to team-level coordination.
What evidence is there that the bottleneck has indeed shifted, meaning that there has ever been "individual code production"? Has the bottleneck really shifted, or was it always team-level coordination (and decision-making, and figuring out what's the right thing to do, and dealing with changing priorities, etc.)?
There is an expressed (implicit) belief that might be the case, but what's the evidence to support this statement?