Meninjau Keluaran dalam Skala Besar

Ini masalah yang jujur: ketika agent menulis ratusan baris di beberapa tugas, kamu tidak bisa membaca setiap baris seperti kamu meninjau diff sepuluh baris. Berpura-pura bisa akan membawa pada salah satu dari dua hal: rubber-stamping (kamu menyetujui tanpa melihat) atau kelumpuhan (kamu tidak pernah mempercayai apa pun). Tidak satu pun dari keduanya menghasilkan produk yang bisa dirilis.

Jalan keluarnya adalah menggerbangi (gate) beberapa lapisan alih-alih membaca semuanya:

• Test adalah lantai dasarnya. Tidak ada keluaran agent yang digabungkan tanpa test yang relevan berwarna hijau dan pemeriksa tipe (type-checker) yang bersih. Ini tidak bisa dinegosiasikan dan bersifat otomatis — mesinlah yang melakukan bagian ini.
• Tinjau secara spot pada bagian yang berisiko. Kamu tidak bisa membaca semuanya, jadi bacalah bagian dengan radius ledakan tinggi: apa pun yang menyentuh autentikasi (auth), uang, penghapusan data, atau panggilan eksternal. Skim sisanya untuk mencari tanda bahaya dari bab membangun fitur — berkas yang seharusnya tidak disentuh, hal-hal yang dihapus diam-diam, permintaan kecil yang menghasilkan diff yang besar.
• Baca diff-nya, bukan basis kodenya. git diff --stat memberitahumu apa yang berubah dan seberapa banyak dalam hitungan detik. Sebuah tugas yang dibatasi ruang lingkupnya pada satu modul namun menunjukkan perubahan di enam modul adalah sinyal untuk memeriksa lebih dalam, sebelum kamu membaca satu baris pun.
• Jalankan. Test suite yang hijau bukanlah aplikasi yang berfungsi. Klik benda itu. Pemeriksaan terakhir selalu sama seperti dari setiap bab lain: apakah itu benar-benar melakukan apa yang kamu minta, di depan matamu?

Membatasi ruang lingkup terbayar dua kali di sini. Tugas yang kamu batasi ketat menghasilkan diff yang benar-benar bisa kamu tinjau; tugas yang kamu lepaskan longgar menghasilkan diff yang tidak bisa. Masalah peninjauan sebagian besar sudah terselesaikan sejak awal, di dalam brief-nya.