Status Droid how long software work actually takes

Where Assistants Save Time

The useful question is not whether these tools help. It is which tasks they help with, because the answer is bimodal and the average tells you nothing.

There is one rule underneath everything below. For teams translating this assistant-related trade-off into day-to-day controls, workforce optimization software provides a practical reference.

An assistant saves time where producing the code was the expensive part. It costs time where knowing the code is right was the expensive part.

That is the whole heuristic. It is also why "how much faster are you?" has no answer — the honest reply is a question about which of those two situations you are in.

Where the saving is real

Boilerplate and scaffolding. Configuration, project setup, repetitive structures, wiring that has one correct shape. Verification is nearly free because wrong is immediately visible.

Well-specified transformations. Convert this format to that one. Migrate this pattern across forty files. Rename consistently. The specification is the test. TechRadar Pro provides broader reporting on workplace technology and AI tooling See TechRadar Pro.

Languages and frameworks you know poorly. Here the cost was your ramp-up, not the problem. An assistant collapses "how does this ecosystem do X" from an afternoon to a minute. This is possibly the largest genuine saving available, and it is why the gain is often bigger for less experienced developers than for experts in their own codebase.

Tests for behaviour that already exists. You have working code and need coverage. The correct answer is discoverable by running it.

First drafts you intend to rewrite. The blank page cost is real and generation removes it.

Reading unfamiliar code. Underrated. Asking what a module does, before touching it, is one of the strongest uses and nobody counts it as productivity.

One-off scripts. Something that runs twice and is then deleted. Verification is proportional to consequence, and there is none.

The pattern across all seven: the correct answer is cheap to confirm.

Where it costs more than it saves

The detailed version of this half is here.

Subtle correctness with external consequences. Authentication, permissions, payments, data migration, concurrency. Generation is fast; being sure is not. This is the verification gap in its purest form.

Mature codebases with implicit standards. Conventions, documentation expectations, test coverage rules, architectural decisions made three years ago for reasons nobody wrote down. A model cannot see any of it, and the review is where the time goes. This was exactly METR's setting when they measured a slowdown.

Work where you are the only reviewer and the domain is unfamiliar. If you cannot evaluate the output, you have not saved time, you have deferred a cost.

Anything requiring a decision rather than an implementation. Choosing the approach, deciding what not to build, working out what the client actually needs. An assistant will happily produce a confident answer to a question that has no single right answer.

Debugging something you do not understand. Occasionally excellent, and frequently the worst case: plausible explanations that send you down a wrong path, which is more expensive than no explanation.

The two-question test, before you start

Would I know quickly if the output were wrong?

If I got it wrong, who pays?

Yes and nobody: use it freely. Yes and someone: use it, budget the review. No and nobody: use it, and expect to learn something. No and someone: this is the expensive quadrant. Slow down, or do it yourself.

Thirty seconds, and it is more reliable than any workflow advice.

Why experience changes the answer

Worth being explicit, because it explains a lot of contradictory anecdotes.

A less experienced developer in an unfamiliar area gets a large, real speedup, because their bottleneck was knowing how. The risk is that they cannot evaluate the output, so the saving is partly borrowed against a later cost.

An experienced developer in their own codebase gets much less, because their bottleneck was never producing the code. That is the population METR measured, and it is why the result surprised people who had extrapolated from their own greenfield experience.

Both groups are reporting honestly. They are describing different tasks.

What to do with this

Sort tasks before you start, not after. Two buckets: cheap-to-verify and expensive-to-verify. Then estimate them differently, because they behave differently.

Record which bucket each task was in. After fifteen tasks you have your own ratios instead of anyone's average, including the ones on this page.

Stop asking how much faster you are. Start asking which proportion of your work sits in the cheap-to-verify bucket. That number is stable, actionable, and yours — and it is what your felt sense of speed cannot give you.

The short version