この記事は、GitHub Next が探究してきた Continuous AI というパターンを紹介する。これは、バックグラウンドのエージェントが CI ジョブと同じようにリポジトリの中で動くが、ルールではなく推論を必要とするタスクだけを担うというものである。記事の議論は、継続的インテグレーションが失敗しているわけではないと認めるところから始まる。CI はまさに設計されたとおりのこと、すなわち決定論的に表現できる作業、テストが通るか落ちるか、ビルドが成功するかしないかという作業を処理している。
記事が指摘するギャップは、意図の理解に依存する作業である。挙げられている例は、実装とは違うことを述べている docstring、アクセシビリティの lint は通るのにユーザーを混乱させるテキスト、メジャーバージョンを上げずにフラグを追加して振る舞いを変える依存関係、ループの中でコンパイルされる正規表現、そして操作を通じてしか見えない UI の振る舞いである。記事は GitHub Next の責任者である Idan Gazit の言葉として、判断を必要とするタスクはヒューリスティクスを超えるものであり、ルールやフローチャートとして表現できないところこそ AI が役立つところだ、と引用している。
要点
- このパターンは一行で要約されている。自然言語のルールとエージェント型の推論を組み合わせ、リポジトリの中で継続的に実行するというものである。
- これは製品としても CI の代替としても位置づけられていないことが明言されている。記事は、従来の CI は依然として不可欠であり、自然言語は YAML を置き換えるのではなく補完するものだと述べる。問題が決定論的に表現できる場合には、CI を拡張することこそが正しいアプローチだとされている。
- 安全性は設計の第一原則として説明されている。エージェントはデフォルトで読み取り専用で動作し、明示的に許可されない限り、イシューを作成したり、プルリクエストを開いたり、コンテンツを変更したりすることはできない。これが記事で Safe Outputs と呼ばれる仕組みである。
- このモデルは、エージェントが失敗したり予期しない振る舞いをしたりしうることを前提としている。出力はサニタイズされ、パーミッションは明示的であり、活動はログに記録されて監査可能であり、影響範囲は決定論的であると説明されている。
- 開発者は設計上ループの中に置かれ続ける。エージェント型ワークフローは自律的なコミットを行わず、開発者が作るのと同じ成果物を生み出すとされ、記事はエージェントがコードをマージすることはなく、すべてが目に見えてレビュー可能なままであると述べる。最も一般的な出力はプルリクエストだと説明されており、その理由は Gazit の言葉を借りれば、PR こそが開発者が作業をレビューすることを期待している既存の名詞だからである。
- 記事は、こうしたワークフローを簡潔さで測ることに異を唱える。開発者がそれを一度で書き上げることはまれであり、むしろエージェントと協働しながら意図を洗練し、制約を加え、許容される出力を定義していくと述べる。
- 7 つのカテゴリが、これらは理論上の例ではなく、GitHub Next が実際のリポジトリでパターンを試したものだという主張のもとで示されている。ドキュメントと振る舞いの整合、イシュー、プルリクエスト、コミット、CI の結果を横断して統合する定期的なプロジェクトレポートの生成、原文が変わったときに翻訳を再生成して単一のプルリクエストを開くことによる翻訳の最新化、依存関係のドリフトの検出、テストカバレッジ不足の自動的な解消、バックグラウンドでのパフォーマンス改善、そしてエージェントをプレイテスターとして使う自動化された操作テストである。
- 依存関係のドリフトのデモは、エージェントが依存関係をインストールし、CLI のヘルプテキストを調べ、それを前日までのものと差分比較し、ドキュメント化されていないフラグを見つけ、メンテナーが気づく前にイシューを起票したものとして説明されている。記事は、これには単なる差分ではなく意味の解釈が必要であり、だからこそ従来の CI では扱えないのだと述べる。
- テストカバレッジのカテゴリは、数値が報告されている唯一のものである。ある実験ではカバレッジがおよそ 5% からほぼ 100% になり、45 日間で 1,400 を超えるテストがおよそ 80 ドル分のトークンで書かれた。エージェントは小さなプルリクエストを毎日作成し、開発者はそれを少しずつレビューした。
- パフォーマンスの例は、関数呼び出しの中でコンパイルされるため呼び出しのたびに再コンパイルされる正規表現である。エージェントはこれを認識し、事前コンパイルするように書き換え、説明付きのプルリクエストを開く。
- 操作テストのカテゴリは、エージェントに単純なプラットフォーマーゲームを何千回もプレイさせて UX の退行を検出するものと説明されており、記事はこのパターンがオンボーディングのフロー、複数ステップのフォーム、リトライのループ、入力検証、アクセシビリティのパターンにも一般化できると論じる。
- 翻訳のケースについて記事は、機械翻訳は最初から完璧ではないかもしれないと率直に認め、その価値は完成品ではなく、レビューの準備が整った下書きにあると論じる。
背景
この記事は GitHub が自社の研究プロトタイプについて述べたものであり、そのプロトタイプは意図的に単純なパターンを使っていると説明されている。エージェント型ワークフローを書き、それを GitHub Action にコンパイルし、プッシュし、任意の Actions のトリガーで実行させる、というものである。カテゴリは理論上のものではなく実際のリポジトリで試されたものとして示されているが、そのほとんどは計測値なしに説明されており、数値とともに報告されているのはテストカバレッジの実験だけである。Gazit はこの変化を時代の区分として捉えた言葉とともに引用されている。コードのための AI の第一の時代はコード生成に関するものであり、第二の時代は認知的に重い雑務を開発者から取り除くことに関するものだという。そして読者に、自分の仕事のどの部分、すなわち自分の判断や自分のセンスを手元に残したいかを考えるよう促している。