エージェントが書いたコードの「検証の証拠」をコミットごとに残すDocket
Docket – Per-commit evidence records for agent-written code
コーディングエージェントは誰も検証できない速さでコードを生み出すが、レビュアーには完成したdiffしか届かず、何を試し何が検証されたのか分からない。Docketはエージェントのトランスクリプトを解析し、編集をファイル単位で再生して各行の出所を追跡、コミット時にdiffと突き合わせてhunkごとの証拠記録を生成する。テスト実行やカバレッジを編集と関連付け、根拠のない箇所を先頭に並べてレビューの注意をそこへ向ける。記録はorphan refに保存され、アカウントもネットワークも不要だ。
自信を持って間違える帰属エンジンは、製品がないより悪い。だからunknownは常に取り得る答えであり、必ず理由を伴う。
- sleeby
AIツールは通常、エージェントが作業の大部分を行ったコミットに「Co-Authored-By XXX」というトレーラーを追加する。
安上がりで、あらゆるgitツールでも生き残る。
それ以上にこれで何が得られるんだ？
- Yukonv
変更の監査記録を文書化する興味深いアプローチだ。履歴を散らかすコミット説明に情報をぶち込む代わりにね。このvibe codeで対処されていない大きなリスクの一つは、孤立した参照が安全な保存場所ではないことだ。`git prune`は、それらがどのhead参照の一部でもないため、すべて削除してしまう。https://git-scm.com/docs/git-prune
- bastawhiz
これは誰のためのもの？誰が見るの？新しいエンジニアリングプロセスを導入することで、エンジニアリング文化やプロセスの失敗を解決しようとしているように見える。たとえば、a) 意図などの情報と共にチェンジセットを整理するCIや必須レビュー、PRがない状況で、b) これらのコミットがmainに到達することが許されているにもかかわらず、この情報を知りたいと思うのはどんな状況なのか理解しようとしている。物事がうまくいかなくなったときに同僚を責めるため？インフラのデプロイを避けるため？