Alexandru Nedelcuが指摘するAI支援プログラミングの中心的なリスクは、単一の明白なエラーではありません。ソフトウェアを理解、変更、テストしにくくする設計上の選択が、時間をかけて蓄積していくことです。彼の警告はモデルそのものというより、生成されたコードに人間の判断や、誤りを修正する経験から得られる知見を置き換えてしまう組織に向けられています。

この議論は、測定に関する問題から始まります。保守性は、機能が最初に動作した時点では通常目に見えず、脆弱なアーキテクチャの影響が表面化するまで、何か月、あるいは何年もかかる場合があります。コードベースは生産的に見えても、隠れた依存関係、不明瞭な不変条件、重複したロジック、壊れやすいテストによって、将来の変更がますます高コストになることがあります。そのためNedelcuは、保守性を従来のリンターや即時のテスト結果によって保証できる性質ではなく、長期的な時間軸で評価すべき属性だと考えています。

この区別が重要なのは、機械学習システムには測定可能なフィードバックが必要だからです。利用可能な報酬がコードがその日に実行されるかどうかを反映する場合、モデルは、完成した設計が複数のリリースを経ても一貫性を保てるかを学ばないまま、短期的な振る舞いを改善できます。これはNedelcuの主張をより限定した形で裏づけるものです。自動コード生成は観測しやすい成果を最適化し、後から現れる結果を見落とす可能性があるということです。だからといって、すべてのモデルが有用なアーキテクチャに関する知識を持たないことや、AI支援のプロジェクトがすべて劣化するわけではないことは証明されません。

Nedelcuはまた、専門能力は失敗を経験することによって育まれると主張しています。エンジニアは、どの抽象化が実際に再利用可能なのか、どの近道が将来の制約を生むのか、そして局所的な単純化がいつシステムの意図を曖昧にするのかを学びます。開発者がコードを読んだり書いたりしなくなると、彼の主張では、そうした判断を下し、その結果から学ぶ機会を失います。その結果として生じるリスクは組織的なものです。設計がなぜ機能するのか、あるいはなぜ機能しなくなったのかに関する知識が、責任を日常的にツールへ移す過程で保持されなくなる可能性があります。

提示されたDreyfusのスキル習得モデルは、この議論の一部を理解するための背景を提供します。同モデルでは、学習者が明示的な規則や手順から始め、経験を通じて、より直観的で文脈に応じた判断へ徐々に発展していくと説明されています。また、意識的な規則への依存を続けることが、熟練の段階へ進む妨げになる可能性についても警告しています。この枠組みはNedelcuの懸念を理解しやすくしますが、AIコーディングが同じ効果を生むことを独立して証明するものではありません。このモデルはスキル発達に関する理論を示すものであり、コーディングエージェントをテストしたり、ソフトウェアメンテナンスを測定したり、この記事の予測を検証したりするものではないからです。

そこから実践的な問いが生まれます。チームは、アーキテクチャに関する判断を手放すことなく、コーディングエージェントを利用できるのでしょうか。提示された証拠は、この問いに決着をつけていません。ただし、責任ある利用には何を守らなければならないかについては示唆しています。エンジニアは生成された変更を精査し、設計上のトレードオフを理解し、意味のある振る舞いを検証するテストを維持し、要件の変化に応じて判断を見直す必要があります。自動化は反復的な作業を担えますが、境界、不変条件、そして設計の背後にある理由に対する責任は人間が担い続けるべきです。

この証拠は、重要な比較についても結論を出していません。AI支援によって書かれたコードと人間が書いたコードを比較した管理された研究、メンテナンスコストの長期的な測定、そして「AIを使わない」方針が競争上の優位性をもたらすという証明はいずれもありません。また、コード品質には有用な指標が存在しないことも示していません。妥当に導ける結論は、より限定されたものです。容易に測定できる指標は長期的な保守性を表す不完全な代理指標にすぎず、組織はビルドが成功したことを、設計が時間とともに良好な状態を保つ証拠と見なすべきではありません。

読者にとって有用な教訓は、反技術的なものではなく、運用上のものです。結果がすぐに明らかにならない判断には、人間を関与させ続ける必要があります。アーキテクチャ上の判断理由を記録し、実質的なレビューを求め、生成されたコードは理解すべき提案であり、自律的な知恵の源泉ではないと考えるべきです。このアプローチは、自動化による効率上の利点を保ちながら、Nedelcuが指摘する特定の失敗モード、すなわち現在は動作していても、自社チームにとって変更がますます難しくなるコードベースという問題に対処します。