Twelve Ways We Get AI-Assisted Coding Wrong

Current methods for measuring the value of AI coding assistants systematically produce wrong conclusions. Activity metrics like lines of code, commit counts, and ticket counts are easily gamed once they become targets and do not guarantee quality. Acceptance rates for suggestions and adoption rates only signal that a tool looks plausible or has been deployed—they have nothing to do with correctness, security, or maintainability.

4 Fundamental Flaws in Experimental Design:

• Timing toy tasks: A GitHub Copilot study reported a 55% speed improvement on a 90-minute HTTP server implementation, but real development involves navigating legacy codebases, ambiguous requirements, and team coordination. Conversely, a randomized controlled trial with experienced developers found that completion time increased by 19% when using AI tools
• Before/after comparisons without control groups: When hiring, CI refactoring, and infrastructure changes happen simultaneously during the same period, the LLM's effect cannot be isolated
• Comparing voluntary users vs. non-users: Early adopters tend to be more experimentally inclined to begin with and are likely already high performers. A 2-year tracking study at a large IT organization found that users were already more active before tool adoption
• Weak baseline (AI vs. nothing): Real developers use documentation, colleagues, and thinking time. The important question is whether LLMs outperform existing alternatives

Fatal Gaps in Measurement Scope:

LLMs make code generation faster (the easy half), but review time, debugging costs, security vulnerabilities, and technical debt go unmeasured (the hard half). A significant portion of code generated by GitHub Copilot had security vulnerabilities, and the acceptance rate of unsafe suggestions increased under time pressure. In a 2025 evaluation of 5 major LLMs, none produced web application code that met industry security standards.

An analysis of over 300,000 AI-generated commits found that more than 15% introduced at least one quality issue, and a quarter of those remained in the codebase long-term. An analysis of 807 open-source repositories after Cursor adoption found that development speed temporarily increased after adoption, but code complexity and static analysis warnings continued to increase.

Ignoring System-Level Bottlenecks:

Even if individual coding speed improves by 30%, if the team's ticket-to-production lead time remains unchanged, the bottleneck was never code writing. Empirical research found that AI tools increased junior output, but senior developers' own productivity dropped by 19% as their AI-generated code review load increased by 6.5%.

Time Distortion and Novelty Effects:

Self-reports like "87% of developers are more productive" are contaminated by the Hawthorne effect, novelty effect, and social desirability bias. A 4-week study shows only a 4-week effect; skill degradation, technical debt, and changes in collaboration require long-term observation.

Conclusion:

Productivity cannot be reduced to a single number. Without control groups, realistic baselines, control for selection bias, long-term observation, and system-level metrics, it's impossible to distinguish the effects of AI tools from other changes. Software engineering needs to take human-science research methodology more seriously.

The author is one of the founders of Software Carpentry, and a METR follow-up study effectively failed due to selection bias as developers refused to work without AI.