テクニカルリーダーは最大のAI排気量を持つべき

エンジニアをAIの排気量（トークン消費量やコード行数）で評価するのは悪い考えだ。生成されたコードや消費されたトークンは、インパクトと同じではない。スタッフエンジニアは、非コーディング活動（ビジョンドキュメントの推敲、複雑なプルリクエストのレビュー、他チームへの影響力、メンタリングなど）に多くの時間を費やしても、倍のPRを作成したエンジニアよりも大きなインパクトを持つことができる。High Output Managementでアンディ・グローブはこれをレバレッジと呼んだ。リーダーの出力は、直接生み出す仕事を超えて、組織全体で可能にすることにまで及ぶ。グローブは、トレーニングをリーダーが実行できる最もレバレッジの高い活動の一つと呼んでいる。エンジニアの経験が長くなるほど、ピアフィードバックや、主導した、あるいは貢献した仕事のインパクトに基づいて評価されるようになり、インパクトのあるPRの数に基づく評価は少なくなる。歴史的に、これはシニアリティと直接的な技術的出力の間に逆の関係を生み出した。エンジニアがシニアになるにつれて、コーディング以外のレバレッジを見つけることが期待された。しかし、AIは私たちの実践を変え、私はこれがもはや当てはまらないと考えている。エージェントを使ったコーディングの正しい方法を知る人はいない長らく、ソフトウェアエンジニアリングの実践は十分に安定していたため、シニアエンジニアはソフトウェアがどのように作られているかという感覚を完全に失うことなく、主にコーディングから離れることができた。確かに、言語、インフラ、フレームワークは時々変わったが、基本的な原則は真実のままだった。人間とソフトウェアの主なインターフェースはIDEとターミナルだった。エンジニアはシステムを設計し、コードを書き、プルリクエストをレビューし、テストし、出荷し、CI/CDを構築した。しかし今、私たちは人間の意図とソフトウェアの間のインターフェースを再検討する期間に入った。コーディングエージェントで構築するための確立された方法はなく、テクニカルリーダーは新しい生産手段で直接的な経験を必要としている。私が個人的に格闘している未解決の質問のリストを以下に示す（網羅的ではない）：コードレビューについて：エンジニアはすべてのコードを読むべきか？主にテストと結果の振る舞いをレビューすべきか？AIにコード変更の説明をさせるのはOKか？AIによるコードレビューは1回で十分か、それとも複数のゲートが必要か？コンテキスト管理について：AGENTS.mdには何を含めるべきか？効果的なコンテキストウィンドウとは何か？エージェントは自分でスキルを呼び出すことを許可されるべきか？コードベースについて：LLMはコードベースのウィキを維持すべきか？Markdownの計画はリポジトリに保存すべきか？コードベースのキュレーションと整理はまだ重要か？自律性について：エージェントをコパイロットとして扱うべきか、それとも監視なしで作業させるべきか？仕様駆動開発を採用すべきか？エージェントは独自のIDを持つべきか、それともユーザーの代わりに動作すべきか？エージェントはコーディングのみに焦点を当てるべきか、それともGitHubやJiraのような外部サービスに接続されるべきか？Meanwhile、毎日新しいツールが登場している。私が実験しているツールのカテゴリをいくつか挙げる（これも網羅的ではない）：UI：ターミナル、ターミナルマルチプレクサ、エージェントGUI、差分ビューア、アーティファクトビューアエージェントの委任：ハーネス、プラグイン、スキルパック、オーケストレーター、タスクマネージャーセキュリティ：サンドボックス、ツール使用前のフック、クレデンシャルボールト、クレデンシャルプロキシプロダクションソフトウェアを構築するための標準的な方法に合意できる段階にはまだ遠いと思う。これらの質問は、エンジニアリングの原則について推論することでは答えられない。これらは経験的な質問だ。エージェントを実際のコードベースで実行し、それらを失敗させる方法を見つけなければならない。好みのスタックを立ち上げ、独自のカスタムツールを構築し、3ヶ月後にすべてを捨ててやり直す準備ができている必要がある。そうでなければ、知的な立場を開発することはできない。二手間の報告、デモ、記事だけでは不十分だ。シニアリティはより多くの排気量を生み出すべきだエンジニアはタスクを完了するためにコーディングエージェントを使用する。テクニカルリーダーは今や、コーディングエージェントを集合的に活用する効果的な方法を見つけるという、より広範な任務を負っている。エージェントはどこでうまく機能するか？どこで失敗するか？どのようなコンテキストが必要か？人間は何をレビューすべきか？どのコントロールが決定論的であるべきか？チーム全体で標準化されるべきことは何か、そして個々のエンジニアに任されるべきことは何か？これらの決定に影響を与えるには、多くの直接的な経験が必要だ。スタッフエンジニアやプリンシパルエンジニアは、実験を実行し、新しいツールを試し、現実の問題に対してモデルを最も厳しくプッシュすべきだ。それは必然的に、燃焼したトークン、コード行数、失敗したプロトタイプ、放棄されたブランチといった、かなりの量のAI排気量を残すことになる。実験を通じて私が達した結論をいくつか紹介する：コンテキストウィンドウについて：FableやSolのような最も有能なモデルでさえ、まだ多くの間違いを犯し、指示を無視する。これは特に長いコンテキストウィンドウで顕著だ。したがって、エージェントには効果的なコンテキストウィンドウがあると結論付けた。それが何であるかはまだわからないし、それが厳密な数ではなく、タスクに大きく依存すると疑っている。それにもかかわらず、私は現在、コンテキストウィンドウを50%に制限しており、20%を超えたら警告が表示されるようにしている。自律性について：モデルは最近非常にエージェント的になっている。それらはPRを作成し、メインにプッシュし、あなたが要求しなかった機能を構築する。これは、エージェントの指示が曖昧な場合に特に当てはまる。私は最近、スタック全体をゼロからやり直すために削除したときにこれを発見した。すべてのスキルとAGENTS.mdをクリアし、仕様駆動開発（SDD）フレームワークの使用をやめた。現在、指示ガードレールと決定論的なフックおよびワークフローを備えたハーネスを再構築している。事前に明確に定義されたタスクは、驚きを最小限に抑え、エージェントをより予測可能にする。コードレビューについて：人間によるコードレビューにはまだ多くの価値がある。エージェントは、仕様や指示で決定されていない部分を埋めることが多く、その結果、過剰に設計されたソリューション、要求されなかったテスト、あるいは単にひどいコードになることがある。また、尋ねない限り、それについて教えてくれないことも多い。仕様に含めるのを忘れたために、決して尋ねないかもしれない。もし何か重要なことであれば、PRを出荷する前にコードをスキャンすることは絶対に必要だ。人間とエージェントの理解においては多くのイノベーションが起こっており、私はこの分野を注意深く見守っている。コードベースの保守について：エージェントはgrepを使用してコードベースのコンテキストを構築する。コードベースがgrep可能でない場合、エージェントはタスクに必要なコンテキストをすべてロードするのに苦労する。コードベースがgrep可能であるとは、ドメインの単語を知っているエージェントが、ファイル全体を読むことなく検索することで、概念とその配線を特定できる状態を指す。私はしばしば、エージェントに「名前はそれが意味することを意味する」「副作用には明確な所有者がいる」「ディレクトリは1つの状態責任を持つ」といった原則に対してコードベースを監査させている。私はリポジトリにMarkdownファイル（spec.mdなど）を保存しない。なぜなら、それらはgrepで見つかり、望ましくないコンテキストをロードしてしまうからだ。AIレビューについて：エージェントは仕様を実装する最初のパスでバグを導入する。独立したQAエージェントが実装作業をゲートすることは、バグを表面化させるのに効果的だ。実装者のモデルとは異なるモデルファミリーのQAエージェントは、より良い結果を生み出す傾向がある。しかし、QAエージェントは細部にこだわりすぎる傾向があるため、エージェントが過度に批判的になり、不要な「防御的深さ」を導入する可能性があるため、修正されるべきものに対する人間のゲートは依然として必要だ。これらの結論の多くは、私自身の個人的なプロジェクトを行うことによって収集したことに注意してほしい。私のプロフェッショナルな仕事では、私が所有するものの多くがクリティカルであるため、エージェントには厳しい制限を設けている。AI排気量は貢献ではない高トークン消費量自体は何の証明にもならず、パフォーマンス目標になるべきではない。私が言いたいのは、真剣な実験は目に見える排気量を生産するということだ。フロンティアモデルをテストし、ハーネスを構築し、ワークフローを比較し、エージェントの失敗を研究し、困難な問題に対してエージェントをプッシュしているなら、トークンを消費し、コードを生成することになる。高いAI排気量は誰かがテクニカルリーダーであることを証明するものではないが、技術的な方向性を設定する人々からの低いAI排気量は疑問を投げかけるべきだ。過去には、シニアエンジニア