何が語られたか
Paul Dixの主張はシンプルです。AIが100万行（1M LOC）のコードを書き、そこから「a couple of months（2〜3か月）」かけて改良を重ね、結果として数百万台の開発者マシン上で稼働する信頼性あるソフトウェアが生まれた。この事実そのものが驚くべきことだ、というものです。
興味深いのは、Dixが自ら反論を持ち出している点です。「オラクル（比較対象となる正解）があったのだから、ある言語から別の言語へ移すのは単純な作業で、大して凄くない」という見方です。Dixはこれを「achievement を過小評価している（selling the achievement short）」として退けます。
そして結論はこうです。「検証システムを構築し、適切な方向づけを与えられるなら、AIは極めて複雑で高度なソフトウェアを生み出し、それが動くようになるまで改良し続けられる」。
なぜこの一節が重要なのか
注目すべきは、Dixが強調しているのが「AIの賢さ」ではなく「検証システム（verification system）」と「適切な方向づけ（proper direction）」という2つの外部条件だという点です。つまり、成果の再現条件を語っている発言なのです。
ここで、退けられたはずの反論が別の意味を帯びてきます。「オラクルがあったから簡単だった」という批判は、裏返せば「正解と突き合わせられる仕組みがあれば、AIは100万行規模でも収束できる」という観察でもあります。Dixが「過小評価だ」と言うのは、その条件を用意すること自体が成果の本体だ、という含意として読めます。
「数か月かけて改良した」という時間軸
もう一つ見落とされやすいのが時間の扱いです。100万行が一度の生成で完成したとは語られていません。書いたあと、数か月にわたって refine（改良）を続けた結果として信頼性に到達しています。
これは「AIにコードを書かせる」話ではなく、「AIに改良を回し続けさせる」話です。プロンプト一発の生産性ではなく、失敗を検知して差し戻すループをどれだけ長く安く回せるかが成果を決めている、という構図になります。
「動くまで直せる」の前提条件
Dixの表現「until it just works（動くようになるまで）」が成立するには、「動いている／いない」を人間の目視以外の方法で判定できる必要があります。判定が自動化されていない領域では、改良ループは人間のレビュー速度で頭打ちになります。
逆に言えば、テストスイート、既存実装との出力比較、型検査、実データでの再生といった「機械が正誤を返す仕組み」を持つ領域ほど、この発言が示す生産性の変化が起きやすいことになります。
💼 事業会社視点：これは自社にどう効くか
この発言を自社に引き寄せるなら、問うべきは「AIに書かせるか」ではなく「自社の開発対象に、機械が正誤を返す仕組みがあるか」です。
受託開発・SI事業者にとっては直撃の論点です。レガシー言語からの移行案件は、まさにDixが言う「オラクルがある」タイプの仕事——旧システムという正解が存在し、出力が一致するかを機械判定できます。工数積算で見積もる前提が崩れる可能性があり、経営としては「移行案件の単価は維持できるか」を今期中に検討すべきです。同時に、検証環境の構築力そのものを売り物にする転換も選択肢になります。
SaaS事業者は、リグレッションテストの網羅率が今後は開発速度の上限を決める変数になります。テスト整備を「コスト」として後回しにしてきた組織ほど、AI活用の恩恵を受け取れません。CTOは開発リソースの一定割合を検証基盤へ振り向ける判断を、来期予算の議論に乗せる価値があります。
EC・事業会社の情シスでは、判定が自動化しにくい業務ロジック（社内独自の商習慣、例外処理）ほどAIによる置き換えが効きにくい領域として残ります。ここを見極めずに一律の「AI活用目標」を掲げると、現場が疲弊します。
共通する打ち手は一つです。自社の開発工程を「正誤が機械判定できる部分」と「人間の判断が必要な部分」に棚卸しし、前者から順に投資すること。Dixの言う verification system は、AI導入の前提条件であって結果ではありません。