AI Coding Assistant Productivity: The Perception Gap (2026)

In the middle of 2025, sixteen experienced open-source developers agreed to let a research lab put a stopwatch on them. AI coding assistant productivity finally got the experiment it had been missing: real repositories, real issues, and a coin flip deciding which tasks allowed AI.

Before starting, the developers forecast that AI tools would speed them up by 24%. After finishing, they estimated the tools had sped them up by 20%.

The stopwatch disagreed with both numbers, because on the tasks where AI was allowed, they took 19% longer.

I design motivation systems for a living, and that result is the cleanest evidence I have seen for the argument I made in my hub post on gamification and AI: when AI absorbs a human execution loop, the felt experience improves while something underneath quietly erodes.

In this arena, the thing eroding is a developer’s ability to tell progress from motion.

What follows is my field manual for AI-assisted engineering. We will trace where the fast feeling comes from, which Core Drives it feeds on, what the delivery data shows at team scale, and how I would redesign the motivation loop so that the feeling and the shipping point in the same direction.

Speed Run Notes

• The gap has been measured directly. In a 2025 randomized trial, experienced developers using AI tools took 19% longer per task while estimating that the same tools had made them 20% faster.
• The reward signal sits in the wrong place. GitHub’s research found that acceptance rate best predicts how productive developers feel, so the win moment fires long before anyone learns whether the code survived.
• The codebase keeps the honest ledger. Duplicated blocks of five or more lines grew eightfold during 2024, and copy-pasted lines outnumbered moved lines for the first time on record.
• Fear keeps the tools open. Adoption is near 90% while favorability dropped from 72% to 60% in one year, a usage-up, enjoyment-down pattern that marks Black Hat motivation at work.
• The fix is motivational design. Move the celebrated moment from accepted suggestion to merged-and-stable work, protect deliberate reps for mastery, and track the calibration gap between felt speed and measured speed.

Author Credibility: Yu-kai Chou

Yu-kai Chou created the Octalysis Framework after studying gamification since 2003 — years before the term entered mainstream vocabulary. As a Human-Systems Architect & Behavioral Designer, his framework has been applied by LEGO, Microsoft, Porsche, Coca-Cola, Salesforce, and MrBeast, impacting over 1.5 Billion Users.

Chou has taught the Octalysis methodology at Harvard, Stanford, Yale, Tesla, Google, BCG, and IDEO.

His work has been cited by Harvard, Stanford, MIT, Forbes, Wall Street Journal, Wired, US Department of Energy, NIST, NSF, NCBI, US Department of Education, ClinicalTrials.gov, and Google Scholar — with 3,700+ more academic publications. Explore his books here.

The Experiment That Measured the Feeling

The most important finding in AI coding research so far is a calibration failure: developers who were measurably slower with AI remained convinced it had made them faster.

That study came from METR, a research nonprofit that evaluates AI capabilities. Its design was unusually honest for this field.

Sixteen experienced developers worked on large open-source repositories they had contributed to for years, codebases averaging more than 22,000 stars and over a million lines. They brought 246 real issues: bug fixes, features, refactors.

Each issue was randomly assigned to either allow or forbid AI tools. When AI was allowed, most developers worked with Cursor Pro running Claude 3.5 and 3.7 Sonnet, frontier models at the time.

Three numbers came out of that setup. The developers predicted a 24% speedup before starting. They reported a 20% speedup after finishing. The measured result was a 19% slowdown.

Sit with the second and third numbers together, because they came from senior contributors estimating their own recent performance on their own codebases, immediately after doing the work.

Their self-report landed roughly 39 percentage points away from their own timestamps.

Now for the part an honest field manual has to include. In February 2026, METR published an update: a larger follow-up with 57 developers and over 800 tasks, run on late-2025 tools, found central estimates pointing toward speedups of around 18% for returning developers and 4% for new ones, with confidence intervals wide enough to include zero in both cases.

METR itself calls that weak evidence, because the follow-up ran into a problem that should fascinate anyone who studies motivation. Developers increasingly refused to participate rather than work without AI, and surveys found 30% to 50% of them withheld tasks they did not want to do unaided.

Read that as a motivation researcher rather than as a productivity researcher. Within about a year of these tools maturing, experienced engineers would rather sit out a paid study than code without them.

So the tools are improving, and the honest summary of the measurement record is this: the direction of the speed effect is now uncertain and probably improving, while the perception gap, the 39-point miss, stands as the replicated, uncontested core.

People cannot feel their own velocity in AI-assisted work. That is the design problem this post is about, because a motivation system built on a miscalibrated feeling eventually bills you for the difference.

The Reward Fires at the Wrong Moment

The fast feeling has a specific source: AI coding tools moved the psychological reward from verified completion to suggestion acceptance.

Think about what the old loop looked like. A developer wrestled with a problem, wrote a solution, compiled it, ran the tests, and watched it work.

That final moment carried the payoff, and it carried information. The code running correctly was both the reward and the proof that the developer’s model of the problem was right.

Behavioral scientists following Albert Bandura call this kind of moment a mastery experience, the strongest known builder of self-efficacy. The feeling of competence stayed calibrated because it was earned at the same instant the evidence arrived.

AI assistants quietly relocated that moment of payoff. The new micro-reward arrives when a suggestion appears and you accept it: a small, frequent, satisfying click of apparent progress, dozens or hundreds of times a day.

GitHub’s own research team, studying Copilot usage across thousands of developers, found that acceptance rate of shown suggestions predicts perceived productivity better than any alternative measure they tested. GitHub has also reported, in its 2023 research, that roughly 30% of Copilot suggestions get accepted on average.

Hold those two findings next to each other. The moment that makes developers feel productive is the acceptance, and acceptance happens long before anyone learns whether the code was correct, maintainable, or even kept.

In Octalysis terms, the tools built a tight loop around the feeling of progress and left the verification of progress outside the loop. The reward signal now fires on a claim about the work instead of on the work.

Game designers will recognize the pattern, because suggestion streams also pay out on a variable schedule. Sometimes the completion is exactly right, sometimes close, sometimes absurd, and that unpredictability keeps attention locked in the same way any variable-reward mechanic does.

None of this required bad intent. Tool makers optimized for the metric they could see, acceptance, and human brains did what brains do with fast, frequent, variable rewards: they learned to want the loop.

Core Drive 2: The Accomplishment Illusion

Core Drive 2 (CD2): Development & Accomplishment runs on evidence of your own growth, and AI-assisted coding floods the evidence channel with output you did not produce.

Within the Octalysis Framework, Core Drive 2 (CD2): Development & Accomplishment is the engine behind progress bars, skill trees, and the quiet satisfaction of a hard task finished well. It needs two ingredients: a challenge that could have defeated you, and proof that it did not.

AI assistance changes both ingredients at once. The challenge shrinks, because the machine absorbs the hard middle of the task.

The proof inflates, because the visible output grows. A developer who produced 400 lines of plausible code in an afternoon has a screen full of accomplishment-shaped evidence, whatever the eventual fate of those lines.

This is why the METR developers could be wrong about their own speed by 39 points and stay wrong after the fact. The feeling of accomplishment was tracking generated volume and accepted suggestions, two quantities AI inflates on contact, rather than tracking resolved problems per hour, which the stopwatch said had declined.

Effort itself used to be the calibrating signal. When finishing something hard required sweat, the sweat told you roughly how much you had done, the way a runner’s legs report the distance even without a watch.

AI-assisted work removes the sweat while keeping the finish line, so the internal odometer loses its best input. What remains is a sense of motion with nothing underneath it to check against.

I want to be precise about what I am claiming here, because the research record on raw speed is mixed, and the tools keep improving. The durable problem is the calibration, and a CD2 loop with corrupted calibration is worse than a weak one.

A developer with an accurate sense of slow growth will seek harder challenges and build real skill. A developer with an inflated sense of fast growth will coast on the feeling, and the gap only becomes visible when the machine is absent: the outage, the novel bug, the system design interview, the problem no model has seen.

Core Drive 3: Feedback Loops That Close Too Early

Core Drive 3 (CD3): Empowerment of Creativity & Feedback requires that your choices produce consequences you can observe, and AI-assisted workflows keep declaring victory before the consequences arrive.

Core Drive 3 (CD3): Empowerment of Creativity & Feedback is the drive behind creative flow: try something, see the result, adjust, try again. For it to function, the feedback has to be real and reasonably prompt.

The agent that announces a task complete is delivering a claim, and the true feedback, whether the code integrates, passes review, and holds up in production, arrives hours or days later, often landing on a different person.

Stack Overflow’s 2025 survey of more than 49,000 developers measured what living inside that delay feels like. The top frustration, named by 45% of respondents, was AI solutions that are almost right, but not quite.

And 66% of developers said they are spending more time fixing almost-right AI-generated code than they used to spend on the equivalent work.

Almost-right is the most expensive wrongness there is, because it survives the glance. Obviously broken code announces itself at compile time, while almost-right code sails through the acceptance click, through the demo, sometimes through review, and detonates where fixing it costs the most.

There is a second CD3 cost that compounds quietly: debugging code you wrote exercises your own mental model, while debugging plausible code a machine wrote is closer to archaeology. You reconstruct intent you never had.

Meanwhile the unclosed loops pile up. Psychologists have known since the 1920s that unfinished tasks occupy the mind rent-free, the Zeigarnik effect, and an AI-saturated workflow multiplies exactly that inventory: branches awaiting review, agent output awaiting verification, fixes awaiting the fix for what they broke.

I wrote about the extreme version of this in my piece on AI morale overload, where developers running many agents at once end the day with enormous activity and no single moment of closure.

CD3 pays out only when you observe the consequence of your own judgment, and a workflow that postpones every consequence starves the drive while looking busy.

Core Drive 8: The Fear That Keeps the Tools Open

If the accomplishment is thinner and the feedback is slower, why does adoption keep climbing? Because the third drive in this stack is Core Drive 8 (CD8): Loss & Avoidance, and fear scales beautifully.

Core Drive 8 (CD8): Loss & Avoidance motivates through what you might lose: your edge, your relevance, your job. In the Octalysis Framework it sits among the Black Hat drives, the ones that produce urgent action and, over time, exhaustion.

Look at the adoption numbers through that lens. The 2025 DORA research from Google found that nearly 90% of technology professionals now use AI in their work.

Over the same period, Stack Overflow measured positive favorability toward AI tools falling from 72% to 60% in a single year, and trust in the accuracy of AI output falling from 40% to 29%.

Usage rising while enjoyment and trust fall is the signature I teach companies to watch for in White Hat and Black Hat gamification analysis. People who stay because something feeds them behave differently from people who stay because leaving feels dangerous, and the second group shows exactly this pattern of rising compliance alongside falling affection.

The fear has three layers in engineering organizations right now. Individual developers fear falling behind peers who prompt faster.

Managers fear reporting lower AI adoption than the next team over. Executives fear telling a board they moved slowly on the decade’s defining technology.

Every layer passes its anxiety downward, and the result is adoption mandates measured in usage metrics, the one number that says nothing about whether the work got better.

I traced the organizational endgame of this pattern in my analysis of why AI-fluent employees quit first. The engineers most capable with these tools are the ones whose CD2 and CD3 loops hollowed out earliest, and CD8 pressure holds them in place right up until a better offer makes the fear irrelevant.

Black Hat motivation does work in the short run, and it will ship the quarter.

It also borrows against the asset an engineering organization can least afford to spend, which is the supply of people who still find the work itself rewarding.

What the Delivery Data Shows at Team Scale

Individual feelings can argue; aggregate delivery data keeps books. Three independent datasets now tell a consistent story about where AI-assisted engineering actually stands.

Start with DORA, the long-running Google research program on software delivery. Its 2024 report found that environments adopting AI showed a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, and that 39% of respondents had little or no trust in AI-generated code.

In other words, the 2024 data showed teams producing code more easily while delivering working software slightly worse.

The 2025 DORA report shows movement, and it deserves honest reporting just like the METR update did. The relationship between AI adoption and throughput turned positive this time, while delivery instability continued to rise, and the researchers found no evidence that AI-driven speed was offsetting that instability through faster repair.

Their headline conclusion is the one I would frame and hang in every CTO’s office: AI acts as an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.

An amplifier is a motivation-neutral technology. Whatever loop your team already runs, healthy or hollow, AI runs it louder.

Then there is the codebase itself, which no survey can flatter. GitClear’s analysis of 211 million lines of code found that code blocks with five or more duplicated lines increased eightfold during 2024.

The same analysis recorded a 39.9% decrease in moved lines, the signature of refactoring, and 2024 became the first year on record in which copy-pasted lines outnumbered moved ones.

Refactoring is what care looks like in a version-control log. It is the work of someone who owns a codebase’s future rather than its next diff.

So place the three datasets side by side. Developers report feeling dramatically more productive, with over 80% of DORA respondents saying AI increased their productivity.

Delivery stability keeps degrading, duplication is exploding, and the maintenance behaviors that keep systems alive are in retreat. The feeling and the ledger have decoupled, at industry scale, in exactly the direction the METR experiment predicted from sixteen developers.

That decoupling is what a motivation vacuum looks like from orbit. Each layer of the system is optimizing a feeling: developers for the acceptance click, managers for the adoption dashboard, executives for the AI narrative.

Nobody in that chain is holding the loop that used to connect effort to verified outcome, and the codebase quietly records the difference.

The Octalysis Redesign for AI-Assisted Engineering

The goal of the redesign is one sentence: move the moment of celebration back to the moment of verified truth, without giving up the machine’s speed.

None of what follows requires abandoning AI tools. I use them constantly, and the evidence above suggests their raw capability keeps improving.

Every pattern below is about relocating rewards, so the Core Drives feed on real signal again.

1. Move the win to merged-and-stable

Decide, as a team, that the celebrated unit of work is a change that merged and then survived a defined stability window, and make that the thing your rituals notice. Stand-ups report survivals rather than generations.

Demo days show what held, and the team’s progress bar advances on it. This single change points Core Drive 2 (CD2): Development & Accomplishment back at verified reality, because the accomplishment loop now closes where the truth lives.

The acceptance click can keep its small dopamine. It just stops being the scoreboard.

2. Make the calibration gap a visible score

Before each nontrivial task, have the developer log a thirty-second estimate of how long it will take. Compare against actuals at the end of the week.

The METR developers missed their own speed by 39 points because nothing in their environment ever showed them the gap. A team that tracks estimate accuracy turns calibration itself into a skill with a progress curve, which is CD2 working on the exact muscle AI-assisted work atrophies.

Done in the open and without blame, it also becomes a shared game. The best-calibrated engineer on the team holds a title worth having.

3. Protect deliberate reps

Pick the capabilities your team cannot afford to lose, the debugging instinct, the systems design judgment, the reading of unfamiliar code, and schedule regular work on them without AI, the way lifters schedule heavy days. One no-AI bug hunt per sprint changes nothing about delivery and everything about skill retention.

The point is choosing deliberately which loops stay human. Mastery needs repetitions, and a team that hands every repetition to the machine is deciding, by default and without noticing, to stop training.

4. Rebuild review as the craft loop

If verification is where truth enters the workflow, then review is now the craft, and it deserves the motivational design that writing code used to get. Require every AI-assisted change to carry a short statement of intent from its human author: what this change does, why this approach, what would break it.

Writing that paragraph forces the comprehension that acceptance clicks skip, and it hands reviewers real feedback to respond to. Core Drive 3 (CD3): Empowerment of Creativity & Feedback revives the moment reviews become conversations about judgment rather than scans of plausible diffs.

Pace it like flow theory suggests: reviewers need challenge matched to skill, so route gnarly changes to people who find them interesting rather than spreading everything thin.

5. Retire the fear messaging

Audit every piece of internal AI communication and strike the survival framing: the falling-behind warnings, the adopt-or-else subtext, the usage leaderboards that shame the bottom quartile. Replace them with exploration structures that run on curiosity and growth, such as opt-in guilds, internal show-and-tells of AI experiments that failed instructively, and time budgeted for tool exploration with no adoption quota attached.

Core Drive 8 (CD8): Loss & Avoidance will remain in the room, because the labor market put it there. Leadership’s choice is whether to amplify it, and every amplification buys this quarter’s usage metrics with next year’s resignation letters.

6. Put the scoreboard before the tooling

Most engineering organizations adopted AI tools first and asked what to measure second, which is backwards for any motivation system. The Strategy Dashboard process I use with clients starts from business metrics and desired actions, then works backward to feedback mechanics.

Run that exercise for your AI adoption before the next tool purchase. If the desired outcome is maintainable software shipped faster, then the metrics, rituals, and rewards should touch maintainability and shipping, and nothing in the stack should pay out on raw usage.

What to Measure Instead

A simple test for any engineering metric in the AI era: does it measure something a machine can inflate, or something only verified work can move?

Usage metrics, suggestions accepted, lines generated, and tasks marked complete by an agent all fail that test. Here is the replacement set I would instrument, each one tied to the drive it protects:

• Time-to-stable, measured per change: elapsed time from first commit to surviving its stability window in production. This is the honest version of velocity, and it is the number the 19% result says nobody was feeling.
• Rework share: the fraction of engineering time spent fixing, reverting, or re-prompting over AI-assisted changes. The 66% of developers fixing almost-right code are living inside this number while their dashboards ignore it.
• Calibration gap: median difference between estimated and actual task time, tracked per quarter. Watching this gap shrink is watching judgment recover.
• Duplication and refactor trend: GitClear-style structural metrics on your own codebase, reviewed quarterly, so the care ledger is visible before the interest compounds.
• Felt ownership, asked directly: whether people can describe, in their own words, what they contributed to AI-assisted work. I proposed this test in the hub post, and engineering is the easiest place to run it, because the honest answers are already circulating in private.

Notice that improvement on this scoreboard is slower and quieter than improvement on a usage dashboard, and that the slowness is deliberate.

Real competence has always moved at the speed of verified feedback, and a scoreboard that outruns the truth has started measuring something else.

FAQ: AI Coding Assistant Productivity

Do AI coding assistants make developers slower?

The measured record is mixed and moving. METR’s mid-2025 randomized trial found experienced developers took 19% longer on familiar codebases with early-2025 tools, while its late-2025 follow-up pointed weakly toward speedups, and the 2025 DORA report found a positive relationship between AI adoption and throughput alongside still-rising instability. The replicated constant across all of it is that developers misjudge their own speed with AI, so any team that wants the answer for itself has to measure rather than ask.

Why do developers feel faster with AI even when the clock disagrees?

Because the psychological reward moved from verified completion to suggestion acceptance, which pays out dozens of small wins per day before any code is proven correct. GitHub’s research found acceptance rate is the strongest predictor of perceived productivity, and effort, the signal people once used to estimate their own output, has been removed from the loop. The feeling tracks accepted suggestions and generated volume, both of which AI inflates regardless of outcomes.

What is the acceptance-rate trap?

The acceptance-rate trap is my name for a feedback loop in which the moment of reward, accepting an AI suggestion, sits upstream of the moment of truth, which is the code surviving review and production. Core Drive 2 (CD2) and Core Drive 3 (CD3) then feed on claims instead of consequences, producing confident developers, rising duplication, and slower verified delivery. Escaping it means relocating celebration and measurement to merged-and-stable work.

How should engineering teams measure AI coding assistant productivity?

Measure outcomes a machine cannot inflate: time from first commit to stable-in-production, share of time spent reworking AI-assisted changes, the calibration gap between estimated and actual task time, structural codebase health like duplication and refactoring rates, and felt ownership asked directly. Treat usage metrics as cost accounting rather than success evidence, since near-90% adoption now makes usage a measure of fear as much as value.

Should teams stop using AI coding assistants?

No, and the amplifier finding from DORA 2025 explains why that question misses the target. The same tools amplify healthy loops and hollow ones, so the productive question is which loops your team runs: where the wins get celebrated, which skills keep deliberate human reps, and whether your scoreboard pays out on verified work. Teams that redesign those loops get the machine’s speed and keep the human’s judgment.

Keep a Loop You Can Feel

Engineering spent decades learning that untested code is unproven code, and the entire discipline of CI exists because claims about software needed verification before trust. The motivation layer now needs its own CI.

Feelings of productivity are claims, and this field just produced the clearest evidence in its history that those claims fail verification: 19% slower under the stopwatch, 20% faster in the mind, and an industry whose favorability falls while its usage climbs.

The repair does not run through less AI. It runs through putting the reward back where the truth lives: celebrate what merges and survives, score your own calibration, keep the reps that build the judgment only humans carry, and let the machine be fast inside a loop a human still owns.

If you lead an engineering team, start with one change this week. Pick the single most AI-saturated workflow you have and ask the people in it what they contributed, in their own words, to the last thing it shipped.

The answers will tell you which Core Drives are still being fed, and the redesign follows from there.

I have spent over two decades building the frameworks for exactly this kind of motivational engineering. If you want the full design language, from the 8 Core Drives to the technique-level mechanics, explore my books, where the systems in this post are laid out in the depth a real redesign deserves.

Related Reading

• AI in Education Motivation: What Should Count as Learning: the same accomplishment-evidence crisis, playing out in classrooms instead of codebases.
• Buridan’s AI: Pick a Main to Escape AI Tool Paralysis: why juggling eleven AI tools fragments the feedback loops this post is trying to repair.
• Agentic Commerce: Designing for Buyers Who Aren’t Human: what happens to motivation design when the agent becomes the customer.
• Self-Determination Theory: The Complete Guide: the academic backbone for why competence needs calibrated feedback.
• AI Companion Apps, Loneliness, and the Way Back to Humans: the most personal arena of the same motivation vacuum.

WOULD YOU LIKE YU-KAI CHOU TO WORK WITH YOUR ORGANIZATION?