Phodal Huang が中国語で書いたこの記事は、著者が以前にも述べてきたという見方から出発している。AI による支援は、個々の開発者を助けることから、要件分析、設計、開発、テスト、デプロイにまたがるソフトウェア開発ライフサイクル全体をカバーすることへと移りつつある、というものである。著者が投げかける問いは、AI 支援開発ツール間の壁をどう取り払い、それらが連携して動くようにするかである。
その答えは、クラウドエージェントと IDE エージェントの連携である。すなわち、IDE 側のエージェントオーケストレーションシステムがクラウド上のエージェントと協働して、開発プロセス全体を自動化するというものだ。著者はこれを、AI コーディングエージェント言語である Shire を用いて例示している。
要点
- 著者は、主流のアプローチを、既存の DevOps ツールやプラットフォームに AI を追加して、エンドツーエンドのワークフローや複数の役割の協働のためにシナリオ特化型のエージェントを提供するものだと説明している。
- 著者は、自身のチームが企業に注力を勧めてきた「すぐに成果が出てレバレッジの高い」領域——構造化された要件の支援、コード生成、コードレビューなど——はすでに手がつけられており、多くの企業が自前のツールを試験運用している一方で、デプロイや運用といったロングテールの領域はまだ未成熟で、必ずしも費用対効果が高いわけではないと論じている。
- 著者は、AI プラットフォームとツールの断片化が進んでいると論じている。企業は GitHub Copilot、Tongyi Lingma、CodeGeeX といったツールを購入するか、Dify、AutoDev、Continue、あるいは各種チャットボットといったオープンソースソフトウェアをもとに独自のものを構築しており、その結果ツールがチームごとに散在し、作業が重複し、協調が難しくなっている。
- 著者は IDE エージェントの例として、Bloop、Tabnine の Jira-to-code 機能、GitHub Copilot Workspace を挙げ、それらに共通するのは、ツールチェーンを通じて取得した IDE のコンテキストとクラウドのナレッジベースを組み合わせている点だと述べている。
- 著者は IDE 側のエージェント機能を 2 種類に区別している。1 つはローカルエージェントで、ローカルのコンテキストを直接読み取るため高速だが、クラウドのナレッジベースにはアクセスできない。もう 1 つはクラウドエージェントやエージェントマーケットプレイスとの統合で、要件からのコード生成やコードレビューといったタスクにドメイン知識を持ち込むことができる。
- 著者は、開発エージェントは互いに依存し合っている——たとえば要件アシスタントには、ドメイン知識だけでなく既存コードのロジックも必要である——ため、単一のエージェントがプロセス全体をカバーすることはできず、エージェント同士を統合しなければならないと論じている。
- 著者は、IDE のエージェントオーケストレーションシステムがサポートすべきものとして、IDE のコンテキストへの高速なアクセス、コード検索や静的解析といった軽量なコンテキスト処理、API を通じたクラウドエージェントとのやり取り、SonarQube、GitHub、Git といったサードパーティツールとの統合、そしてコードや要件といった機密情報の暗号化を挙げている。
- 著者の Shire の例では、Dify 上にデプロイされたリモートエージェントを呼び出してビジネス要件を取得し、モデルがそれを分析した後に、企業の SQL 規約に従って SQL を生成するローカルエージェントを呼び出すスクリプトが定義されている。
背景
この記事は、成果の報告ではなく、ある方向性を主張するものである。著者はこれを、オープンソースの IDE プラグイン AutoDev (unit-mesh/auto-dev) に関する自身の以前の取り組みと結びつけている。そのプラグインのために著者のチームは、GitHub や GitLab の Issue を要件として受け取り、ローカルのコードベースのコードを修正する AutoCRUD エージェントを構築した。