この実験では、単一の機能をテスト生成、実装、検証の3つの異なる役割に分解するマルチエージェントコーディングパイプラインをテストします。Codexはテストと最小限のスタブを生成し、当初はテストがコンパイルされるものの、アサーションが失敗しました。Claudeはこれらのテストをソースコードに対して正確性とシンボルの存在を確認するためにレビューしました。Claudeは次に、テストが特定の理由で実際に失敗していることを確認するために、コードを隔離された環境に配置しました。Grokは、テスト自体を変更せずに失敗したテストをパスさせる実装を書くことを担当しました。最後に、Claudeはテストを実行し、メモリリークを確認し、コードの変更をレビューすることで、Grokの作業を独立して検証しました。特定された主な利点は、人間の労力を置き換えることではなく、明確なテスト契約をエージェント間で作成することによって、エラー検出を早期化し、より独立させることです。このアプローチは、自己検証のリスクが高い単一エージェントによるTDDとは異なります。また、人間の書いたテストとエージェントによる実装との比較では、後者の方が信頼性は高いものの、かなりの人的コストが必要となります。実験では、Grokとのパラメータの非互換性や、手動でのテスト検出を必要とするZigビルドシステムの詳細など、特定の問題に遭遇しました。このパイプラインは、特に静的型付けと堅牢なテストフレームワークを備えたプロジェクトにおいて、厳格なテストプロトコル下で実行可能と見なされます。仕様がまだ定義されていない探索的な作業や機能にはあまり適していません。著者は、このマルチエージェントワークフローの成功は、プロジェクトがテストを具体的な契約として扱う能力にかかっていると結論付けています。