The AI velocity paradox: why faster code means working weekends

You ship a feature on a Tuesday afternoon. The assistant in your editor drafted most of it — the boilerplate, the tests, a migration, even a tidy commit message. It felt great. It felt fast. Then the pull request sits in review for two days because nobody on the team has the bandwidth to read four hundred lines of code none of them wrote. The security scan flags a dependency. Staging breaks in a way the unit tests did not catch. By Saturday morning you are back at your laptop, coffee going cold, untangling a deployment that the Tuesday-afternoon version of you was sure would be done.

If that arc feels familiar, you are living inside what the engineering-tooling company Harness named the AI velocity paradox. The promise of AI coding tools was that they would give us our evenings back. For a lot of developers, the opposite is happening — and the reason is not that the tools are bad. It is that they sped up exactly one stage of a long pipeline and left the rest running at human speed.

Where the time actually goes

Writing code was never the slow part. Anyone who has shipped software for a living knows the bulk of the calendar disappears into the steps around the code: understanding the problem, reviewing someone else’s change, waiting on a flaky test suite, getting a security sign-off, chasing an approval, watching a deploy, and fixing what the deploy broke. AI tools are extraordinarily good at the writing. They are, for now, no help at all with most of the rest.

So the writing accelerates and the volume of code goes up — more pull requests, more diffs, larger changes, generated faster than before. All of that output flows into the same review queues, the same continuous-integration runners, the same security gates, the same on-call rotation. The picture is a four-lane motorway feeding into a single-lane bridge. Traffic does not get faster; it backs up. And in software, when work backs up against a release deadline, it does not vanish. It moves into the hours when nobody is watching the queue, which is to say, your hours.

This is the part the productivity pitch leaves out. A tool that doubles your typing speed does not double your delivery speed if typing was a fifth of the job and the other four-fifths just got handed twice as much to process.

The data: heavy AI users work the most weekends

The clearest evidence comes from the Harness State of DevOps Modernization 2026 report, which surveyed around 700 engineers and technical managers across the United States, the United Kingdom, France, Germany, and India. The headline finding is stark, and it runs against the marketing.

Among developers who use AI coding tools very frequently, about 96 percent said they were required to work evenings or weekends multiple times a month because of release-related work. Among developers who use AI tools only occasionally, that figure was 66 percent. Both numbers are high — release crunch is an old problem — but the gap is the story. The more you lean on AI to generate code, the more likely you are to lose your weekend to shipping it.

The same survey points straight at the mechanism. Roughly 69 percent of the very-frequent AI users said their teams frequently hit deployment problems with AI-generated code. The faster code arrives, the more often it stumbles on the way out the door — and the testing, security, and deployment stages that would normally absorb that risk have not been scaled up to match. The report also found developers still spend about 36 percent of their time on repetitive manual work: configuration, approvals, rerunning failed jobs, chasing tickets. That is the friction AI was supposed to remove, and it is still sitting there, now feeding a bigger pile.

The feeling of speed is not the same as speed

Here is the most uncomfortable finding, and it deserves to be sat with rather than waved away. In 2025 the research group METR ran a randomised controlled trial with experienced open-source developers working on their own real projects. Half their tasks allowed AI tools; half did not. The developers expected the AI to speed them up by around 20 percent. They reported afterward that it had.

Measured by the clock, the AI tasks took about 19 percent longer.

Read that twice. Experienced engineers, on code they knew well, were slower with AI — and could not feel it. The likely culprits are the hidden costs that never show up in the demo: time spent prompting, time spent reading and verifying generated code, time spent fixing the subtly wrong twenty percent, and the cognitive switch between authoring and auditing. METR has since cautioned that this was a specific setting with early-2025 tools and that self-reported speedups in general are unreliable, which is exactly the point. The gap between how fast AI feels and how fast it is can be large, and it runs in the direction that costs you time. If your sense of velocity is inflated, you will commit to deadlines you cannot hit, and the shortfall gets paid down on the weekend.

The industry is quietly walking back the hype

None of this means AI coding tools are a fad. Adoption is close to universal and still climbing. Stack Overflow’s 2025 Developer Survey found that about 84 percent of developers use or plan to use AI tools, with roughly 51 percent using them every day. These tools are now part of the furniture, and that is not going to reverse.

But the same survey caught the mood turning more sober. Favourable sentiment toward AI tools cooled to around 60 percent, down from the highs of 2023 and 2024. And on the specific question of accuracy, more developers said they distrust what the tools produce — about 46 percent — than said they trust it, around 33 percent. That distrust is not Luddism; it is the lived experience of reviewing generated code and finding the confident, plausible, wrong parts. It is also a quiet admission that all that generated output still has to be checked by a human, which is to say the work did not disappear, it changed shape.

The people running the largest engineering organisations are sounding the same note. Google’s chief executive Sundar Pichai has framed AI’s real contribution as something like a 10 percent gain in engineering velocity — meaningful, but a long way from the order-of-magnitude transformation in the pitch decks — and has said the company intends to hire more engineers, not fewer. A 10 percent lift is a genuinely good outcome. It is also a number you can plan around honestly, instead of one that quietly turns your roadmap into a series of weekends.

What this means for the people doing the work

The trap in the velocity paradox is that it is invisible from the top. A dashboard that counts commits or lines or merged pull requests will light up green, because the writing stage really did get faster. What it will not show is the queue depth behind review, the rising rate of failed deploys, the on-call engineer who has not had a clean Saturday in a month. The numbers that look good are the easy ones to measure; the cost is showing up in the numbers nobody is plotting.

So if you are a developer, a data engineer, or an ML engineer feeling this squeeze, a few things are worth saying plainly to yourself and to whoever sets your deadlines.

First, separate generated from understood. Code you did not write is not done when it compiles; it is done when you understand it well enough to defend it in review and debug it at 2 a.m. Budget that reading time openly, and resist letting the speed of generation set the pace of the commitment.

Second, name the bottleneck out loud. If the pain is in testing, security, or deployment — and the Harness numbers say that for heavy AI users it usually is — then the highest-leverage investment is widening that stage: faster and more reliable test suites, automated security checks that run early, deployment that is boring and reversible. Generating more code faster while that bridge stays single-lane just lengthens the queue and your evenings.

Third, treat the feeling of speed as a hypothesis, not a fact. The METR result is a standing warning that velocity can be felt where it does not exist. When you make a commitment, anchor it to how long the whole pipeline takes, not how quickly the first draft appeared.

The tools are not the problem, and they are not going away. The problem is a pipeline that got faster in one place and an expectation that scaled as if the whole thing had. Until the bottleneck moves, the surplus will keep flowing to the only buffer the system has — which is you, on a Saturday. The most productive thing you can do this quarter may not be to write more code. It may be to make the case, with the numbers above, for fixing the lane that everything is backing up against.