エージェント移行を本気でやるなら初期セットアップに時間を使え
Boris Chernyの自動化メモは、私がチームに言い続けてきたことと同じです。レバレッジは同じバグにトークンを燃やすことではなく、判断をインフラに移すことです。
この2週間、登壇と大企業幹部との会議で同じことを言い過ぎました。エージェント仕事は初期セットアップで決まります。トークンを振り切って分かったのは、高いのは賢いプロンプトではないこと。環境がすでに自分の働き方を知っているかどうかです。
それが自分のバイアスかもしれないと思っていました。そこにClaude CodeリードのBoris Chernyのメモがほぼ重なりました。
優秀なエンジニアが昔からやっていたこと
Borisが指すのは古い習慣です。優れたエンジニアはvim自動化、lint、e2eなど「仕事の周りの仕事」を自動化する時間を取り、エージェント以前から自分の出力に倍率をかけました。
自動化はエージェント数だけ掛け算される
かつてのDevXは一人を速くしました。今は同じ自動化が艦隊全体のスループットになります。
問題をコードに移すと種類ごと消せる
エージェントは同じissueを見るたびに直し直せます。トークンを燃やし、まだ落とします。lintやCIにすればそのクラスの失敗は繰り返さない。「ループ」とは無限リトライではなく、問題カテゴリの削除です。
自動化が他者の貢献を可能にする
初日からのコミット、かつてはフル席が必要だった水準の非開発者貢献がすでに起きています。壁は頭の中だけのドメイン知識です。オンボーディングを文章・ルール・例・レビュー基準へ移す必要があります。
インフラにできる知識の範囲が広がった
lint・型・テストに加え、コメント、skills、CLAUDE.md、エージェントメモリに判断を載せられます。「そのFWは使わない」とPRを止めてルールを書かないなら、チームがインフラ化に失敗しています。
すべてのチームの宿題
追加コンテキストなしでエージェントが生産的に動けるCLAUDE.md、REVIEW.md、skills、ドキュメントを書くこと。シニアがずっとやってきた自動化をエージェント向けにしただけです。
初期セットアップは遅く感じます。飛ばすチームは高いモデルを買いながら、空のコンテキストに同じ基準を一日中説明し直します。
ニュースレターに登録
最新のAIに関するインサイトをお届けします。