大企業での昇進の真実は、最も醜い「レガシーシステムの山」を掃除することだ。
翻訳・編集 | 王啓隆（ワン・チロン）
シリコーン・バレーのエンジニア階層において、ピラミッドの絶対的頂点に立つ一団がいる。彼らは華やかなフロントエンドを書かず、派手なプロダクトも作らない。彼らは日夜、オペレーティングシステムの最下層に潜り、コンパイラーやビルドシステム、仮想ファイルシステムと睨み合っている。彼らの存在意義は、数十億行ものコードと数万名のエンジニアを抱えるメタ（Meta）のような超巨大コードベースが、エンジニアがリターンキーを叩くたびに崩壊しないよう保証することだ。
マイケル・ボーリン（Michael Bolin） は、大企業の技術コミュニティにおいて、まさしく最下層を鎮める「掃除僧」のような存在である。
元メタのディスティングィッシュド・エンジニア（Distinguished Engineer、職位E9、大企業技術職の天井に位置するランク）として、彼はフェイスブックのAndroid向けビルドシステムの書き換えを主導した。コードベースが巨大すぎて、オペレーティングシステムの最下層でシステムコールを傍受し、エンジニアがgit statusを実行してもPCがフリーズしないよう、仮想ファイルシステムを作り上げたほどである。
長い間、ボーリンは自身を「容赦なくコードを書く機械」と定義していた。
しかし、こうした伝統的なエンジニアリング分野のトップ王者が、OpenAIに転職し、Codex（後のGitHub Copilotの基盤モデル）の技術責任者となった際、彼の世界観は完全に打ち砕かれた。
最近の『The Peterman Pod』でのディープインタビューにおいて、ボーリンは極めて率直に、むしろ自嘲を含む口調でこう認めた：「私は現在、ほとんどコードを手書きしていない。私のコードの80％から90％は、AIが生成してくれたものだ。」
この対話から、神経を逆撫でするいくつかの核心的な見解を抽出した：
大企業昇進の「ヒーローイズム」罠： 多くのシニアエンジニアが昇進できないのは、ゼロから完璧な「玩具」を書こうとし、醜いながらも会社の生命線に関わるレガシーシステムを引き継ぐことを嫌うからだ。メタでE9に昇進するには、汚れ仕事や苦役を引き受ける「政治家」にならなければならない。 カルチャーショック：研究主導対エンジニアリング主導： グーグルやメタではエンジニアが絶対的王者だが、OpenAIではリサーチャー（科学者）こそが王者であり、エンジニアは計算インフラを構築する「補助人員」に過ぎない。この落差は、AIラボに転職した大企業のエリートたちを苦しめている。 トップエンジニアの最終的な救済は「ドキュメント作成」： ボーリンが明かしたところによると、メタで昇進した最も重要な武器はコードを書くことではなく、「経営層や部門横断チームが理解できる技術計画を作成すること」だった。 AI時代の护城河（moat）は移行しつつある： AIが90％のコードを代わりに書いてくれる一方で、大規模言語モデルは「幻覚（ハルシネーション）」に陥りやすい。メモリ割り当て、ポインタ、アセンブリなどの深いシステム理解は、AIの誤りを迅速に特定し、大企業のアーキテクチャを修正できる唯一の切り札となっている。
以下は、この対談の日本語訳である。
Firefox拡張からGoogleカレンダーまでの「サバイバル」
ライアン・ペターマン（Ryan Peterman、ポッドキャスト司会者、元Instagramソフトウェアエンジニア、以下「ライアン」）：本日のポッドキャストへようこそ。本日はマイケル・ボーリン氏をお迎えしております。OpenAIのオープンソースプロジェクトCodexの技術責任者であり、元メタのディスティングィッシュド・エンジニア（E9）でもあります。マイケル、まずはキャリア初期からお話ししましょう。あなたの個人サイトを深く掘ったところ、昔はとても興奮していたが、今はリンクが全部切れているプロジェクト「Chickenfoot（チキンフット）」を発見しました。あれは一体何だったのでしょうか？
マイケル・ボーリン（以下「ボーリン」）：ああ、なんてことを。確かに懐かしい話題ですね。あれは私の修士論文プロジェクトで、Firefoxブラウザーの拡張機能でした。Firefox用にJavaScriptを書くというのは、当時としては絶対的に先進的な卒業設計でした。
簡単に言えば、Firefoxのサイドバーに統合された小さなプログラミングツールです。核心理念はWeb向けの「エンドユーザープログラミング（End-user programming）」でした。enter（入力）やclick（クリック）といったマクロコマンドを提供していました。文字列パラメータを渡してenterと入力すると、ウェブページ上で対応する入力欄を自動的に探し出します。click searchと言えば、検索ボタンをクリックします。
低レイヤーでは、極めて複雑なヒューリスティックアルゴリズム（Heuristics）を大量に構築していました。ウェブページのDOM構造を解析し、「名」「姓」といったテキストを探し出し、それらのテキストに最も近いテキストボックスを特定し、JavaScriptで入力を自動的に埋め込みます。
今思えば、これは非常に興味深いことです。なぜなら現在多くのAIエージェント（インテリジェントエージェント）が行っていることは、私たちがChickenfootで行っていたことと全く同じだからです。ただし、現在は本物の自然言語大規模モデルを使用している一方、私たちが当時使っていたのは荒削りのJavaScriptスクリプトを無理やり「組み合わせた」ものだったのです。
ライアン：つまり、フロントエンドコードを解析し、インタラクティブなコンソールを提供して、自然言語コマンドでウェブページを操作できるということですか？
ボーリン：その通りです。ウェブアクセシビリティタグ（Accessibility tags）や画像のaltテキストなど、ありとあらゆる情報を活用しました。Craigslistのような極めて簡素なウェブサイトでは特に上手く動作しました。友人たちはこのツールを使って自動化スクリプトを作成し、お金を稼いでいたこともあります。
ライアン：その後、業界に正式に参入し、最初の勤務先がGoogleで、しかも最初からGoogleカレンダー（Google Calendar）プロジェクトを担当されたと伺っています。あの時代のGoogleはどのような雰囲気でしたか？あなたを引きつけた理由は何でしたか？
ボーリン：それは2000年代初頭の話です。私が90年代にインターネットに初めて触れた頃、何かを検索したい場合は、YahooやLycosなど5つの異なる検索エンジンを同時に開く必要がありました。2000年3月のこと、はっきりと覚えています。ルームメイトが「ねえ、スタンフォードにGoogleという検索エンジンができたらしいけど、他のより優秀みたいだよ」と言ってきたのです。
試してみると、検索品質が高いだけでなく、ページが極めてシンプルでした。それ以前は、Yahooのトップページは目まぐるしい広告やポータルリンクで埋め尽くされていましたが、Googleのトップページは浄土のようで、非常に抑制されていました。このような質重視で短期的なトラフィックを犠牲にするエンジニアリング文化は、私を卒業と同時にそこで働きたいと思わせました。
Googleカレンダーチームへの参加は私にとって完璧な機会でした。当時、MicrosoftのIEブラウザーが絶対的な支配を築いており、彼らはIEの後続開発計画を直接廃止するまでになりました。しかし、この厳しい環境の中で、GoogleはWebベースのアプリケーションで僵局を打開しようとしていました。あの時代、JavaScriptのエンジニアリング品質は極めて低く、フロントエンドを書くことは「玩具のコード」だと考えられていました。しかし私たちのチームは極めて優秀なエンジニアを迎え入れ、デスクトップアプリの体験（予定のドラッグや無リフレッシュ読み込みなど）をブラウザーに移し替えようとしていました。当時としては極めて先駆的なことでした。
メタ戦記（前編）——百万行規模のコードベースで「ビルドシステムを力技で解体」
ライアン：Googleで数年過ごした後、当時絶頂期にあったFacebook（現メタ）に転職されたと伺っています。あなたはそこでトップクラスのJavaScript専門家でしたが、最初に引き受けた大プロジェクトは、Android向けビルドシステム（Build System）のリファクタリングだったとか。これはどのような経緯でしたか？
ボーリン：当時のFacebookには非常に過激なハッカソン（Hackathon）文化がありました。会社が「モバイルこそ未来だ」と決断し、これは会社の生死に関わる最重要事項でした。
ある日、JavaScriptを理解する友人が私に言いました。「ねえ、君はJavaが得意なんだから、Objective-Cも学んでモバイル開発をしてみればいいじゃないか。今、プロダクトを作りたい人はみんなモバイル開発を知らなければならないんだ。」これは私にとって大きな刺激でした。なぜなら私はObjective-Cが全然好きではなかったからです。
私が最初に自分に課した役割は、PhoneGapのようなフレームワーク（ウェブページをネイティブアプリにパッケージングする初期の技術）を開発することでした。少人数のグループを集めて、HTML5でモバイル版Facebookを開発しようとしました。しかし実際に進めていく中で、このウェブベースのモバイルアプリの体験は極めて悪く、パフォーマンスが遅すぎて耐えられませんでした。最終的にマーク・ザッカーバーグ（Mark Zuckerberg）が自ら決断し、この方案を廃止し、全線を純粋なネイティブ開発（Native App）に転換すると宣言しました。
この節目で、私は選択に直面しました。嫌いなネイティブ言語を学ぶか、あるいは別のことを探すかです。
幸いなことに、私は痛み（ペイン・ポイント）を見つけました。当時、FacebookのAndroidチームは毎日苦痛の中で過ごしていました。前線のエンジニアにとって、一行のコードを修正し、「コンパイル」をクリックしてシミュレーターで結果を見るまでの時間（イテレーションサイクル）は、生産性を決定づける核心指標です。
しかし当時、FacebookはAnt（Apacheの初期のビルドツール）をベースとした極めて旧式なビルドシステムを使用していました。ビルドプロセスにモジュール化もキャッシュもなく、一行のコードを修正するたびに、システムは巨大なコードベース全体を再コンパイルし、時間が極めて長くかかりました。
私は「私はJavaを知っている。こうした低レイヤーの雑用なら絶対に難しくない」と思いました。最初はバグをいくつか修正しに行こうと思っただけでしたが、深く掘れば掘るほど、このシステムの基盤は完全に腐敗しており、最初からやり直す必要があると気づきました。
ライアン：でも、なぜGoogleの既存ツールを直接使用しなかったのですか？確かその頃、Google社内には非常に強力なビルドシステム（後にBazelとしてオープンソース化）があったと記憶していますが。
ボーリン：これは最高の質問です。確かに当時、特にGoogleから転職してきた人々の間で、「私たちはGoogleに素晴らしいツールがあったのだから、なぜそれをそのまま模倣しないのか？」と言う人がたくさんいました。
実際、私たちも試みたことがあります。社内でGoogleビルドシステムのミニチュア版を再現したこともあります。しかし問題は、Facebookのコードベース構造はGoogleとは全く異なるということでした。
Googleのコードベースは非常に規範的で、すべてのモジュールに明確な境界があります。しかしFacebookの当時のAndroidコードベースは、歴史的な重荷に満ちた山のようなもので、ごちゃごちゃしたリソースファイル（XML、画像）や極めてカスタマイズされたスクリプトが絡み合っていました。もし無理にGoogleのシステムを適用しようとすれば、すべての低レイヤーロジックを書き直す必要がありました。
さらに致命的だったのはタイムラインでした。当時は会社のモバイル戦略転換の生死を分ける瀬戸際で、経営層からの指示は「今すぐ、すぐにイテレーション速度を上げろ！ほんの少しでもいいから早くしろ！」というものでした。私たちは、完璧なGoogleアーキテクチャを再構築するのに一年もの時間をかける余裕は全くありませんでした。
これが私が主導して開発したBuck（Facebookのオープンソースビルドツール）の背景です。最初はPythonでいくつかのスクリプトを書いて、中間コンパイル結果をキャッシュしようとしました。しかし時間が経つにつれて、この寄せ集めは限界に達しました。そこであるハッカソンで、Pythonスクリプトを完全に廃し、Javaで型安全で高並列のビルドシステムの原型をゼロから書き直すことを決意しました。
はっきりと覚えています。その原型を動かしたとき、コンパイル速度が2倍に向上したのです。Androidチーム全員が驚きました。彼らは当初、低レイヤーツールのリファクタリングなど全く気にしていませんでしたが、私がコンパイル時間を4分から1分に圧縮したとき、全員がこの新システムの忠実な信者となりました。
メタ戦記（後編）——「スケールの呪い」に抗うためIDEの書き換えとシステムコール傍受
ライアン：Androidビルドシステムの難題を解決した後も、あなたは立ち止まらなかったようです。後のキャリア軌跡を見ると、より巨大なインフラに移行しています——IDE（統合開発環境）の書き換えを始め、仮想ファイルシステムまで作り上げました。これはどういうことでしょうか？
ボーリン：これは実に自然な進化でした。ビルドシステム（Buck）を作り上げたとき、エンジニアたちは確かに速くコンパイルできました。しかし新たな問題が発生しました。コードベースが指数関数的に膨張するにつれ、従来のIDEが耐えられなくなったのです。
当時私たちはEclipseを使用していました。数千万行のコードを持つ大規模なモノレポ（Monorepo）にとって、Eclipseでこのプロジェクトを開くと、インデックス（Indexing）の構築だけで30分かかります。その間、PCのファンが狂ったように回転し、メモリを食い尽くし、マシン全体がレンガのように固まってしまいます。
エンジニアたちはこう嘆き始めました。「ビルドは速くなったが、コードが開けないじゃないか！」
当時、業界には二つの声がありました。一つはローカルIDEを完全に放棄し、クラウドベースのブラウザー環境（Web-based IDE）に開発環境を移すこと。もう一つは軽量なローカルエディターを探すことでした。
私たちは中間路線を選びました。当時GitHubがAtomエディター（VS Codeの前身）をリリースしたばかりでした。Atomはウェブコア技術をベースにしており、非常に柔軟でした。私たちはAtomをベースにして、Facebookの巨大なコードベース専用のIDEプラグインシステムを開発することにしました。これをNuclideと名付けました。
パフォーマンスを極めて消費する言語解析、オートコンプリート、定義ジャンプ機能などを、すべて切り離してリモートの強力なサーバー上で実行させました。ローカルのNuclideエディターは、UIの表示とユーザーのキー入力の受け取りだけを担当します。これはすべてのエンジニアに見えない「スーパーコンピューター」を配備したのと同じです。
ライアン：これは非常に巧妙に聞こえます。しかし先ほど「仮想ファイルシステム」（Virtual File System）について言及されましたが、これはどのような痛みから生まれたのでしょうか？
ボーリン：仮想ファイルシステムの誕生は、物理学の法則に抗うためでした。
ご存知の通り、Facebookは「単一コードベース」（Monorepo）という哲学を掲げています。つまり、会社のすべてのプロダクト（Facebook、Messenger、Instagramなど）のコードが、すべて一つの巨大なリポジトリの中にあるのです。
これは壊滅的な結果をもたらしました。コードベースが数百万のファイル、数十GBのサイズに膨張したとき、従来のバージョン管理システム（GitやMercurial）は完全に崩壊してしまったのです。
このシナリオを想像してみてください。新入社員が入社し、一行のフロントエンドコードを修正したいだけです。従来のロジックでは、数百万のファイル、数十GBのデータをノートPCのハードディスクに完全にクローン（Clone）しなければなりません。これには数時間かかり、しかも単純なgit statusコマンドを実行するたびに、システムは数百万のファイルを巡回して変更がないか確認しなければならず、ターミナルが死にます。
この「スケールの呪い」に直面し、従来の最適化手段は失効しました。私たちはオペレーティングシステムの最下層まで深く潜らなければなりませんでした。
私たちはEden（後にMilesへと発展）という仮想ファイルシステムを作り出しました。簡単に言えば、LinuxのFUSE（Filesystem in Userspace）メカニズム、またはMac上の類似メカニズムを利用して、オペレーティングシステムのファイル読み取り要求を傍受しました。
ノートPCでコードベースを閲覧しているとき、数百万のファイルの完全なディレクトリ構造が見えています。しかし実際には、ハードディスクにこれらのファイルは全く存在していません。それらはすべて「プレースホルダー」です。
特定のファイルをダブルクリックして実際に開くか、コンパイラーが特定のファイルを読み取る必要があるときのみ、私たちの仮想ファイルシステムが瞬間的にネットワークリクエストをトリガーし、サーバーからその特定のファイルを「遅延ロード」（Lazy load）してダウンロードします。
これはまさに魔法のようです！このオンデマンド読み込みの方式により、元々数時間かかっていたクローン時間は数秒に圧縮されました。元々ハードディスク全体を巡回する必要のあったシステム状態チェックは、瞬時に応答するようになりました。私たちはオペレーティングシステムの低レイヤーで、すべての上位アプリケーションを騙したのです。
E8からE9への「血の道」と昇進失敗
ライアン：信じられない話です。ビルドシステムから仮想ファイルシステムまで、あなたが解決したのは大企業で最も核芯で最も低レイヤーの生死に関わる難題でした。これは自然に、あなたのキャリアで最も注目を集めた経験——メタでプリンシパルエンジニア（E8、主任エンジニア）からディスティングィッシュド・エンジニア（E9、傑出エンジニア）に昇進した過程に繋がります。
多くの大企業で苦闘しているエンジニアが昇進の難しさに直面しています。E8からE9は、ほとんど「血の道」です。この背後にある物語を共有していただけますか？
ボーリン：これは極めて苦痛だったが、私を完全に変貌させた経験でした。
多くの人はシニアエンジニアに対して誤解を抱いています。彼らは「10倍エンジニア」（10x Engineer）でありさえすれば、誰よりも速く、誰よりも良いコードを書けば、頂点まで昇進できると考えています。
早期の職位（初級から上級）では、これは確かに有効です。しかしスタッフエンジニア（E6）を超え、プリンシパル（E8）に至ると、「純粋にコードを書くこと」は逆に昇進の最大の毒になるのです。
当時はNuclideと初期の低レイヤーツールの構築を終えたばかりで、すぐにE9に昇進できると確信していました。しかし提出した昇進申請は無情に却下されました。
私の第一反応は極度の憤怒と困惑でした。「私はこれらの低レイヤーアーキテクチャを社内で最も理解している人物ではないのか？私は一人で十人分の成果を上げていないか？なぜ昇進してくれない？」
しかし後に冷静になり、数人のベテランE9やE10の大御所と長談議しました。彼らは私の問題をいちげきで指摘しました：私は「ヒーローイズムの罠」に陥っていたのです。
あの頃、私は問題を発見し、どっちりと部屋にこもってゼロから新しいツールを書き、それから皆に「ほら、もっと良い車輪を作ったから、これを使え」と言いに行くことに慣れていました。
しかしこれは極めて傲慢なやり方です。会社規模が数千名のエンジニアに達すると、新しいツールを無理やり推進することは、全員の既存のワークフローを破壊することを意味します。極大の抵抗に遭います。
真にE9レベルで影響力を発揮できるのは、「新しい車輪を作る」ことではなく、「誰も引き受けようとしない、極めて醜いシステム上の難題を解決し、全員を連れて行く」ことなのです。
ライアン：つまり、純粋な技術オタクから、極めて強い政治的手腕と説教能力を持つ技術リーダーに変わる必要があったということですか？
ボーリン：全くその通りです。その昇進失敗後、私は「コードを手書きする」誇りを捨てました。そして大量のエネルギーを「非標準自動化」（Non-standard automation）と部門横断調整に注ぎ始めたのです。
先ほど述べた仮想ファイルシステムEdenのようなプロジェクトです。このプロジェクトの抵抗は極めて大きく、低レイヤークライアントの修正だけでなく、バックエンドサーバーの全力協力も必要で、さらに全社数千人の開発習慣を変える必要がありました。
私は数ヶ月をかけて、もはやC++やJavaを書くのではなく、狂ったようにドキュメント（Tech Specs）や戦略計画を書きました。文書内で経営層に対し、この極めてリスキーなことがなぜやむを得ないのかを証明しなければなりませんでした。バックエンドのストレージチームを説得し、彼らに私たちのために専用のAPIを開発する価値があると信じさせなければなりませんでした。前線のビジネスエンジニアを安心させ、新システムがオンラインになっても彼らがデータを失わないことを約束しなければなりませんでした。
これは実に「ポイント稼ぎ」のゲームのようなものです。会社レベルの痛みを見つけ、さまざまなチームに散らばっているリソースをパズルのピースのように組み合わせて、最終的にこの戦いに勝利しなければなりません。
最終的にチームを率いて、その極めて醜いが極めて巨大で、無数の利害関係に絡むレガシーシステムの山を完全に片付けたとき、私のE9昇進は水到渠成の結果となりました。それは強請って得たものではなく、自然な帰結でした。
OpenAIへの参加、「研究主導」によるカルチャーショック
ライアン：メタでエンジニアの栄誉の頂点に達した後、多くの人を驚かせる決断をされました——11年間奮闘し、極めて得意としていた技術スタックを持つこの巨人を離れ、当時は現在ほど規模が大きくなかったOpenAIに転職されました。何がこの決断を促したのでしょうか？
ボーリン：メタでの最後の一年、私はある種の職業倦怠（Burnout）に陥っていました。低レイヤーアーキテクチャという分野に長くいたことで、天井をはっきりと見ることができていました。すべての最適化は限界効用逓減を迎えていました。一年かけても、あるシステムのパフォーマンスを5％向上させるだけかもしれません。このような繕い仕事は、私から当初の世界を変える興奮を奪っていました。
ちょうどその時、2023年末に大規模言語モデル（LLM）の波が完全に爆発しました。私は余暇を利用して、Transformerやアテンションメカニズム（Attention Mechanism）に関する論文を狂ったように読み始めました。そしてこれは全新の計算パラダイムであることに気づいたのです。
私は、この列車に乗り遅れれば、私の技術的キャリアはここで終わってしまうと感じました。ちょうどOpenAIが大規模エンジニアリング低レイヤーを知るベテラン人材を募集していたので、私は躊躇なく履歴書を送りました。
ライアン：伝統的なインターネット巨人から、波の頂点にあるAIラボに飛び込んだとき、最大の衝撃は何でしたか？
ボーリン：まさに天と地ほどの「カルチャーショック」（Culture Shock）でした。
メタやGoogleのような伝統的大企業では、その核心文化は「エンジニアリング主導」（Engineering-led）です。これは何を意味するか？ソフトウェアエンジニア（SWE）が会社の核心資産であることを意味します。プロダクトマネージャーが要件を出し、エンジニアがアーキテクチャとスケジュールを決定し、最後にコードを書いてリリースします。すべての栄光、リソース、昇進チャンネルはエンジニア中心に構築されています。
しかしOpenAIに足を踏み入れた瞬間、全く異なる空気を感じます——ここは「研究主導」（Research-led）なのです。
ここでは、真の核心の切り札は数学や物理学のバックグラウンドを持つリサーチャー（科学者）たちです。彼らの日々の仕事は、数式の導出、モデル構造の調整、lossカーブ（損失関数曲線）の観察です。
そして私たちような華やかな経歴を持つ大企業のトップエンジニアも、ある種「補助人員」になったのです。
私たちの責任はもはやプロダクトの方向性を決めることではなく、後方支援部隊のように、最も极致的な分散計算クラスターを構築し、GPUのメモリ利用率を最適化し、データクレンジングのパイプラインを構築することです。私たちのエンジニアリング上のあらゆる努力は、リサーチャーが次の実験を成功させるためのものなのです。
もしあなたが極めて個人的なヒーローイズムを渇望し、プロダクトをコントロールしたいエンジニアなら、この落差は非常に苦痛でしょう。しかし私個人としては、この状態を非常に楽しんでいます。なぜなら、この全新の分野では、私は「小学生」になったからです。私はE9の肩書きを捨て、再び科学者たちとの対話の仕方、極めて壮大な数学理論を何千何万枚ものH100グラフィックカード上で安定して動作するC++やCUDAコードに変換する方法を学び始めました。これは極めて刺激的です。
ライアン：これではOpenAIであなたが担当する核心プロジェクト——Codex（GitHub Copilotの基盤となる頭脳）について話さないわけにはいきません。聞くところによると、Codexは当初、ハッカソンから生まれたのだとか？
ボーリン：はい、それは極めて狂った週末でした。
実はOpenAI社内では、初期のコード生成モデルを使用して作業を補助していたエンジニアがずっといました。しかしある社内ハッカソンで、私たち数人が突発的に思いついたのです。「もしこのモデルをコマンドライン（CLI）で直接呼び出せるツールにカプセル化したら、どうなるだろうか？」
私は短時間で、粗雑なターミナルラッパーを書きました。結果、出てきた効果は皆の顎が外れるほどでした。ターミナルで英語で「現在のディレクトリ下の拡張子が.txtのすべてのファイルを.mdにリネームし、ファイル名の空白を削除して」と入力するだけで、瞬時に完璧に動作するPythonやBashスクリプトを生成するのです。
このツールは社内で即座にウイルスのように拡散しました。これはあることを証明しました。AIはコードの書き方を教えるだけでなく、面倒な雑務を直接代行してくれるのです。
これが後に、私たちがCodexのテストスイート（Harness）を完全にオープンソース化した重要な理由でもあります。私たちは开源コミュニティ全体に、これは魔術ではなく、実在のエンジニアリング標準であることを見せたかったのです。このような方法で、未来のAIコードアシスタントの評価基準を定義しようとしているのです。
ライアン：トップクラスの低レイヤーシステムエンジニアであるあなたが、現在、毎日どれだけの時間をコードを書くことに費やしていますか？
ボーリン：これは核心を突く質問で、最近私が最も多く考察している点でもあります。
以前の私は、私が言ったように、コードを書く機械でした。キーボードを軽やかに動かし、一行一行精巧なロジックを打ち込んでいく快感を極めて楽しんでいました。
しかし今、もし「昨日書いたコードのうち、どれだけが自分で手で入力したものですか？」と聞かれれば、非常に率直にお答えします：「おそらく10％もない。多くの場合、この数字は0に近い。」
私の毎日のワークフローは完全に変わりました。今私がしていることは、エディターを開き、実装したいデータ構造、インターフェースロジック、境界条件を詳細に記述した英文コメント（Prompt）を書くことです。それからショートカットキーを押し、数秒で数百行のコードが出力されるのを見ることが仕事です。
そして私の役割は、「作家」（Writer）から「レビュアー」（Reviewer）に変わりました。
私は二十年にわたって蓄積してきたシステムエンジニアリングの経験を駆使して、AIが生成したコードにメモリリークのリスクがないか、並行処理のデッドロック隠されていないか、あるエッジケースが無視されていないかを吟味します。あれば問題を指摘し、再生成させます。
最も解放感を覚えるのは、AIが私がかつて最も嫌っていたこと——ユニットテスト（Unit Tests）の作成やCI/CDスクリプトの設定——を引き受けてくれたことです。今では「上記の関数に対して100％カバレッジのテストケースを生成して」と言うだけで、極めて完備したテストコードを生成し、偽のmockデータまで自動的に生成してくれます。
これにより、構文の細部に生命を無駄にするのではなく、より高次元のシステムアーキテクチャ設計を考えるための大量の時間が生まれました。
ベテラン技術者からの最終的な提案：次元を下げて考え、次元を上げて打つ
ライアン：これは本当に衝撃的です。学校にいる人や、職場に入ったばかりの若いエンジニアにとって、E9の大御所がもはやコードを手書きしていないと聞くと、「AIがコードを書けるなら、一生懸命データ構造やアルゴリズムを学ぶ意味はあるのか？」とパニックになるかもしれません。彼らに何かアドバイスはありますか？
ボーリン：このパニックは大変理解できます。しかし明確にしておかなければならないのは、深い技術的基本（Deep Technical Skills）は、長い間、あなたの最も堅固な护城河（moat）であり続けるということです。
なぜか？現在のAIは本質的には確率モデルに基づいています。幻覚（ハルシネーション）を起こし、一見完璧に見えて実は致命的なバグを隠したコードを生成することがあります。
もし初級エンジニアが完全にAIに依存した場合、システムがオンラインでクラッシュし、何ギガバイトものログと乱雑なスタックトレースエラーに直面したとき、彼は手も足も出なくなります。低レイヤーで何が起きているのか全くわからないのです。
そして私が90％のコードをAIに代筆してもらっても、それほど自信を持てるのは、10％の低レイヤー制御力があるからです。私はC++のメモリ割り当ての低レイヤー原理を理解し、オペレーティングシステムのスレッドスケジューリングを理解しているので、AIが生成したコードを一目見ただけで、それが「でたらめ」かどうかを瞬時に判断できます。
この時代、AIはあなたの手にある無限弾倉の機関銃のようなものです。しかしどこを狙えばいいかわからず、弾詰まりの処理方法さえ知らなければ、この銃は自分を殺す武器にもなり得ます。
ライアン：個人の能力向上の面で、何か特別な経験を共有できますか？
ボーリン：システムの深みを上げたいエンジニア全員に強くお勧めしたいのは、CTF（Capture The Flag、サイバーセキュリティの旗取り競技）に参加することです。
これは私の個人的な小さな秘密です。極めて過激な低レイヤーのセキュリティホールを解決するとき、あなたはアセンブリ言語、レジスタの動作原理、ネットワークプロトコルの一つ一つのバイトを深く理解することを強いられます。このような極めて強い目的意識を持ち、パズルゲームのようなトレーニング方式は、教科書を暗記するより百倍効果的です。
また、もし技術書を推薦するなら、二冊を推します。一冊はオペレーティングシステムの低レイヤーに関するもの（例えば古典的な恐竜本）、もう一冊は技術文書の作成に関するものです。
ライアン：技術文書作成？それはあまり「硬派」に聞こえませんが。
ボーリン：これこそが最も高度な硬派なのです。
E9への昇進方法を総括したときに言ったように、数百人規模の部門横断プロジェクトを動かそうとするとき、あなたがどれほど良いコードを書いても無意味です。コードを全く知らないバイスプレジデントや財務ディレクターに、なぜこの極めてリスキーなことがやむを得ないのかを説得できる、極めて明確で説得力があり、論理厳密なビジネス/技術文書を書く必要があります。
もしあなたがコードを書くだけなら、せいぜい高度な職人でしかありません。しかしあなたが文章を使って壮大な技術ビジョンを構築し、全員が心からあなたに従ってくれるなら、あなたこそが真の技術リーダーです。
ライアン：マイケル、本当にありがとうございました。あなたは私たちに、伝統的なソフトウェア時代からAI時代へと移行する極めて素晴らしい個人的縮図を示してくれました。
ボーリン：招待していただきありがとうございます。ここで踏んだ坑（くぼみ）や流した血を皆さんと共有できて嬉しいです。今も深夜にデバッグを続けているすべてのエンジニアたちに、幸運を祈ります。