AIはオープンソース開発者を遅くする。Peter Naurはその理由を説明できる

• 最近の研究によると、オープンソース開発者が自分のよく知るコードベースでAIツールを使うと、かえって作業時間が19%増加する
• 開発者はAIが自分をより速くすると信じているが、実際には遅くなるという認識と現実のギャップが存在する
• 中核的な原因は、開発者が持つ精緻なメンタルモデル（理解の構造）とAIのあいだにある知識伝達の限界にある
• Peter Naurの理論によれば、プログラミングで最も重要なのは開発者の頭の中にある「精神的モデル」である
  • デンマークの計算機科学の先駆者であり、2005年のチューリング賞受賞者。プログラミング言語の構文を説明するために使われるBackus-Naur form (BNF) 記法に貢献した
• 長期的な観点では、プロジェクトを深く理解するために自分でコードを書きながらメンタルモデルを構築することが重要である

---

AIがオープンソース開発者を遅くする現象

• Metrの研究によると、AIツールの使用時には問題解決の速度がむしろ19%遅くなるという結果が出た
• 開発者は作業前にはAIが24%速くしてくれると期待し、作業後も実際より20%速かったと信じていた
• この研究は、自分が深く理解しているオープンソースプロジェクトを直接管理する熟練開発者を対象に行われた
• この結果をすべての開発者に一般化することはできないが、この集団ではAIツールが生産性に逆効果をもたらすことを示している
• 企業環境や、新しいコードベースに適応しなければならない一般的な開発者にとっては、AIツールが生産性向上により前向きな役割を果たす可能性がある

なぜAIは熟練したオープンソース開発者を遅くするのか

• Peter Naurの論文「Programming as Theory Building」によれば、**プログラミングの真の成果物はコードではなく、『プロジェクトに関する開発者のメンタルモデル』**である
• このメンタルモデルは、システムの理解、問題診断、効果的な改善の中核である
• LLMベースのAIは開発者のメンタルモデルに直接アクセスできず、一部の情報を与えても知識伝達の過程で本質的な損失が生じる
  • 例として、誰かに赤ちゃんを寝かしつける役目を任せるとき、明確に説明しても実際には意図と違う行動を取ることが多い
• メンタルモデルの伝達はきわめて複雑であり、AIがテキストだけでこれを吸収するのはほぼ不可能である
• したがって、自分が深く理解しているプロジェクトでAIに作業を委任すると、かえって生産性が低下する
• 開発者の豊富な文脈情報と直感的な理解は、AIが容易に置き換えられるものではない

現場でAIツールを禁止すべきか?

• 必ずしもそうではない。これは「自分でよく知り、よく理解したプロジェクトで働く人」にだけ当てはまる
• 多くの企業開発者は、すでに去ったシニア開発者のコードを保守したり、システム全体の構造を深く理解しないまま作業したりすることが多い
• こうした環境では、AIがコードベースを素早く把握し、変更を自動生成することで、短期的な生産性向上に貢献しうる
• 短期的なビジネス価値の創出と即時の効率だけを見るなら、AIツールは生産性に前向きな役割を果たしうる

メンタルモデルの構築とAI

• もしプロジェクトに関するメンタルモデルがないなら、LLMが生産性向上を助けることはありうる
• しかし、ソフトウェア開発の本質が「メンタルモデルの構築」にあるなら、AIに過度に依存するとその能力が低下する可能性がある
• 長期的にプロジェクトを深く理解し、能動的に変化させたいなら、自分でコードを書く経験が必要である
• 逆に、「とにかく動けばよい」というタイプの作業なら、AI活用は効率的かもしれない

追加の議論と結論

• 現在の水準のAIツールでは、十分なメンタルモデルを持つ開発者の生産性を向上させるのは難しい
• AIがメンタルモデルを適切に支援したり、熟練開発者の生産性を革新的に高めたりする方向性には、なお研究と発展が必要である
• 今後モデルが進化すれば、人間の開発者があえてメンタルモデルを持たなくてもよい日が来るかもしれないが、現時点では直接的な理解と学習が不可欠である
• 最終的に、AIは『自分が何をしているのかを深く理解している環境』では妨げになり、『素早い成果物が重要な環境』では生産性ツールになりうる

[paruaa]

> 開発者たちはAIが自分をより速くしたと信じているが
AIを活用したリサーチが速くなることで、より高い品質を実現できるなら、同じ作業でも品質が少し高くなるのではないでしょうか。開発者は作業後の成果物の品質に合わせて開発しようとするなら、自力で到達するよりも、AIの助けを借りて到達するほうが速いと考えているのではないでしょうか。
そもそも使わなかった場合は、もう少し限られた知識だけで実装することになるから、そう見えるのではないかという気がします。

[tested]

> 逆に、「とにかく動けばいい」という प्रकारの作業であれば、AIの活用が効率的な場合もある。

開発者に限った話ではありませんが、さまざまな志向を持つ人がいる中で、たまたま開発者をしていて、コードを書いたり読んだりすることを嫌ったり怖がったりし、体系的な構造や保守性の観点で解釈するよりも、とにかく動けばいいというマインドであるほど、AIへの依存や盲信が強いように感じます。違っていたらすみません

[xguru]

AIはオープンソース開発者を遅くする。Peter Naurがその理由を教えてくれる

経験豊富なオープンソース開発者の生産性に及ぼす「AIのインパクト」を測定する

[GN⁺]

Hacker Newsの意見

• HNのみなさん、私はこの論文の著者です。
  このブログ記事は、AIが開発速度を落としうる具体的な要因のひとつを興味深く扱っていると思います。
  論文の開発者引用（C.1.5節）も参考にしてください。
  多くの人は論文を読んで、自分に当てはまる要因をひとつ見つけると、「このひとつの問題だけが遅くなる理由だ」と結論しがちです。
  ですが実際には要素は複数あります（少なくとも5つが有力で、最大9つまで排除できません。p.11の要因表を参照）。
  ひとつだけが原因だと仮定するより、多面的に原因を分析するほうが妥当です。
  自分でも実験してみる予定のある方は、ぜひ論文記載のメールアドレスに結果を共有していただければと思います。
  そして記事タイトルが「AI slows down open source developers. Peter Naur can teach us why」となっていますが、より正確には「2025年初頭、AIは経験豊富なオープンソース開発者を遅くする。Peter Naurは特定の要因にさらなる文脈を与えてくれる」くらいが適切だと思います。
  表現としては刺激が弱いかもしれませんが、正確さが重要だと考えています。
  改めてすばらしい記事に感謝します。引き続きコメントも読んでいます。
  以前の関連議論
  論文全文
  • 個人的に気になるのですが、この研究ではAI使用前後で実際の所要時間がどれだけ変わったかを、どのように信頼できる形で測定したのでしょうか。開発者にAI使用後どれだけ時間が短縮されるか予想してもらい、その後に実際の使用時間を測って差を見たのでしょうか。また、各イシューの難易度や解決に必要な時間の見積もりが難しい場合、研究チームはどのように統制したのかも知りたいです。こうした測定が本当に複雑だという点には共感します
  • 結果には共感しており、回答にも感謝します。タイトルは急進的なスタイルが好きなので変える予定はありませんが、記事内で誤解を招く表現であることは明確に修正するつもりです。自分の記事でも、研究結果の主要な寄与要因である「リポジトリへの高い開発者の習熟度」「大きく複雑なリポジトリ」「暗黙的なリポジトリ文脈」などが、この研究と軌を一にしていることを示しました。自分でもこの実験をやってみたいのですが、業務上の要件と並行しながら統制された環境を作るのは非常に難しいと感じます。短時間で完了できる明確なタスクのリストも不足しています
  • 自分がよく知っているプロジェクトで最適化済みのワークフローを変えれば、最初は遅くなるだろうと予想します。重要なのは、こうした開発者が6か月後、1年後にどうなっているかを見ることです。今回の研究は長期的な推移を示していないので、今後の研究で、同じ開発者が慣れた後に成果がどう変わるのか分かることを期待します。自分でも、これまでAIで自動化が難しかった多くの作業をスクリプト化できると体験しています。常に「これは時間に見合う価値があるのか？」という問いを持つべきです
    xkcd タイムマネジメント漫画
  • 「2025年初頭、AIが経験豊富なオープンソース開発者を遅くする」という表現も一般化しすぎだと指摘します。AIが時間を節約できる特定の作業もあるので、どんな課題かによって効果は異なります
  • 遅くなることが必ずしも悪いわけではなく、遅いプログラミング（リテラリープログラミング／Knuth流）はむしろ理論化に役立つとも思います。ファストフード的なプログラミングではなく、十分な思考と抽象化を伴う遅い開発が重要だという主張もできるでしょう
• 「その道具が本当に自分を速くしたのか遅くしたのかを、開発者自身が把握できない」という現象には共感します。ボートが風や潮流のせいで目標からそれる現象を例に、私たちは現在の周囲の動きだけをもとに進展を認識しており、目標に近づいているかどうかを直感するのは難しいと指摘しています。そのため「進んでいる気分」になれる戦略を選ぶ傾向があり、それが非効率だったり、実際には遅い経路（たとえば運転中にやたら右折するなど）を選ばせることがあります
  • AIツールを初めて使ったときは、詰まりがなくて仕事がどんどん進む感じが気持ちよかったです。ですが実際には自分で1行直したほうが速い場合でも、習慣的にAIを呼んでしまうことがあります。運転の比喩で言えば、ある道が混むとまた元の道を勧めてくるGPSのように、同じパターンへ戻りやすいのです
  • Wazeのようなナビアプリが、実際にはより長いルートを案内しているのに、入り組んだ迂回路のおかげで「進行中」だと錯覚させ、速いと感じさせるのに似ています。AIツールもプログラミングを簡単にしてくれると感じられますが、実際の生産性は下がることがあります。人間は苦痛なく進めたという短期的な体験だけを覚えやすく、難しくなかったという理由で前進したと思い込みがちです
  • 結局のところ、人間は本能的に貪欲法（greedy algorithm）を好むのです
  • Linux/Unixユーザーは、キーボード操作とCLIツールが最高効率だと考えがちですが、多くの作業ではマウスのほうが速いという研究結果があります。キーボード入力のほうが速いと感じるのは、1秒あたりの動作数が多いからです
  • AIが生成したコードはほとんどレビューされず、多くの開発者はコードレビュー自体をつらいと感じて読みたがりません。だから新しいフレームワークやコードの全面書き換えが人気になる現象が起きます
    Joel on Software: Things you should never do, part I
    AI生成コードの多くは、ただ作られて簡単なテストを通すだけで終わります。しかも、自分自身ですら全体の文脈や理由を十分に理解していないコードが増えていきます
• この研究の要点は、「AIが、実際よりも生産性向上が大きいかのような錯覚を生み出す」と要約できます。生産性がわずかに向上した参加者は一部だけで、ほとんどはむしろ大きく低下していました。AIのおかげで生産性が爆発的に上がったと言う人は多いですが、実際には、その効果自体が錯覚かもしれないという研究の洞察が見落とされています。AIは、ユーザーにこの製品を使うべきだ、有用だと信じさせるよう最適化された商品です。個人的価値は知覚された現実なので否定できませんが、AIに強く依存する人は、自己認識の歪みや偽の達成感、ツール依存に本当に注意すべきです。AIは最適化されたトークン列で答えてくれますが、その最適化目標が本当は何なのか、一度考えてみるべきだと思います
  • LLMは何かを学ぶときには役立ちますが、その理解はかなり抽象的でLLM的なものになる感覚があります。学習するときは複数の方法を混ぜるのがよいと思います
  • AIツールは、開発者を「速くする」というより、「瞬間的に機敏だと感じさせる」ものです。脳の負担が減ったかのような錯覚があり、別のフィードバックループによって感覚自体が変わり、記憶形成の仕組みまで変わることで生じる興味深い錯視現象です
• 「経験豊富なオープンソース開発者が自分のプロジェクトでAIを使うとむしろ遅くなる」という研究を議論していた最中、私はまったく他人が作った3か月物のコードベースと、慣れていないフレームワークで作業することになりました。ところがClaude Codeを使ったことで、以前なら別のプロジェクトで1日から2日、あるいは最大2週間かかっていたような作業（データ同期など）を数時間で片付けられ、ものすごいジャンプスタートになりました。複雑さが増せばだんだん遅くなるでしょうが、ツールの助けで出だしが非常に速かったのは驚きです
  • 私にも似た経験がありますが、この研究が言っているのは、私たちが経験したようなramp-up（立ち上がり期間）の話ではなく、すでに非常によく慣れたオープンソース開発者がAIでタスクをこなすときの話です。LLMが新しいコードベースへの適応を確かに速めてくれる一方、慣れた後はかえって邪魔になるという経験があります
  • 「2週間かかるPRが数時間で」という主張にはいつも生産性向上の話が付きまといますが、実際に私たちの開発期間予測がどれほど正確なのか検証されることはあまりありません。また、そうして急いで出したPRの品質が当初想定していた水準なのか、単に速さを優先して重要なシステム文脈を省略し、バグの確率を上げていないかも問うべきです。AIがなくても、品質を犠牲にすれば速くはなります
  • AIのおかげで、コードベースやシステムに対する平均的な習熟度が自然に高まっているのかも疑問です。LLM使用時の学習効果は、新しい言語で「読む」ことはできても、自分で最初から「書く」のは難しい、という感じに似ています。C++で言えば、読んだり既存コードを直したりはできても、どこから新しく組み立てるかは難しいのです
  • AIツールのおかげで非常に大きなジャンプスタートを得た、というだけで、研究や記事、論文を批判したかったわけではなく、特定の文脈ではAIが本当に役立つことを言いたかったのです。単にコードを書くことだけでなく、たとえばClaude Codeがプロジェクト内のコンテナから直接AWSクラスタへの接続を試みるなど、インフラ全体や構造を把握するのにも大いに役立ちました。私の経験では80〜90%はコード品質より「ビジネス価値」が優先されます。実際にコード品質が重要な作業や、特殊なアルゴリズム・データ構造が必要な分野でどれだけ有用かは分かりません。それでも、良い例と明確な文脈を与えれば、かなり使えるコードを書いてくれるという経験もしました。ツールは毎週あるいは毎月のペースで急速に進化しています。結局、AIは魔法ではなく道具であり、プロダクトや結果に対する責任は最終的に自分にあります
  • 論文（TFA）が扱っているのは、非常によく慣れたプロジェクトでの事例だという点を忘れてはいけません。私の経験した事例はその逆で、AIは不慣れな状況でこそ主に力を発揮しました
• 「AIのagenticツール（Claude Code、Amp、Gemini CLIなど）は、プログラミングにおけるテーブルソーのようなものだ」という比喩を引きつつ、使い方を覚えれば一部の作業はより速く、うまくできるが、慣れていないうちはかえって指を切ることもあると述べています。私はagentic AIのおかげで少し野心的なプロジェクトにも挑戦しやすくなり、やりたくないことや反復的な作業はAIに任せることで思考の余裕が生まれます。一方で、AIに全部やらせて理解もないままコミットするのはだめだという警戒もあります。道具として、よりよい使い方を身につけようとする努力が必要です
  • テーブルソーの比喩は合わないと思います。テーブルソーは手工具に比べて精密な道具ですが、agentic AIは精密さとは程遠いからです
  • 「あなたはAIの使い方を間違っている」という論理は、AIが現れる前からオープンソースのスタックを築いてきた開発者に対して侮辱的です。しかも、AIを使って価値あるソフトウェアが作られたという証拠はまだありません
• この研究では、Cursorの経験が50時間を超えていた開発者（研究参加時間を含む）はたった1人だけで、その開発者は25%の高速化を経験しました。残りは全員初心者で、新しい道具を使う初心者が遅くなるのは当然です。この研究だけでAIの生産性について結論を出すのは難しいと思います
  • 論文の詳細を見ると、似たような（あるいはむしろそれ以下の）ツール経験者を対象にした以前の研究では、逆に速度向上が報告されていました。LLMプロンプト経験は大半の参加者に十分あり、とくにCursorはVSCodeに似ていて別途大きな学習コストがあるわけでもありません。もしすべての開発者がAIツールに極度に慣れたなら、AIなしで作業するときの能力がかえって落ち、その結果、AI使用時には単に悪化した基準と比べて速く見えるだけかもしれません。どのツールを使ったかよりも、生産性の自己申告が実際に比べて過度に楽観的だったことこそ重要な洞察だと思います。実際の効果を判断するには具体的な測定値が必要です
    （論文C.2.7「平均以下のAIツール活用」節でさらに詳しく扱われています）
  • 長年自分のIDE（Vim/Neovimなど）を使ってきた開発者であれば、新しいツール（Cursorなど）へ切り替えた際に、生産性が数か月にわたって著しく低下することもありえます
  • 私も同感です。不慣れな道具を使う開発者は遅くなって当然です。AIも例外ではありません
• 現在、Burn（Rustベースのディープラーニングフレームワーク）の定期コードレビュアーだと明かします。最近、まるごとAIエージェントが書いたようなバグ修正PRをクローズしたことがありました。そのPRは問題の根本原因を解決せず、エラーをただ無視するだけの内容で、無駄に長々とした言い訳めいたコードを追加し、エラー無視をテストするコードまで含んでいました。コミット履歴を稼ぐための行動だと推測されます。このようなAI乱用が広がるのは懸念すべき傾向です
  • LLMが正解を知らないと見当違いの答えを出し、間違いを指摘すると「その通りです、直します」と反応するのは奇妙です。実際、経験の浅い人がイシューの区別をつけられなかったり、次第にコードそのものを気にしなくなったりするのが怖いです。本格的な脆弱性や悪用事例が大量に出てくるのではという懸念もあります
  • 同僚のMRをレビューしていたところ、明らかにAI生成だと分かるテストケース（thing1、thing2など、変数名だけ違って中身はほぼ同じ）が見つかりました。フィードバックとして、もっと区別しやすい名前を提案したところ、今度はAIが各ケースの特徴を全部列挙するような冗長すぎる変数名を付け、結果として一目で把握しづらいコードになりました。書いた本人は作成速度が大きく上がったと感じていたのでしょうが、実際にはフィードバック、レビュー、修正に時間を使っており、生産性の利得はすべて消えてしまったわけです
  • 「Rustでディープラーニングフレームワーク → AIと絡んだ悪循環」という趣旨の、冗談めいた意見も見られます
  • 実際、コミットを積むためにAIを使う雰囲気はすでに長く存在しています。AIは単純なスパム生成すら容易にしてしまいます
    参考: 昔のAIスパム問題
  • LLMがtry:catch構文を広く使いすぎて、問題の発生源の追跡を難しくしてしまうと指摘しています。私は問題を素早く、そしてはっきり表面化させて（=fail fast）、すぐに直したいのです
• 個人的な感想を共有すると、AIプログラミングは集中の流れがたびたび切れ、より疲れやすくなります。コーディングを一日中続けるというのは神話で、普通は1〜3時間ほど集中して、その合間に休憩を取ります。同僚のコードや変更を読む時間も仕事の進捗に含まれはしますが、実際の前進にはあまりつながらないことがあります。agentic AI（小さなコードのリファクタリングなど）は有用かもしれませんが、大きな生産性向上はあまり感じません。コード補完（初期のCopilotのようなもの）は、むしろ不要なノイズが多いです
  • 実際に一日の作業を録画したら、その結果はかなり憂うつなものになるでしょう。とくに成熟したコードベースでは、1時間集中したというのすら誇張かもしれません
• 不慣れなコードベースで厄介なバグ（たとえばrace condition）をデバッグするときは、ログ追加、ライブラリ関数の差し替え、構造改善などが必須ですが、AIが「ここはレースコンディションで、こう直せばいい」と短期的な解決だけを提示すると、コード構造やロジックの理解をむしろ損なう危険があります。長期的にAI主導のコード編集が続けば、コードそのものが劣化し、やがてAIですらまともに対処できなくなる可能性さえあります
  • 「AIを使って知らない言語、知らないコードベースに貢献した」という体験談を聞くたびに、短期的にはよくても、実際に何を学んだのかと問いたくなります。こうした貢献は小規模な作業には使えるのかもしれませんが、長期的な保守についての体験談はあまり聞かない気がします
• 最近、AIツールを積極的に活用した最初のプロジェクトを振り返った結論としては、1) 速くはならなかった、2) むしろ遅くなった可能性がある、3) ただし成果物の品質は上がった、の3点です。遅くなったことと品質向上はつながっていて、アイデア検証や代替案の探索など、主に補助手段として使ったためです。AIのおかげで不慣れな分野での学習体験も良く、主戦場では自分のアイデアやAIのアイデアを磨くことで、結果として品質が向上しました。速度だけが重要なわけではなく、品質の定量化は難しいとしても、十分に価値があると感じます
  • AIはむしろ品質向上に貢献しうるので、最近は自己主張をして、むやみに同意しないAIを好みます。AIにアイデアを求めて問題点を突かせたり、自分のアイデアの穴を一緒に探してもらったりすると生産的です。実際には採用しないとしても、以前なら思いつかなかったさまざまな視点を得られます。適度にその分野について意見を言ってくれる同僚と会話しているのに近い体験です。

[eususu]

私も似たような考えを持っていましたが、どう表現すればいいのか曖昧でした。
メンタルモデル、いいネーミングですね。時々使ってみようと思います。