Lauren Tan、信頼構築で月2000PR

Tan氏はこの問題を多くのチームが心当たりのあるものとして位置づける。エージェントがコードを書くと、人は結局すべての行をレビューしチャットで細かな修正を指示することになり、同氏によれば真のスケーラビリティには程遠い。その答えはより良いモデルを待つことではなく、エージェントが自力で働ける環境を設計することだ。

5段階のTrust Hierarchyがその理由を説明する。コードベースとアーキテクチャにおける物理的制約が最も自動的に拡張し、次にlintやCIなどの静的解析、次にルールとプレイブック、次に自然言語のスタイルガイド、最後に人的レビューが来るが、これは人に依存しほとんど拡張しない。同じ考え方で、同氏は自分を庭師に例える。大規模言語モデルはコンテキストにあるコードを模倣する傾向があり、1つのパッチがウイルスのように広がりうるため、回避策を抜き取るというわけだ。

同氏が挙げる支援インフラには、Chrome DevTools Protocol上に構築された検証CLI「ControlGlass」がある。エージェントがアプリを起動し、トレースを収集し、ヒープスナップショットを自力で分析できる。さらに曖昧なバグ報告を正確なDOM要素とコード位置に結びつけるFeature Map、シニアエンジニアのワークフローから抽出したプレイブック集Pystackもある。最も外側に位置するのがイベント駆動レイヤーだ。Grok Bot RoutinesがSentryのアラートとSlackスレッドを監視し、クラウドエージェントを起動してバグを再現し、パフォーマンス統計付きの修正PRを作成する。このモデルが同氏のチームを超えて広がるかは、一般的な組織がこうしたツール群をどれだけ構築する意欲があるかにかかっているだろう。アプローチ全体が単一のモデルではなく、その土台に依存しているからだ。