Bagaimana Tim Claude Code Melakukan Code Review: Tujuh Langkah dan Tanpa Circuit Breaker

Pada 15 Oktober 2026, tim Claude Code menerbitkan laporannya sendiri tentang bagaimana mereka meninjau kode, sebuah tulisan teknis berdurasi baca empat belas menit yang dikreditkan kepada Addy Osmani, Morgan Westlee Lunt, dan Qing Wang. Kalimat yang menjelaskan mengapa orang mencari-cari ini muncul sejak awal: Claude menulis sekitar 90 persen dari kode Claude Code itu sendiri. Tulisan itu bukan pembelaan atas angka tersebut, melainkan deskripsi tentang mesin yang harus ada di bawahnya sebelum hal itu bisa bertahan, dan bagian yang layak dibaca dengan saksama justru bagian yang masih hilang.

Sebagian besar ringkasan berhenti pada dua angka utama: pull request yang di-merge ke basis kode Claude Code lebih dari dua kali lipat antara Juni dan September 2026, sementara porsi yang harus dibatalkan turun lebih dari 40 persen. Keduanya berasal dari tim itu sendiri, dan keduanya dapat dihasilkan oleh beberapa penataan berbeda, termasuk yang diasumsikan orang, yaitu bahwa tinjauan dihapus secara diam-diam. Tulisan itu menyatakan bukan demikian. Mereka memindahkan sebagian besar pembacaan ke mesin, mengoptimalkan waktu dan perhatian manusia, serta berinvestasi agar kesalahan dapat dibatalkan dengan cepat dan mudah. Sisanya adalah detail tentang bagaimana caranya.

Mengapa tinjauan menjadi hambatan utama sejak awal

Tekanan itu tidak berasal dari keputusan kebijakan. Tekanan itu berasal dari volume. Di monorepo Anthropic, menurut laporan tersebut, perubahan yang masuk per hari naik dari sekitar 2.500 pada Mei menjadi lebih dari 30.000 pada September 2026. Claude Code berada di repositori sendiri, terpisah dari monorepo itu, tetapi berada di bawah tekanan yang sama dalam skala yang lebih kecil.

Dengan laju seperti itu, tulisan tersebut mengakui, tinjauan manual baris demi baris sangat sulit, bahkan mustahil. Tidak ada seorang pun di sana yang mengklaim bahwa manusia membaca setiap diff tidak diperlukan. Mereka mengklaim bahwa membaca setiap diff tidak lagi dapat diskalakan, dan bahwa "apakah manusia membaca kode" selalu menjadi proksi yang tidak tepat untuk pertanyaan yang penting: apa yang bisa salah dengan perubahan ini, dan pemeriksaan mana, otomatis atau manusia, yang tepat untuk menangkapnya.

Begitu diungkapkan dengan cara itu, gerbangnya bergeser. Tinjauan tidak lagi menjadi pintu di ujung jalan dan menjadi berkelanjutan, lebih mirip pemeriksaan ejaan saat Anda menulis. Sebagian besar perubahan telah dibaca dan diperbaiki oleh Claude sebelum seseorang melihatnya.

Apa yang mereka optimalkan, dan apa yang dianggap sebagai kegagalan

Tujuan yang dinyatakan adalah agar sebagian besar pull request di repositori Claude Code, yang dalam tulisan tersebut diuraikan sebagai CLI, aplikasi desktop dan web, serta aplikasi seluler, di-merge dengan paling banyak satu manusia yang terlibat dalam prosesnya, yang bisa saja merupakan penulisnya sendiri, tanpa peningkatan revert atau insiden. Klausa ketiga itulah yang menjadikannya target yang sesungguhnya, bukan sekadar upaya pemangkasan biaya.

Mereka mengukur waktu manusia di kedua sisi neraca: waktu yang dihabiskan orang untuk meninjau, dan waktu yang mereka habiskan untuk memperbaiki apa yang rusak akibat kode buruk. Memangkas yang pertama tidak membantu jika biayanya muncul kembali pada yang kedua, dan tim mengatakan hal itu secara langsung. Jadi angka yang dilacak adalah persetujuan manusia per pull request, yang dilaporkan sebagai median dan persentil ke-95, komentar manusia, dan berapa lama sebuah pull request menunggu seseorang. Tingkat revert dan insiden berada di bawah semua itu sebagai pagar pengaman: jika angka-angka itu naik, waktu manusia tidak dihemat, hanya dipindahkan.

Metrik biaya tinjauan mudah dimanipulasi jika berdiri sendiri; peninjau yang menyetujui segalanya akan menghasilkan grafik waktu persetujuan yang indah. Pagar pengamanlah yang mencegah grafik itu berbohong.

Tujuh langkah, bukan satu gerbang

Pos ini menguraikan jalur perubahan tipikal sebagai tujuh langkah bernomor. Setiap lapisan menangkap sebagian masalah dan melewatkan yang lain, dan pemeriksaan yang lebih murah dijalankan sebelum yang lebih mahal.

• Verifikasi sebelum pull request dibuat. Claude menjalankan tes, build, dan linter, lalu agen kedua meninjau diff dalam konteks yang baru. Banyak engineer juga menjalankan skill internal: satu berburu bug, satu menyederhanakan diff, satu memeriksa perilaku secara end to end. Boris Cherny, pembuat Claude Code, menyebut bahwa memberi Claude cara untuk memverifikasi pekerjaannya sendiri mungkin merupakan hal terpenting untuk hasil yang baik, dan memperkirakan hal itu membuat hasil akhirnya dua hingga tiga kali lebih baik.

• Tinjauan AI pada setiap pull request. Tinjauan Claude membaca diff terhadap seluruh repositori dan maksud yang dinyatakan dalam pull request. Beberapa agen mencari bug secara paralel, lalu kelompok terpisah memberikan suara pada setiap temuan dan temuan itu hanya diposting jika cukup banyak yang setuju bahwa temuan tersebut nyata. Temuan tentang gaya, diagnostik, atau pembersihan diabaikan. Yang tersisa muncul sebagai komentar inline dengan tag Penting, Kecil, atau Sudah Ada Sebelumnya. Saat pratinjau riset diluncurkan, proporsi pull request internal yang mendapatkan komentar tinjauan substantif naik dari 16 persen menjadi 54 persen. Admin mengatur setiap repositori ke Cepat, Standar, atau Mendalam.

• Tinjauan keamanan. Proses otomatis terpisah. Pull request tidak dapat digabungkan selama temuan dari salah satu tinjauan masih terbuka; Anda memperbaikinya atau menutup utas dengan alasan singkat. Pemeriksaan yang sama tersedia untuk publik sebagai GitHub Action tinjauan keamanan sumber terbuka atau perintah /security-review.

• Pemeriksaan otomatis yang memblokir. Lint, pemeriksaan tipe, pengujian di setiap platform, dan build.

• Persetujuan manusia, diskalakan berdasarkan risiko. Sebuah pengklasifikasi membaca perubahan dan menetapkan tingkatannya, bukan penulisnya yang menetapkan. Langkah ini memiliki bagiannya sendiri di bawah, karena di sinilah sebagian besar desain yang menarik berada.

• Antrean merge, flag, dan rilis bertahap. Antrean ini menjalankan ulang setiap pemeriksaan terhadap main dengan perubahan yang diterapkan, sehingga dua pull request yang masing-masing lolos tidak dapat bergabung menjadi main yang rusak. Perilaku baru dikirim di balik flag kepada karyawan Anthropic terlebih dahulu, lalu ke channel latest, dengan stable menyusul di belakang.

• Deteksi dan rollback yang cepat. Flag dapat dimatikan tanpa perlu deploy, ada rotasi on-call mingguan, dan tinjauan insiden menanyakan lapisan mana yang seharusnya sudah menangkap masalah tersebut. Beberapa kesalahan tetap akan lolos, jadi lapisan terakhir adalah tentang menyadarinya dengan cepat, bukan mencegahnya.

Perubahan tersebut menetapkan tier, bukan penulisnya.

Perbaikan dokumentasi dan perubahan auto-updater tidak membawa risiko yang sama, jadi keduanya tidak mendapat tinjauan yang sama. Tabel dalam artikel ini memiliki tiga tingkatan, dan masing-masing menjawab satu pertanyaan: berapa banyak orang, jika ada, yang harus menyetujuinya sebelum perubahan itu digabungkan.

Rendah mencakup dokumentasi, copy, fitur khusus internal, dan perubahan aditif di balik flag; setelah tinjauan otomatis dan keamanan dinyatakan lolos, tidak diperlukan orang. Sedang mencakup perubahan produk biasa ditambah area sensitif seperti caching, auto-updater, dan prompt sistem, serta memerlukan satu orang. Tinggi mencakup kode paling berisiko dan sekumpulan kecil jalur yang selalu memerlukan dua orang.

Pengklasifikasi hanyalah separuh dari desain. Pengklasifikasi kedua menanyakan apakah perubahan khusus ini membutuhkan orang lain bahkan ketika tingkatannya menyatakan tidak. Beberapa jalur selalu membutuhkan orang, terlepas dari tingkatannya: apa pun yang dicantumkan pemilik sebagai sensitif, dan file alur kerja CI apa pun. Hanya penulis dalam daftar tepercaya repositori, sebagian besar tim pemilik, yang mendapatkan jalur yang lebih ringan; semua orang lain membutuhkan orang kedua. Persetujuan agen tidak pernah dihitung sebagai persetujuan orang, sehingga tinjauan otomatis dapat meloloskan perubahan berisiko rendah tetapi tidak dapat mengisi slot yang membutuhkan manusia. Siapa pun yang memicu perubahan bertanggung jawab atasnya. Dan persetujuan mencakup satu commit tertentu, jadi commit baru, termasuk push agen atau merge yang diselesaikan secara manual, membutuhkan persetujuan lagi.

Dua detail layak diadopsi bahkan jika Anda tidak pernah membangun pengklasifikasi. Tingkatannya berasal dari perubahan, bukan dari penulisnya, dan kepercayaan adalah gerbang terpisah yang lebih sempit di atasnya. Dan persetujuan diikat ke commit, bukan ke pull request, yang menutup celah paling umum dalam sistem review: centang hijau yang diperoleh di awal sebuah branch lalu dipakai untuk kode yang belum pernah dilihat siapa pun.

Peninjau dilatih terhadap insiden mereka sendiri.

Inilah bagian yang dilewatkan sebagian besar tulisan, dan ini menjelaskan mengapa pengaturan tersebut terus berjalan alih-alih melenceng.

Tim mengumpulkan pull request masa lalu yang menyebabkan insiden, beserta fix-forward dan revert-nya, lalu meminta engineer yang memahami kode tersebut untuk mengonfirmasi setiap bug dan tempat bug itu berada. Kumpulan itu kini menjadi eval. Reviewer menjalankannya setiap hari. Saat prompt, tool, atau modelnya berubah, perubahan itu harus bertahan pada seluruh set: pertahankan jika skornya naik, buang jika tidak. Kegagalan mereka menjadi rangkaian tes bagi hal yang seharusnya menangkap kegagalan mereka.

Itu adalah pendekatan yang berbeda dari menyetel linter, yang dinilai berdasarkan seperangkat aturan tetap. Reviewer ini dinilai berdasarkan cara-cara spesifik basis kode ini sudah pernah rusak, sehingga eval bertambah setiap kali ada yang salah. Tidak ada skor untuknya yang muncul dalam apa pun yang diterbitkan Anthropic yang kami baca, dan tulisan itu tidak mengklaim reviewer ini sudah selesai.

Lapisan yang belum dibangun

Inilah pengakuan yang membuat tulisan ini kredibel. Semua yang di atas menggambarkan sistem yang menangkap dan membalikkan kesalahan, bukan sistem yang menyadari bahwa tingkat kesalahannya sendiri berubah. Tim tersebut belum memiliki circuit breaker yang secara otomatis memperketat persetujuan ketika angka revert atau insiden berubah, dan para engineer di sana menginginkannya sebelum lebih banyak kode beralih ke merge tanpa manusia.

Yang ada sebagai gantinya adalah manusia yang memperhatikan. Flag dimatikan tanpa deploy, rotasi on-call mingguan mengawasi, dan tinjauan insiden menanyakan lapisan mana yang seharusnya menangkap masalah tersebut. Kalimat seorang kolega adalah kalimat paling berguna bagi siapa pun yang merencanakan peluncuran serupa: memperlambat memang menurunkan tingkat kesalahan Anda, tetapi terutama karena Anda melakukan lebih sedikit dari segala hal. Tim lebih memilih menjadi lebih cepat dalam menyadari dan memperbaiki masalah daripada lebih lambat dalam menghasilkannya.

Baca kembali tujuh langkah itu dengan mempertimbangkan hal tersebut. Enam langkah menentukan apakah suatu perubahan dilanjutkan. Langkah ketujuh adalah serangkaian kebiasaan untuk menyadarinya setelah kejadian. Tidak ada lingkar umpan balik yang terpasang dari hasil kembali ke gerbang keputusan, dan orang-orang yang membangun sistem itu mengatakan demikian.

Tugas kedua Review, yang sebagian besar dikesampingkan oleh postingan itu

Tulisan ini secara eksplisit menyatakan bahwa code review memiliki dua fungsi: menemukan dan memperbaiki masalah sebelum dirilis, serta membangun konteks bersama di seluruh tim. Tulisan ini berfokus pada fungsi pertama, lalu kembali ke fungsi kedua dengan jawaban yang luar biasa jujur: tidak ada proses formal untuk itu, tidak ada yang menyimpan model mental lengkap tentang Claude Code di kepala mereka, dan menurut mereka tidak ada yang perlu melakukannya. Ingin memahami bagian tertentu dari basis kode? Minta Claude memberikan penjelasan persis tentang bagian itu.

Dua file instruksi membawa konteks yang dulu ada di kepala para reviewer. CLAUDE.md memberi tahu Claude apa proyeknya, stack, konvensi, tujuan dan non-tujuan, sengaja dibuat singkat. REVIEW.md ditulis oleh pemilik kode dan menjelaskan seperti apa kegagalan di bagian kode mereka, jalur mana yang harus dilewati, serta meminta file dan baris alih-alih tebakan.

Akuntabilitas mendapat tempatnya sendiri: kamu yang menggabungkannya, kamu yang bertanggung jawab. Gabungkan perubahan kecil atau menengah dan sesuatu menjadi kacau, maka norma yang berlaku adalah kamu yang memperbaikinya. Itu berhasil karena perubahannya kecil, karena flag dan revert membatalkan sebagian besar kesalahan dalam hitungan menit, dan karena radius dampak menetapkan standar berapa banyak pemeriksaan yang didapat suatu perubahan. Itu adalah norma yang berlapis di atas aturan persetujuan, bukan pengganti aturan tersebut.

Di mana router cocok, dan di mana tidak

Pipeline di atas adalah pipeline panggilan model: agen peninjau yang membaca diff terhadap seluruh repositori, beberapa agen pemburu bug secara paralel, sebuah kelompok yang memberikan suara pada setiap temuan, tahap pemeriksaan keamanan, dan peninjau yang dijalankan ulang setiap hari terhadap eval yang terus berkembang. Itu masalah perutean sebelum menjadi masalah peninjauan, karena satu penyedia yang mengalami hari buruk tidak boleh menghentikan antrean merge.

OrcaRouter adalah satu endpoint yang kompatibel dengan OpenAI untuk lebih dari 200 model dengan satu kunci, dengan failover otomatis antarpenyedia dan tanpa markup, artinya harga daftar penyedia diteruskan apa adanya. Tim yang menjalankan versi pipeline ini sendiri mendapatkan satu hubungan penagihan dan satu tempat untuk mengganti model ketika kualitas peninjau berubah, yang justru merupakan hal yang dirancang untuk dideteksi oleh eval harian.

Batasannya penting. Kami menghosting model. Kami tidak menghosting Claude Code, kami tidak menjalankan Code Review untuk Claude Code, dan kami tidak memiliki akses ke pipeline yang dibahas artikel ini. Code Review untuk Claude Code adalah produk Anthropic, tersedia secara umum pada paket Team dan Enterprise, dengan versi yang lebih ringan tersedia secara lokal sebagai /code-review. Jika yang Anda inginkan adalah pipeline itu, di sanalah letaknya; pada versi pipeline tim Anda sendiri, router adalah keputusan teknis infrastruktur, bukan keputusan tinjauan.

Apa yang sebenarnya bisa ditiru oleh tim yang lebih kecil

Tuliskan aturan tinjauan di tempat yang bisa dibaca oleh peninjau: CLAUDE.md singkat untuk proyek dan REVIEW.md per area yang menyebutkan seperti apa kegagalan itu dan menuntut file dan baris, bukan tebakan. Tuliskan tingkat risiko secara tertulis, jadikan itu properti dari perubahan, bukan dari penulisnya, mulai dengan ketat dan longgarkan hanya dengan bukti. Batasi apa yang bisa disetujui oleh tinjauan otomatis dan jangan pernah membiarkan persetujuan agen dihitung sebagai persetujuan seseorang. Ikat persetujuan ke commit. Jalankan antrean merge. Ubah insiden dan revert menjadi kasus uji dan nilai ulang peninjau setiap kali Anda mengubahnya, karena peninjau yang tidak diukur adalah linter dengan pemasaran yang lebih baik.

Lalu perhatikan guardrail-nya, bukan waktu persetujuannya. Kerangka berpikir tim sendiri memberi Anda ujian untuk setiap perubahan tinjauan yang sedang Anda pertimbangkan: apakah tingkat revert dan insiden tetap terjaga, atau apakah waktunya hanya berpindah dari peninjau ke orang yang membereskan setelahnya? Pertanyaan itu bisa dijawab dengan data yang sudah dimiliki sebagian besar tim, dan itu memisahkan proses yang benar-benar menjadi lebih cepat dari proses yang hanya tampak lebih cepat selama satu kuartal.