ハクソク

世界を動かす技術を、日本語で。

AIはオープンソース開発者の作業を遅らせる。ピーター・ノールがその理由を教えてくれる

2025年7月14日原文(johnwhiles.com)

概要

  • AIツール は熟練オープンソース開発者の 生産性を低下 させる傾向
  • Peter Naur の理論がその理由を説明
  • 開発者はAIで 速くなると錯覚 しやすい
  • メンタルモデル の重要性とAIの限界
  • 一般的な企業開発者には 異なる効果 の可能性

AIツールは熟練オープンソース開発者を遅くする理由

  • Metr社 の研究によると、オープンソース開発者が 自分の得意なコードベース でAIツールを使うと、AIなしよりも 19%遅く 課題を完了
  • 開発者自身は AIで24%速くなる と予測し、実際に遅くなっても 20%速くなった と錯覚
  • この 認知と現実のギャップ が顕著
  • 対象は 熟練のオープンソース開発者、他の開発者全体には一般化できない点に注意
    • 例：企業の保守的なプロジェクトでは AIで生産性向上 の可能性

Peter Naurの「プログラミング＝理論構築」論

  • Peter Naurの論文「 Programming as Theory Building」の要点
    • プログラミングとは プログラム全体の洞察（理論） を構築する活動
    • 本当の成果物は 開発者の頭の中のメンタルモデル
    • このモデルがあるからこそ、 ソフトウェアの理解・保守・拡張 が可能
  • Metr社の被験者 は自分のプロジェクトの 深いメンタルモデル を持つ
  • AI（LLM） はこのメンタルモデルに アクセスできない
    • 開発者がAIに情報を渡す過程は 遅く、情報損失も大きい
    • 結果として 独自の強みが損なわれる

メンタルモデルの移転困難性

  • 他者にタスクを委任する時の 伝達の難しさ に類似
    • 例：「赤ちゃんを寝かせる」指示でも意図通りに伝わらない
  • メンタルモデル は非常にリッチで 完全な伝達は不可能
  • テキストのみでAIに伝える 場合、AIは
    • 質問や確認 をしない
    • 重要度の判断 ができない
    • 学習能力が限定的
  • このため、 AIツールは熟練開発者の生産性を低下 させる

一般的な企業開発者へのAIの効果

  • 「自分のプロジェクトを深く理解している」開発者には AIは逆効果
  • しかし、企業では
    • 古いコードベース や 他人が作ったシステム を扱うことが多い
    • 理解よりも納期重視 の環境も多い
  • こうした場合、 AIはコードベースの理解を早めたり、動く変更を素早く生成 できるメリット
  • 「 短期的なビジネス価値の創出」を生産性と定義するなら、 AIで生産性向上 もあり得る

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

  • メンタルモデルがない状態 でAIに頼れば 一時的な生産性向上 は可能
  • しかし、 本質的な目的はメンタルモデルの構築
  • AIに作業をアウトソースすると モデル構築が困難
  • 長期的にプロジェクトに関わり、 深い理解と自立的な改修能力 を得たいなら 自分でコードを書くべき
  • 逆に「 使い捨ての開発現場」ではAI活用も選択肢

AIツールの今後と注意点

  • 現在のAIツールは 熟練開発者のメンタルモデル支援 には不十分
  • 将来的に より高度なAI が登場すれば、状況は変わる可能性
  • 今は「 Claude Code」などを 適切に活用 しつつ、自分の目的に応じて使い分けが必要

参考

  • Metr社の研究論文（要約だけでも読む価値あり）
  • Peter Naur「Programming as Theory Building」
  • Claude Code推奨、Cursorは非推奨

Hackerたちの意見

彼らは経験豊富なオープンソース開発者で、自分たちのプロジェクトに取り組んでいます。 私は、他の誰かが書いた3ヶ月前のコードベースに取り組み始めたばかりで、使ったことのないフレームワークとアーキテクチャでした。 数時間後、Claude Codeの助けを借りて、ステージングからローカル開発にデータを複製するための素晴らしいシステムを作成しました。 これは他のプロジェクトで以前に作ったことがあり、手動でやると1日か2日はかかるだろうなと思っていました。 特にそのアーキテクチャに経験がなかったので、開発がさらに加速しました。 今はローカルでテストするためのデータが良くなったからです。 それから数時間後、私はすでに最初のPRをプッシュしました。 すべてのコードは、既存のプロジェクトとフレームワークの適切なコーディングスタイルとプラクティスに従っています。 そのPRは、手動で書いてテストするのに少なくとも数日、場合によっては2週間かかっていたでしょう。 だから、AIがすべての人やすべてのことを加速するわけではないけれど、少なくともこのケースでは大きな助けになりました。 これから進めていく中で、プロジェクトの複雑さが増すにつれて、少しスピードが落ちると思います。 でも、素晴らしいスタートを切るチャンスをもらったのも事実です。

└

記事のポイントを見逃してるよ。それは実際に君のエピソードと一致してる。

開発者がシステムを理解することにあまり価値を置かず、主に動作する変更を迅速に提供することに多くの価値を置く環境で働くのは同じくらい一般的です。 この文脈では、AIツールがより有利だと思う。 彼らは、人間よりも早く不慣れなコードベースを取り込むことができ、基本的に動作する変更を生成することが多いから。

└

私もAIとオープンソースで似たような経験をした。 AIのおかげで、あまりよく知らない言語やスタックで機能を実装できた。 その機能が欲しかったのに、他の誰も実装しようとしなかったから。 自分でスタックを直接勉強しようとしたけど、全体像が複雑で、初心者にはドキュメントが不足していると感じた。 Warpターミナル（Claudeを使っている）を使うことで、その壁を乗り越えて、以前は全く得られなかった結果を得ることができた。

└

俺も似たような経験があるけど、これは研究が言ってるような仕事じゃないよ。「オープンソースの開発者が、自分がよく知っているコードベースでAIツールを使ってタスクを完了しようとすると、タスクを完了するのに時間がかかる」っていうのは、俺も実際にそうだと思う。LLMは新しいコードベースに慣れるのを大幅に早めてくれるけど、プロジェクトに慣れた後は逆に迷わせることが多い。

└

逸話とデータが一致しないときは、だいたいデータが間違ってることが多い。必ずそうとは限らないけど、AIが実際に人々の生産性を下げているという研究や議論を読むたびに、ほとんどのプログラマーが、俺も含めて、これらのツールに価値を見出している理由が気になる。高水準のプログラミング言語でも同じことがあったんじゃないかと思う。人々は「自分でガーベジコレクタを管理しない方が生産性が上がると思うかもしれないけど、実際は…」って言ってたし。たとえ私たちがもっと「生産的」じゃなくても、何百万もの人がこれらのツールを使いたがっているんだから、何か意味があるはずだよね。そんなことを教えてくれる「研究」は必要ないよ。

└

明らかにその研究を読んでないね。問題は、開発者たちが自分たちは20%速くなったと思ってたけど、実際は遅くなってたこと。とりあえず、あなたのプロフィールをざっと見た感じ、バイブコーディングに関して利害の対立があるから、あなたの意見はちょっと疑ってかかるよ。

└

まあ、今のところそれが得意なことだね。ボイラープレートのスターターテンプレート、ランディングページ、使い捨てアプリとか。でも、データパイプラインやセキュリティみたいに精度が必要なプロジェクトでは、生成されたコードには微妙な欠陥がたくさんあって、すべての行を掘り下げないと大きな頭痛の原因になるよ。

└

TFAは、彼らが取り組んでいるプロジェクトやコードベースに非常に精通している人々についてのものだったんだ。君のエピソードは、まさにその状況とは逆のことを言ってるし、君が説明しているようなプロセスも認めているよ。

└

あのPR、俺だったら完全に手動で書いてテストするのに、少なくとも数日から2週間はかかるな。ソフトウェア開発の見積もりの正確さってどうなの？いつも「俺だったらこうなった」とかいう生産性の主張を見かけるけど、見積もりが得意かどうかは全然考慮されてないよね。俺は見積もりが苦手だし。PRの質が本来のものと同じかどうかも考えられてないし。手順やシステムの理解をスキップして、早く進めることができるけど、その分バグが出る確率も高くなるんじゃない？AIなしでも同じスピードアップはできるよ。

└

LLMがそう言ってるからって、どうしてそのコードやコーディングスタイル、プラクティスに自信を持てるの？コードベースを理解してないのに、ハルシネーション（幻覚）じゃないってどうやって確認するの？

いい記事だね。 この生産性の研究や「プログラミングは理論構築だ」という論文について、私も似たようなことを考えてた。 プログラムのオリジナル著者で、そのプログラムのコンテキストが頭に残っているなら、どんなAIシステムも近づくけど超えられないアシンペトートになるんじゃないかって思い始めてる。 生のコーディングスピードではなく、プログラムの理解、開発のビジョン、欠陥やハック、コンテキスト、ユーザーのニーズ、プログラムが存在する文化などに関してね。 著者が言ったように、日常の仕事の大半では理論が構築されていないし、その一部が変わるかどうかは分からないっていうのも面白い。

誰かがXで言ってたけど、これらのエージェントAIツール（Claude Code、Amp、Gemini Cli）は、プログラミングにおけるテーブルソーのようなものだって。 人間がノコギリでやるよりも速くて良いものを作れるけど、正しく使い方を学ばないと（指を失うことになるかも）。 個人的には、エージェントAIツールのおかげでプロジェクトに対する野心が高まった。 以前は考えもしなかったことに挑戦できるようになったし、嫌な仕事は彼らに任せてる。 彼らは私よりも早くて上手にやってくれるからね。 だから、私の頭はアーキテクチャやコードの技術的負債などの本当の問題に集中できる。 ただ、AIエージェントにすべてを任せて、自分のコードを理解せずに結果だけをコミットする誘惑があるのが問題。 （そう、AIが生成したけど、コミットにサインしたら君がそのコードの責任を持つことになるからね）。 だから、どんなツールでも、使い方を理解する時間を取って、自分に合うかどうかを見てみてね。

Hacker Newsで議論の続きを見る