コードのコストが崩壊した後のエンジニアリングマネジメント

私は3年以上エンジニアリングディレクターを務めていますが、私が「古いルール」と呼ぶものを繰り返し耳にしたり読んだりしています。ディレクターはコーディングに時間を費やすべきではない、良い仕事には時間がかかる、チームをビジネスから守る、コミットする前にコンセンサスを得る、などです。 しばらくの間、これらのセリフを繰り返す人々は遅れていると思っていました。それから私たちの組織にLLMが導入され、コード生成のコストが下がり、私は各ルールをその根底にある仮定に対してチェックし始めました。驚くべき発見は、古いルールの約半分が壊れた仮定の上に成り立っており、残りの半分はそうでない仮定の上に成り立っており、そのうちのいくつかは以前よりも今の方が重要であるということでした。 以下は、過去1年間に蓄積したメモを整理したものです。Gemini 4が編集を手伝いました。 実際にわかっていること もっともらしいコードを生成するコストは崩壊し、元に戻ることはありません。それ以上のほとんどの主張は、証明されていないか、間違っています。 AIツールがエンジニアリング組織を劇的に速くした：証明されていない。 コードレビュー、ドキュメンテーション、オンボーディングは時代遅れである：間違っている。 同じロードマップを半分の人数で実行できる：事実ではなく、賭けです。 管理プラクティスを狭い主張に基づいて再構築すれば、あなたは正しいでしょう。広範な主張に基づいて再構築すれば、あなたは他人のキャリアを賭けており、それを結論と呼んでいます。 仮定の監査に焦点を当てる すべての管理プラクティスは、特定の仮定に基づいています。ベロシティ追跡は、出力が出力に対する有用な代理であるという仮定に基づいています。6ヶ月のオンボーディングは、構文を学ぶのが遅いという仮定に基づいています。コンセンサス駆動のアーキテクチャは、変更が高価であるという仮定に基づいています。人員計画は、出力が人と共にスケールするという仮定に基づいています。 各プラクティスに関する質問は、その古さではなく、プラクティスが実際に何に基づいているかです。 プラクティスがコードを書くコストに基づいている場合、それをレビュー対象にしてください。なぜなら、そのコストは移動したからです。それが人間の調整方法、信頼の構築、注意の割り当て、または正しさの検証に基づいている場合、それがどれほど時代遅れに見えても、それについて何も変わっていません。 これは明白に聞こえますが、多くの人が感覚でソートしていると思います。モダンに見えるものは残り、古いものは去ります。それは、有用な摩擦を放棄し、無用なプロセスを維持するチームを生み出します。なぜなら、プラクティスの年齢とプラクティスの妥当性は無関係な変数だからです。 証拠はノイズよりも小さい あなた自身のチームを含む、誰かが大規模なスピードアップを報告し、それだけを報告する人には疑いを持ちなさい。私が知っている利点は、グリーンフィールドワーク、定型的なコード、および不慣れな領域で明確に現れます。それらは、エンジニアがすでに理解しているシステムでの深い作業では、フェードするか、逆転します。私は、古いレポートや研究が基づいていたモデルの機能を完全に凌駕した2025年第4四半期以降に行われたデータと研究を非常に楽しみにしています。 しかし、感じられる速度と測定される速度の間のギャップ自体が管理上の問題です。エンジニアがより速く感じて、より多くの欠陥で同じ量の出荷をする場合、あなたは間違った人員配置をし、間違った計画をし、ビジネスとの期待を設定しますが、あなたは満たすことができません。AIを採用する組織での最初の仕事は、加速したかどうかを正直に伝える計装です。 安価なものの弱い代理 ベロシティ、プルリクエスト数、クローズされたチケットは、常に不完全でした。それらが存続したのは、それらが近似していたもの、つまりコードを書く労力が本当に希少であったため、ノイズは許容範囲内に収まっていたからです。 今、代理されているものは安価です。それはメトリックを単に不完全にするのではなく、実際に積極的に誤解を招くものにします。なぜなら、それらを増やす最も安い方法はボリュームを生成することであり、ボリュームはあなたの組織がもはや不足していない唯一のものであるからです。 AI固有のメトリックは間違った問題を解決します。受け入れ率とプロンプト数は、新しい形式で同じ間違いだと思います。耐久性のある動きは古く、より困難です。ビジネスの成果とシステムの健全性を測定し、コードボリュームを称賛される出力ではなく、正当化されるコストとして扱います。優秀なエンジニアはLLMの前にこれを言っていました。それは当時真実でした。それは今、施行可能であり、それは以前はそうではありませんでした。なぜなら、より多くのコードを書くことが難しい部分であったと誰も主張できないからです。 「正しい」ことには（今のところ）時間がかかる 良い仕事には時間がかかるというルールは、きれいに2つに分かれます。 配管時間は崩壊しました。サービスのスキャフォールディング、テストの生成、フレームワーク間の翻訳、移行の最初のドラフトの作成：これらすべてが今や速くなり、これらのコストに基づいたあらゆるタイムラインは圧縮に値します。 正確性の時間は2つに分かれます AIシステムは、人間レビュアーよりも速くコードをチェックし修正できるようになりました。そうでなければ、信憑性を失います。 一方、機械的な検証は崩壊しています。タイプ、テスト、契約、リンティングルール、不変条件、カナリアメトリックなど、正しいことが機械が評価できる形式で表現できるものはすべてです。エージェントはテストループを実行し、失敗を読み、差分を修正し、それを再度実行します。レビュアーの速度には及びません。あなたの正確性がこのレイヤーに存在する場合、チェック時間は実際に低下しており、低下し続けます。しかし、このレイヤーを速くしているものに注意してください。それは、誰かがすでに正しいとは何かを書き留めており、機械が評価できる形式であるため、速いのです。仕様が作業を行い、チェッカーがそれを読みます。 意味論的な検証は別の問題です。コードは、ビジネスが実際に必要としているポリシーを実装していますか？このトレードオフは、規制上のエクスポージャーに合致していますか？ここでは、正しいことは人間の頭と組織の歴史にあります。AIがAIをチェックすることには構造的な問題があります。チェッカーは、ジェネレーターと同じトレーニングデータ、バイアス、および盲点を共有しています。両方のレイヤーは、同じ理由で同じ場所で失敗します。自己レビューはタイプミスを検出します。それは共有された誤解を検出するものではありません。 私は3つの結果が続くことを信じています。そして、この投稿の核心です。 単価は下落し、総作業量は増加します。安価なチェックはより多くの生成を招き、より多くの生成はより多くのチェックを要求します。個々のチェックは安くなりますが、検証作業量はボリュームとともに増加します。正味の暦時間は曖昧であり、インシデントプロファイルはシフトします。単純なエラーは減りますが、システム的なエラーは増えます。なぜなら、高ボリュームのもっともらしい出力が、高ボリュームのもっともらしいレビューを通過するからです。 境界は戦略的な変数です。あなたの正確性のどれだけが機械でチェック可能かは固定されていません。それはあなたの仕様、契約、および不変条件の関数です。強力な仕様を持つチームは、安価なチェックの恩恵を完全に受けます。弱い仕様を持つチームは、生成したのと同じ機械によってレビューされる生成コードを受け取ります。機械でチェック可能な正確性への投資は、組織が資金提供できる最もレバレッジの高いインフラストラクチャ作業の1つです。なぜなら、それはこの波のどれだけを実際に使用できるかを決定するからです。 検証の最も遅い部分は、チェックではなく、アカウンタビリティでした。誰かが署名し、誰かが間違っていることの結果を吸収します。インシデントレビュー、規制当局、顧客。署名時間は圧縮されません。なぜなら、それは情報処理ではないからです。それはリスクの受容であり、法的および信頼システムはそれを人々に割り当てます。 したがって、検証は依然としてスループットを設定します。移動したのは制約の場所です。チェック速度から仕様の品質へ、そして結果を所有することに特定の人間が同意するかどうかへ。 ジュニアパイプラインは未解決の問題です 誰もこの環境でエンジニアを訓練する方法を知りません。 シニアエンジニアに求められる判断は、歴史的にはAIが吸収する作業を行うことによって構築されてきました。小さなバグの修正、定型的なコードの記述、行き詰まり、そしてそこから抜け出すこと。これらは単なるタスクではなく、判断を生み出す実践そのものでした。機械がその実践を引き継ぐと、シニアを育成するパイプラインは壊れ、遅れて壊れるため、3年から5年は気づかないでしょう。 もっともらしい対応策があります。生成されたコードの構造化されたレビュー、意図的な補助なしの演習、テストおよび検証作業を通じたローテーション、厳格なシニア監督下での実際のシステムへの早期の露出。私はこれらのいくつかを実行しています。