ソースは https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f77... で、アーカイブは https://archive.is/hLd8X にあります。

リンクありがとう。でも、変なことに、archive.isの「私はロボットではありません」っていう壁を越えられないんだよね。クリックしてリフレッシュされて、またクリックして、今度は信号機を探せって言われて、また「私はロボットではありません」って繰り返し。これ、誰かにやってもらわないと無理かも…

低品質なコードの出力が多すぎるのを、固定されたものとして扱ってそれを基に運用するのが持続可能な解決策かは疑問だけど、まあ、そういうこともあるよね。

2000年代初頭のオフショアリングのエピソードと同じだね。低品質なコードをなんとか機能させようとする巨額の財政的インセンティブがあるんだ。彼らはそれが大きなマイナスだって現実を受け入れるのをできるだけ長く抵抗しようとするだろうね。

この「必須ミーティング」って、最近の運用問題を話し合う毎週の会社全体のミーティングに過ぎないよ。先週大きな運用問題があったから、今週は参加者も多くて話し合いも増えるのは当然。これ、毎週やってるし、何年も続いてるから。メディアが大げさに騒いでるだけな気がする。

> メディアが大げさに騒いでるだけな気がする。ケーブルニュースが登場して以来、ずっとそういう仕事をしてるよね。

記事にはこう書いてある: 「彼はスタッフに通常は任意の会議に出席するよう求めた。」これって間違いなの？それに新しいポリシーについても触れてる: 「ジュニアや中堅のエンジニアは、AIを使った変更に対してシニアエンジニアの承認が必要になる」とトレッドウェルが追加した。これも不正確なの？定期的に行われる会議であることは良い文脈だけど、定期的な会議でもニュースバリューのある出来事が起こることはあるよね。

その会議には参加してないけど、週次のオペレーション会議がメディアの注目を集めるなんて、ちょっと笑っちゃった。アマゾンではずっとそういうことだよ。CoEのことが公に知られるのを待ってみて！

ニュースにはならなかったみたいだけど、少なくともNYCでは金曜日の午後ずっとアマゾンのストアが壊れてたよ。アイテムの価格が表示されなくて、カートに何も追加できなかった。午後2時から5時まで続いたんだ。特に変なのは、もしコンピュータの不具合でウォルマートみたいな大手小売業者がダウンしたら、もっと何か見かけると思うのに、彼らの売上は低いからかもね。

僕の経験では、グループ単位でやってると思うよ。AWSは週次のオペレーションミーティングを始めて、実質的に前の週のすべてのサービスのオンコールが参加しなきゃいけなかったんだ。それが大きくなりすぎて、オプションになったけどね。AlexaもAWSのやり方を真似しようとした似たようなミーティングがあったよ。ホリデーシーズンやプライムデー、スーパーボウルに向けて負荷テストをレビューするのにたくさんの時間を使ってた（スーパーボウルの広告はAlexaにとって狂ったTPSスパイクを引き起こしてたから）。もし一つのチームで障害があったら、指を指し合うことも多かった。運用の基準を上げるのには役立ったかもしれないけど、エンジニアたちがエラーや修正を文書化するために忙しい仕事や書類作業に無駄な時間を使ってたのは残念だよね。

> このミーティングは文字通り毎週行われていて、何年も続いてる。メディアが大げさに言ってるだけじゃない？提出のポイントを完全に見失ってるんじゃない？「アマゾンが毎週必ずミーティングをやってる」ってことじゃなくて、その特定のミーティングの内容について、AI支援のツールが「インシデントの傾向」を引き起こして、「大きな影響範囲」を持ち、「ベストプラクティスと安全策がまだ完全に確立されていない」ってことなんだ。一般的にミーティングがどれくらいの頻度で行われているか、またはそれが義務かどうかなんて誰も気にしてないよ。

記事の核心メッセージは、アマゾンがAIの不具合で運用の信頼性に問題を抱えているということで、これは100%正確なようだね。

ここで言っている「メディア」って誰のこと？これはツイッターポストだよ。私の知る限り、彼らはメディア会社で働いているわけじゃない。気になるのは、どうして人々がSNSで情報を使ったり、消費したり、広めたりすることについてすぐに「メディア」を責めるのかってことだね。

> 現在の対応？ジュニアとミッドレベルのエンジニアは、シニアの承認なしにAI支援のコードをプッシュできなくなった。つまり、シニアエンジニアの生産性を殺し、ジュニアエンジニアが何かを学ぶ能力を奪い、シニアエンジニアが自分の仕事を嫌いになるようにしてる。大胆な動きだね、どうなるか見ものだ。

人が燃え尽きるまでのスピードを加速させるって感じだね。

え、何それ？ジュニアエンジニアはAIアシスタントを使わないと何も学べないってこと？（それとも、シニアが彼らのコードをレビューすることで学べなくなるってこと？）シニアエンジニアは仲間のコードをレビューするのが嫌だって？今の人たちはどんな現実に生きてるの？

ジュニアは昔ながらの方法でコーディングすればいいんじゃない？そんなに難しくないし、もしそれが難しすぎるなら、この仕事に向いてないってことだよ。

> ジュニアとミッドレベルのエンジニアは、シニアの承認なしにAI支援のコードをプッシュできなくなった。シニアのレビューは、マネージャーが抱える最大の「銀の弾丸」幻想の一つだよ。誰か（シニアでもそうでなくても）が、自分の経験レベルに近い結果を確認するために必要な粒度でコードや設定を検証するには、実際に自分でやった場合にかかる時間に近い時間がかかるんだ。つまり、シニアのレビューは価値があるけど、悪いコードを良くするわけじゃない。これが、過去数十年のシステム管理における最大の問題の一つの重要な側面だと思う：何かを「バカに優しい」ものにすることが、バカを雇えるようになるっていうマネジメントの誤解。

そうだね、コードレビューはすでに人間が書いたジュニアのコードで行われているべきだよ。AIが生産性を向上させて、ジュニアが10倍のPRを生成するなら、シニアも10倍必要なのか、それともジュニアを1/10に減らしてコストを抑えるべきなのか。多くの状況では、純粋なコードの速度が制限要因ではなかったことを思い出してほしい。バカな証明についてだけど、企業が大きくなるにつれて、リスクを制限し、中央値を管理しようとするのは自然な進化だと思う。成長マインドセットで採用や解雇、パフォーマンスを考えるのではなくね。

専門家のレビューは、AI生成コードを実用的にする唯一の方法だと思うけど、後からやるのはちょっと怪しいよね。効率的にするためには、モデルが動いてる間に何をしているかを見守る必要がある。チェックなしだと、AIモデルはバグだらけで非効率なコードを出力する。小規模なグリーンフィールドではそれほど悪くないけど、大規模なコードベースでは、全体像にアクセスできないからパフォーマンスが悪くなる。私の経験では、モデルが機能を実装するのにかかる時間の5〜15倍をレビューやエラー修正に使うべきだよ。それを専門家の目でやれば、変更は通常高品質で正確になる。そうしないと、モデルはおそらく人間が同じ時間で出力できる量の100倍もの低品質なコードを生成する。チェックなしだと、最もやる気のあるジュニア開発者の小さな軍隊がコードベースで完全に暴れ回ってるみたいなもんだ。

でも、いいインセンティブを生むかもしれないね。もし僕がジュニアで、AIを使うたびにシニアに仕事を見せなきゃいけないとなったら、使い方にもっと選別をかけるし、使うときはもっと慎重になると思う。AIはすごくスムーズに使えるから危険だし、これが摩擦を加える方法かもね。まあ、典型的なジュニアエンジニアの考え方について、僕は正しいメンタルモデルを持ってないかもしれないけど。できるだけシニアに迷惑をかけたくなかったから。

> 自分でやった場合にかかる時間に近い時間が必要 だって、雑なものを直すのって、最初から書くよりも実際には難しいことが多いから。直すには、元のものと新しい解決策の両方を頭に入れて、その違いを計算しなきゃいけないから、すごく混乱することもあるんだよね。元の解決策が問題へのアプローチを固定してしまうこともあって、それがなければ最初から解決することができるのに。

キャリアの初期に、メンターから「コードレビューはバグを見つけるためじゃなくて、コンテキストを広めるためだ（つまり、バスファクターを増やすため）」って言われたことがある。バグを見つけるのは副産物で、たくさんの人に各プルリクエストをレビューしてもらわない限り、基本的にはギャンブルみたいなもんだよね。もっと高くて地味な選択肢は、実際にテストを簡単にすること（プログラム的にも手動でも）、もっとテストを書いて、テストのレベルを増やして、コードの複雑さを減らすために時間を使うことだと思う。問題なのは、問題を未然に防ぐことで昇進する人が少ないことだよね。

なんでAI生成のコードだけなの？ジュニアやミッドレベルの開発者のコードを本番環境に出す前に、少なくとも既知のホットスポット—同時実行性やセキュリティ、データベーススキーマ、他のいろんな非機能要件を確認しないなんてありえないよ。本当に使いやすさや要件、セキュリティ以外で、誰かが作ったランダムなウェブサイトをレビューすることはないと思う。

彼らがシニアレビューアがAIのバグを徹底的に探して修正すると思っているとは思えない。仮にできたとしても、時間がないだろうしね。でも、他の利点もあるんだ。1. 詳細を見ずにAIの使用が適切かどうかを評価できる。例えば、AIが小さなバグを修正するために1000行のコードを変更したり、セキュリティにとって重要なコードを変更したりした場合。2. AIの使用を抑制するため、追加の摩擦を生むこと。

つまり、シニアレビューは価値があるけど、悪いコードを良くするわけじゃないよね。多分、それが目的じゃないと思う。シニアの人がレビューすることで、ジュニアからシニアに責任が移るし、「ああ、ジュニアが何も知らずに全部壊しちゃった」から「うーん、そのシニアが承認したコードが全部壊れたから、パフォーマンスが悪い」って問題の見方が変わるんだよね。

シニアはジュニアに対して、理解しているかどうかをしっかり確認しないとダメだよ。そうじゃないと、ジュニアが意味不明なことをいっぱい提出して、いつも「あなたのせいで詰まってる」って言ってくるのが、ほんとに辛くなるから。

「バカを雇うな」以外に、この問題の解決策は何かある？あなたに同意するし、この特定のシステム管理の問題はソフトウェアに限った話じゃないよね。

これが本当なら、コードレビューの主な目的を誤解してるね。コードレビューは（主に）重大なエラーを見つけるためのものじゃない。常にエラーが多いなら、レビューでほとんどを見つけるのは無理だし、エラーが少ないなら時間の無駄だよ。目的は、チームがデザインや基準について同期していることを確認すること。ジュニアエンジニアを教育し、システムの理解を広めること。複雑で重要な決定に多様な視点を持ち込むこと。これらの目標が、レビュー過程に入るエラーの数を減らす助けになるべきなんだ。

PRの時にAI生成コードをレビューするのはボトルネックだね。シニアリーダーシップが考えてるAIの利点（納品スピード）をほとんどキャンセルしちゃう。エンジニアがあまり好まない暗黙の不均衡もあるしね。僕はClaudeのおかげで10分で完全な機能を提出できるけど、手動でPRをレビューする人にはその10～20倍の時間がかかる。編集：結局、本物のエンジニアは、努力が必要なのはa) 何を作るべきか、なぜそれを作るべきかを知ること、b) 作ったものが正しいかどうかを確認することだって知ってる。今のところ、AIはこの2つのポイントにはあまり役立ってない。中間的な部分は必要だけど、それは副産物なんだ。シニアリーダーシップはこれを知らないけどね。

このポリシーについて理解できないのはこれなんだ。シニアが自分より下のAIによるPRのゲートキーパーになるほどの余裕があるわけないじゃん。だから、シニアたちは追いつくためにもっとAIを使うようになるけど、今度はそれを許してしまったことで責められることになる。シニアにとっては、プロのコードレビュアーを意味するなら、すごく損な話に聞こえるよ。

確かに。CEOとしての私の見解は、もし自分でコードをレビューしているなら、どれだけ早くテキストを生成できても意味がないってこと。人には質の高いコードを書いてもらって、進めながらチェックしてほしいし、思いつかなかったことも出てくる余地を残しておきたい。LLMを使うプロセスは全く違うから、今の状態ではメリットが見えない。例えば、もし自分が求めているものが非常に明確なら、エンジニアにLLMを使って書かせる理由はないよね。LLMは生産とレビューの両方をこなせないから。これが変わる可能性はあるけど、今のところ私にとってそのやり方にシフトするメリットはないよ。まずはその仕組みが整ってから、ビジネスに影響を与えるリスクを背負いたくない。包括的な解決策が欲しいんだ。

彼らはこれを全部知っているはず。AIコードがコードベースの品質を低下させることを心配しているから、ブレーキをかけているんだ。

> シニアリーダーシップはこれを知らないんだよね。まあ、シニアリーダーシップは自分たちのビジネスや人がどう動いているかを知っておくべきだと思うけど。

アマゾンにとって、これは本当に悪い印象だね。長年働いている人たちの大量離脱、二流のAI製品、そして一連の悪い障害が、現在のリーダーシップがかつて尊敬されていたエンジニアリングの列車が脱線している様子を描いている。内部からのニュースでは、状況がかなり悪化しているように聞こえるよ。

私が知っているアマゾンでは、人々はただ「解雇されないこと」と「昇進」を気にしているだけだよ。開発者にとってのマトリックスはこんな感じ：1. 出荷：チケットを届けるか、ピップされるか。2. PRのコメントが少ないこと：何故か、PRが徹底的にレビューされるのは悪い品質のサインとされている。L7以上はこの指標を使って人をピップする。3. ドキュメント：ドキュメントを書いてレビューを受けて、高レベルであることを示す。AIなしでは、従業員は上記のすべてにおいて、先に進むためにズルをする人たちよりも不利だよ。「自分の自己防衛を放棄するように」と人に頼むのがどう機能するのか、全然想像できない。特に何年も人を対立させてきたのに。

PRにコメントが多すぎるのも良くないけど、他の人のPRにコメントを残さないのも良くないよ。どちらも重要な指標なんだ。

AIがあるから、チームをスリムにするのは理にかなってるね。速く進むためには、より大きな責任が求められる。