Cara Review Kode Hasil AI dengan Kritis

Salah satu kebiasaan paling berbahaya yang saya lihat berkembang sejak AI coding assistant jadi bagian sehari-hari adalah percaya karena kodenya terlihat rapi. Indentasi konsisten, nama variabel jelas, ada komentar di sana-sini, bahkan sudah dibungkus try-catch. Secara visual itu meyakinkan. Tapi rapi dan benar adalah dua hal yang berbeda, dan model bahasa sangat pandai menghasilkan yang pertama tanpa selalu menjamin yang kedua. Sebagai orang yang kerja di sistem yang menyentuh data klinis, saya belajar bahwa kebiasaan review yang longgar terhadap kode AI bisa lolos ke produksi justru karena terlihat meyakinkan, bukan karena benar-benar diperiksa.

Berikut cara saya membiasakan diri me-review kode hasil AI secara kritis, bukan sekadar membaca sekilas lalu klik approve.

Jangan percaya sebelum cek asumsi yang dipakai

Setiap kode yang dihasilkan AI membawa asumsi implisit tentang input, urutan eksekusi, dan lingkungan tempat kode itu jalan. Model tidak tahu skema database Anda yang sebenarnya, tidak tahu apakah suatu field bisa null di produksi, dan tidak tahu apakah service lain di sistem Anda punya kebiasaan aneh yang sudah jadi kesepakatan tak tertulis di tim. Ia hanya menebak berdasarkan pola paling umum.

Kebiasaan yang saya pakai: setiap kali menerima kode baru, saya coba tuliskan ulang asumsinya dalam kalimat eksplisit. Misalnya, "fungsi ini mengasumsikan array tidak pernah kosong" atau "query ini mengasumsikan relasi selalu ada". Begitu asumsi itu tertulis, jauh lebih mudah menguji apakah asumsi tersebut memang berlaku di kode base saya, atau justru bertentangan dengan validasi yang sudah ada di layer lain.

Cari edge case yang model cenderung lewatkan

Ada pola edge case yang berulang kali saya temukan lolos dari kode hasil AI: penanganan nilai kosong atau null, race condition pada operasi yang dijalankan concurrent, batas angka (misalnya pagination yang tidak menghitung baris terakhir dengan benar), dan encoding karakter khusus pada input teks bebas. Model cenderung menulis jalur bahagia (happy path) dengan sangat baik, tapi jalur gagal sering ditangani secara generik, misalnya satu blok catch besar yang menelan semua jenis error tanpa membedakan mana yang perlu di-retry dan mana yang harus langsung gagal.

Untuk kasus seperti operasi database, saya selalu bertanya: apa yang terjadi kalau fungsi ini dipanggil dua kali bersamaan? Apa yang terjadi kalau koneksi putus di tengah transaksi? Pertanyaan semacam ini jarang terjawab otomatis oleh kode yang dihasilkan, karena model tidak benar-benar mensimulasikan concurrency, ia hanya menulis kode yang secara sintaks terlihat menangani hal itu.

Periksa konsistensi dengan kode lain di sistem

Kode AI biasanya ditulis "dalam vakum" per prompt, tanpa benar-benar membaca seluruh code base Anda kecuali diberi konteks eksplisit. Akibatnya, ia bisa memperkenalkan pola yang bekerja secara terisolasi tapi tidak konsisten dengan konvensi yang sudah dipakai di tempat lain, misalnya menulis validasi manual padahal tim sudah punya form request khusus, atau memanggil query mentah padahal seluruh sistem sudah pakai query builder atau ORM secara konsisten.

Sebelum menerima kode baru, saya cek: apakah pola error handling-nya sama dengan modul lain? Apakah penamaan variabel dan struktur foldernya mengikuti konvensi yang sudah ada? Ketidakkonsistenan ini kelihatan sepele, tapi lama-lama membuat code base sulit dipelihara karena setiap bagian punya "gaya" masing-masing tergantung siapa atau apa yang menulisnya.

Jangan lupa baca kode yang dihapus atau diubah

Review yang kritis bukan cuma soal kode baru, tapi juga soal apa yang diubah atau dihapus dari kode lama. AI kadang menyederhanakan logika yang sebelumnya sengaja dibuat rumit untuk menangani kasus khusus, karena dari sudut pandang model, versi yang lebih sederhana terlihat lebih "bersih". Kalau saya tidak membaca diff secara utuh, perubahan semacam ini gampang lolos karena hasil akhirnya tetap terlihat berfungsi saat dites dengan kasus umum.

Takeaway

Kode hasil AI layak dipakai sebagai titik awal yang cepat, tapi tidak layak dipercaya begitu saja hanya karena rapi. Biasakan menuliskan asumsi secara eksplisit, cari edge case yang biasanya lewat dari happy path, cocokkan dengan konvensi yang sudah ada di sistem Anda, dan selalu baca diff secara utuh, bukan cuma potongan yang baru ditambahkan. Kebiasaan ini butuh sedikit lebih banyak waktu di awal, tapi jauh lebih murah dibanding menemukan bug semacam ini setelah sampai ke pengguna.