Does AI coding assistance actually make you worse?

In early 2025, METR ran a randomized controlled trial with 16 experienced open source developers working on their own repositories, projects averaging over 22,000 GitHub stars and a million lines of code. Each of 246 real tasks was randomly assigned: AI tools allowed, or not. With AI allowed, developers took 19% longer to finish.

That number gets quoted a lot. The part that should bother you is the other number. Before the study, those same developers predicted AI would make them 24% faster. Afterward, having just lived through the slowdown, they estimated it had sped them up by about 20%. They were slower and they walked away convinced of the opposite.

If you use AI assistants daily and your evidence that they're working is that it feels like they're working, this result is aimed directly at you. It doesn't prove AI makes you worse, and METR itself has since flagged the headline slowdown as out of date. What survives the caveats is narrower and more uncomfortable: for the one group of experts anyone has measured this carefully, felt productivity and measured productivity pointed in opposite directions.

What the METR study actually showed

The setup matters, because it was unusually honest. These weren't students solving LeetCode puzzles. They were maintainers with an average of five years on their specific repository, doing issues from their own backlog, using Cursor with Claude 3.5 and 3.7 Sonnet, close to state of the art at the time. Screen recordings were checked for compliance. The 19% slowdown survived that scrutiny.

METR's own writeup is careful about what this does and doesn't generalize to, and you should be too. Sixteen developers is a small sample. The setting was maximally unfavorable to AI: experts working in large, mature codebases they know intimately, with high standards for what gets merged. Someone writing boilerplate in an unfamiliar framework, or spinning up a greenfield service, is in a different regime, and the study says nothing about them. And the result has aged: the study page now carries a prominent notice that it no longer reflects current AI productivity, and METR's February 2026 update reports weak evidence, muddied by self-selection in who took part, that developers do see speedups with more recent tools. The 19% figure is a snapshot of early 2025, not a verdict on your setup today.

The perception gap comes from those same 16 people, so it inherits every one of those limits; you can't discard the caveats on the slowdown and keep the finding you happen to like. What it still shows is that, for this group, "it feels faster" turned out to be fully compatible with "it was measurably slower." That should at least lower your confidence in your own impressions, which for most of us are the only measurement we've ever done.

The cognitive debt study, and its limits

The other paper that gets waved around is MIT Media Lab's "Your Brain on ChatGPT". Fifty-four participants wrote essays across multiple sessions, split into an LLM group, a search engine group, and a brain-only group, with EEG measuring neural connectivity. The LLM group showed the weakest connectivity, reported the least ownership of their work, and, most memorably, a large majority couldn't accurately quote from an essay they had finished writing minutes earlier. The other groups mostly could.

Before you extrapolate that to your career, look at what it measured. Essay writing is not coding. The sample was small, recruited around Boston-area universities, and mixed: students, but also postdocs, research scientists, and working software engineers. At the time of the media cycle it was a preprint, not peer-reviewed work. "Cognitive debt" is the authors' framing, not an established construct. Treating this as proof that Copilot is dissolving your brain is exactly the kind of unearned certainty this topic attracts from both directions.

What the study does offer is a plausible mechanism, and it lines up with much older memory research: material you produce yourself tends to stick better than material you merely read, the generation effect that Slamecka and Graf documented in 1978. How far that carries from word lists in a lab to accepting an autocomplete suggestion is an open question, but any engineer who has shipped an AI-written function and then, two weeks later, debugged it like a stranger's code has felt something like it. Codebase memory is a real asset, arguably the main one that separates a senior on a team from a contractor, and offloading generation plausibly erodes it. Plausibly. The long-term study on professional programmers has not been run. Anyone telling you it's settled, in either direction, is ahead of the evidence.

"Worse" is three separate questions

Part of why this debate goes in circles is that "does AI make you worse" bundles three different claims that can be true or false independently.

Speed. Task-dependent, and the honest summary is that nobody knows the average. METR's early-2025 trial showed experts in familiar code getting slower, and METR's own later data points the other way for newer tools. Meanwhile GitHub's controlled experiment found freelance developers completing a scaffolded HTTP server task 55.8% faster with Copilot. All of these can be right about their own setting. If speed is what you care about, the fix is boring: time yourself on comparable tasks with and without the tool, because if the METR sample teaches anything, it's how far felt speed can drift from measured speed.

Retention. Whether you can still produce the thing unassisted. This is where the generation-effect mechanism would bite, and where most working engineers already notice slippage. You reach for a reduce and stall on the accumulator signature. You know a recursive solution exists but your hands have forgotten the base-case reflex. None of this shows up in your output while the assistant is on, which is precisely why it accumulates quietly.

Judgement. Whether you can evaluate what the tool hands you. This one matters most, because the standard defense of AI-heavy workflows is "I review everything." The industry-wide trends are at least worth a look. GitClear's analysis of 211 million changed lines of code found duplicated code blocks rising sharply through 2024, with copy-pasted lines exceeding moved lines for the first time in their dataset. Moved lines are a proxy for refactoring, so their decline suggests code is being added faster than it's being consolidated. Be careful with what this does and doesn't establish: GitClear can't tell which lines an AI wrote, and rising duplication doesn't prove reviewers are asleep. It's a correlation with the years assistants went mainstream, not a causal finding. It is, however, the direction you'd expect if more generated code were getting merged with less consolidation behind it.

Developers seem to sense the tension. In the 2025 Stack Overflow survey, 84% of respondents use or plan to use AI tools, yet 46% actively distrust the accuracy of AI output against 33% who trust it, and 66% name "solutions that are almost right, but not quite" as their top frustration. Usage climbing while trust falls is a strange equilibrium, and it puts all the load on the reviewer's judgement. Judgement is a fundamentals problem. You can only catch the subtly wrong async code if you still hold the event loop model in your head, and you only hold it by using it.

What to actually do about it

If you half-suspect this applies to you, here is what follows from the evidence rather than from vibes.

Stop trusting your self-assessment. This is the most direct lesson the METR data offers, small sample and all. Pick a few representative tasks over the next month and actually time them with the assistant on and off. You may find the tool earns its keep. You may find what the METR developers found. Either way you'll know something instead of feeling something.

Keep a no-AI lane. Choose some category of work, a module you own, a class of bug, one day a week, and write it by hand. What this buys you is a recurring, honest reading of what you can still do unassisted, which your normal workflow never surfaces. If the no-AI lane starts feeling alarming, that's information you'd never get otherwise.

Predict before you accept. Before reading a suggestion, decide what you would have written, then diff it against what appeared. This converts passive acceptance into active production, the same self-generation the memory literature keeps finding sticky. It costs seconds and it keeps you the author instead of the approver.

Review generated code like a stranger wrote it. Because functionally, one did. Whatever is driving the duplication trend in GitClear's data, those near-identical blocks made it into commits somewhere, and each one presumably looked fine in isolation to somebody. Ask the questions you'd ask a new hire's PR. Does this already exist in the codebase? Why this approach? What happens on the empty input?

Put fundamentals on a schedule instead of hoping. Skills you don't exercise decay on their own timetable, not yours, and "I'll do some LeetCode when it gets bad" is a plan nobody executes. Testing yourself and spacing that practice over time were the two techniques rated most broadly effective in Dunlosky and colleagues' review of the learning literature, and that's the model Unrot is built on: pick the stacks you want to keep sharp, do a 2-5 minute session a day, let spaced repetition decide what you're about to forget. To be clear about the limits, five minutes of recall drills will not substitute for building real things, and it won't fix a workflow where you never write code at all. What it does is keep the retrieval paths alive so that when you do write code, or review generated code, the fundamentals are still there to check against. You can try a session without an account and judge whether it's worth a streak.

The honest answer

Does AI coding assistance make you worse? Measured over careers, nobody knows yet. The studies are small, the settings are narrow, the most-quoted result has already been superseded by its own authors, and the long-term data doesn't exist. What's better established is narrower and, for a working engineer, more useful: felt productivity and measured productivity can come apart, industry-wide duplication is trending in a direction consistent with weaker consolidation, and a plausible mechanism for skill decay sits right there in how these tools get used.

The doom-versus-fine argument will run for years without your input. The useful move in the meantime is smaller. The one group we've measured carefully was wrong about themselves, so check rather than assume.