Verification loop Claude Code: tabel benchmark, checklist Stop hook, dan sumber

TL;DR

Rekomendasi Anthropic sendiri benar pada intinya: model yang mendapat feedback loop menghasilkan kerja yang lebih baik. Masalahnya ada pada siapa yang menjalankan loop itu. Dalam 116 run, /verify bawaan mengembalikan PASS 24 dari 24 kali, termasuk pada perubahan yang melanggar requirement yang disebutkan.
Model yang memeriksa perubahannya sendiri punya blind spot yang sama dengan penulisnya. Haiku 4.5 melewatkan kasus unique-field yang sama di 11 dari 11 run, di setiap setup dengan model yang sama, dan /verify miliknya sendiri menaruh tanda centang di samping kasus yang salah.
Di Opus 5.5, /verify berbiaya 2.5x ($0.96 dibanding $0.39) dan tidak mengubah hasil apa pun. Opus polos benar 12 dari 12 dan menjalankan test suite sendiri di 11 run itu.
Project skill bersifat opsional bagi model: ia aktif di 10 dari 24 run, 0 dari 6 di Haiku. Stop hook aktif di setiap run dengan biaya tambahan sekitar 20% di Opus.
Pemeriksaan yang berhasil datang dari luar penulis: /verify yang sama dijalankan oleh Opus menjawab FAIL 3 dari 3 pada perubahan Haiku dan menyebut bug-nya. Dipasang sebagai Stop hook, ia membuat Haiku memperbaiki bug 3 dari 3 kali, dengan biaya $1.36 per tugas dibanding $0.76 jika Opus menulis sendiri.
Salin ini: Stop hook untuk bagian deterministik, verifier yang bukan penulisnya untuk bagian yang butuh penilaian, dan tanpa /verify di Opus untuk pekerjaan yang spesifikasinya jelas.

Apa kata pengukurannya

Klaim Anthropic: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Blognya mengubah itu menjadi workflow adopsi 5 langkah: pilih pemeriksaan manual yang paling sering Anda ulang, coba /verify bawaan, tulis prosedurnya dalam bahasa Inggris biasa sebagai skill, buat deterministik, lalu pindahkan ke CI. s1 Sejak v2.1.215: "Claude no longer runs the /verify and /code-review skills on its own; invoke them with /verify or /code-review when you want them." s3

Laporan dari lapangan menyangkut verifikasi yang diklaim tetapi tidak dijalankan. Issue #96416 adalah vonis review dengan 19 concern, 5 terverifikasi, dan tetap diberi "accept as-is". s6 Issue #97039 adalah klaim "held up" setelah pemeriksaan parsial, padahal checklist sudah dimuat. s7 "build passes" dan "production-ready" adalah standar yang berbeda, dan setiap kelolosan menghabiskan 2-3 putaran prompt ulang. s8

Benchmark kami menilai setiap "done" dengan acceptance test tersembunyi yang tidak pernah dilihat agent. 112 run tugas + 4 run /verify lintas model = 116 run, $66.29 setara biaya API. "Done" palsu: 12 dari 112, 11 di antaranya Haiku pada T6 di setiap setup A sampai E, 1 Sonnet pada T6 dengan setup skill, saat test barunya sendiri gagal dan skill tidak pernah aktif. s1

/verify bawaan menjawab Verdict: PASS di 24 dari 24 run pada ketiga model (23 bisa di-parse, 1 pass tanpa label), termasuk pada T6 Haiku yang rusak. Di Opus biayanya $0.96 dibanding $0.39 tanpa itu (2.5x) dan 125 s dibanding 75 s; hasilnya tidak berubah. s3

Project skill yang ditulis sesuai workflow 5 langkah dipanggil di 10 dari 24 run: Opus 8/12, Sonnet 2/6, Haiku 0/6. Stop hook aktif di setiap run, dengan $0.47 dibanding $0.39 di Opus (+20 %). s19

Blind spot-nya adalah satu requirement, T6 req 4: satu update yang memberi beberapa dokumen yang cocok nilai unik yang sama harus memunculkan DuplicateKeyError. Haiku melewatkannya di 11 dari 11 run, di setiap setup (plain, /verify, skill, hook, tests first). /verify Haiku sendiri memeriksa "update one doc onto another's email" dan tidak pernah mencoba satu update yang mengenai banyak dokumen. Aturan tests-first tidak membantu: 3/3 tetap melewatkan req 4, dan satu juga merusak req 3. s1

Perubahan Haiku yang sama, /verify dijalankan oleh model lain: Sonnet menjawab PASS (1/1), Opus menjawab FAIL 3/3, setiap run menyebut kasus yang sama, satu update yang menulis nilai sama ke beberapa dokumen, dengan biaya $0.39 sampai $0.47 per pemeriksaan. Sebagai Stop hook di Haiku (setup F), verifier Opus membuat bug diperbaiki di 3 dari 3 run; ketiganya menyentuh batas 60 turn saat memperbaiki, dengan rata-rata $1.36 per run T6 termasuk verifier, dibanding $0.76 untuk Opus yang menulis T6 sendiri dengan 0 "done" palsu. s19

Pengukuran

Harness: Claude Code 2.1.283 headless (claude -p), config dir terisolasi, prompt sama per tugas, batas 60 turn. Repo: msiemens/tinydb @ 18d73a1 (Python, 226 test). Enam feature request T1 sampai T6 dengan 5 requirement yang disebutkan masing-masing (T5: 6). Acceptance test tersembunyi, satu per requirement yang disebutkan dan tidak pernah ditunjukkan ke agent, menilai setiap run; suite milik repo juga dijalankan. "Done" palsu adalah run yang berakhir dengan klaim selesai sementara ada hidden test atau suite repo yang gagal.

Setup: A plain (hanya request); B /verify (A, lalu /verify bawaan sebagai turn kedua); C verify skill (project skill yang bisa dipanggil model, ditulis sesuai workflow 5 langkah); D Stop hook (prove-it.py: memblokir stop selama suite merah, dan memblokir stop pertama dengan meminta satu baris bukti per requirement); E tests first (aturan CLAUDE.md: satu failing test per requirement sebelum kode apa pun); F Opus verifier hook (claude -p /verify --model opus pada perubahan, memblokir jika verdict bukan PASS, maksimal 2 putaran).

model	setup	run	done palsu	biaya rata-rata	turn rata-rata	waktu rata-rata
Opus 5.5	A plain	12	0	$0.39	16.6	75 s
Opus 5.5	B /verify	12	0	$0.96	22.3	125 s
Opus 5.5	C skill	12	0	$0.43	19.5	80 s
Opus 5.5	D hook	12	0	$0.47	19.8	94 s
Opus 5.5	E tests first	2 (T6)	0	$0.64	18.5	129 s
Sonnet 5	A	7	0	$0.44	24.0	112 s
Sonnet 5	B	6	0	$1.18	36.3	210 s
Sonnet 5	C	7	1	$0.48	25.7	136 s
Sonnet 5	D	6	0	$0.53	27.0	157 s
Haiku 4.5	A	8	3	$0.34	35.4	172 s
Haiku 4.5	B	6	1	$0.68	43.3	217 s
Haiku 4.5	C	6	1	$0.26	28.2	124 s
Haiku 4.5	D	8	3	$0.37	38.9	179 s
Haiku 4.5	E	3 (T6)	3	$0.41	38.3	186 s
Haiku 4.5	F Opus verifier	3 (T6)	0	$1.36 termasuk verifier	61 (batas)	457 s
Sonnet 5	F	1 (T6)	0	$2.30 termasuk verifier	50	512 s

Keterbatasan: satu repo (library Python kecil yang teruji baik), enam request dengan spesifikasi jelas, 1 sampai 3 pengulangan per sel, run headless. Hidden test hanya memeriksa apa yang disebutkan request.

Lakukan ini hari Senin

Tulis sendiri satu acceptance test per requirement yang disebutkan, sebelum Anda membaca "done" dari model. Hidden test di benchmark menangkap apa yang dilewatkan setiap pemeriksaan dengan model yang sama.
Tambahkan Stop hook yang menjalankan test suite Anda dan mengembalikan keputusan block selama suite masih merah. Ia aktif di setiap run; skill tidak.
Buat stop pertama dari sebuah tugas hanya bisa lolos dengan satu baris bukti per requirement (pola prove-it.py): sebuah perintah dan outputnya, bukan sebuah kalimat.
Arahkan pemeriksaan yang butuh penilaian ke model yang tidak menulis perubahan: claude -p /verify --model opus pada diff, memblokir jika verdict bukan PASS, dibatasi 2 putaran.
Di Opus 5.5 dengan request yang spesifikasinya jelas, berhenti mengetik /verify karena kebiasaan. Biayanya 2.5x dan tidak mengubah apa pun dalam 12 run; simpan untuk area tanpa test atau perburuan bug yang sudah ada.
Jika Anda mendelegasikan ke Haiku 4.5 demi biaya, anggarkan verifier-nya: $1.36 per tugas dengan hook Opus dibanding $0.76 jika Opus menulis sendiri.
Catat setiap percobaan ulang perbaikan yang gagal di sebuah ledger dan hentikan loop setelah ada pengulangan, agar hook pemblokir tidak menghabiskan token pada patch salah yang sama.
Baca ulang requirement Anda untuk kasus multi-row: "satu update yang cocok dengan beberapa dokumen" adalah bentuk kasus yang tidak pernah dicoba 11 dari 11 run Haiku.

Bacaan lanjutan

Workflow 5 langkah dan tangga kematangan, dari pemeriksaan manual sampai gate CI: anak tangga teratas (gate CI dan PR) adalah tempat bagian deterministik berada begitu hook Anda berjalan baik secara lokal. s1
Semantik Stop hook: keputusan block dengan alasan mengembalikan turn ke model; baca kontrak exit code dan JSON sebelum menulis gate Anda sendiri. s19
Groundtruth, Stop hook yang menolak mengakhiri turn sampai pemeriksaan lolos: versi deterministik dari idenya, siap dibaca sebagai implementasi referensi. s5
regressionledger, sisi biaya: hook yang mencegah loop mencoba ulang perbaikan gagal yang sama, bagian yang tidak dimiliki Stop hook kami saat run menyentuh batas 60 turn. s10

Sumber

Building verification loops in Claude Code with skills, blog Anthropic. Kenapa dibaca: workflow 5 langkah dan tangga yang menjadi dasar setup skill di benchmark.
Building verification loops in Claude Code, kanal resmi Claude. Kenapa dibaca: tiga menit tentang apa yang dilakukan /verify pada run pertama, sebelum Anda memutuskan memakainya atau tidak.
Claude Code CHANGELOG, GitHub. Kenapa dibaca: v2.1.215 adalah saat /verify menjadi hanya dipanggil pengguna, yang mengubah seberapa sering ia jalan untuk Anda.
Boris Cherny: give Claude a way to verify its work, X. Kenapa dibaca: klaim "2-3x the quality" dalam kata-kata aslinya.
Groundtruth, GitHub. Kenapa dibaca: gate Stop hook yang berfungsi untuk ditiru, daripada menulis dari nol.
Issue #96416, GitHub. Kenapa dibaca: transkrip bertanggal dari vonis review yang memverifikasi 5 dari 19 concern lalu tetap menerima.
Issue #97039, GitHub. Kenapa dibaca: kegagalan yang sama dua hari kemudian dengan checklist termuat, jadi checklist bukan solusinya.
AI coding agents can verify some of their work now, dev.to. Kenapa dibaca: pernyataan paling jelas tentang jurang antara "build passes" dan "production-ready".
Saguaro, GitHub. Kenapa dibaca: perdebatan review in-loop versus tingkat PR, dengan argumen tandingan di komentar.
regressionledger, GitHub. Kenapa dibaca: masalah biaya retry yang diciptakan hook pemblokir, dan satu cara membatasinya.
SPICE simulation to oscilloscope to verification with Claude Code, blog pribadi. Kenapa dibaca: verification loop yang oracle-nya adalah instrumen fisik.
Hooks reference, code.claude.com. Kenapa dibaca: kontrak keputusan block yang harus dipatuhi Stop hook Anda.

FAQ

Apakah /verify bawaan menangkap bug?

Tidak di benchmark ini. Ia mengembalikan PASS di 24 dari 24 run pada Opus 5.5, Sonnet 5 dan Haiku 4.5, termasuk perubahan Haiku yang melanggar requirement yang disebutkan. Satu-satunya temuannya yang berguna adalah bug upstream yang sudah ada dan tidak terkait perubahan.

Kenapa verifier yang lebih kuat membantu penulis yang lebih lemah?

Pemeriksaan Haiku sendiri menguji kasus yang sudah ia pikirkan. Opus, dengan perubahan dan /verify yang sama, mencoba satu update yang mengenai beberapa dokumen dan menjawab FAIL 3 dari 3. Sonnet menjawab PASS. Verifier harus melihat kasus yang tidak dilihat penulisnya.

Lebih murah memverifikasi Haiku dengan Opus, atau menulis dengan Opus?

Tulis dengan Opus. Hook verifier Opus di Haiku rata-rata $1.36 per run T6 dan menyentuh batas 60 turn setiap kali; Opus yang menulis T6 sendiri rata-rata $0.76 dengan 0 "done" palsu.