「here's how i shipped 2,500 PRs last month to production」を見ました
今更ながら、直近話題になっていた動画を見ました。
here’s how i shipped 2,500 PRs last month to production
すごく分かりやすい英語で話してくれているので、英語に慣れるという意味でも良かったです。
既にいろんなところで分かりやすくまとめられていますし、AIに聞けば簡単に良いまとめを作ってくれる時代ですが、自分の記憶や理解のために、自分の感じたことを書いて（書き殴って）おきたいと思います。
そして、せっかく(？)なので公開しておこうと思います。 （私は解説記事はほぼ意味がなくなってきたと感じていますが、感想は意味があると思っているタイプの人間なので…）
「here’s how i shipped 2,500 PRs last month to production」の概要
意味が分からないくらいの超効率でGrokBotの開発を進めるための、AI Agentの使い方について解説している動画です。神動画。
potetoさんも最初は数個のAgentを並列で回していて常にその出力を確認して軌道修正するような感じだったが、次第に自分がボトルネックだと感じるようになり、いかにそのボトルネックを解決したかということが語られています。
人間の並列数は増やせないものの、AIエージェントの並列数は増やせる・一定の信頼を置けるレベルになってきているという前提があるのだと思っています。
何が大切と言われているのか？
とにかくAgentを信頼できるようにする（≒ほぼ手放しで稼働させられる環境を作る）ことが大切だと言っていると感じました。 それにあたって以下のようなことが語られていました（他もありますが）。
Feature Map
site mapのようなイメージのものらしい。
GrokBotが持つ各機能について、ユーザー目線でどのように使われるものかみたいなのを書いたものでめっちゃ重要とのこと。
おそらくこういう情報がないと平均値的なアプリの挙動を目指して作成を進めてしまうので、重要なんだろうと思っています。
自分の感覚としては、今まで前例がないようなものは苦労する一方で模倣するようなものは本当にAI Agentでぱっと作れるので、平均的なものから外れたり前例が少ないようなものでは非常に大切になるものなのかなと感じています。
記載内容はこのあたりが参考になりそう。
High-quality verification
Agent自身が品質を担保できること。 当初はChromeDevTools等で手動で原因を探っていたりしたそうですが、そういうことも確認できるようにしたりして確認の質を上げること。
上記のFeature Mapと合わせて
- 実現したいこと
- 確認すべき事項や手順
をきちんと言語化しつつ、スクリプト等で使い回せるかということが大切そうです。 （使い回せる形にしないとAgentが都度生成するのでブレが大きい）
なお、このあたりの流れでガッチガチのルール過ぎて(?)人間には書きづらいようなリポジトリになっているらしい。 AI Agentを最大限活かすならAIエージェントが書きやすいリポジトリにせよ、という方針。確かに。
refeactoring/rewriting architechture to be agent friendly
目をそむけた感じな部分なので少し耳が痛かったです…。
AI Agentは既存のコードの真似をする傾向があったり、コメントにかかれているworkaroundを使い回す傾向がある（コンテキストに入るのでそりゃそうですよねえ…）。
そのため、一回取ったworkaround等がどんどん波及してコード全体を蝕むウィルスのようになるとのことでした。
とはいえ何をどう頑張ろうとそういうのは残るので、改善をエージェントを使ってどんどん回し続けることが大切と理解しています。 そしてこれをするにもエージェントが成果を判断できる必要があるので High-quality verification は避けられないなあと思っています。
whenever you correct your agent
エージェントが正しく（思うように）動くようにするためには何を改善していくべき？という話で、下記の順でやっていくといいよということでした。
1. codebase
2. static analysis
3. rules/bugbot
4. skills
5. style guide既存のコードを真似するなら既存のコードを直せ、すぐに直せないならlintとかで弾け、無理ならエージェントに検知させる何かを作れ、style guideみたいなものは無視される可能性が高いから良くない
static analysis を強めるのがいいかなと思ってたのですが、大切なのはcodebaseの修正とのこと。
既存コードを触るときはコンテキストに必ず既存のコードが入るので、確かにそうかもという感じはしつつも実感は湧いていない部分です。これを感じ取るの結構難しそうだな。
実際にどう落とし込んでいくのか？
Agentの仕事を信頼出来るようにすることがとても重要だと改めて感じているので、まずは以下を同時にやっていくことなのかなと思ってます。
- High-quality verification
- linterやrules相当のものを作り込む
- codebase の改善
自分がほとんど見ないでも仕事が進む状況と考えるとまだまだハードルは結構ありそうですが、進められるだけ進める価値はありそうです。
成果を出すのが早すぎない？
ボトルネックの特定や、改善の方向性が的確なため…？ 自分の並列度がボトルネックだと感じたら自分を再現するように色々組んでいくことや、まずはverificationの部分から手を入れるなど、後から言われると納得感はありますが先の見えない中でこれを進めて成果を出すのはすごい…。
凡人が少しでも近づいていくなら、エンジニアリング以外の勉強も色々必要だなと思わされた気がします。
その他
ちなみに別のX上のポストで大体16並列でプロジェクトを進めていて、数百（数千?）のエージェントが並列で稼働しているの投稿していました。 コンテキストスイッチきつくない？というリプがあったのですが、しばらくやってたら慣れるから慣れの問題だよ、みたいに返していました。
いや本当かよ…。。
と、同時に逆に全てをエージェントに投げるのではなく、無限に並列数が上がっているわけではないので（少なくとも今はまだ）何かしら人が手を入れる領域があるということも感じました。