BizTechLab — Ideas, Innovation, ImpactBizTechLab — Ideas, Innovation, Impact
Back to Opinion Articles
Opinion #011•4 min read•21 September 2026

AI Saves Developers 13 Hours a Week. So Where Did the Time Go?

Developers say AI nearly doubled the amount of coding time it saves them in a year. The survey suggests those hours haven't become free capacity — a lot of them are going into work that takes more judgment.

Rajnish Kumar

Rajnish Kumar

Editor-in-Chief & Founder

AI Saves Developers 13 Hours a Week. So Where Did the Time Go? — Opinion article hero image

The Number Everyone Wants to Believe

Every AI coding pitch ends in the same arithmetic: if the tool saves each developer hours every week, the team gets that time back. BairesDev's Q3 2026 Dev Barometer, published on 15 September 2026, gives that arithmetic its strongest recent number. It surveyed 705 developers across more than 60 countries and 41 enterprise CTOs, and found that 42% of developers now say AI writes at least half their code, up from 12% a year earlier. Developers also report that AI saves them about 13 hours a week on coding, up from roughly 7 hours the year before. On paper, that is most of a working day handed back every week.

The Hours Didn't Come Back

The same survey points to where the time is going, and it isn't idle time or extra features. Two thirds of developers (67%) say they now spend more time reviewing AI-generated code, and 52% say they spend more time debugging problems the AI introduced. Developers also report spending around 9 hours a week learning AI tools and new technologies, against about 4 hours a year earlier. BairesDev's CEO summarized it in the VentureBeat coverage as "not one of those hours came back," but that is a headline, not an audit: the survey reports directions of change, not an hour-by-hour ledger. The time didn't simply disappear. A meaningful share of it moved up the stack, into work that takes more judgment than the coding it replaced.

The Capacity Illusion

This is what I'd call the capacity illusion: measuring the saving at the point where code gets written, and assuming it shows up as spare capacity at the point where software gets shipped. A saved hour on typing isn't a free hour if it creates a fraction of an hour of review, a fraction of debugging, and a fraction of learning a workflow that changes every quarter. In the same survey, only 21% of developers spend more than half their week writing new code from scratch, which means new code is no longer where most of the week goes. Any planning model that converts saved coding hours directly into extra delivery capacity is counting the same hours twice.

Organizations Are Already Behaving as If They Know

The most telling number in the report isn't about developers at all. Companies aren't responding to AI-generated code by loosening the checking side of the pipeline; if anything, the survey suggests the opposite, with 78% of the 41 CTOs surveyed saying spending on code review, QA and validation has increased. That is what you'd expect when the cost of producing changes falls faster than the cost of deciding whether those changes are safe to ship, though the survey reports the spending, not the reason for it. Only 7% of developers say shipping decisions have been completely delegated to AI, so a human is still the last gate almost everywhere.

We Already Know Feelings About Speed Are Unreliable

There's a second reason to be careful with a self-reported "13 hours saved." In the well-known METR randomized trial of experienced open-source developers in 2025, developers using AI took 19% longer on real tasks in their own repositories, yet afterwards estimated they had been about 20% faster. METR has since said its follow-up experiments are hard to interpret because many developers refused to work without AI or held back tasks they expected AI to speed up, so that early slowdown should not be read as the final word on AI productivity. What survives is narrower and more useful: how fast AI feels to the person using it and how much faster the work actually gets delivered are two separate measurements, and only one of them is a survey answer.

A Fair Caveat About This Data

The BairesDev numbers deserve honest handling. The developer sample is drawn largely from applicants in BairesDev's own screening process, not a random sample of all developers, and the CTO sample is only 41 people. BairesDev is also a company that sells engineering talent, which is worth remembering when it publishes a barometer about engineering work. I read these figures as corroboration of a pattern that other, larger datasets already show, such as Faros AI's 2026 report, which tracked two years of telemetry from 22,000 developers and compared each organization's period of lowest AI adoption with its period of highest, and found median time in code review up 441.5%. That is a comparison between adoption levels inside the same organizations, not a claim about every team everywhere. Taken alone, this survey would be thin; next to that telemetry, it points the same way.

What Leaders Should Stop Doing

The practical mistake is to bank the saved hours in advance: cutting headcount, or promising a roadmap twice as large, because the survey says developers are saving 13 hours a week. If review, debugging and learning are absorbing that time, the promise is being made against capacity that doesn't exist. Teams that will handle this well are the ones that start measuring what actually leaves the building, meaning changes shipped, incidents caused and time from merge to production, instead of how much code the tools helped produce. They will also treat review capacity and test infrastructure as the real production constraint, and budget for them the way CTOs in this survey already are.

Faster Typing Was Never the Whole Job

AI coding tools are genuinely changing how software gets built, and nothing here argues for going back to writing every line by hand. What the data argues against is the story that the time saved is free. Developers are reporting that more of their time is going into reviewing, debugging and learning new tools and workflows. In other words, the scarce part of the job is moving away from producing code and toward deciding whether the code deserves to ship. The teams that pull ahead won't be the ones who saved the most hours; they'll be the ones who knew, week by week, exactly where those hours went.

Sources

Every figure above is traceable to a specific survey, report or study below.

Found this useful? Share it

Published under the BizTechLab Editorial Code of Integrity.

Explore More Opinion Articles