# Twelve Ways to Be Wrong About AI-Assisted Coding

# Twelve Ways to Be Wrong About AI-Assisted Coding

Suppose your manager asks you to demonstrate that the AI coding tools your company signed up for are worth the subscription cost. Would you measure lines of code generated, or tickets closed? Or send out a survey asking whether developers feel more productive? Each of those approaches is flawed in a different way.

> Note: this post is about how people are assessing AI, not about LLM-assisted coding itself; with a little rewording these criticisms could apply to a lot of claims made about agile development, TDD, and other practices. Software engineering would be a lot further ahead if we had let our peers in the human sciences teach us how to study these things properly. The author offers a one-day [workshop](https://third-bit.com/notwrong/) and a [one-hour talk](https://third-bit.com/notwrong/lecture/slides.html) on the research methods.

## 1. Counting Lines of Code Generated

Lines of code is one of the oldest proxy metrics. LLMs generate more code, not necessarily better outcomes: a 40% increase in lines per developer measures verbosity, not productivity. Deleting 2000 tangled lines and replacing them with 200 clean ones is an improvement that looks like a loss on this metric [Sadowski2019]. More code means more to read, maintain, and debug — a future burden that never appears in the line count.

## 2. Timing Artificial Tasks

A widely cited study found developers using GitHub Copilot completed a task 55% faster [Peng2023]. The task was implementing an HTTP server in JavaScript from scratch in ninety minutes, with no other obligations. Real development involves navigating a large codebase you did not write, ambiguous tickets, coordinating with colleagues, meetings. Speed on a greenfield toy task does not predict any of that. A randomized controlled trial with experienced open-source developers found the opposite of what participants predicted: AI tools increased task completion time by 19% [Becker2025].

## 3. Before/After With No Control Group

Start using LLMs in January; by June PRs ship faster, so the tools must be working. But you also hired twelve engineers, refactored CI, and switched cloud provider. Without a group that did not adopt the tools you cannot separate the effect of LLMs from everything else. Internal validity requires a credible counterfactual.

## 4. Asking Developers If They Feel More Productive

"87% of developers report feeling more productive" [Liang2024] is misleading for three reasons: the Hawthorne effect (people work differently when observed), the novelty effect (new tools feel faster, fades within weeks), and social desirability bias (respondents say what they think the survey wants, especially when management chose the tool).

## 5. Counting Commits, Pull Requests, and Tickets

In 2023 McKinsey proposed measuring individual productivity via counts of commits, PRs, and code reviews [McKinsey2023]. Goodhart's Law: when a measure becomes a target it ceases to be a good measure [Goodhart1984]. Track commit count and developers make more, smaller commits; track ticket counts and tickets get split. The numbers improve while the work does not [Beck2023]. Activity is not output; output is not value.

## 6. Measuring Only the Easy Half

Code generation is easy to measure. The hard half: reviewing generated code, debugging confidently wrong suggestions, security vulnerabilities from plausible-but-insecure code, technical debt. A study found a substantial fraction of Copilot code contained security vulnerabilities, and developers under time pressure accepted insecure suggestions at higher rates [Pearce2022]. A 2025 evaluation of five major LLMs found none produced web app code meeting industry security standards [Dora2025]. A large-scale analysis of over 300,000 AI-authored commits found more than 15% introduce at least one quality issue, and nearly a quarter of those persist long-term [Liu2026].

## 7. Treating Adoption Rate as a Success Metric

"90% AI tool adoption across engineering" is a procurement outcome, not a productivity outcome. Adoption measures whether the tool is installed and opened — not whether suggestions are useful, accepted thoughtlessly, or correct. A study of IBM's enterprise AI coding assistant found net productivity increases were not experienced uniformly across the user base [Weisz2025].

## 8. Comparing Volunteers to Non-Volunteers

Comparing developers who chose to use LLMs against those who did not compares two populations, not two conditions. Early adopters are more motivated, more comfortable with new tooling, more likely already high performers — selection bias. This is the most common design flaw in industry AI reports because it is the cheapest study to run. A two-year longitudinal study at a large IT org found Copilot users were consistently more active than non-users even before it was introduced [Stray2026].

## 9. Measuring the Individual Instead of the System

If AI helps write code 30% faster but time from ticket to production does not change, the bottleneck was not writing code. More code means more to review. An empirical study found AI boosted output for less-experienced contributors, but senior developers saw a 19% decline in their own productivity as they absorbed a 6.5% increase in code review load from AI-generated code [Xu2025]. Optimizing one pipeline stage while ignoring the rest is a systems-thinking failure [Forsgren2021].

## 10. Measuring During the Novelty Period

A four-week study that finds a boost has found a four-week boost. The novelty effect inflates observed performance. Effects that matter emerge over months: skill atrophy, technical-debt accumulation, changes in collaboration. An analysis of 807 open-source repos adopting Cursor found exactly this: a large but transient velocity increase alongside a substantial and persistent increase in code complexity and static-analysis warnings [He2026].

## 11. Treating Suggestion Acceptance Rate as a Quality Signal

Acceptance measures whether generated code looked plausible enough to press Tab — not whether it was correct, secure, or maintainable. Developers under time pressure accept more, including insecure ones [Pearce2022], so a tight deadline raises acceptance for the wrong reasons. An enterprise study of 400 developers found a 33% average acceptance rate alongside high satisfaction, but tracked no measure of correctness or security of accepted code [Bakal2025].

## 12. Comparing AI to Nothing

Studies comparing AI-assisted developers to a control using nothing chose a baseline that does not exist in practice. Developers without LLMs use documentation, colleagues, and time thinking through the problem. The relevant question is whether LLM tools outperform the alternatives developers already have — a comparison rarely made [Peng2023]. A weak baseline makes any tool look good.

## Key References

- Peng2023 — Copilot 55%-faster claim (arXiv:2302.06590)
- Becker2025 — RCT, AI increased completion time 19% (arXiv:2507.09089)
- Xu2025 — senior devs -19% productivity, +6.5% review load (arXiv:2510.10165)
- He2026 — Cursor: transient velocity, persistent complexity (MSR '26)
- Liu2026 — 300k+ AI commits, >15% quality issues (arXiv:2603.28592)
- Pearce2022 — "Asleep at the Keyboard?" Copilot security (IEEE S&P 2022)
- Dora2025 — five LLMs, none meet web security standards (arXiv:2504.20612)
- Goodhart1984, Sadowski2019, McKinsey2023, Liang2024, Weisz2025, Stray2026, Bakal2025, Beck2023, Forsgren2021