Status Droid how long software work actually takes

The Verification Gap

The work did not disappear. It moved.

Generating a function is now close to free. Establishing that the function is correct, secure, and appropriate for your codebase costs roughly what it always did — and is harder than before, because you are now reviewing code you did not write, which looks finished, passes linting, and compiles. For teams translating this assistant-related trade-off into day-to-day controls, accountability and responsibility in the workplace provides a practical reference.

That transfer is the single most important thing to understand about estimating and billing this work. The saved time went into a category most teams do not track.

What the screen recordings showed

METR's 2025 trial labelled 143 hours of developer screen recordings. The decomposition is the useful part, more than the headline.

Time spent actively writing code went down. Time spent searching for information went down. Time spent prompting, waiting for output, and reviewing that output went up. Sourcegraph focuses on code intelligence and AI-assisted work across codebases See Sourcegraph.

Both directions feel like progress. Less typing feels like speed. More reviewing feels like overhead rather than work, and overhead is systematically under-perceived — which is most of why measured and felt time disagree.

Why checking is harder than writing

Not a moral point. Three structural reasons.

You lack the author's model. When you write something, you hold the reasoning: why this branch, what you decided not to handle, what you were unsure about. Reviewing generated code, you have the artefact and none of the reasoning, and you have to reconstruct it.

Correct-looking is the default output. Generated code is fluent by construction. The signals humans use to sense uncertainty in a colleague's work — hesitant naming, a scrappy comment, an obviously provisional structure — are absent. Everything arrives with the same finished surface, whether it is right or wrong.

The failures are the ones review is worst at. Not syntax errors, which the compiler catches. Subtle logic that works on the happy path, error handling that swallows the case you care about, an assumption that holds until the data changes.

What the security data says

The evidence here is substantial and almost all of it comes from companies that sell security tooling, which is stated where relevant. The most independent source is a university project.

Georgia Tech's Systems Software and Security Lab runs the Vibe Security Radar, tracking CVEs directly attributable to AI-generated code after scanning tens of thousands of security advisories. The count climbed from single digits in early tracking to dozens per month during 2026. Reported figures differ between write-ups — you will see 6, 35 and 74 quoted against different periods and definitions — so treat the trajectory as the finding rather than any specific total.

Veracode, which sells application security testing, tested over 100 models across 80 coding tasks and reports that 45% of generated samples introduced an OWASP Top 10 vulnerability, with Java worst at over 70%, and that the rate did not improve across testing cycles from 2025 into early 2026.

Cloud Security Alliance research notes report that across 2.23 million AI-generated code samples from 16 models, 19.7% contained at least one hallucinated package name — a dependency that does not exist, and which an attacker can register.

GitGuardian, which sells secrets detection, reports AI-assisted commits leaking credentials at roughly 3.2% against a 1.5% baseline across public GitHub commits.

And the figure that captures the whole problem, from enterprise research cited by CSA: AI-assisted developers produced commits at three to four times the rate of their peers while introducing security findings at ten times the rate.

Read that as a ratio rather than an indictment. Output roughly quadrupled. Problems roughly decupled. The checking did not scale with the writing.

What this means for your estimates

Estimate the review separately. If you estimate a task as "the work," you have estimated the writing, which is now the cheap part. Review has to be its own line.

Expect the ratio to invert on some work. Tasks where generation is trivial and verification is expensive — anything touching authentication, payments, permissions, data migration — can now cost more in total than they used to, because the writing was never the expensive part there either.

Treat generated code as unreviewed third-party code, which is the standard recommendation across every source above and the only one they all agree on. If verification is the constraint, this is where the leverage is. That framing sets the right expectation about effort: you would not merge a stranger's pull request unread.

The part that is genuinely good

Not an argument against these tools.

The transfer is favourable when the writing was the bottleneck: boilerplate, a language you know poorly, a well-specified transformation, a test suite for existing behaviour, a prototype you intend to throw away. In those cases generation collapses hours into minutes and the verification is genuinely cheap, because the surface is small and the failure mode is obvious.

The transfer is unfavourable when correctness is subtle and consequences are external. Which is a description of most production work in a mature system, and exactly the setting where METR measured a slowdown.

Knowing which of those you are in, before you start, is the whole skill. It is also what makes an estimate possible at all.

The short version