The Coding Assistant Paradox: Faster to Use, Slower on the Clock

One result from 2025 deserved more attention than it got. In a randomised trial, experienced open-source developers working in repositories they already knew took longer to complete tasks when AI assistance was available than when it was not — while estimating that they had been considerably faster.¹ Perception and measurement pointed in opposite directions.

Two caveats before anyone builds a policy on it. It is one study rather than a body of evidence, and the sample was experienced developers working in code they knew well, which is close to the least favourable case for the tool. It does not generalise to someone new to an unfamiliar codebase.

But the finding about perception is the durable part, and it does not depend on that study being right. Feeling productive and being productive are separately measurable, and they come apart.

Why the feeling misleads

Three mechanisms, none of which require the tool to be bad:

Waiting is passive. Reading code that appeared on screen is cognitively cheaper than writing it. The clock runs at the same rate, but perceived effort drops — and humans estimate duration from effort rather than from elapsed time.²

Review time is not counted. Generation is instantaneous and memorable. The fifteen minutes spent checking whether the function does what it claims, whether that API call exists, whether the edge case is handled — that time dissolves into the general sense of having been busy. It is real work and it does not enter the ledger.

The cost arrives later. Code you did not write is code you do not know. The difference surfaces three weeks on, when something breaks and reading it takes twice as long — and nobody attributes that cost back to the generation session that produced it.

Where it genuinely wins

Being specific, because specificity is what the discussion lacks. In our own work the gain is clear and repeatable in four places:

• Repetitive code with a known shape. CRUD forms, data transformation, test scaffolding. The pattern is already clear in your head and typing is the bottleneck.
• A language or library you rarely touch. Here the assistant substitutes for documentation search, and it substitutes well.
• Explaining someone else's code. Reading an unfamiliar file and getting a structural summary is close to pure gain, with a self-correcting failure mode: if the explanation is wrong you find out as you read.
• A first version of something disposable. One-off script, proof of concept. The cost of being wrong is near zero.

Where it costs more than it saves

• Business rules with financial consequence. Tax calculation, reconciliation, pricing. The output looks right, reads plausibly, and verifying it demands the same reasoning that writing it would have — without the benefit of having thought the problem through.
• Debugging a system you know. Here your mental model is the fastest tool available, and consulting the assistant interrupts the reasoning that was already converging.
• Architecture decisions. Models are trained on what is common, and what is common is the elaborate stack. Ask for an architecture and you get the internet's average, which favours more layers — the opposite of the argument in Single-File Architecture.
• Anything where plausibility is dangerous. Wrong code that looks right is worse than code that does not compile, because the second kind announces itself in seconds.

Measuring it in your own work

The practical point is that your impression is not evidence, and the experiment costs almost nothing:

1. Pick a recurring task type. Not any task — one that repeats often enough to compare.
2. Time ten runs with the assistant and ten without, under similar conditions. A stopwatch, not a recollection.
3. Record total time until it works, including review and correction. This is the step that most often reverses the result.
4. Count the bugs in each group thirty days later. Speed that produces defects is not speed, it is deferral.

What this is not

It is not an argument against the tool. We use one every day and would not go back.

It is an argument against deciding by feel in a domain where feel demonstrably diverges from measurement. Which is the same error the other desk of this publication documents in judgments about people: confidence and accuracy are different variables, and the first rises more easily than the second. We made that case in Thin Slices, about hiring, and it holds here for exactly the same reason.