ソフトウェア

Googleのエンジニアが語るAI支援コーディングの「70%問題」、AIが生産性を爆上げしたのになぜ製品は改善されない?


Google Chromeの開発エクスペリエンス責任者であり、AI支援開発に造詣が深いアディ・オスマニ氏が、AIによってエンジニアの能率が格段に改善したにもかかわらず、よく使われるソフトウェア製品に目立った変化がない理由を考察しました。

The 70% problem: Hard truths about AI-assisted coding
https://addyo.substack.com/p/the-70-problem-hard-truths-about


◆2種類のAI支援エンジニア
オスマニ氏によると、AIを活用してコーディングしている開発者は「ブーストラッパー」と「イテレーター」の2種類に大別することができるとのこと。

まずブーストラッパーは、「Bolt」「v0」「screenshot-to-code」などのAIツールを用いてゼロから新プロジェクトを立ち上げる人たちで、以下のような特徴を持っています。

・デザインや大まかなコンセプトから始める。
・AIで完全な初期コードベースを生成する。
・数時間から数日で実用的なプロトタイプを作る。
・迅速な検証と反復に重点を置く。

例えば、オスマニ氏が見たある開発者は、Boltを使ってデザインツール・Figmaのデザインをあっという間に実用的なWebアプリにしてしまったとのこと。それはまだ製品版ではありませんが、初期のフィードバックを集めるには十分なほど実用的だったそうです。


一方、イテレーターは「Cursor」「Cline」「Copilot」「WindSurf」などのツールを日々の開発ワークフローに役立てている人たちで、派手さはないものの大きなイノベーションをもたらす可能性があるとオスマニ氏は考えています。

イテレーターは以下のような用途にAIを使っている点に特徴があります。

・コード補完と提案。
・複雑なリファクタリング(ソースコードの改善)作業。
・テストやドキュメント作成。
・問題解決のための「ペア・プログラマー」としてAIを使う。

どちらも開発を劇的に加速させることができますが、そこには落とし穴となる隠れたコストがあると、オスマニ氏は指摘しています。


◆AI支援の落とし穴
上級エンジニアがAIツールで開発をしている様子をながめると、まるで魔法のようですが、よく見るとAIの提案をそのまま受け入れているのではなく、常に次のような作業を行っていることがわかります。

・生成されたコードをよりコンパクトで的を絞ったモジュールへとリファクタリングする。
・AIが見逃したエッジケース、つまり極端な事例への処理を追加する。
・包括的なエラー処理の追加。
・型定義とインターフェースの強化。
・アーキテクチャー上の判断の吟味。

このような作業は、一言で言えば「長年の苦労で培ったエンジニアリングの知恵を、AIの出力の成形と制限に応用している」と換言することができるとのこと。つまり、ベテランエンジニアはAIを駆使して実装を加速させつつ、自らの専門知識も動員してコードの保守性を維持しているわけです。

一方、若手エンジニアはこうした工程を見逃し、AIの出力をうのみにしてしまうため、オスマニ氏が「トランプのカードハウス」と呼んでいる、見てくれはよくても実用には堪えないコードができあがることになります。


◆AIの学習曲線に見る「70%問題」
こうした経験から、オスマニ氏は「AIツールは初心者よりも経験豊富な開発者にとって有用」という、一見すると逆説的な事実に気がつきました。

このパラドックスの存在を指摘しているのはオスマニ氏だけではありません。AI関連のニュースレターを書いている作家のPeter Yang氏はSNSへの投稿で、「AIを使ってコーディングしてきた非エンジニアとして率直に振り返ると、AIのおかげで70%までは作れても、残りの30%には手を焼かされます」と述べました。


この70%問題は、AIツールでコーディングすると小さなバグが見つかり、それを直そうとすると別の場所が壊れるイタチごっことして顕在化します。経験豊かなエンジニアなら、AIツールの出力に潜む間違いを見つけられますが、初心者は無限ループに陥ってしまうわけです。しかも、初心者がAIに頼るとデバッグのスキルや基本的なパターンの習得もままなりません。

◆AIとの付き合い方
オスマニ氏は、AIツールに手を出すこと自体を非難しているわけではありません。オスマニ氏が見てきた非エンジニアの中で最もAIを使いこなしている人は、AIによる出力結果の理解に時間を割くなど、AIをコードジェネレーターではなく学習ツールとして活用していたそうです。

また、多くのチームによるAIの活用を見てきた経験から、オスマニ氏はAI支援開発を始めようとする人に、次のような使い方を推奨しています。

・明確に定義された独立タスクにAIを使用し、生成されたコード全行をしっかり確認して、徐々に大きな機能を構築していくこと。
・すべてを小さなファイルに分割し、コンポーネント間のインターフェースを明確に維持しつつ、各モジュールの境界をドキュメンテーションする。
・AIに判断を委ねるのではなく判断を加速させるのに使い、エンジニアリング基準を維持して、違和感があるコードはそのままにしない。


◆まとめ
オスマニ氏によると、ソフトウェアの品質のボトルネックになってきたのはコーディングの速度ではないとのこと。現にAIでソフトウェアが劇的に改善されていないのも、これが理由だとオスマニ氏は考えています。

オスマニ氏は末尾で、「ゴールはより多くのコードをより速く書くことではなく、よりよいソフトウェアを構築することだというのを忘れないで下さい。AIを賢く使えばその実現に役立ちますが、『よりよい』というのが何を意味するのか、それをどう達成するかは、依然として人間次第なのです」と述べました。

この記事のタイトルとURLをコピーする

・関連記事
Mistral AIが初のコーディング用生成AIモデル「Codestral」をリリース、80以上のプログラミング言語でトレーニング済み - GIGAZINE

GPT-3.5ベースのChatGPTのコーディング能力は「古い問題には有効も新しい問題では困難に直面する」ことが明らかに - GIGAZINE

オープンソースのコーディング支援AI「Qwen2.5-Coder」シリーズの性能はGPT-4oに匹敵、64GBのRAM&M2搭載MacBook Proでもローカル実行可能 - GIGAZINE

NVIDIAのCEOが「AIがコードを書くのでもうプログラミングを学ぶ必要はない」と発言して議論を巻き起こす - GIGAZINE

GitHubの調査により開発者の92%がAIコーディングツールを愛用している実態が判明 - GIGAZINE

AIに自力で解決しようとするのではなく「正しいタイミングで外部ツールを頼る」方法を学ばせることでパフォーマンスが約30%上昇したという研究結果 - GIGAZINE

in ソフトウェア, Posted by log1l_ks

You can read the machine translated English article here.