NS2 は、決定論的なチェックとエージェントが裁定するチェックを積み重ねた下で 4 ツールのエージェントループを実行する、issue 駆動型の システムハーネス である。ポジション：コーディングベンチマークはエージェント型ソフトウェアエンジニアリングと噛み合っていない の著者らが構築してオープンソース化したもので、https://github.com/drufball/ns2 で公開されており、同論文全体を通じて具体的な参照例として用いられている。著者らは、これを構築・運用する中で、論文で論じているベンチマークのずれの多くが浮かび上がったと述べている。
その中心となる考え方は、GitHub の issue を協調のプリミティブとすることである。プロダクトマネージャーエージェントが機能の issue を垂直スライスの子 issue に分解し、ソフトウェアエンジニアリングエージェントがそれらの issue を分離されたセッションで実装する。そしてレビュアー、テスト品質、スモークテスト、プルリクエスト作成の各エージェントが issue とプルリクエストのイベントを受け取り、作業を先に進めるべきか、修正すべきか、レビューのために説明を付けるべきかを判断する。論文は NS2 を、issue トラッカーを作業の永続的なステートマシンとして扱い、タスクごとに別々のエージェントセッションを起動するハーネスの一つに位置づけている。
機能
NS2 は、単一のチェッカーではなく、多層的な検証スタックの具体例として提示されている。最大限に厳格な lint、カバレッジのしきい値、依存グラフのユニットテストは、インナーループの厳格な検証器として働く。これらは 1 回の変更試行の中で実行される、高速でブロッキングなチェックである。ミューテーションテスト、LCOM による凝集度チェック、エージェントによる日次のアーキテクチャレビューとテスト品質レビューはミドルループのフィードバックとして機能し、個々の変更よりも広い範囲の作業を集約して評価する。スモークテストエージェントからのフリクションレポート、マージ後の revert シグナル、本番インシデントはアウターループのフィードバックとして働く。
これらのコンポーネントの一部は、他のコンポーネントの評価対象にもなっている。論文によれば、NS2 ではミューテーションテストがユニットテストスイートの品質を評価し、エージェントによる linter 品質レビューが lint 設定を評価する。論文はこれを「検証器を検証する検証器」のスタックと呼んでいる。また論文は、エージェント自身を制約する lint ルールやルーブリックを、そのエージェントが書き、保守しているとも述べている。
採用とエコシステム
NS2 は著者ら自身のハーネスでオープンソースとして公開されており、論文はこれを Symphony や GasCity と並べて、個々のエージェントハーネスではなくシステムハーネスのレベルで動作する最近の取り組みとして挙げている。協調の場として GitHub の issue とプルリクエストに、チェックとして lint 設定、カバレッジのしきい値、依存グラフのユニットテスト、ミューテーションテストに、フィードバックとしてマージ後の revert シグナルと本番インシデントに連携している。