Mengurangi Positif Palsu

Anda menghubungkan Claude Code ke pipeline CI untuk meninjau setiap permintaan pengambilan. Sistem ini bekerja — tetapi pengembang mulai mengabaikannya. Mengapa? Terlalu banyak gangguan. Peninjauan terus menandai hal-hal yang bukan masalah nyata: rewel soal gaya, komentar TODO yang tidak berbahaya, dan pemeriksaan null defensif.

Inilah masalah positif palsu. Peninjau yang terlalu sering memperingatkan akan dibisukan. Dalam Skenario 5 (Claude Code untuk CI/CD), salah satu keterampilan arsitektur utama adalah meminimalkan positif palsu agar sinyal yang tersisa dapat dipercaya.

Dalam pelajaran ini, Anda akan mempelajari taktik cepat dan terarah: menonaktifkan sementara kategori yang sangat bising agar peninjauan tetap berguna sambil Anda menyempurnakan aturan yang sebenarnya.

Peninjau CI hanya memiliki satu tugas: menampilkan masalah yang perlu ditindaklanjuti manusia. Saat menghasilkan lebih banyak alarm palsu daripada temuan nyata, dua hal terjadi:

• Pengembang berhenti membaca komentar.
• Bug nyata tersembunyi di dalam gangguan (hilang di tengah: perhatian menurun pada bagian tengah daftar yang panjang).

Agregat "kami menemukan 40 masalah" terdengar produktif, tetapi jika 35 di antaranya adalah gangguan, peninjauan itu bernilai negatif — menghabiskan perhatian dan memberikan sedikit hasil. Mengurangi positif palsu bukan sekadar kosmetik; hal itu melindungi kredibilitas seluruh pipeline.

Sebelum menonaktifkan apa pun, cari tahu kategori mana yang menghasilkan gangguan. Jalankan peninjauan dalam mode noninteraktif dengan keluaran yang dapat dibaca mesin agar Anda dapat menghitung temuan berdasarkan jenis, bukan sekadar membaca sekilas prosa.

Gunakan -p (juga --print) untuk proses CI noninteraktif dan --output-format json untuk hasil yang dapat diurai.

Setelah Anda menemukan kategori yang sebagian besar menghasilkan positif palsu — misalnya style atau doc_formatting — perbaikan tercepat adalah menonaktifkannya sementara. Jangan menghapusnya selamanya; bisukan sekarang, lalu aktifkan kembali setelah Anda menulis kriteria yang lebih tajam.

Tempat paling bersih untuk melakukan ini adalah instruksi yang dibaca peninjau. Jelaskan secara eksplisit hal-hal yang harus dilewati, karena kriteria eksplisit lebih baik daripada permintaan samar seperti "kurangi gangguan."

Flag pada satu perintah hanya membisukan satu proses. Agar aturan konsisten pada setiap peninjauan CI, letakkan aturan tersebut di CLAUDE.md tingkat proyek (./CLAUDE.md atau .claude/CLAUDE.md) — bagikan melalui sistem kontrol versi agar setiap rekan tim dan setiap proses pipeline mewarisinya.

Hindari ~/.claude/CLAUDE.md tingkat pengguna untuk tujuan ini: berkas tersebut bersifat pribadi dan TIDAK dibagikan melalui VCS, sehingga rekan tim baru dan pelaksana CI tidak akan mengetahui aturan tersebut.

Terkadang sebuah kategori hanya bising di sebagian repositori. Berkas yang dibuat secara otomatis atau perlengkapan pengujian, misalnya, akan terus-menerus memicu peninjau yang ketat. Alih-alih memperbesar CLAUDE.md monolitik, gunakan berkas .claude/rules/ dengan frontmatter YAML paths — berkas ini dimuat hanya ketika berkas yang cocok sedang diproses, sehingga menghemat konteks dan token.

Membisukan kategori yang bising memberi Anda ruang bernapas, tetapi perbaikan yang bertahan lama adalah kriteria yang lebih tajam untuk kategori yang tetap digunakan. Kriteria eksplisit selalu lebih baik daripada instruksi samar.

• Samar: "Tandai komentar yang buruk." → terpicu pada semuanya.
• Eksplisit: "Tandai komentar ONLY ketika komentar tersebut bertentangan dengan kode yang dijelaskannya." → terpicu pada cacat nyata.

Mengaktifkan kembali kategori dengan aturan yang tepat jauh lebih baik daripada membiarkannya dibisukan selamanya.

Ketika sebuah kategori terus salah terpicu pada kasus yang berada di batas, jangan hanya menjelaskan batasnya — tunjukkan. Dua hingga empat contoh few-shot terarah untuk setiap ambiguitas mengajarkan model garis pemisah antara sinyal dan gangguan. Model menggeneralisasi dari contoh tersebut; model tidak sekadar menyalinnya.

Few-shot sangat kuat untuk konsistensi, kasus batas, format keluaran, dan pengurangan temuan halusinasi — tepatnya tuas yang menurunkan jumlah positif palsu.

Salah satu sumber positif palsu yang sulit disadari adalah bias. Jika sesi yang sama yang menghasilkan kode juga meninjaunya, penulis masih mengingat alasannya dan tidak akan mengkritik dirinya sendiri — ia merasionalisasi pilihannya sendiri. Hal yang sama berlaku untuk peninjau yang telah dipengaruhi oleh konteks pembuatan kode yang panjang.

Lakukan peninjauan dalam sesi baru yang terisolasi. Instans independen mengevaluasi perubahan berdasarkan keunggulannya sendiri dan menghasilkan temuan yang lebih bersih serta tidak terlalu membenarkan diri.

Pola yang sering menimbulkan kebisingan pada PR iteratif: peninjau melaporkan ulang temuan yang sama pada setiap push, sehingga temuan yang benar-benar baru tenggelam. Saat menjalankan ulang peninjauan, berikan hasil sebelumnya dan minta peninjau melaporkan hanya masalah baru atau yang masih belum diperbaiki.

Dengan demikian, keluaran setiap proses tetap ringkas dan pengembang tidak perlu menggulir melewati pengulangan — faktor lain yang diam-diam menyebabkan kelelahan akibat positif palsu.

Menonaktifkan kategori yang berisik adalah keputusan penyetelan terkait sinyal peninjauan — itu BUKAN cara untuk menegakkan aturan penting. Instruksi pada tingkat perintah memiliki probabilitas sekitar 90%; instruksi tersebut sangat baik untuk mengarahkan hal yang dilaporkan peninjauan, tetapi tidak tepat untuk memberikan jaminan.

Jika sebuah aturan memiliki konsekuensi finansial, hukum, atau keselamatan (memblokir pengembalian dana di atas $500, menolak rahasia yang di-commit ke repositori), tegakkan aturan itu dengan kait deterministik, bukan perintah. Bisukan kebisingan dengan perintah dan konfigurasi; tegakkan aturan ketat dengan kait. Pisahkan kedua tugas tersebut.

Hal-hal penting untuk menjaga kepercayaan terhadap peninjau CI:

• Kebisingan menghancurkan kepercayaan — peninjau yang terus memberi peringatan palsu akan dibisukan, dan bug nyata tersembunyi di dalam daftar.
• Ukur terlebih dahulu — jalankan dengan -p dan --output-format json, lalu hitung temuan berdasarkan kategori untuk menemukan sumber kebisingan.
• Nonaktifkan sementara kategori dengan kebisingan tinggi; bisukan sekarang, lalu aktifkan kembali dengan aturan yang lebih tajam.
• Masukkan ke dalam CLAUDE.md proyek (dibagikan melalui VCS), dan gunakan .claude/rules/ dengan paths untuk membatasi pembisuan pada berkas yang dibuat otomatis atau berkas perlengkapan pengujian.
• Pertajam temuan yang tersisa dengan kriteria eksplisit dan 2-4 contoh few-shot untuk setiap ambiguitas.
• Lakukan peninjauan dalam sesi terisolasi dan laporkan hanya masalah baru atau yang belum diperbaiki saat pengulangan.
• Bisukan dengan perintah/konfigurasi; tegakkan aturan penting dengan kait deterministik. Jangan pernah menyamakan keduanya.