The Biggest Risk in AI-Assisted Coding Might Be Your Own Brain

The hardest bugs in AI-assisted development are in the human.

In 2025, METR ran a randomized controlled trial with 16 experienced open-source developers working on 246 real tasks in their own mature codebases. Each task was randomly assigned to allow or forbid AI tools. Developers forecast a 24% speedup. After finishing, they still believed AI had saved them about 20%. The measured result was that they took 19% longer with AI.

The speed question is still open. The gap between feeling and measurement is the part worth studying, and psychology has been explaining it for decades.

Follow-up Trial Update for 2026

1. Fluency feels like progress

When code appears instantly, your brain registers momentum. Watching a diff stream in feels like work getting done. The time you spend afterward on prompting, waiting, reading, correcting, and re-prompting doesn't register the same way, because it's fragmented and feels like "just cleanup."

Psychologists call the underlying effect the fluency heuristic. Things that are easy to process get judged as better and as more done. Your sense of productivity tracks how smooth the experience felt, not how much time actually passed.

What to do

Track cycle time, review time, and rework rate on AI-assisted changes versus the rest. If you can't measure it, you're relying on exactly the instinct the study showed can be wrong.

2. Reviewing is harder than writing, and we're worse at it than we think

When you write code, you build a mental model as you go. When you review AI-generated code, you have to reconstruct a model of something you didn't build, and verify it. In the METR study, developers accepted fewer than half of the AI's generations, and many made major changes to clean up what they kept. Reviewing feels passive, so people do it less carefully than it deserves.

Two well-documented effects stack here.

Automation bias: people over-trust output from automated systems, especially when it's usually right. A tool that's correct 90% of the time trains you to skim the other 10%.

Vigilance decrement: humans are bad at sustained monitoring for rare errors. Mackworth documented it in WWII radar-operator research, and it doesn't improve with intelligence or good intentions.

Lisanne Bainbridge described the core trap in her 1983 paper Ironies of Automation: the more reliable the automation, the less practiced the human becomes at catching its failures, yet the human is exactly who's left to catch them.

What to do

Don't rely on willpower during review. Make verification mechanical: tests written (or at least read) before the implementation, type checks, linters, and CI gates the model can't talk its way past. Treat "looks right" as weak evidence at best.

3. We trust confident prose

LLMs produce code with the same calm tone whether it's correct or subtly broken. Humans read confidence as competence, a bias we apply to other people too. A hallucinated API call or a plausible-but-wrong edge case arrives wrapped in the same tidy explanation as a correct one.

There's no tonal signal to calibrate on, so the signal has to come from outside: running the code, checking the docs, reading the actual library source.

What to do

Ask for verification paths, not reassurance. "How would I test that this is correct?" gets you more than "Are you sure?", which mostly produces a polite restatement.

4. The skill you stop using is the skill you need to review

Skills decay without practice. If you stop writing certain kinds of code, say regex, SQL joins, concurrency, or auth flows, you lose the fluency required to spot when the model gets them wrong. This is Bainbridge's irony again, applied to your own career.

It also hits juniors differently. Someone who never builds the underlying intuition has nothing to judge the output against. Struggle is annoying, but it's also how mental models get built.

What to do

Keep a deliberate practice zone. Write some things by hand, on purpose, especially in areas where you're responsible for correctness. Ask the model to explain why, not just what, then check the explanation.

5. The IKEA effect makes bad output hard to throw away

People overvalue things they helped build. Prompting, iterating, and steering a model toward a result creates a feeling of authorship, even if you couldn't have written or debugged the result yourself. That attachment makes it harder to discard bad output and start over, and starting over is often the cheapest move.

It also makes post-mortems awkward. "The AI did it" and "I shipped it" are both true, and only one of them is yours to fix.

What to do

Set a sunk-cost rule up front. If three rounds of prompting haven't converged, stop, write the core by hand, and use the model for the boring parts around it.

A workflow that respects how brains actually work

1. Spec first, in your own words. If you can't state the expected behavior, you can't review the output.
2. Tests before code. Even a few. They convert "looks right" into something checkable.
3. Small diffs. Review quality collapses as diff size grows, with or without AI.
4. Make the model argue against itself. Ask what would break this, then verify those claims too.
5. Own the merge. Whoever approves it is responsible for it, full stop.

The takeaway

Whatever the true speedup turns out to be, and it will likely keep shifting as tools change, the failure mode of AI-assisted engineering isn't mostly that the model writes bad code. It's that humans are predictably bad at supervising something that's usually right and always confident. The tools will keep improving, but the human side of the loop doesn't get a version upgrade.

The teams that get real value won't be the ones with the best model. They'll be the ones who designed their process around how people actually behave: measuring instead of trusting their gut, automating verification instead of relying on vigilance, and keeping their own skills sharp enough to notice when something's off.

Have you measured your own AI-assisted cycle time, or are you going on feel? I'd like to hear about what you found in the comments.