コードのコストが崩壊した後のエンジニアリングマネジメント
コードのコストが崩壊した後のエンジニアリングマネジメント
生産から検証へのシフト
plausibly コードを生成するコストは崩壊し、多くの伝統的なエンジニアリングマネジメントプラクティスの基盤となっている仮定を根本的に崩した。"plumbing"— scaffolding、ボイラープレート、初期ドラフト—の生成速度は加速しているが、ソフトウェアデリバリーのボトルネックはコードを書く行為から、その正しさを検証し、デプロイのリスクを負う行為へとシフトしている。
生産コストの崩壊
plausibly コードの生成は今では安価かつ豊富になった。しかし、これがエンジニアリング組織が自動的に速くなることを意味するわけではない。得られる利益はグリーンフィールド作業とボイラープレートで最も顕著だが、複雑な既存システムでのディープワークではしばしば薄れたり逆転したりする。
生産コストが低下したため、ベロシティ、プルリクエスト数、クローズドチケット数などの伝統的なメトリクスは積極的に誤解を招くものになった。これらのメトリクスを増やす最も安い方法がボリュームを増やすことであり、ボリュームがもはや希少でなくなったため、これらのプロキシはビジネスバリューと相関しなくなった。持続可能なマネジメントの手段は、ビジネスアウトカムとシステムヘルスを測定し、コードボリュームを称賛すべきアウトプットではなく正当化すべきコストとして扱うことだ。
正しさと検証の再定義
検証は現在、機械的と意味的という2つの異なるカテゴリに分かれる。
機械的検証
機械的検証—型、テスト、契約、リントラルールのチェック—は、AIエージェントが人間にはかなわない速度でテストループを実行し、diffを修正できるため、速くなっている。この効率は、人間がすでにマシンチェック可能な形式で"正しい"とは何かを定義しているからこそ可能である。したがって、機械的正しさ（強力な仕様と不変条件）への投資は、組織ができる最高レバレッジのインフラストラクチャ投資の一つとなっている。
意味的検証
意味的検証—コードが実際のビジネスポリシーを実装し、規制への曝露を管理することを確認する—は人間中心のタスクのままである。AIチェッカーはしばしばAIジェネレーターと同じトレーニングデータと盲点を共有しており、同じように失敗する可能性がある。
これにより、重要なパラドックスが生じる：個々のチェックは安くなったが、安価な生成がボリュームを増やすため、総検証ワークロードは増加する。その結果、インシデントのプロファイルがシフトする：組織は"愚かな"エラーは減るかもしれないが、高ボリュームの plausibly な出力が高ボリュームの plausibly なレビューを通過するため、システム全体の失敗は増える可能性がある。
マネジメントの"古いルール"のアップデート
多くの長年にわたるマネジメントの格言は、もはや真実ではない仮定に基づいている。効果を維持するため、これらのルールは再調整される必要がある：
- "A director should not code": これは機能のリリースではなく、キャリブレーションについてである。ディレクターはAIツールと十分に直接接触し、本当に速いチームと、単にボリュームで"スロップ"（確信しているが間違った出力）を生産しているだけのチームを見分ける必要がある。
- "Shield the team from the business": エンジニアを高コストなコンテキストスイッチングから守ることは依然として有効だが、ビジネスコンテキストを奪うことは今では危険である。ビジネスコンテキストなしでAIに触れずにAIにプロンプトを出すエンジニアは、スケールで流暢だが間違った仕事を生産する。マネジメントは、デフォルトでコンテキストをフィルタリングするのではなく、特定のコンテキストを意図的に選択する方向にシフトすべきである。
- "We need consensus before we commit": コンセンサスは不可逆的な決定のためにある。なぜなら、可逆的な技術的選択は今では元に戻すのが安くなったから、スピードを維持するために最小限のグループで決定すべきである。
- "We need more headcount": ヘッドカウントのリクエストは、その仕事が人間の判断を必要とするか、単なる生産かを基準に精査されるべきである。調整コストとオンボーディングのドラッグは、構文のコストにかかわらず一定のままである。
ジュニアエンジニアパイプラインの危機
現在、AI拡張環境でのジュニアエンジニアのトレーニングに実証済みの方法はない。歴史的に、シニアレベルの判断は、AIが今吸収しているタスクをこなすことで培われてきた：小さなバグの修正とボイラープレートの作成。書くという練習が取り除かれると、シニアエンジニアを生み出すパイプラインが崩れる可能性があり、その影響は3〜5年後にしか明らかにならないかもしれない。
マネジメントロールの未来
マネジメントは2つの機能に分かれている：情報ルーティングと判断。
- 情報ルーティング: ステータスを集約し、アップデートをダッシュボードに翻訳する。この機能はLLMによって商品化されつつあり、その価値はゼロに向かっている。
- 判断と所有権: 雇用、昇進、悪い決定の結果を所有する。この機能は自動化できない理由は、組織の文書化されていない信頼関係と機関の歴史のモデルが必要だからである。
"エージェントリックリミット"では、組織図は誰が生産するかを記録するのではなく、誰が署名するかを記録するようになる。ヘッドカウントはもはやキャパシティを測るのではなく、組織がどれだけの説明責任とリスクを吸収できるかを測るようになる。
コミュニティの視点と反論
コードコストの崩壊は主導的なナラティブだが、実践者の議論からいくつかの重要な反論が浮かび上がっている：
"仮定は、LLMがコードを書き、人間エンジニアがレビューすべきだということだが…私は根本的にそれに反対だ…コードを理解することがまだボトルネックだ。しかし、理解は確かに書くループの中で得られるものだ。"
一部では、AIの最も効果的な展開は、人間が書き、LLMがレビューすることであり、これにより深いシステム理解に必要な認知ループを保存できると主張している。また、"コードのコスト"は実際には技術的負債の形で増加している可能性があると指摘する人もいる。なぜなら、AIはコード負債の蓄積をクリーンアップよりも速く進めるからだ。さらに、ソフトウェア組織の主なボトルネックはコードを書く行為ではなく、チームの組織、システム設計、仕事の優先順位付けにあると考える人もいる。