AIコーディング100%義務化から1年、誰もコードを理解できなくなった
あるRedditの投稿が話題を呼んでいる。AI生成コードを義務化したチームが、今では自らのコードベースを説明できなくなったという。LLM APIで開発する開発者が学ぶべき点とは。
投稿が実際に主張していること
見出しは率直だ。AIの100%義務化から1年、誰もコードを理解していない。Redditのスレッドで報告され、Hacker Newsで広まった主張は、あるチームがAI生成コードをデフォルトとして推進し、今その代償を理解と保守の面で払っているというものだ。
ここでは慎重になるべきだ。これはオンラインフォーラムからの単一の逸話であり、対照実験ではない。コードベースの規模、レビュープロセス、チームのシニア層の構成も分かっていない。普遍的な結果の証明ではなく、起こり得る失敗モードに関するシグナルとして扱うべきだ。
理解の負債が複利で膨らむ理由
チームの誰も説明できないコードは、誰が、あるいは何が書いたかにかかわらず負債だ。人間が論理的に検討していないモジュールでバグが発生すると、デバッグは極端に遅くなり、あらゆる変更に追加のリスクが伴う。これがスレッドが提起する中心的な懸念だ。
AI生成は、レビューが弱いとこれを加速させる。テストが通るからと出力がマージされ、そのテストも生成されたものなら、チームは動作について独立した理解をほとんど持てないかもしれない。負債は本番環境で何かが壊れるまで見えない。
LLM APIで開発するチームにとっての意味
LLM APIの上に製品を提供しているなら、同じ力学が自らの統合コードにも当てはまる。プロンプトテンプレート、リトライロジック、スキーマ検証、フォールバック経路などだ。これらはまさに、生成コードが正しく見えながら予想外の動作をし得る領域である。
実践的なパターンは、各重要モジュールについて少なくとも1人のエンジニアが行ごとに読まなくても説明できることを求め、最も重要な経路については人間が書くかレビューしたテストを維持することだ。小さな差分、明示的なオーナーシップ、文書化された設計意図といったベンダー中立の習慣は、プロバイダーをまたいでも有効だ。
モデル変更に耐えるガードレール
モデルの挙動は時間とともに変わるため、前提をコードとテストに固定する方が、プロンプトが安定し続けると信じるより安全だ。構造化出力を検証し、デバッグ用に生の応答をログに残し、モデル呼び出しとビジネスロジックの間に明確な境界を保つことで、プロバイダーの切り替えに書き直しが不要になる。
これはいずれもAI支援開発に反対する議論ではない。スレッドからの教訓はオーナーシップとレビューの規律についてであり、生成を禁止することではない。最も恩恵を受けるチームは、生成コードを依然として人間の正式な著者を必要とする下書きとして扱う傾向がある。