Mengapa tinjauan kode AI tidak bisa menjadi sanggahan yang memadai

• Solusi bahwa manusia cukup meninjau semua kesalahan yang sering dibuat alat coding LLM sulit menjamin kualitas dan produktivitas sekaligus karena batas kapasitas pemrosesan code review
• Menurut studi empiris, tinjauan yang efektif memiliki batas atas sekitar 1 jam·400 LOC dalam satu sesi; jika melewati itu, efektivitas deteksi cacat cepat menurun akibat kelelahan dan turunnya konsentrasi
• Jika standar ini diterapkan, setiap 400 LOC yang ditulis LLM membutuhkan 1 jam tinjauan terfokus oleh developer berpengalaman, sehingga throughput harian yang realistis bisa di bawah 1.000 LOC
• Ada bukti awal bahwa manusia menemukan lebih sedikit cacat pada kode yang dihasilkan LLM tetapi menunjukkan keyakinan yang lebih kuat, sehingga sulit menganggap tinjauan saja cukup untuk menyaring kesalahan
• Diperlukan studi empiris yang secara langsung mengukur dan mereplikasi tingkat deteksi cacat, kecepatan review, serta volume harian berkelanjutan untuk kode LLM, agar efektivitas alat dapat dinilai berdasarkan bukti, bukan anekdot

---

Alasan bersikap skeptis terhadap alat coding LLM

• Fokus masalahnya bukan pada hak kekayaan intelektual, biaya ekologis, konsumsi sumber daya, atau penilaian bahwa semua output LLM buruk
• Dengan bukti ilmiah yang ada saat ini, sulit memastikan bagaimana alat coding LLM membantu developer menulis kode yang lebih baik atau lebih cepat
• Argumen pendukung tidak membahas langsung masalah dan bukti yang relevan, dan bantahan terhadap skeptisisme justru kadang memperkuat masalahnya
• Karena artikel ini ditulis sekitar setahun lalu, istilah Coding Assistants yang kini hampir tergantikan masih digunakan; namun karena tidak menemukan istilah lain yang mencakup berbagai penggunaan coding dari AI generatif, istilah itu tetap dipertahankan

Analogi “magang” dan solusi tinjauan menyeluruh

• Alat coding LLM memiliki risiko kesalahan yang relatif tinggi karena struktur kerja dan antarmuka interaksinya
  • Dapat membuat halusinasi atau typo
  • Dapat menghasilkan hasil yang tidak terkait dengan permintaan atau mengerjakan tugas lewat jalur lain
• Pengguna sering menganalogikan alat seperti ini sebagai magang
  • Harus diasumsikan bahwa hasilnya akan keliru sampai tingkat tertentu
  • Harus dianggap bekerja tanpa benar-benar memahami apa yang sedang dilakukan
• Respons yang umum dipakai adalah meminta orang berpengalaman meninjau seluruh hasilnya seperti kode dari magang atau developer junior
  • Berdasarkan asumsi bahwa manusia lebih tahu dan memegang tanggung jawab akhir
  • Juga diikuti logika bahwa semua kode yang masuk ke codebase memang pada dasarnya harus direview

Tingkat review yang dibutuhkan untuk mengawasi LLM

• Dalam industri dan literatur riset, review mencakup berbagai praktik yang berbeda
• Review ringan yang dibagi ke beberapa orang berguna untuk berbagi pengetahuan tentang perubahan dan menerapkan aturan permukaan, tetapi tidak cukup sebagai standar untuk mengawasi kode LLM
• Tidak sampai perlu memeriksa setiap baris dengan menyakitkan selama berjam-jam seperti tinjauan berbasis komite di masa lalu, tetapi tetap dibutuhkan code review yang cukup mendalam dan menyeluruh
• Karena LLM dapat menulis kode kompleks dan cacat perangkat lunak sering bersembunyi di detail, pengecekan ringan saja tidak cukup

Batas empiris yang dihadapi code review

• Batas utama review efektif yang ditemukan dalam studi empiris adalah sebagai berikut
  • Satu sesi review menjadi terlalu panjang jika melebihi 1 jam
  • Jumlah yang dapat ditinjau secara efektif dalam waktu itu maksimal sekitar 400 LOC
• Review yang melewati 1 jam cepat mengalami penurunan efektivitas, terlepas dari ukuran kode
  • Bukan hanya karena sebagian besar kode sudah ditinjau
  • Menjaga konsentrasi tinggi selama 1 jam menimbulkan kelelahan dan kebosanan sehingga diperlukan istirahat
• Saya tidak menemukan studi yang meneliti waktu pemulihan yang dibutuhkan di antara sesi 1 jam
  • Sebagai batas atas ekstrem, dapat diasumsikan beberapa kali dalam sehari
  • Sekitar 2 kali sehari disarankan sebagai jumlah rata-rata yang mungkin, tetapi ini bukan angka pasti
• Jumlah baris kode yang dapat direview per jam sangat bergantung pada konteks dan jenis kode, serta pengalaman dan pengetahuan reviewer
• Meski bukan standar absolut, hampir tidak ada data empiris tentang review yang lebih cepat dari 400 LOC/H namun tetap efektif menemukan dan menandai cacat, sehingga angka ini dapat dilihat sebagai kecepatan maksimum yang efektif

Perhitungan throughput saat diterapkan pada kode LLM

• Untuk menyelesaikan masalah kode LLM lewat review, bahkan dalam skenario terbaik dibutuhkan 1 jam developer berpengalaman untuk setiap 400 LOC yang dihasilkan
• Sesi review yang dapat dijalani developer sekitar 10–40 kali per minggu, dan di antara tiap sesi dibutuhkan waktu pemulihan yang durasinya tidak diketahui
  • Waktu pemulihan mungkin setidaknya 1–2 jam, tetapi tidak ada riset langsung yang mendukungnya
• Waktu fokus seperti ini juga harus digunakan untuk rapat, desain, respons insiden, dan memikirkan kode yang akan ditulis sendiri
• Dalam skenario terbaik, developer yang menggunakan LLM dapat menulis, meninjau, dan meng-commit beberapa ribu LOC per hari
• Dalam skenario realistis, throughput harian bisa di bawah 1.000 LOC
  • Ini mencakup boilerplate, test, migrasi, dan file konfigurasi
  • Satu file test saja bisa melebihi 400 LOC
• Bahkan dalam kondisi terbaik ketika sebagian besar kode sederhana dan mudah direview, review berfungsi sebagai batas atas peningkatan produktivitas

Perbedaan review kode manusia dan kode LLM

• Bukti yang ada berasal dari situasi ketika reviewer manusia mencari cacat pada kode yang ditulis manusia, dan tidak ada bukti bahwa efisiensi yang sama berlaku untuk kode LLM
• Bukti awal menunjukkan bahwa orang yang meninjau kode yang dihasilkan LLM cenderung menemukan lebih sedikit cacat, tetapi lebih yakin bahwa mereka telah menemukan semua cacat
• Dibanding kombinasi penulis manusia dan reviewer manusia, kombinasi alat coding LLM dan reviewer manusia dapat menghasilkan keluaran berkualitas lebih rendah, sementara reviewer pada kasus kedua bisa menilai performanya sendiri lebih tinggi
• Review menyeluruh tidak hanya membatasi manfaat produktivitas LLM, tetapi juga kekurangan bukti kuat bahwa ia benar-benar menyelesaikan kesalahan yang sering muncul

Biaya yang muncul sebelum cacat diperbaiki

• Perhitungan ini tidak mencakup biaya untuk memperbaiki cacat yang ditemukan
• Pembahasan hanya mencakup kemampuan dan biaya developer profesional untuk meninjau kode dan menandai masalah dalam lingkungan kerja
• Terlepas dari jumlah atau tingkat keparahan cacat yang dibuat LLM, biaya untuk meninjau kode yang dihasilkan tetap ada
• Sekalipun alat coding LLM menghasilkan kode berkualitas sangat tinggi, jika semua output harus ditinjau, biaya dan batas produktivitas yang sama tetap berlaku

Kontradiksi dalam menyerahkan kode yang sulit ditinjau

• Pendukung LLM menonjolkan sebagai keunggulan bahwa alat dapat memproduksi kode yang menyakitkan bagi manusia untuk ditulis
• Salah satu contoh mengusulkan agar LLM menulis 100% kode Bash yang dibutuhkan ke depan
• Skrip shell memiliki parsing yang longgar dan makna yang terlalu bertumpuk, sehingga satu typo pada tanda baca bisa saja tidak berbahaya atau justru berujung menghapus seluruh komputer
• Kode seperti ini mudah menimbulkan kesalahan, sulit dipahami dan direview, serta sulit menyadari kesalahan fatal
• Pendekatan menyerahkan kode yang paling sulit direview kepada alat yang membuat kesalahan secara acak lalu cukup meminta manusia memeriksanya belum membuktikan lebih dulu bahwa output LLM benar-benar merupakan objek review yang efektif
• Masalahnya adalah menjadikan kode yang paling sulit direview sebagai contoh penggunaan utama tanpa menjawab apakah review menyelesaikan kesalahan dan apakah peningkatan produktivitas yang memadai masih tersisa

Tugas empiris yang harus diverifikasi

• Tugas pertama adalah mengukur seberapa baik reviewer manusia menemukan cacat pada kode yang dihasilkan LLM
  • Kemampuan deteksi cacat
  • Kecepatan review
  • Volume review yang dapat dipertahankan sepanjang hari
• Diperlukan data tentang manusia yang mereview kode LLM, seperti riset terhadap kode yang ditulis manusia
• Eksperimen dan data empiris yang ada terbatas dari segi skala dan konteks, sehingga lebih banyak studi replikasi diperlukan
• Data ilmiah saat ini mengarah pada kemungkinan bahwa manusia tidak meninjau hasil LLM dengan baik atau sulit mendeteksi masalahnya
  • Ini bisa konsisten dengan karakteristik LLM yang dilatih untuk menghindari deteksi
  • Kemungkinan bahwa hasil yang ada hanya kebetulan juga harus diverifikasi
• Tugas kedua adalah memastikan apakah review atas keluaran LLM merupakan masalah yang berbeda secara kualitatif dari review atas hasil tulisan manusia
  • Jika perbedaannya begitu besar sehingga riset code review yang ada tidak berlaku, logika kritik saat ini bisa runtuh
  • Namun bukti awal menunjukkan bahwa review kode yang dihasilkan LLM mungkin lebih sulit, bukan lebih mudah; dalam hal ini kritik justru diperkuat

Evaluasi empiris untuk alat profesional, bukan anekdot

• Dengan mempertimbangkan fakta yang diketahui tentang code review, sulit memastikan manfaat apa yang diberikan alat LLM dengan antarmuka dan prosedur saat ini kepada developer profesional
• Yang lebih menjadi sumber ketidakpuasan bukanlah vendor yang berulang kali menyediakan alat dan prosedur yang bertentangan dengan bukti, melainkan sikap yang memperlakukan skeptis sebagai tidak normal tanpa membahas masalahnya
• Pada TDD, type system, pemisahan organisasi testing dan development, CI/CD, serta DevOps, pola anekdot yang mengungguli bukti empiris juga telah berulang
• Alih-alih bersandar pada kisah “kali ini berhasil untuk saya”, perlu dilakukan riset nyata mengikuti cara bukti empiris tentang code review dibangun
• Jika alat coding LLM ingin diperlakukan sebagai alat pengembangan profesional, efektivitas dan batasannya harus diverifikasi dengan berpusat pada ergonomi manusia dan bukti empiris

[GN⁺]

Pendapat di Lobste.rs

• Kecepatan tidak harus menjadi satu-satunya tujuan. Perbaikan bug bisa dipisahkan menjadi commit persiapan tersendiri agar ditinjau secara independen, struktur tipe yang masih bisa merepresentasikan state yang salah bisa diperbaiki, dan jika keandalan pengujian kurang maka property-based testing, fuzzing, dan metode formal bisa dicoba
  Dulu pekerjaan seperti ini sering ditumpuk dalam satu commit atau ditinggalkan sebagai TODO utang teknis, tetapi sekarang biaya marjinal untuk mengimplementasikannya dengan benar menjadi sangat rendah. LLM adalah alat yang terbuka, jadi manfaat yang diberikannya akan sebanding dengan nilai yang diprioritaskan penggunanya
  Memang ada risiko makin banyak prototipe yang tidak selesai dan tidak pernah sampai ke produksi, tetapi secara umum ini sangat membantu rekayasa yang mengutamakan ketelitian

  • Saya sangat sepakat dengan penilaian ini, tetapi rasanya yang benar-benar terjadi di kebanyakan perusahaan berbeda. Meski LLM bisa meningkatkan ketelitian, alat ini sering dipakai untuk perlombaan MVP dengan kualitas serendah mungkin
    Mungkin ini masalah budaya perusahaan, tetapi tetap mengecewakan, dan saya berharap industri ini sadar lalu membuat perangkat lunak yang lebih berkualitas

• Jika agent dimasukkan ke proyek lama dengan satu prompt, ia terus menemukan bug nyata tanpa perlu banyak usaha. Manusia juga ceroboh dan saya sendiri pun sering salah, tetapi LLM lebih cepat sekaligus lebih bodoh dalam banyak hal, jadi masalahnya hanya terlihat lebih cepat
  Kesalahan akan terakumulasi, jadi jika agent dibiarkan mengubah kode sembarangan, semuanya cepat rusak; tetapi menganggap alat ini tidak berguna hanya karena cara pakai naif tidak stabil juga merupakan penilaian yang malas
  Sekarang setiap kali ada perubahan saya menjalankan 5 tinjauan ahli secara otomatis, mencakup arsitektur, maintainability, reliabilitas dan keamanan, lalu menatanya dalam sistem dokumen desain untuk sangat memperbaiki pengambilan keputusan agent. Ini memang belum sempurna, tetapi lebih baik daripada pendekatan naif, dan fakta bahwa masih banyak ruang untuk perbaikan juga menjadi bagian menarik dari memakai alat baru

  • Di sini yang dibahas hanya pembuatan dan peninjauan kode, bukan penggunaan analisis teks probabilistik untuk menemukan pola bug

• Meski bisa dibuat lebih cepat lewat prompt, waktu yang dibutuhkan untuk memverifikasi dan memahaminya justru lebih besar, sehingga saya jadi bertanya-tanya apakah akan lebih cepat jika menulisnya sendiri dari awal. Menilai mana yang lebih baik pun memakan waktu dan energi, dan saya ingin memakai sumber daya itu untuk hal lain
  Namun, jika pengirim PR menanggung kepemilikan dan tanggung jawab, apakah ia memakai LLM atau tidak menjadi tidak penting. Jika standar kualitas, akurasi, dan konsistensi terpenuhi, silakan pilih cara yang lebih cepat, dan tanggung jawab tetap berada pada penulis manusianya
  Secara pribadi AI bagus untuk belajar serta memperluas dan memperdalam pemahaman, tetapi jika mempertimbangkan keseluruhan proses, bukan hanya waktu input, menulis kode langsung sendiri masih lebih produktif

• Masalahnya dimulai dari fakta bahwa tulisan ini dibuat hampir 1 tahun lalu. Dalam 6 bulan terakhir, terutama 3 bulan terakhir, kegunaan model cloud berbayar terkini meningkat jauh
  Seperti prinsip MFIC yang dikembangkan dalam pekerjaan audit, kita perlu memeriksa apakah ada kontrol yang mencegah seluruh kategori kegagalan: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
  Kita juga butuh alat seperti https://github.com/pmarreck/dirtree dan https://github.com/pmarreck/codescan yang menjaga kode dan struktur proyek tetap ada dalam konteks, dan ini juga berguna bagi pengembang manusia yang lupa atau belum familiar dengan codebase
  Pada akhirnya, kita bisa memanfaatkan ini dengan benar dan memperoleh keuntungannya, atau terus menulis kode kustom sendiri sambil tetap membuat bug dan celah keamanan lalu disalip pesaing yang lebih cepat. Dari sudut pandang orang yang pernah menghabiskan 2 orang-tahun pada codebase Ruby on Rails Desk.com yang dibuang dengan skala sejuta baris, kode perusahaan itu sementara, sehingga cocok dengan kode hasil LLM
  Jika menyangkut implementasi internal Erlang mungkin sulit dipercaya, tetapi tetap bisa disuruh menulis per fungsi lalu ditinjau, dan kadang hasilnya lebih baik dari dugaan. Daripada memilih hanya salah satu antara jarum rajut dan mesin tenun, idealnya keduanya dipakai sesuai situasi

  • Bukan implementasi internal; saya juga menangani kode perusahaan, dan saya orang yang membereskan kode yang ditinggalkan pengguna LLM. Yang barusan Anda katakan tidak membantah satu pun kalimat di tulisan asli, malah justru mendukungnya
  • Klaim bahwa dalam 6 bulan atau 3 bulan terakhir ada peningkatan besar sudah diulang setidaknya 2 tahun

• Dari pengalaman pribadi dan para pengembang berpengalaman tepercaya di sekitar saya, LLM berulang kali memungkinkan coding yang lebih baik dan lebih cepat, jadi sulit bagi saya untuk menanggapi serius tulisan yang mengatakan bukti ilmiah menunjukkan ini tidak mungkin membantu
  Walau tanpa paper peer-review, saya sudah melihat cukup banyak, dan saya tidak akan mengubah penilaian yang ada hanya karena satu riset METR membantah perkiraan peningkatan produktivitas pengembang

  • Untuk seseorang yang menyebut dirinya peneliti, mengatakan pengalaman pribadi saja sudah cukup adalah standar bukti yang sangat rendah sampai terasa mencengangkan
  • Pengalaman pribadi juga dipakai saat dokter menolak cuci tangan atau membela praktik bloodletting. Sains dibangun di atas sejarah membunuh orang karena mempercayai pengalaman seperti itu
    Jika ditunjukkan secara ketat dan sahih secara metodologis, serta dijelaskan di mana letaknya berbeda dari riset empiris kuat yang sudah ada, saya siap mengubah pikiran. Tetapi pengalaman pribadi atau selusin anekdot tanpa penjelasan tidak cukup
    Sains dan rekayasa telah memperbaiki hidup miliaran orang, dan kita tidak bisa membuangnya hanya karena seseorang percaya dirinya lebih benar
  • Anda meminta bukti yang bisa meyakinkan orang lain, lalu menjawab bahwa Anda sendiri sudah yakin jadi tidak perlu lagi, itu berarti Anda belum menjawab pertanyaannya
    Saya tidak bermaksud menyebut seseorang pengikut sekte, tetapi sikap yang menerima tantangan terhadap keyakinan secara personal sambil tidak tahu cara meyakinkan orang lain mirip dengan pola komunikasi kelompok sekte
  • Saya masih menahan penilaian untuk LLM yang dipakai menghasilkan kode, tetapi apakah penulis PR itu manusia atau mesin tidak penting dan standar kualitas yang sama harus diterapkan
    Meski kebanyakan PR dibuat dengan LLM, pengirimnya tetap harus bertanggung jawab dan membaginya dalam konteks serta ukuran yang mudah dipahami orang lain. Kode tetap merupakan spesifikasi akhir perangkat lunak, dan fakta bahwa pengembang harus memilikinya serta memahaminya tidak berubah

• Klaim bahwa agent AI banyak membuat kesalahan setahun lalu memang benar, tetapi belum jelas apakah sekarang masih begitu, dan sekitar November tahun lalu saya merasa ada titik belok pada model frontier
  Memang benar LLM menambah jumlah kode dan menciptakan tekanan baru pada kapasitas review, tetapi engineer harus menahannya dan memastikan volume review sesuai dengan kemampuan pemrosesan yang nyata

  • Mereka masih membuat kesalahan arsitektur yang serius. Misalnya tidak menyadari situasi di mana perilaku bersama bisa diekstrak dan digunakan ulang, lalu malah menambahkan kode baru
    Yang lebih buruk, kode baru itu biasanya tetap berjalan sehingga besar kemungkinan di-merge tanpa dibereskan

• Saya heran mengapa ketika model frontier menulis kode dalam jumlah besar, tidak ada eksplorasi serius terhadap kontribusi negatif berupa usulan menghapus kode. Seperti “The Best Code is No Code At All” - Jeff Atwood, akan menarik jika mereka bisa mengurai kompleksitas codebase yang membengkak oleh lapisan abstraksi dan mengusulkan penghapusan baris
  Mungkin ini sudah mungkin dilakukan, tetapi saya sendiri belum melihatnya

• Sebagai koreksi, bagian “The Limits Of Reviews” menyebut kecepatan maksimum yang efisien adalah 400 baris per jam, bukan 400 baris per review seperti yang awalnya saya kira
  Namun saya masih penasaran dari paper code review yang mana tepatnya angka 1 jam dan 400 baris itu berasal. Jika nama papernya tidak disimpan terpisah, tidak perlu menghabiskan banyak waktu untuk mencarinya lagi

  • Saya menyimpan materi terkait di suatu tempat jadi bisa saya cek. Sebagian besar menyebut batas 100~200 baris per jam, tetapi banyak penelitian lama ketika bahasa pemrograman lebih rentan terhadap bug dibanding sekarang
    Saya sedang bepergian sekarang, jadi tolong ingatkan saya lagi beberapa hari lagi
  • Angka 400 baris per jam terdengar meragukan, jadi saya hitung dari catatan kerja saya. Dalam 6 bulan terakhir saya meninjau 173 PR yang setara dengan perubahan 139 ribu baris
    Jika dari 40 jam kerja per minggu, porsi untuk review adalah 25%, maka hasilnya sekitar 540 baris per jam; jika 15% maka 900 baris per jam; jika 5% maka 2.700 baris. Throughput nyata saya diperkirakan sekitar 500~1.000 baris per jam, cukup dekat dengan angka yang disebut tanpa sumber jelas itu

• Saya sulit memahami logika bahwa kode hasil AI harus ditinjau lebih banyak atau lebih sedikit daripada kode yang ditulis manusia. Karena kriteria persetujuannya sama, maka saya meninjaunya pada tingkat yang sama