品質保証
作るのではなく確かめるエージェントです。要求と照らして変更を読み、ブラウザーで試し、読まれる場所に所見を書きます。変更そのものの上に。
現状
自分の仕事の見直しは下手になります。人でも同じで、エージェントでも同じです。確かめることを明示的に任された二体目のエージェントは、別のものを見ます。賢いからではなく、別の問いを立てるからです。動くかどうかではなく、頼まれたとおりのことをしているかどうか。
確認の流れ
出された変更から、それが関わる行の上の所見まで。
出された変更が起こす
変更を書いた同僚と同じリポジトリで働きます。ただし任務は自分のもの、権限も自分のものです。
要求と照らして読む
変更そのものだけではありません。ひもづいたチケットを、あればドキュメントのページも取ってきます。頼まれた内容が変更の中に書いてあることは、めったにありません。
試す
画面を持たないブラウザーで、人がするようにアプリケーションを操作します。スクリーンショットは記録に残り、所見は主張されるだけでなく示されます。
所見を書き入れる
関係する行へのコメントとして。確かめられなかったことは、はっきりそう書きます。抜けを隠す報告は、報告がないより悪いのです。
何と一緒に働くか
この領域のために同梱されているシステムです。足りないものがあれば、MCP サーバーがいちばん早い道です。独自の起床イベントと細かい権限が必要なら、プラグインを書きます。
- Browser (headless Chrome)
- GitLab
- GitHub
- Jira
プラットフォームが守らせること
QA のエージェントがしないこと。
代用品をこしらえる
確認に必要なサービスがなければ、それを確かめて報告します。代用品を組み立てるのは、存在しないものについて合格の報告を書くことです。
人を裁く
所見が向き合うのは変更であって、それを書いた人ではありません。原因がプラットフォームにあるなら、それは不具合の報告としてそちらへ行き、非難として戻ることはありません。
決定する
結果は受信箱の中の所見であって、拒否権ではありません。変更を取り入れるかどうかは、統合する人が決めます。
自分で試す
covey はあなたが動かします。プログラム一つ、Postgres データベース、作業場には Docker。手順はドキュメントにあります。