Claudeはコンパイラではない

2025年初頭、私は「Claudeはコンパイラか？」と書きました。その時、私の答えは「わからない」でした。今では、「いいえ、それはカテゴリのエラーであり、コンパイラよりも優れています」とほぼ確信しています。しかし、これには少し説明が必要です。 コンピュータプログラムは、驚くほど複雑で気難しいものです。プログラムは極端な精度レベルで動作します。「手を振る」CPU命令はありません。一方、高レベルの目標は、深く仕様が定められていません。世界の非常に様式化された見方では、ソフトウェアはレイヤーで構築され、各レイヤーは仕様を追加し、「不要な」詳細を隠します。ビジョンは戦略になり、製品計画はコーディング計画になり、コードはバイナリになります。各ステップは異なる役割によって処理されます：エグゼクティブ、VP、PM、アーキテクト、エンジニア、コンパイラ。 決定的に、すべてのステップには多くの意思決定が含まれます。それが仕様レベルを上げることの意味です。（だからこそ、エンジニアを採用する際の私の2つの主要な指標のうちの1つは判断力であり、もう1つは協調性です。） ソースコードからバイナリへの最も下のレイヤーは、コンパイラが行うことです。コンパイラは多くの決定を行います！インライン化、レジスタ割り当て、警告を発するかプログラムを即座に拒否するかなどです。そして、これらの決定は重要です：それらはパフォーマンス、システムの安定性、予測可能性、および障害モードを駆動します。コンパイラエンジニアの仕事は、コンパイラが一貫して良い決定を下すように手配することです。良い、信頼できるコンパイラは、ソフトウェアエンジニアがこれらの決定を下す必要から解放します。ほとんどのエンジニアはコンパイラがどのように機能するかをほとんど知りません。効果的であるためにそれらを必要としません。 2025年、私たちは小規模なコードチャンクを生成するためにLLMを使用する世界で活動していました。このメンタルモデルでは、コーディングエージェントはソフトウェアエンジニアと従来のコンパイラの間に新しいレイヤーとしてスロットインされる可能性があります。それは、エンジニアがする必要のない決定を下し、自然言語をコードに「コンパイル」します。その価値は、その信頼性と、行うことができる決定の規模に比例します。 問題は、この世界の様式化された見方は偽であるということです。抽象化は漏れ、レイヤーは擦れます。そして、たとえそうでなかったとしても、私たちはそれらに穴を開けるでしょう。レイヤーを横断して作業することは非常に価値があります。機械的な共感（mechanical sympathy）が重要です。 エンパイアステートビルディングが1年未満で予算内で（!!）建設された方法の一部は、レイヤーを体系的に横断して作業することでした。例えば、外装のクロムニッケル鋼クラッドを決定する際：建築家も、建設業者も、下請け業者も、完全な協議なしにこの複雑な建設技術問題に対処する能力があると感じていませんでした。したがって、完全な予備協議の後、オーナー、建築家、建設業者、材料を圧延する下請け業者、製造および設置する金属加工業者、そして準備のいくつかの段階で全てのシートをテストする検査官の代表者が出席する包括的な会議が招集されました。 これは、口に出して言うと非常に明白に聞こえます。そして、私たちは実践において体系的にこれを失敗しています。金属加工業者が、作業が遅く miserable になるようなものではなく、設計を導く機会を得たことの喜びを想像することしかできません。 私たちが失敗する理由の一部は、何について尋ねる価値があるのかさえ知らないことです。最高の経営幹部がその業界に関する深い知識を持っているのには理由があります。また、一部は軽視（「線材加工業者が私に何を伝えられるだろうか？」）であるとも疑っています。しかし、大きな部分はコミュニケーションと組織的なオーバーヘッドでもあります。レイヤーが存在するのには理由があります—情報隠蔽は組織のスケーリングを可能にします。 Claudeはコンパイラよりも優れています。なぜなら、スタック全体を垂直に移動できるからです。LLMは今や戦略、製品、アーキテクチャ、コード、そしてマシンコードを話します。それは（まだ？）経験豊富な専門家ほど個々のタスクのほとんどをうまく実行できませんが、会議をスケジュールしたり許可を求めたりすることなく、それらすべてを実行できます。 具体的な例を挙げましょう。exe.dev VMには、vm-name.exe.xyzのような素敵なドメイン名があります。新しいVMを開始する際には、CNAMEエントリを1つか3つ追加します。簡単ですよね？しかし、私たちのVMは高速に起動するため、VMを作成する前にDNSエントリを作成した場合でも、ユーザーはDNSが伝播するのを待たなければならず、時には数分ではなく数秒かかりました。私たちは明白なことをしました：独自のDNSサーバーを書き、DNSが常にソースオブトゥルースに即座に一致するようにしました。そして生活は良くなりました。 しかし、レイテンシーは重要なので、リージョンを追加しました。そして、DNSは再び長いポールになりました。なぜなら、すべてのDNSはオレゴンから提供されていたからです。また、デプロイメントは小さなDNS障害を引き起こしました。 これを修正するために、地理的に分散されながらも完全に一貫したDNSサーバーが必要になりました。私たちは、困難な問題に直面したときに、まともなエンジニアがすることをした：チートした。私たちは、特定のニーズに合わせて調整された分散DNSサーバーをバイブエンジニアリングしました。目標は明確でした：オレゴンから遠いユーザーのレイテンシーを削減し、アップタイムの回復力を高めること。しかし、残りはそうではありませんでした。 私たちは、特に様々な障害条件下での正確な動作、それが全体的な会社の計画にどのように適合するか、目標を達成するために最適なアーキテクチャ、そして細かい実装の詳細に至るまで、すべてを把握する必要がありました。私たちは、最も高いレベルの戦略的およびアーキテクチャ的な決定を対面で話し合いました。汎用的なDNSサーバーを作成し、特定の動作の調整を加え、ハブアンドスポークモデルを使用し、追記専用レプリケーション戦略を使用し、エッジに永続性を持たせることにしました。残りは、それを実際に構築することでした。 LLMに分散DNSシステムの標準設計を調査させ、DNSの内部構造と癖について教えさせ、過去のセキュリティ上の失敗を指摘させ、代替実装戦略（AXFR/IXFR？いいえ、結構です）を探求させ、オープンソースの提供物を調査させ、障害モードをゲーム化させ、テスト戦略を計画させました。 有望に見える設計の初期スケッチができた後、複数の同時エージェントループに、テストや敵対的なコードレビューを含む全体を構築するように指示しました。 彼らは、主要な構造的アプローチから行レベルのコードの懸念に至るまで、あらゆる詳細レベルで多くの質問を投げかけました。私がそれらに答える（または後悔を生んだ回答を元に戻す）につれて、私は学んだことを非常に簡潔な書面によるガイダンスにゆっくりと変換し、重要であることが証明された決定を成文化しました。 次に、新しいエージェントに完成した実装を比較させ、興味深い逸脱を探させました。エージェントが尋ねなかったが、単に決定した—そして異なる方法で決定した—多くの重要な決定があったことは衝撃的でした。 例を挙げましょう。レプリケーションは、かなり明白なアプローチを使用します：最後の既知のエントリ以降のすべてを要求してキャッチアップし、次に新しいエントリをロングポールします。1つの厄介なひねりがあります：データベースのロールバックです。まれですが、発生し、それは「追記専用」契約を破ります。 エージェントはこのことに気づき、非常に異なる方法でそれを解決しました。私が最終的に落ち着いた設計は、各行に「タイムライン」フィールドを持たせることでした。「どのタイムラインに住んでいますか？」のようなものです。これらはランダムに生成され、「行N以降のエントリ」という同期リクエストには、エッジサーバーの行Nのタイムライン値が含まれます。タイムラインの不一致がある場合、履歴が変更されたことを認識し、完全なクリーンな再同期にフォールバックします。 また、異なるエージェントによって構築されたシステム間には、明白なスタイルの違いもありました。ClaudeとCodexは両方とも、Claudeがよりエレガントなシステムを作成したが、Codexはより徹底的であることに同意しました。 私は、特定された主要な分岐点のリストを調べ、実験し、その後、さらに書面によるガイダンスを追加しました。 その後、その差分仕様分析プロセス全体を2回繰り返しました。 私は自分の格言を知っています。 計画を1つ捨てることを計画せよ。いずれにせよ、そうするだろう。— Fred Brooks 捨てる計画を立てるなら、2つ捨てることになるだろう。— Craig Zerouni キーパーを構築する準備ができたときまでに、私は、高レベルの目標からアーキテクチャ、そして時折低レベルのデに至るまで、あらゆるレイヤーで、ほとんどの重要な決定をエージェントに導くのに経験的に十分な、傷跡の文書を蓄積していました。