AIコード生成がエンジニアリングの厳密さの必要性を排除しない理由

手放し開発の誤謬

既存アプリケーションの大規模な言語書き換え（CampfireのRuby on RailsからRustおよびElixirへの変換など）にAIエージェントを使用する最近のトレンドは、AI生成コードがエンジニアリング的判断の代替にはならないことを示しています。開発者がコードを読んで理解する責任を放棄すると、パフォーマンス、メモリ使用量、障害モードに関するLLMによる一連のコイントス的決定を暗黙的に受け入れることになります。核心的な教訓は、プログラミングは依然としてトレードオフの学問であり、AIエージェントは具体的で専門家レベルのガイダンスなしにはこれらのトレードオフをナビゲートできないということです。

暗黙的決定の隠れたコスト

LLMが書き換えを実行するとき、プロンプトで明示的に定義されることはめったにない何千ものマイクロ決定を行わなければなりません。これらには以下が含まれます：

• 後方互換性： 既存のAPI契約を維持するか、アーキテクチャ上の都合で破るか（例：CSRFトークンの削除）の決定。
• リソース管理： プロセス内キューとRedisなどの外部サービスの選択。
• 並行性モデル： 特定の言語のランタイムの制約内でデータベース操作とロックメカニズムを処理する方法の決定。

Campfireの書き換えの場合、RustバージョンはElixirバージョンとは異なる互換性制約を選択し、言語自体の直接比較を誤解を招くものにしました。違いは言語に固有のものではなく、AIのガイドなしの実装選択の産物でした。

ベンチマークがしばしば誤解を招く理由

パフォーマンスベンチマークは、ある言語や実装の優位性を正当化するためによく使用されますが、完全な運用上の現実を捉えられないことがよくあります。ほとんどの「スロップ」ベンチマークは、クローズドループシステムでのスループットを測定するものであり、以下のような重要な要素を無視しています：

• 背圧処理： システムが限界に達したときの挙動。
• イベント配信レイテンシ： 接続を切断する（フェイルファスト）ことと、イベントを無期限にキューに入れること（巨大なレイテンシスパイクにつながる）の違い。
• メモリフットプリント： 持続的な負荷下でのOOM（メモリ不足）クラッシュのリスク。

例えば、イベントブロードキャスターのRust実装は当初、小さなチャネル容量によって制限され、負荷がかかるとメッセージをドロップしていました。この容量を増やすと配信率は向上しましたが、同時にレイテンシが130秒以上に膨らみました。これは、「修正」がしばしば新たな、より深刻な運用リスクを導入することを浮き彫りにしています。

批判的思考の必要性

エンジニアリングとは、障害モードを管理する行為です。遅れているクライアントを切断することで優雅に失敗するシステムは、極端なレイテンシでイベントを処理しようとするシステムよりも優れていることがよくあります。これらの決定には、何が「正しい」失敗かを定義する人間が必要です。

コミュニティの議論で指摘されているように、危険はAIをツールではなく「魔法のボタン」として扱うことにあります。AIはコードの生成を加速できますが、以下の必要性を置き換えることはできません：

• 敵対的テスト： AIを使用して、システムの前提に挑戦するテストスイートを生成する。
• コードレビュー： 生成されたコードを手動で監査し、アンチパターンとパフォーマンスのボトルネックを特定する。
• 制約の設定： AIが尊重しなければならない非機能要件を明示的に定義する。

最終的に、ソフトウェアシステムの品質は、それに注がれる注意に比例します。コードが人間によって書かれたかAIによって書かれたかにかかわらず、その信頼性、パフォーマンス、保守性に対する責任は、それをデプロイするエンジニアにあります。