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

シャベルウェアはどこに?AIコーディングの主張が合わない理由

概要

  • AIコーディングツール の生産性向上に対する疑念
  • METR研究 や自己検証で明らかになった効果の限界
  • 業界全体で 出荷ソフトウェア数に顕著な増加なし
  • 開発者や企業が AI導入圧力 に苦しむ現状
  • データと現実 が誇大広告と大きく乖離

AIコーディングツールの幻想と現実

  • ソフトウェア開発 歴25年以上の開発者による現場実感
  • AIコーディング 初期は期待していたが、最近の研究(METR)で疑念が生じた経緯
  • METR研究で、 開発者自身の生産性評価が不正確 である事実
    • AI導入で「20%速くなった」と思い込んでいたが、実際は「19%遅くなった」実例
  • 自己検証 のため、タスクごとにAI利用/非利用をコインで決定し、作業時間を計測
    • 6週間の記録でも 統計的有意差なし
    • メディアンで21%遅くなる傾向、METR研究と一致
  • AI導入による2倍速等の劇的な生産性向上は一切観測できず

業界の誇大広告と現実の乖離

  • Cursor 「異常な生産性向上」や Claude Code 「より早く良いソフトウェア」などの宣伝文句
  • GitHub Copilot 「Delegate like a boss」、 GoogleOpenAI の生産性向上主張
  • 開発者の14%が「AIで10倍生産性」と自己申告
  • 経営層や業界全体がFOMO(取り残される恐怖)でAI導入を急ぐ
    • 企業の「AIファースト」化、リストラや給与抑制の正当化材料
  • 実際には、AI普及後も新規ソフトウェアリリース数は横ばい
    • Indieブームや「シャベルウェア洪水」は発生せず
    • 数十TBのデータ分析でも リリース数グラフは平坦

データが示す現実

  • AI普及による新規アプリやゲームの爆発的増加は皆無
  • 「10倍生産性」主張が正しければ、 世界中のソフトウェアリリース数は倍増しているはず
  • GitHub等の新規プロジェクト数にも顕著な変化なし
  • AI導入が現場開発者の生活に悪影響
    • ツール未導入で解雇されるケース
    • 新しい職場への転職不安
    • 「プロンプト力」習得プレッシャーと自己否定感

開発者へのメッセージ

  • AIツール利用を強制されている開発者へ
    • もし「使いづらい」「遅くなる」と感じているなら、それは正常な感覚
    • データが直感を裏付けている
    • 「今まで通り」で問題なし、焦る必要なし
  • 経営層や同僚が「AIで10倍速」と主張したら、証拠を求めるべき
  • 本当に重要なのは出荷数のみ、AI導入でそれが増えていない現実に注目

よくある反論への反論

  • 「プロンプト力が足りないだけ」
    • データ上、10倍生産性の新規開発者は存在しない
    • 14%の「10倍速」自己申告が事実なら、リリース数は倍増しているはず
  • 「新技術だから時間がかかる」
    • 既に数年経過、今も効果が見えないのは問題
    • ユーザーの人生や雇用に直結する問題
  • 「プロンプト習得で成長」
    • Copilot調査でも6ヶ月で29%→34%の微増のみ
    • 劇的な効率化は見られない
  • 「品質向上で出荷数は変わらない」
    • コード品質自体も向上していない現状
    • テストやTDDも減少傾向
  • 「独自ドメインや.aiドメイン増加」
    • AIブーム便乗による一時的な現象、全体数の急増なし
  • 「大企業は会議が多く、個人開発は別」
    • 個人開発でも新規プロジェクト数は増えていない

AIファースト文化の矛盾

  • AIで10倍速になれるなら、なぜ公式トレーニングやガイドが機能しないのか
  • 「自分で試して学べ」という曖昧な指示
  • 公式プロンプトガイドも効果が薄い現実

結論 : AIコーディングツールの 劇的な生産性向上データで裏付けられていない。 開発者は 過度なAI導入圧力 に惑わされず、 自分の直感と実績 を信じて行動すべき。

Hackerたちの意見

なんか分かる気がする。CEOたちが「AIのおかげで既存の開発者が10倍生産的になったから、開発者を雇わない」って言ってるけど、その生産性向上が本当なら、全員雇おうとするんじゃない?同じ投資で10倍の生産性が得られるなら、もっとお金をつぎ込むはずだよね。もしかしたら、これらのグラフは、経営陣がAI革命をうまく活用して、コストを削減しつつ生産性をそのままに保ってるってことを示してるのかも。

今日は、限界効用について学ぶことになるよ :) ビジネスやアイデアの中で、利用できる人数や行動には限界がある。要するに、問題に対して無駄にリソースを投げつけているだけ。解雇が多い理由は、AIが効率を生んでいるから。みんなが気づいていないのは、AIロボットやGPUが人間を1対1で置き換えるわけじゃないってこと。1人ができる作業量を置き換えるんだ。それが結果的に1人の従業員を減らすことになる。あなたの仕事がAIに奪われるわけじゃなくて、もう始まってる。でも、どれだけの人間が必要かが新しい供給と需要のポイントで、仕事がどれくらい続くかに関わってくる。常にもっとクリエイティブな頭が必要とされるけど、今はそれが不足してる。職を探しているソフトウェアエンジニアがどれだけいるか、信じられないよ。年収10万ドルから20万ドルの仕事を探してるのに、ビジネスにどれだけお金を節約できるか全然分かってない。学校で創造性が潰されちゃったんだ。誰かに指示されるのを待っていて、誰もいないときにどうしていいか分からなくなってる。みんな行き詰まってる。見えているのは能力の欠如じゃなくて、方向性をコントロールしたり、追う価値のあるアイデアを作る能力の欠如なんだ。

こういうC-suiteの人たちも、残っている人たちがAIに置き換えられることを期待している。彼らはホッケースティックの「AGIがすぐそこにある」という話に乗ってる。私はそうは思わないけど、少なくともそれなりに論理的ではあるよね。本当にそう信じているなら、もっと開発者を雇いたいとは思わないはず。

利益率が下がるにつれて、どこかから価値を絞り出さなきゃいけなくて、それが労働の雇用や解雇、報酬に影響するから、そういう結果に強いバイアスがかかるんだ。AIの魅力の99%は労働コストの削減にあるし、雇用はそれに逆行する。とはいえ、AIの生産性主張は信じてないけど、理論的にあなたの仮説に寄与する要素を指摘してるだけだよ。

同時にいくつかのことが真実であり得るよね。1. LLMは一般的なタスクに対して開発者の生産性を一律10倍にはしない。2. LLMは限られたタスクのセットに対しては劇的に生産性を上げる。3. LLMは単純作業を自動化できて、時間的には人間よりかかるかもしれないけど、実質的にはバックグラウンドで作業が進んでる。LLMは新しいAPIやライブラリについて、俺が自分で調べるよりもずっと早く理解させてくれる。知らない言語で少しのグルーコードを書く必要があるとき、LLMは時間を節約してくれるし、二度と使わないかもしれないことを学ぶ必要もなくしてくれる。既存の大規模なコードベースを修正するのは?生産性はせいぜいトントンだね。新しいウェブサイトの足場を作るのは?LLMはそれが得意だよ。クラスのモックを書くのも?LLMはモックライブラリの使い方をよく知ってて、俺よりずっと早く終わらせてくれる。特に、複雑なモックを書くのは年に数回しかやらないから、その間にやり方を完全に忘れちゃうし。新しいコードベースをナビゲートするのも?LLMは約70%くらいはいい感じだね。過剰に設計されたWTFプロジェクトを開いたことがあるなら、HTTPルートがどこで定義されているかを見つけるだけでも大変だよ。「おい、クロード、このプロジェクトのルートエンドポイントはどこで定義されてるの?認証のための依存性注入された関数はどこにある?」正しい道具で、正しい仕事をしよう。釘にハンマーを使うのはやめて。

新しいウェブサイトのための足場を作るの?LLMはそれが得意なんだ。すごく得意で、記事の著者が示したすべての統計は、既存のコードベースではなく新しい開発に基づいているにもかかわらず、せいぜい横ばいだったよ。

依存関係がどこから来るのか分かるなら、もっと調べてみないと。インジェクションのせいで他の人のコードベースが手に負えなくなるのが本当に嫌なんだ。「フレームワークは数十億行のコードをスキャンして実装を見つけることができるし、君もできるよ!」

LLMは新しいAPIやライブラリについて、俺が自分で調べるよりもずっと早く理解させてくれる。すごいスピードアップだよ。知らない言語でちょっとしたグルーコードを書く必要があるとき、LLMは時間を節約してくれるだけじゃなく、たぶん二度と使わないであろうことを学ばなくて済むようにしてくれるんだ。これについては、気持ちが揺れ動くんだよね。同じような感情を抱いたこともあるけど、あまりにも頻繁にカーテンの裏を覗いて、ドキュメントを読んで外部依存関係に慣れた後、LLMの返答が逆説的に慣習に従っていなかったり、オンラインで見つけたコード例に問題を無理やり合わせようとしていたり、機能を不適切に使ったり、シンプルにできることをわざわざ遠回りしてやったりすることに気づくんだ。近くで見ると魔法のように感じるけど、あまりに近づきすぎると理解している気になってしまうのが心配なんだよね。

釘にハンマーを使うのはやめて。え、じゃあ釘には何を使えばいいの?

LLMは雑務を自動化できるけど、人間よりも時間がかかることもある。それでも、実際にはバックグラウンドで作業が進んでるんだ。バックグラウンドで監視なしにできるこの雑務って何なの? AI推進派は、成功している具体的なタスクについてもっとはっきり説明するべきだと思う。あまりにも曖昧で手を振るだけの説明にはみんな疲れてきてるよ。

俺の経験とも合ってる。ちょっとしたリファクタリングやスキーマからの型定義なんかでは役立つけど、それ以上のタスクになると、見落としがあって再作業が必要になることが多い。未来には俺の言葉を食うことになるかもしれないけどね。一方で、最近、経験の浅いエンジニアが大きな機能を実装しようとして、LLMが出すものを「良い」と受け入れてしまって、実際には以下のような問題があることに気づいていないのを見かけた。- 既存のスタイルガイドやパターンに従っていない。- 適切なライブラリが複数あるのに、ゼロからロジックを実装してしまって、今はそのコードを所有することになる。- すべてのことをしようとする巨大なPRになっている。

「適切なライブラリが複数あるのに、ゼロからロジックを実装することで、今私たちが所有するこのコードは、すべてのことをしようとする巨大なPRになっている。コードの量によっては、これをポジティブにしか見れないかな?50行のコードのために巨大なライブラリを引っ張ってくることが多すぎる。」

Hacker Newsで議論の続きを見る