開発を担うエージェントが増えるなか、何をつくり、どう検証し、届けるか。TRM LabsのRahul RainaとCodeRabbitのHarjot Gillが語る。
CodeRabbitの『Founder to Founder』第1回では、司会のErik Thorelliが、TRM Labsの共同創業者兼CTOであるRahul Rainaと、CodeRabbitの共同創業者兼CEOであるHarjot Gillを迎え、AIが両社のソフトウェア開発をどう変えているかを話し合いました。両社のチームが何をつくるかをどのように決め、エージェントが生成したコードを検証し、新しい機能を顧客に届けているかについて語りました。
TRM Labsは、捜査担当者が不正な資金の動きを追跡し、詐欺、ランサムウェア、テロ資金供与、その他の脅威に対抗するためのソフトウェアを開発しています。
TRMでは、エージェントによって顧客の要望に応える方法が増えています。Rahulは、エージェントが機能を実装し、実際に動く様子を収めた画面録画まで提出する例を紹介します。しかし、この例はプロダクト開発でおなじみのジレンマも示しています。解決策としてページにボタンをもう1つ追加するとします。その機能は動きますが、すべての要望を同じ方法で解決していけば、やがてページはボタンだらけになります。
そこでチームは、エージェントが提示した解決策が自分たちも選んだものだったかを問わなければなりません。Rahulの言葉を借りれば、「この問題を、こういう方法で解決したいのだろうか？」という問いです。
何をつくる価値があるかを決める
CodeRabbitでは、バックグラウンドエージェントがサポートチケットやアラートを調査し、コードの変更を提案できます。
「今では、アイデアからプルリクエストにするのが本当に簡単になりました」とHarjotは語ります。
アイデアがこれほど早くPRになる時代には、チームはより早い段階で判断を下す必要があります。サポートチケットは問題を明らかにしますが、それに取り組むか、どう解決するかは、チームが決めなければなりません。CodeRabbitでHarjotが検討しているのは、バックグラウンドエージェントがプルリクエストを開く前に、計画と承認のステップを設けられるかどうかです。エージェントは予定している変更を説明し、そのまま進めてよいかを尋ねます。
Harjotはまた、ジュニア開発者がコーディングエージェントに与えようとしているプロンプトをシニアエンジニアがレビューし、実装が始まる前にアーキテクチャ上の判断を作業へ反映させることも検討しています。
TRMでは、実装前に作業を導く独自の方法として、Rahulが「product cortex」と呼ぶ社内のツールやスキルを集めた仕組みを開発しています。顧客との通話やフィードバックから、取り組みの候補となるアイデアを集めます。プロダクトマネージャーはそのアイデアを検討して何に取り組むかを決め、要件をまとめ、実装前にプロトタイプを改良します。
product cortexの初期バージョンが提示するのは、チームがすでに把握している事柄がほとんどでした。TRMのデザインシステムや戦略上の優先事項を加えたことで、提案の質が改善しました。PMはエージェントに特定の目標を与えることもできます。これにより、エージェントは寄せられるすべての情報にただ反応するのではなく、優先事項に合うシグナルを見つけられます。
Rahulの見積もりでは、そうしたシグナルの約10％が、最終的にチームのつくるものになりました。そのプロセスで作成されたドキュメントやプロトタイプは、機能が実装に進んだ後もリポジトリに残ります。
レビューに根拠を持ち込む
何をつくるかを選ぶのは、最初の判断にすぎません。エージェントが実装した後も、その変更が意図どおりに動くことを示す根拠と、どのような場合に人がレビューしなければならないかを定める明確なルールが必要です。
収録時点で、TRMは顧客向けのプルリクエストとデプロイに引き続き人間の承認を必須としていました。また、テストの根拠を人が集めるのではなく、各PRの一部として生成することを目指し、自動検証にも多くの投資をしていました。
TRMでは、実装と検証を1つの開発工程として扱っています。
「私たちはこれをmake-validateと呼んでいます。検証せずにつくるだけでは、いわば粗製乱造になってしまうからです」とRahulは語ります。
TRMは、認証や認可などセキュリティ上重要な領域への変更を検出する制御の実現に取り組んでいます。そうした変更は人間がレビューし、それ以外の作業はより速く進められるようにする考えです。
Harjotも、CodeRabbitで開発者に残る責任について同じような点を指摘します。AIを使った変更を同僚に見てもらう前に、開発者自身が内容を検証し、求められる品質水準を満たしていることを期待しています。
開発量の増加は、CodeRabbitのデリバリー基盤にも負荷をかけています。開発が加速するにつれ、同社はキャッシュ、ビルドシステム、デプロイパイプライン、マージキューを改善する必要がありました。
より多くの人が開発に参加する
エージェントは、プロダクトマネージャーやデザイナーがソフトウェア開発に貢献する方法も変えています。
Rahulによると、TRMが採用するのは自らものをつくる人たちで、すべてのプロダクトマネージャーに機能を1つリリースすることを求めています。この実践によって、エンジニアを巻き込む前にPMが自分でどこまで調べられるかが明らかになりました。コードベースや過去のPRにアクセスできるエージェントは、仕様をまとめる段階で依存関係やエッジケースを特定するのに役立ちます。
その結果、エンジニアはより具体化された提案をもとに議論できます。
CodeRabbitでは、プロダクト、デザイン、エンジニアリングのメンバーを集めた「ポッド」と呼ぶチームへの再編を進めているとHarjotは説明します。今後はマーケティング担当者もポッドに加える計画です。PMは文言の変更を直接提出でき、デザイナーも自分で改善を実装できます。
「誰もがコードに触れていいんです。もう神聖不可侵なものではありません」とHarjotは語ります。
エンジニアは引き続きスケールやAPI設計について判断し、デザイナーはインターフェースの一貫性を保ちます。エージェントによって、それぞれの専門分野がその知見を実際に動くソフトウェアへ直接反映できるようになります。
機能が形になるまでに蓄積されたコンテキストは、そのローンチにも活用できます。Harjotによると、CodeRabbitはマーケティングを開発に近づけるニュースルーム型のアプローチを検討しています。TRMでは、product cortexがプロセス全体で集めたコンテキストから、営業やマーケティング向けの資料を自動生成します。
これから起業する人へのRahulの助言は、会話の中心にあるプロダクト上の判断へと戻ります。顧客の近くに居続け、解決する価値のある問題を探し続けることです。
「優れたプロダクトを切実に求める声は、今もあります」とRahulは語ります。
プロダクト上の判断、検証、そしてエージェントがエンジニアリング、プロダクト、デザイン、マーケティングの仕事をどう変えているかについての対話全編は、『Founder to Founder』のエピソードをご覧ください。
