AIを拒んだ最高のエンジニアは、半年後、最高ではなくなっていた

出典: My Best Engineer Refused to Use AI. Six Months Later, He Was No Longer My Best Engineer.

彼は最後まで、チームで最も強いエンジニアの一人でした。コードは誰よりもきれいで、本番環境に対する勘は抜群で、他の誰にも読み解けない障害を追い詰めることができた。そこは何ひとつ変わっていません。変わったのは、彼を取り巻く仕事のほうでした。

アレックスはコーディングエージェントを嫌っていました。苦手、というレベルではありません。嫌悪していた。社内に導入した初日、彼は二十分ほど触って、そのまま閉じました。

「これ、俺は遅くなる」

冗談だと思って笑ったのを覚えています。

彼は十年以上コードを書いてきた人間でした。コードベースを誰よりも把握していて、頭の中に異常な量のコンテキストを保持でき、知らないシステムの中をドキュメントを引かずに歩けた。

だから、本当に彼にとっては遅いのかもしれない。そう思って、放っておくことにしました。当時は、まったく妥当な判断に思えたのです。

半年後、私は社内で最も重要なプロジェクトから彼を外しました。あれが正しかったのかどうか、今でも考えています。

問題は、アレックスが優秀なままだったこと

これがもし「彼がダメなエンジニアになった話」なら、ずっと簡単でした。そうではなかった。

彼のPRは誰のものより小さく、抽象化はいい意味で退屈で、他の人間が存在すら忘れている失敗パターンにテストを書いていた。本番で何かが壊れたとき、真っ先に呼びたい相手であり続けた。

チームのPRを十件、匿名で並べたら、上位には高い確率で彼のものが入ったはずです。

だからこそ、次に起きたことは説明しづらい。彼個人のアウトプットは強いままだった。ただ、周りが猛烈に速くなっただけでした。

最初、差はごく小さかった

誰かがエージェントにテストスイートを書かせる。アレックスは手で書く。向こうが四十分早く終わる。誰も気にしませんでした。

誰かが未知のSDKをAIに探らせて、雑な繋ぎ込みを作る。アレックスはドキュメントを読む。彼のほうが遅い。でも実装はきれいでした。それでよかった。

やがてツールが良くなりました。みんな、補完以外の用途に使い始めた。

マイグレーション、テスト生成、デバッグの当たりをつける作業、ドキュメント、似たようなエンドポイントの量産、リファクタ、SQLの分析、インフラのテンプレート、最初の叩き台。次々に委ねられていきました。

差は開きました。ただ、それ以上に興味深いことが起きていた。AIを使うエンジニアたちは、楽をするようになったのではなく、より多くのことに手を出すようになったのです。

アレックスが見誤ったのは、そこでした。

AIは彼らの思考を代替しなかった。思考の置き場所を変えた

ノアというエンジニアは、以前なら午前中いっぱいを使って機能の退屈な骨組みを組み、そこからようやく難しい設計の話に入っていました。

その骨組みが二十分で出てくるようになった。結果、彼は午前中ずっと難しいところを考えることになりました。

別のエンジニアは、何かを書き始める前に三つの実装案をエージェントに出させるようになりました。二つは却下。三つ目が、彼女の想定になかったトレードオフを浮かび上がらせた。

また別の一人は、触ったことのないサービスをAIに説明させてから着手するようになった。説明は不正確でした。それでも、まともな問いを立てられる程度の足場にはなった。

彼らは判断を外注していたのではありません。判断に使う時間を買っていた。

アレックスの目に映っていたものは違いました。自分で書いていないコードを量産する人たち。そして彼は、それを信用していなかった。

言い分はありました。

そしてAIが、美しいバグを出荷した

ある午後、エージェント支援で書かれた変更がレビューを通り、テストを通り、ステージングを抜け、本番に出ました。

それは間違っていた。

厄介だったのは、あからさまに間違っていなかったことです。実装はきれいで、テストは妥当に見え、抽象化は筋が通っていた。「機械が吐いたゴミ」の匂いはどこにもしなかった。

しかし特定のリトライ順序の下では、その処理が二回走り得た。

見つけたのはアレックスでした。五分ほどコードを眺めて、彼はこう訊いた。

「これ、成功したけど ack がタイムアウトしたらどうなる?」

部屋が静まりました。再現しました。彼が正しかった。高くつく前に直せた。

その後、彼からメッセージが来ました。

「これが、俺がずっと言ってたことだよ」

その通りでした。そして同時に、間違ってもいた。

この「両方成り立つ」という感覚こそが、問題のすべてでした。

彼は、障害を捕まえたことがツールの無用さの証明だと考えた

私は逆のことが証明されたと思っていました。

エージェントは、人間が手で書くより速くコードを出した。そのコードには微妙な欠陥があった。経験あるエンジニアがそれを捕まえた。

アレックスにとって、それは「だから人間が書くべきだ」という意味でした。

私にとっては、「だから人間が判断を引き受けるべきだ」という意味だった。

これはまったく別の結論です。

電卓が数字を出したからといって、その数字が妥当かどうかを理解する責任は消えません。コーディングエージェントが実装を出したからといって、それが本番で何を起こすかの責任は消えない。

ただし、誤用され得るからといって電卓を拒むのは、厳密さではない。どこかの時点で、それはただの頑固さになります。

このときはまだ、彼にそう言いませんでした。言うべきだったのだと思います。

そして、その年で最も重要なプロジェクトが始まった

大規模な社内基盤の移行でした。複数サービス。醜いレガシー挙動。不完全なドキュメント。クリーンな書き直しを誰も信用できない程度には、古いコードの中に業務ロジックが埋まっている。

技術リードとして、アレックスは明らかな第一候補でした。ドメインを理解し、経緯を知り、どこに死体が埋まっているかを把握していた。

彼に任せました。

三週間後、プロジェクトは遅れていました。壊滅的ではない。けれど、見てわかる程度に。

似た規模の移行を担当していた別チームは、その頃すでにレガシーの表面をおおむね洗い出し、重要経路に特性テストを敷き、移行スクリプトを組み、新実装の検証に入っていました。

アレックスのチームは、まだ古いサービスを丁寧に読んでいた。

理由を訊くと、彼は言いました。

「何を置き換えるのか、ちゃんと理解したいからだ」

反論しづらい一文です。だからしませんでした。

さらに二週間。差は広がりました。

もう一方のチームは、雑ではなかった

ここが、私の「放っておく」という判断を完全に崩した部分です。

手抜きが見つかるつもりで彼らの成果物をレビューして、居心地の悪いものを見つけました。彼らは自分たちのシステムを理解していた。

エージェントは機械的な探索の加速に使われていた。モジュールの要約、呼び出し経路の追跡、繰り返しパターンの抽出、特性テストの草案、スキーマ比較、移行の足場づくり。

そのうえで、重要な部分は人間が検証していた。

理解を置き換えたのではない。理解に到達するまでの道のりを速めていた。

アレックスは、手を動かすこと自体が理解の証拠だと信じて、すべての工程を手作業でやっていた。

それは証拠ではありません。ときには、ただの手作業です。

ツールを使ってくれ、と頼んだ

全部に、とは言いませんでした。生成されたコードを無検証でマージしろとも言っていない。

低リスクの探索作業にAIを使い、出力は他人のコードをレビューするのと同じ目で見てくれ、と頼んだ。

彼は断りました。理由は強力でした。

「全部検証しなきゃいけないなら、自分で書いたほうが早い」

賢そうに聞こえる一文です。そして、いま我々の業界で最も危険な考え方の一つでもある。

なぜなら、我々は常に検証しているからです。

シニアは自分が書いていないコードをレビューする。アーキテクトは自分が描いていない設計を評価する。実装していないライブラリを信頼し、ストレージエンジンを再実装できないデータベースを運用している。

エンジニアリングとは、自分の判断の下にある全レイヤーを自分で生産することではありません。どこで信頼を打ち切るかを知っていることです。

五週間後、技術リードを交代した

プロジェクトはノアに渡しました。アレックスはチームに残った。

ドメイン知識が決定的に効くいくつかの重要領域は、引き続き彼のものでした。ただ、移行を率いる立場ではなくなった。

彼は受け入れませんでした。私が彼でも同じだったと思います。面と向かって訊かれました。

「AIを使わないことへの罰か?」

違う、と答えました。そして家に帰ってから、それが完全な真実ではないことに気づきました。

彼は特定のツールを拒んだことで罰せられたのではない。彼のやり方が、その役割に必要な結果を出せなくなったから、責任を失った。

この区別は私にとって重要でした。彼にとって重要だったかどうかは、わかりません。

ここで多くの人が怒り出すはずです

言い分は想像がつきます。「会社はエンジニアを成果で評価すべきであって、その年の流行りのツールを使うかどうかで評価すべきではない」

完全に同意します。そして、だからこそリードを替えたのです。

もしアレックスがAIなしで必要なペースを出せていたなら、十五年前のThinkPadでVimを使って書いていようが気にしませんでした。ツールはどうでもいい。結果はどうでもよくない。

ただ、「成果で評価しろ」という主張には、居心地の悪い帰結が含まれています。

成果ベースの評価を要求しながら、他人が出せる成果を実際に変えてしまうツールを無視することはできない。判断力が同等の二人がいて、片方が機械的作業を何時間分も消せるなら、その差はいずれ効いてきます。

道徳の問題ではありません。経済の問題です。会社は実装の苦しみに対して金を払っているのではなく、その向こう側にあるシステムに払っている。

ところが、ノアがアレックスの正しさを証明しかけた

二か月後、ノアが移行計画を持ってきました。優れた内容でした。依存関係の詳細なマッピング、ロールバック戦略、互換期間の設計、データ検証、可観測性、明確なマイルストーン。

感心しました。アレックスはしませんでした。彼は質問を一つしただけです。

「互換ウィンドウ中に作られたアカウントは、旧サービスがバックフィルのチェックポイント後にリトライしたらどうなる?」

誰も答えませんでした。

追っていくと、穴がありました。かなり悪質なやつが。

その移行は、こちらの突合プロセスでは必ずしも検出できない不整合状態を作り得た。AI支援の分析はそれを見落としていた。ノアも見落としていた。私も見落としていた。アレックスは見落としていなかった。

二度目でした。AIを拒むエンジニアが、AIを使う全員が見逃した失敗を掘り当てたのは。

それで、状況の見え方がまた変わりました。

アレックスはAIについて間違っていた。私はアレックスについて間違っていた

私はチームを「適応した側」と「抵抗した側」の二方向で捉えていました。単純すぎた。

実際にそこにあったのは、二種類の能力でした。

ノアは自分の射程を広げることが異常に上手くなっていた。より大きなシステムを速く探索し、より多くの案を試し、機械的な作業をアレックスの追いつけない速度で抜けていく。

アレックスが持っていたのは、ツールがまだ安定して提供できないものでした。疑い。火傷の痕。きれいなアーキテクチャを見て「これを偽にする醜い本番条件はどれだ」と訊く本能。

両方が必要だった。片方がもう片方を置き換えるはずだと考えたことが、間違いでした。

だから、彼をプロジェクトの中心に戻した

技術リードとしてではありません。そこは変えなかった。ノアのままです。

代わりに彼は、設計を攻撃する人間になりました。主要な移行判断はすべて、我々が冗談半分に「アレックス・テスト」と呼び始めたものを通過することになった。

彼の仕事はアーキテクチャを承認することではない。壊すことです。リトライ。部分障害。並行性。古いデータ。ロールバック。イベントの重複。ネットワーク分断。きれいな抽象の裏に隠れた雑な前提。

そして、面白いことが起きました。

ノアはさらに速くなった。アレックスはさらに価値を持った。AI生成のコードは増えた。同時に、精査も増えた。

この組み合わせは、どちらの極端よりも良かった。

それでも、エンジニアはAIを学ぶべきだと思っています

ここで読者の半分は反対するでしょう。それで構いません。

AIを拒むことが原則的な態度だとは、もう思いません。

多くのエンジニアリング職において、これらのツールを学ばないことは、いずれ職業上高くつくようになると考えています。AIが魔法だからではない。レバレッジが効くからです。

強力なツールを下手に使うエンジニアは、ゴミを速く生産できる。強力なツールを上手く使うエンジニアは、機械的な出力に費やす時間を減らし、難しい判断に費やす時間を増やせる。

その差は複利で効きます。

ただし、業界のもう半分も、同じくらい馬鹿げた間違いをしている。速度をエンジニアリング能力と取り違えている。

五倍のコードを出せることは、五倍の価値を意味しません。ときには、五倍危険であることを意味します。

私がいま欲しいのは、アレックスでもノアでもない

その組み合わせです。

レバレッジを崇拝せずに使うノアの姿勢と、「正しく見える」という理由だけでは何も信用しないアレックスの姿勢。

レガシーシステムの地図を十五分でエージェントに描かせ、そのあと一時間かけてその地図が間違っていることを証明しようとする。そういうエンジニアが欲しい。

三つのアーキテクチャを素早く生成し、三つとも却下できる判断力を持っている人間が欲しい。

AIの出力を、真実としても汚染物としても扱わない人。ただの作業物として扱う人。現実との接触を生き延びなければならない作業物として。

これは、プロンプトを書くことよりずっと難しいスキルです。

半年前、問いは「エンジニアはAIを使うべきか」だと思っていた

違いました。

本当の問いは、全員が使うようになった後に、固有の価値として何が残るのかです。

タイプ速度? おそらく残らない。ボイラープレートの知識? 年々薄れていく。構文の記憶? もう消えつつある。

しかし、リトライ一つが無害に見える処理を金銭事故に変え得ると知っていること。結果整合性が許される場面と、誰かが金を失う直前の場面を見分けられること。移行計画は、新旧のシステムがロールバック中に食い違うまでは完璧に動く、と知っていること。

それは別物です。

AIは答えを出すコストを下げた。答えに責任を持つコストは下げていない。

それは、私より先にアレックスが理解していたことでした。彼はツールを拒んだ点で間違っていた。私は、ツールを使えることのほうが深いスキルだと考えた点で間違っていた。

深いスキルは、いつ信じないかを知っていることでした。

そしてこの移行期を生き延びるエンジニアは、たぶん両方の陣営を居心地悪くさせるのだと思います。彼らはAIを絶え間なく使う。そして、ほとんど信用しない。

---