AIによる「バイブコーディング」の台頭と潜在リスク
近年、AIによるコード生成ツールの進化は目覚ましく、「2025年以降コードを書いていない」「コードレビューはもう不要」「誰もコードを読まなくなった」といった声が聞かれるようになりました。これは、AIが開発プロセスに深く統合され、いわゆる「バイブコーディング」が一般化している状況を示しています。しかし、Lobstersの記事は、この風潮が長期的に見てプロジェクトに大きなリスクをもたらすと指摘しています。
AIに依存し、コードを読んだり書いたりしなくなった人々や組織は、自らの危険を顧みずにそうしている。
個人的にも、Claude Codeのようなツールを使って日々の開発を効率化している身としては、この指摘は非常に胸に刺さります。生産性が向上する一方で、本当に「コードを読む力」が衰えていないか、常に自問自答する必要があります。
保守性の定義とAIの限界
記事では、「悪いコード」の定義を明確にしています。それは、読みにくく、理解しにくく、将来の変更に対応しにくいコードです。
具体的には、ある変更がプログラムを非決定論的に壊したり、遠く離れたロジックに影響を及ぼしたり、機能を一つ追加するにも複数箇所を変更する必要があり、一貫性が失われやすいコードを指します。設計の不変性が不明確で、テストが困難なコードもこれに含まれます。
AIが生成するコードがなぜ「保守可能」になりにくいのか、その理由は主に以下の2点に集約されます。(出典)
| 項目 | AIの現状 | 人間(熟練開発者)の能力 |
|---|---|---|
| 学習データ | 初心者向けルールブック、実世界のコード(多くは質が悪い) | 長年の経験、試行錯誤から得た直感 |
| 評価指標 | 即座に測定可能な報酬信号(短期的な結果) | 保守性やアーキテクチャの良さ(数ヶ月〜数年で判明する長期的な影響) |
| 関数設計 | 再利用性の低い、安易な分割 | 専門的なアート、明確で再利用可能な設計 |
| 間違いからの学習 | 不可能(AI自身は学ばない) | 可能(選択と責任、経験として蓄積) |
AIは、コードの「保守性」や「良いアーキテクチャ」といった、長期的にしか評価できない特性を学習するための適切な報酬信号を持っていません。そのため、AIが学ぶのは、初心者向けのルールや、往々にして品質の低い実世界のコードから抽出されたパターンに過ぎません。
特にAIが苦手とするのが「コードの簡素化」や「適切な関数分割」です。再利用性や明確性を考慮せずに小さく分割された関数は、かえって全体を理解するのを難しくします。
経験と直感の重要性
熟練したソフトウェアエンジニアは、長年の経験と苦労を通じて培われた「直感」によって、悪いコードの兆候(コードスメル)を早期に察知し、問題が顕在化する前に対応できます。この直感は、単なる厳格なルールリストには落とし込めない、文脈依存性の高いものです。
記事では「専門家はルールに従うのではなく、ルールを作る」と表現されており、彼らの知見がコード品質維持にいかに不可欠であるかを強調しています。(出典)
現在のAIは、このような熟練者の直感や、文脈に応じた判断能力を持つには至っていません。これは、私の自作PC(RTX 3090搭載)でローカルLLMを動かし、コード生成を試す際にも強く感じるところです。表面的な構文は正しくても、設計思想や保守性を考慮した提案はまだ難しいと感じます。
開発者の成長を阻害するAI依存
AIが生成したコードに過度に依存し、自身でコードを読んだり書いたりしなくなる傾向は、開発者の成長を著しく阻害する可能性があります。なぜなら、彼らはもはや「選択」をせず、「間違い」に対する責任を負わず、そしてその間違いから「学ぶ」機会を失うからです。AIは間違いから学ぶことはなく、AIに依存する人間もまた学びません。
AIが間違いを犯し、AIは間違いから学習せず、AIにコーディングを依存する人々も学習しない。
私自身も、AIは素晴らしいツールだと感じていますし、日々のワークフローにAIを統合しています。しかし、それはあくまでツールであり、開発者自身の思考や学習を代替するものではないという意識を強く持っています。GCPのCloud RunやBigQueryを触っていると、インフラレベルでの理解がなければ、AIに指示を出すことも、その結果を評価することも難しいと感じる場面が多々あります。