AI は新しい問題を生んだのではなく、「人間が関心を持つべき境界」をもう一段押し上げた

AI は新しい問題を生んだのではなく、「人間が関心を持つべき境界」をもう一段押し上げた。そしてその一段がどこにあるかは、人間にしか決められない。

AI は無限の計算量を持ち、人間が課題外在性の認知負荷を回避するのに役立つ。

ただ、課題内在（本当に関心を持つべき、価値のあるスコープ）と課題外在（機能を実装するためにライブラリのバグをワークアラウンドするなど）の境界は主観的で曖昧であり、白黒はっきりしているものではない。絶対的な正解もない。その境界は人間の判断に委ねられている。

本来は課題内在であるべきものも、人間が判断をサボって AI に任せてしまい、とりあえず動くものが出来上がってしまう。

逆に、無限の計算量のおかげで、人間がこれまで見る余力のなかった、さらにその裏側の詳細まで見られるようになった（動的メモリ解析、リバースエンジニアリングなど）。

ただ、人間と違って、自分が見聞きしてきたすべてのことや、人生で培ってきた一般常識と価値観という広範なコンテキストを持たないため、AI は全体感を持てない。それが、コーディングや開発におけるいわゆる「AI Slop」の正体だと思う。

これは AI 時代になって初めて出てきた問題ではない。AI の設計が甘くて人間の設計なら良い、という話でもない。能力と知識でいえば、AI は人間のエンジニアよりずっと強い。

これまでも、マネージャーが現場エンジニアの設計の詳細をすべて理解していたわけではない。事業や目標に対するコンテキストや意識が、現場のエンジニアまで浸透していたわけでもない。人間同士のコミュニケーションでも認識の齟齬は起きるし、お客様の要件を理解しないまま進めて失敗することもよくある。

AI は、ただそのスピードが速いだけだ。

AI によって、人間が関心を持つ必要のある境界は間違いなく上がっている。これも AI 時代が初めてではない。アセンブリや C 言語を書くときは、メモリ管理まで考える必要があった。GC のあるスクリプト言語なら、メモリ管理の仕組みを知らなくても動くものが書ける。コンパイルとは何かを知る必要もなく、あたかもコードがそのまま実行されているように見える。これも、人間が関心を持つべきレイヤーが上がったということだ。

一方で、GC がない代わりに動作が速く、「所有権」の概念を人間が意識して書く Rust もある。Go の内部に詳しいからこそ、その作者は従来の数倍効率の良い監視ソリューションの VictoriaMetrics を開発できた。

すべての詳細を人間が把握することはできないし、その必要もない。ただ、どこまで把握する必要があるのか、どこまでが課題や価値に影響するのかは、AIには決められない。しかも、この境界は一度決めたら終わりではない。「すべての自明でない抽象化は、程度の差こそあれ漏れる」という抽象化漏れの法則のとおり、AI に任せたレイヤーで自分に理解できない問題が起きたとき、人間は一時的にでも下へ潜らなければならない。だからこそ、必要なときに潜れる力は手放せない。

例えば、最初のPoCや簡単なアプリなら、基本的な部分が動くこと以外はすべて課題外といえるので、境界のレイヤーを上げて残りをAIに任せ、AIの恩恵を存分に受ければいい。本番に出したいなら、アルファ版、クローズドベータ、オープンベータと段階を踏みながら境界のレイヤーを下げ、人間が把握する範囲を広げていく。そして、把握する必要のない部分はAIに任せる代わりに、境界の外側から検証する。中身をすべて理解するよりも、テスト、型、不変条件、性能ベンチマーク、監視、ユーザーの反応といった外側からの検証のほうがずっと安く済む。

AI時代のエンジニアリング能力は、「どう検証するか」を設計する能力へと移っていくのかもしれない。これが、AI時代のプロダクト開発におけるバランスの取れたやり方だと考える。