- Pertanyaan menarik tentang apakah kode yang ditulis AI layak direview oleh AI
- Bot seperti Devin AI kini menulis PR paling banyak, dan makin banyak pula kasus ketika review juga dilakukan oleh AI
- Ada pula argumen bahwa karena LLM tidak memiliki state (stateless), dan struktur internalnya berbeda saat menulis dan saat mereview, pemisahan peran tetap dimungkinkan
- Kode yang dihasilkan AI memicu jenis bug yang berbeda dari manusia, dan AI lebih efektif dalam menemukan bug tersebut
- Pada akhirnya, review AI lebih unggul untuk mendeteksi kesalahan nyata dibanding review manusia, meski penilaian arsitektur dan style guide oleh manusia tetap penting
Bolehkah AI mereview kodenya sendiri?
- Sebagian besar perusahaan memegang prinsip penulis ≠ reviewer
- Namun AI berbasis LLM tidak memiliki state dan menilai ulang dari awal pada setiap permintaan
- Artinya, meski menggunakan mesin yang sama, penulisan dan review bisa dianggap sebagai “mobil” yang berbeda
Scaffolding: struktur review AI
- AI untuk review menjalankan workflow khusus seperti berikut:
- analisis diff kode
- deteksi bug
- penulisan komentar dan penilaian tingkat keparahan
- merujuk dokumentasi codebase dan file terkait
- Sementara itu, AI pembuat kode beroperasi dalam konteks yang sepenuhnya berbeda, sehingga review dan generasi kode berbeda secara fungsional
Manusia sebenarnya juga "mesin yang sama"
- Meski penulis PR dan reviewer berbeda, keduanya tetap berasal dari kecerdasan manusia yang sama
- Mereka berbagi pengetahuan dan pengalaman yang mirip, dari perusahaan yang sama dan pelatihan yang sama
- Pada akhirnya, baik AI maupun manusia sama-sama mirip dalam hal “mesin yang sama, kasus yang berbeda”
Kode AI membutuhkan review yang lebih presisi
-
Kualitas kode AI sedikit lebih rendah
- AI memang cepat, tetapi karena keterbatasan prompt, penyampaian requirement bisa menjadi kurang akurat
- Bahkan developer yang baik pun tidak mereview kode AI seteliti kode mereka sendiri
- Akibatnya, kualitas keseluruhan turun menjadi seragam ke bawah, lalu berkumpul di level menengah
-
Bug AI lebih sulit ditemukan manusia
- Bug yang dibuat AI adalah jenis bug yang biasanya tidak dibuat manusia
- Contoh: perubahan baris yang tak terduga, kesalahan halus pada conditional, dan sebagainya
- Menurut pengujian internal Greptile:
- AI (Sonnet) menemukan 32 dari 209 bug “Hard”
- Developer manusia rata-rata hanya menemukan 5–7 bug
Kesimpulan
- AI yang mereview kodenya sendiri secara teknis memungkinkan dan bermakna
- AI lebih unggul daripada manusia dalam deteksi bug, dan benar-benar berguna dalam proses review
- Namun interpretasi niat, penilaian desain, dan penilaian style kode oleh manusia tetap penting
- Standar tradisional penulis ≠ reviewer perlu ditafsirkan ulang untuk AI
3 komentar
Menurut saya menarik juga kalau review dilakukan sambil mengganti model LLM. Misalnya, kode yang ditulis dengan model A direview oleh model B, C, atau D.
Wah, di perusahaan kami praktiknya seperti ini: kalau kode yang ditulis dengan Cursor (Claude) diajukan sebagai PR, kami mereviewnya dengan ChatGPT. Jadi mulai sekarang biar mereka saling berantem. Sejak o4-mini, orang-orang sampai dibuat kagum. Di Cursor juga bisa langsung dicoba dengan cara mengganti model lalu mengajukan permintaan.
Opini Hacker News
Saya ingin menekankan bagian ini: para engineer tidak meninjau kode yang dihasilkan AI seteliti kode yang mereka tulis sendiri. Alasannya, LLM menghasilkan kode jauh lebih cepat daripada kecepatan mengetik. Jadi saat menulis kode sendiri, proses review terjadi secara alami, tetapi saat AI yang menghasilkan, proses itu terlewat. Menariknya, bagi engineer biasa, AI justru kadang meningkatkan kualitas kode. Semakin banyak AI digunakan, engineer yang bagus dan yang kurang bagus akan makin menghasilkan kode pada level yang mirip. Pola pikir pada tahap code review, desain, dan penulisan memang selalu berbeda, jadi selalu menarik
Setiap orang punya cara interaksi yang berbeda, jadi masing-masing ada metode yang lebih cocok. Bagi saya, mereview lebih mudah daripada menulis kode. Saat menulis sendiri, saya harus memikirkan banyak konteks di luar codebase, tetapi saat review saya bisa memusatkan konteks itu hanya pada codebase, jadi pattern matching bisa dilakukan lebih cepat. Sayangnya, level LLM masih setara engineer junior, jadi review PR justru butuh lebih banyak usaha dan energi
Engineer yang bagus belum tentu coder yang bagus
Jika bot dan prompt yang dipakai untuk code review AI berbeda dari yang dipakai untuk menulis kode, jauh lebih banyak error bisa ditemukan. Bahkan dengan mengulang alat yang sama beberapa kali, kadang masalah baru tetap bisa ditemukan. Baik manusia maupun AI sama-sama tidak bisa membuat kode yang sempurna dalam sekali jalan. Tool AI memang terus berkembang sampai bisa menguji dan mereview awal kodenya sendiri, tetapi saya percaya review kode PR oleh manusia maupun AI tidak akan pernah merugikan. Bahkan dengan tool buatan saya sendiri bernama Kamara, saya sering menemukan masalah pada kode yang saya tulis sendiri. Ada juga masalah seperti contoh greptile, yakni memberi saran pada lokasi kode yang benar-benar salah, tetapi itu makin bisa dikendalikan. Belum ada tool yang 100% sempurna, dan rasanya masih butuh sedikit waktu sebelum AI mengambil alih semuanya
Saat memulai OpenHands (nama sebelumnya OpenDevin), PR yang dibuat AI diajukan atas nama akun AI. Ini menimbulkan dua masalah serius: 1) orang yang memanggil AI bisa langsung merge tanpa review kode, sehingga kode yang tidak diperiksa bisa terdeploy, 2) tidak ada penanggung jawab PR yang jelas, jadi kalau tidak di-merge atau timbul masalah, tidak jelas siapa yang harus dimintai pertanggungjawaban. Karena itu kami mengubah strategi agar semua PR memiliki manusia sebagai owner, dan hanya commit yang tetap memakai nama AI. PR itu sendiri sepenuhnya menjadi tanggung jawab manusia
Menarik melihat bagian bahwa LLM pandai menemukan bug. Saya penasaran berapa banyak false positive yang muncul untuk mendapatkan tingkat deteksi bug nyata yang tinggi. Dari pengalaman saya, LLM sering menjawab "ada" padahal sebenarnya tidak ada bug
Sangat setuju. Saat saya bertanya sesuatu ke ChatGPT dan saya tidak suka sarannya, kalau saya bilang "yang bagian itu saya kurang yakin deh?" maka jawabannya langsung berubah. Padahal bisa saja jawaban awalnya benar, tetapi kalau pengguna terlihat tidak yakin, model mudah goyah. Karena itu tidak mudah memvalidasi tool dengan benar
Dalam kasus ini, setiap file hanya punya satu bug dan bot diminta menemukan tepat satu bug. Semuanya adalah contoh false positive, dan model mengarang bug di tempat yang sebenarnya tidak bermasalah sama sekali
Perbedaan di antara berbagai tool AI code review yang ada di pasar justru terletak pada tuning rasio signal/noise. Ada tool yang jauh lebih akurat dan memiliki false positive lebih sedikit
Sebagai programmer, tanggung jawab terpenting adalah membuat kode yang kita yakini benar dan bekerja normal. Tidak masalah apakah LLM digunakan atau tidak. Yang penting adalah saat mengajukan PR, kita punya sikap, "Saya yakin perubahan ini menyelesaikan masalah, dan saya berani mempertaruhkan reputasi saya." Karena itu, baik manusia maupun AI, PR selalu membutuhkan peninjau kedua
Menurut saya reputasi adalah inti dari semuanya. Ini bukan hanya berlaku untuk coding, tetapi juga untuk tulisan bahasa alami. Ke depan, yang bertanggung jawab atas isi bukanlah penulis, melainkan orang yang memublikasikannya, yaitu publisher. Mau chatbot terlibat 5% atau 95%, kalau ada masalah, saya yang memublikasikan tulisan itu yang harus disalahkan. Alasan "itu ulah chatbot" tidak akan diterima
Ini hanya membahas contoh engineer yang sepenuhnya otomatis seperti Devin, jadi situasinya agak berbeda dari engineer biasa
Belakangan ini banyak engineer melempar kode buruk buatan AI secara tidak bertanggung jawab, lalu berharap rekan lain yang menangkap masalahnya. Dulu hal seperti ini lebih jarang karena pembuatan kode itu sendiri lebih sulit
Saya sangat setuju dengan pernyataan bahwa tanggung jawab Anda adalah menghasilkan kode yang bisa dipercaya. Namun bahkan sebelum AI pun, kode yang baik tidak selalu dijaga. Kita mulai memandang coding hanya sebagai alat atau cara mencari uang. Padahal dulu ada kesenangan dalam "memecahkan masalah dan mengubah dunia". Sekarang fokusnya lebih pada "menghasilkan uang cepat atau membangun parit pertahanan". Yang penting bukan apakah kodenya indah, tetapi apakah masalahnya diselesaikan dengan elegan. AI bisa memperburuk budaya ini, tetapi pada akhirnya semuanya bergantung pada bagaimana kita menggunakannya
Saya penasaran. Kalau sebuah PR menyelesaikan semua masalah tetapi hanya mengandung bug kecil, saya ingin tahu contoh kapan PR seperti itu bisa dianggap buang-buang waktu
Code review adalah tahap paling lambat dalam engineering. Saya juga bisa menulis kode dengan cepat tanpa AI, tetapi code review tidak menjadi lebih cepat. Karena itu saya melakukan review awal dengan AI sebelum review sesama rekan, untuk menghemat waktu rekan tim dan menangkap bug lebih awal, sehingga waktu menuju deploy bisa berkurang berhari-hari. AI pernah membantu menangkap bug yang jelas, kesalahan tersembunyi, bahkan benar-benar menemukan bug yang dalam. Saya memakai workflow dengan menyalin diff lewat git cli dan xclip lalu menempelkannya ke model logika seperti o3 untuk direview
Salah satu keunggulan AI adalah bisa menulis jauh lebih banyak unit test dengan sangat cepat dibanding manusia. Dan AI juga bisa memperbaiki sendiri masalah yang ditemukannya. Workflow idealnya bukan hanya code review, tetapi AI juga otomatis menjalankan test sendiri dan memeriksa apakah semuanya memenuhi spesifikasi tertentu. Terlalu banyak test kadang membuat refactor nanti jadi sulit, misalnya test yang bergantung pada detail implementasi, dan saat sedang malas kita bahkan bisa saja membuang terpisah test yang ditulis AI
Saya sangat suka karena saya bisa meregenerasi unit test kapan pun diperlukan. Saat mengajukan review, saya merasa sangat puas melihat ukuran diff, dan saya bisa menghemat waktu menulis test yang membosankan untuk mengerjakan lebih banyak hal lain
Saat ini pun masih ada pekerjaan membosankan dalam pemrograman, tetapi idealnya AI mengurangi inefisiensi seperti ini agar manusia bisa fokus pada wilayah kreatif. Namun pada praktiknya, AI justru makin merambah pekerjaan kreatif tingkat tinggi juga
Sebenarnya, bahkan tanpa AI pun kita bisa memakai framework property-based testing untuk menghasilkan test otomatis dengan sangat banyak nilai input
Ada aturan saat saya melakukan code review: kalau saya tidak yakin bisa memeliharanya sendiri nanti, saya tidak akan menyetujuinya. Jika LLM dipakai baik untuk menulis maupun mereview kode, maka prinsip tanggung jawab yang sama juga bisa dianggap berlaku pada tool itu. Tetapi saya sendiri tidak yakin bisa bertahan lama dalam situasi seperti itu
Saya penasaran apakah ada yang pernah mencoba pipeline seperti ini: satu LLM membuat skrip Gherkin dari requirement, lalu LLM lain menghasilkan kode dari skrip itu, kemudian hasilnya diperiksa dengan Cucumber. Bagaimanapun juga, baik skrip Gherkin maupun kodenya tetap perlu direview, tetapi saya ingin tahu jenis kode apa yang tidak bisa dibuat dengan cara seperti ini. Saya melihat AI sebagai satu developer, dan seperti developer manusia, pasti ada area yang memang tidak dikuasainya dengan baik
Pada akhirnya, penulis yang mengajukan PR harus bertanggung jawab atas dampak dan hasil kodenya sendiri. Dengan coding AI yang makin umum dan semakin banyak engineer junior, tanggung jawab ini menjadi makin penting. Masuk akal jika AI menangani first pass review, tetapi reviewer manusia tetap perlu membangun pemahaman terhadap codebase dari sudut pandang luar dan menemukan masalah di level yang lebih tinggi. Kesimpulannya, struktur yang ideal adalah AI melakukan review tahap pertama, engineer lain melakukan code review dari sisi konteks atau kolaborasi, dan pada akhirnya penulis tetap bertanggung jawab atas semua hasilnya