AIの能力やリスクを科学的に評価する非営利の研究機関「MERT(Model Evaluation and Threat Research)」は、最新の実験により、AIコーディングツールの使用によって、開発者の生産性が19％低下していたと報告しています(Second Thoughts)。MERTの実験は、主要なOSSプロジェクトに関わる経験豊富な開発者16名を対象としたもので、2025年春(2月〜6月)に、実際のプロジェクト環境で行われました。各自が「1〜2時間で完了する作業」を合計246件選定し、ランダムに「AI使用可」と「AI使用不可」に振り分けます。AIツールとしては、Cursor ProやClaude 3.5/3.7 Sonnetなどが使われています。この条件のもと以下のような方法で生産性が測定されました。各課題に対して事前に所要時間を予測完了後は実際の所要時間を自己申告＋画面録画で記録「AIあり vs なし」で生産性(所要時間)を比較結果はAI使用時は平均して19％作業時間が増加していて、生産性が低下していたというものでした。しかも興味深いことに参加者は「AIで作業が20％速くなった」と思い込んでいて、認知のズレがあったことがわかります。なぜ遅くなったのか？生産性が低下した理由に関しては、AIコードの品質が低く、レビューや修正に時間がかかること、AIとの「試行錯誤」の繰り返しで集中力や流れが途切れること、最終的にAIコードを捨てて自分で書き直す場面も多いことなどがあげられていて、実際、Cursorから生成されたコードは約39％しか採用されなかったそうです。なお実験に関する「反論」つぶしも行われています。ジョン・ヘンリー効果では？: 参加者がAIなしタスクで意図的に努力した可能性を想定するも、実際はタスク数が多く、後半で効果が薄れるはずがそうならなかったためこの仮説はあてはまらない。AIを使ってなかったのでは？: AI使用可のタスクでも実際には使われていない可能性を想定。実際はAI使用可タスクのうち84％の画面録画でAIが確認された。使用実績は十分。AI禁止タスクでこっそり使っていたのでは？: ルール違反(チート)でAIが使われていたのではという想定。画面録画とインタビューにより確認。違反はごく少数で結果に影響なし。予測時間がそもそも甘すぎたのでは？: 開発者が見積もりを甘く見ていた可能性。実際はすべての見積もりは、AI使用可／不可が決まる前に行われたため、AIによる偏りはなし。タスク定義が偏っていたのでは？: 「AI向きのタスク」がAI使用可側に多かった可能性。全タスクは事前に分割・定義済みで、ランダム割当なため偏りなし。完了しなかったタスクで結果が偏っていないか？: めんどうなAIなしタスクを放棄していたら結果がゆがむ。未完了タスクは13件のみ、しかも両条件に均等に分布していたため影響なし。ツールが古かったのでは？: Cursor Pro、Claude 3.5/3.7 Sonnetなど当時の最新ツールを使用していたため問題ない。自己申告の作業時間が不正確だった可能性: 画面録画時間やレビュー前までの記録と照合し、同様の傾向を確認。AIが効果を発揮づらい条件が揃っていた？ただし今回の実験は、成熟したコードベースで作業する、経験豊富な開発者のみを選抜しているため、AIが効果を発揮し辛い条件が揃っていたとも考えられます。スキルの高い開発者は、もともと高い基準で効率的に作業でき、またOSSプロジェクトの厳格なスタイルガイドにAIが対応するのも簡単ではないからです。とはいえ、実験は「AIを使えば速くなる」という思い込みに一石を投じるもので、Hacker NewsやRedditにはさまざまな意見が寄せられています。「CopilotやCursorは便利だが、本質的な問題解決には向いていない」という否定的なコメントのほか、ツールの使い方次第で結果は変わるもので「METRの参加者は使い方が最適化されていなかったのでは？」あるいは「METRの条件はAIに不利すぎる」というコメントも寄せられています。