Code Review di Era AI

• AI tidak menghapus code review; justru memperjelas beban pembuktian
• Perubahan sebaiknya dirilis dengan bukti terlampir seperti verifikasi manual atau pengujian otomatis, lalu review digunakan untuk memahami risiko, niat, dan akuntabilitas
• Sementara developer individu mengandalkan otomatisasi untuk mengejar kecepatan AI, tim membangun konteks bersama dan rasa tanggung jawab melalui review
• Jika PR tidak memiliki bukti bahwa kode benar-benar berjalan, itu bukan deployment cepat melainkan hanya memindahkan pekerjaan ke hilir; hanya developer dengan sistem verifikasi yang bisa berhasil dalam pengembangan cepat berbasis AI
• Bottleneck code review telah bergeser dari penulisan kode ke proses membuktikan bahwa sesuatu benar-benar berjalan; AI mempercepat pekerjaan mekanis, tetapi tanggung jawab tetap berada pada manusia

Perubahan code review di era AI

• Per awal 2026, lebih dari 30% developer senior sudah mendeploy mayoritas kode yang dihasilkan AI; AI sangat baik untuk membuat draft fitur, tetapi juga mengekspos kerentanan seperti kenaikan 75% pada kesalahan logika di logika, keamanan, dan edge case
• Developer solo melakukan deployment cepat lewat kecepatan inferensi (inference speed) dan memakai test suite sebagai jaring pengaman, sementara tim tetap mempertahankan human review demi konteks dan kepatuhan
• Jika dilakukan dengan benar, keduanya sama-sama menggunakan AI sebagai akselerator, tetapi perbedaannya terletak pada siapa, apa, dan kapan yang diverifikasi
• Jika Anda belum memastikan sendiri bahwa kode benar-benar berjalan, maka itu belum benar-benar berjalan
  • AI hanya memperkuat aturan ini, bukan memberi pengecualian

Cara developer memanfaatkan AI dalam review

• Ad-hoc LLM check: sebelum commit, tempel diff ke Claude, Gemini, atau GPT untuk mengecek bug atau masalah style dengan cepat
• Integrasi IDE: gunakan alat seperti Cursor, Claude Code, dan Gemini CLI untuk saran inline dan refactoring saat coding
• Bot PR dan scanner: gunakan GitHub Copilot atau agen kustom untuk menandai potensi masalah secara otomatis di PR, sambil menjalankan pemeriksaan keamanan dengan alat analisis statis dan dinamis seperti Snyk
• Loop testing otomatis: gunakan AI untuk membuat dan menjalankan test, lalu tetapkan coverage 70%+ sebagai syarat merge
• Review multi-model: tinjau kode dengan beberapa LLM untuk menangkap bias tiap model (misalnya generate dengan Claude, audit dengan model khusus keamanan)

Developer solo vs tim: perbandingan

• Developer solo
  • Fokus review: test otomatis + spot check terbatas
  • Trade-off kecepatan: kecepatan waktu inferensi, memperbaiki masalah lewat loop iteratif
  • Alat utama: agentic testing (misalnya loop Claude Code)
  • Prinsip: Buktikan sendiri (Prove it yourself)
• Tim
  • Fokus review: meninjau konteks dan keamanan dengan penilaian manusia
  • Trade-off kecepatan: menjaga PR tetap kecil untuk menghindari bottleneck review
  • Alat utama: kombinasi bot + kebijakan (misalnya pelabelan PR buatan AI)
  • Prinsip: Bagikan bukti ke tim (Share the Proof)

Developer solo: deploy dengan “kecepatan inferensi”

• Developer solo cenderung mempercayai ‘vibe’ dari kode buatan AI, memeriksa bagian inti saja, lalu mengandalkan test untuk menangkap masalah agar fitur bisa dirilis cepat
• Coding agent sering diperlakukan seperti intern yang sangat kuat dan bisa menangani refactor skala besar sendirian
• Ucapan Peter Steinberger: “Saya tidak lagi banyak membaca kode. Saya melihat alurnya, dan sesekali hanya memeriksa bagian penting”
• Bottleneck pengembangan telah bergeser dari mengetik ke waktu inferensi (menunggu output AI)
• Catatan penting: tanpa testing yang kuat, peningkatan kecepatan yang terasa akan hilang
  • Melewati review bukan menghilangkan pekerjaan, melainkan menundanya ke belakang
  • Kunci keberhasilan pengembangan cepat berbasis AI bukan kepercayaan buta, melainkan membangun sistem verifikasi
• Developer solo yang bertanggung jawab menggunakan testing otomatis yang luas sebagai jaring pengaman, dengan target coverage di atas 70%
• Test yang independen dari bahasa dan berbasis data memainkan peran penting
  • Jika test memadai, agent bisa membuat, memperbaiki, dan memverifikasi implementasi tanpa tergantung bahasa
  • Saat memulai proyek, AI menulis draft spec.md, lalu setelah disetujui menjalankan loop tulis → test → perbaiki
• Bahkan developer solo tetap melakukan testing manual dan penilaian kritis di tahap akhir
  • Menjalankan aplikasi sendiri, mengklik UI, dan memakai fiturnya langsung
  • Untuk kasus berisiko tinggi, membaca lebih banyak kode dan melakukan verifikasi tambahan
  • Meski pengembangan berlangsung cepat, kode yang berantakan tetap dirapikan segera setelah ditemukan
• Prinsip utama: tugas developer adalah ‘mengirimkan kode yang sudah dibuktikan sendiri benar-benar berjalan’

Tim: AI memindahkan bottleneck review

• Dalam lingkungan tim, AI adalah pendamping kuat untuk code review, tetapi tidak bisa menggantikan penilaian manusia yang dibutuhkan untuk kualitas, keamanan, dan maintainability
• Dalam kolaborasi multi-engineer, biaya kesalahan dan umur panjang kode menjadi pertimbangan yang jauh lebih penting
• Banyak tim memakai bot review AI pada tahap awal PR, tetapi persetujuan akhir tetap harus diberikan manusia
• Ucapan Greg Foster dari Graphite: “AI agent tidak akan pernah menggantikan approval PR dari engineer manusia sungguhan”
• Masalah praktis terbesar bukanlah AI reviewer melewatkan masalah style, melainkan AI menambah volume kode dan melempar beban review ke manusia
  • Seiring adopsi AI meningkat, ukuran PR naik sekitar 18%
  • Insiden per PR naik sekitar 24%
  • Change failure rate naik sekitar 30%
• Jika kecepatan output melampaui kapasitas verifikasi, proses review akan menjadi faktor pembatas kecepatan dalam seluruh alur pengembangan
• Ucapan Foster: “Mendeploy kode yang tidak bisa dibaca atau dipahami rekan manusia adalah risiko besar”
• Di lingkungan tim, karena AI menghasilkan output dalam jumlah besar, pendekatan pengembangan bertahap diperlukan, dan output agent perlu dipecah menjadi unit commit yang bisa direview
• Persetujuan akhir manusia tidak hilang; sebaliknya, ia berevolusi untuk fokus pada area yang terlewat oleh AI
  (penyelarasan roadmap, konteks organisasi dan institusional yang tidak dipahami AI)

Keamanan: kerentanan AI yang bisa diprediksi

• Keamanan adalah wilayah yang mutlak membutuhkan penilaian manusia
• Sekitar 45% kode yang dihasilkan AI ditemukan memiliki cacat keamanan
• Tingkat kesalahan logika 1,75 kali lebih tinggi dibanding kode yang ditulis manusia
• Frekuensi kerentanan XSS 2,74 kali lebih tinggi
• Di luar masalah pada kode itu sendiri, alat berbasis agent dan IDE terintegrasi AI juga menciptakan jalur serangan baru
  • prompt injection, kebocoran data, kerentanan RCE
• Karena AI memperluas attack surface, pendekatan hybrid menjadi efektif
  • AI menandai masalah, manusia melakukan verifikasi akhir
• Aturan: untuk kode yang menangani autentikasi, pembayaran, secret, atau input yang tidak tepercaya,
  perlakukan AI seperti intern berkecepatan tinggi, dan wajib lakukan review threat model oleh manusia serta pemeriksaan dengan alat keamanan sebelum merge

Transfer pengetahuan melalui review

• Code review adalah sarana utama tim untuk berbagi konteks sistem
• Jika AI menulis kode tetapi tidak ada yang bisa menjelaskannya, biaya on-call akan meningkat
• Jika kode buatan AI dikirim tanpa benar-benar dipahami, mekanisme transfer pengetahuan yang membangun ketahanan tim akan runtuh
• Jika penulis tidak bisa menjelaskan mengapa kode bekerja, engineer on-call tidak akan bisa melakukan debugging pada pukul 2 pagi
• Ada kasus maintainer OCaml menolak PR buatan AI sepanjang 13.000 baris
  • Kualitas kodenya belum tentu buruk, tetapi tidak ada bandwidth review untuk meninjau perubahan sebesar itu
  • Review kode buatan AI menuntut beban kognitif yang lebih besar daripada kode yang ditulis manusia
• Pelajarannya: AI bisa menghasilkan kode dalam jumlah besar, tetapi tim harus mengelola ukuran perubahan agar bottleneck review tidak meledak

Cara memanfaatkan alat review AI

• Pengalaman pengguna terhadap alat review AI sangat beragam
• Sisi positif: dalam beberapa kasus, alat ini menangkap lebih dari 95% bug seperti null pointer exception, kekurangan test coverage, dan antipattern
• Sisi negatif: sebagian developer melihat komentar review AI sebagai pengamatan umum yang tidak bernilai, semacam ‘text noise’
• Pelajarannya: alat review AI perlu dikonfigurasi dengan hati-hati
  • atur sensitivitas, nonaktifkan jenis komentar yang tidak membantu, dan buat kebijakan opt-in/opt-out yang jelas
• Jika diatur dengan tepat, AI reviewer dapat menangkap 70–80% masalah yang mudah, sehingga manusia bisa fokus pada arsitektur dan logika bisnis
• Banyak tim tetap menganjurkan PR kecil yang bisa ditumpuk, meskipun AI mampu membuat perubahan besar sekaligus
• Commit perubahan sesering mungkin, lalu kelola tiap perubahan sebagai commit atau PR terpisah yang self-contained dengan pesan yang jelas
• Tim mempertahankan batas tanggung jawab manusia yang jelas
• Terlepas dari seberapa besar kontribusi AI, tanggung jawab akhir tetap ada pada manusia
• Pepatah pelatihan IBM: “Komputer tidak pernah bisa bertanggung jawab. Tanggung jawab adalah milik manusia yang berada di dalam loop”

Kontrak PR: kewajiban penulis terhadap reviewer

• Baik untuk developer solo maupun tim, praktik terbaik yang makin umum adalah memperlakukan kode buatan AI sebagai draft berguna yang tetap harus diverifikasi
• Ada kerangka sederhana yang dipakai bersama oleh tim-tim paling sukses

• Komponen kontrak PR

  1/. What/Why: rangkum niat perubahan dan alasannya dalam 1–2 kalimat
  2/. Bukti berjalan: hasil test yang lulus dan langkah verifikasi manual (screenshot, log)
  3/. Risiko + peran AI: nyatakan tingkat risiko perubahan dan bagian mana yang dibuat AI (misalnya fitur pembayaran berisiko tinggi)
  4/. Fokus review: tunjukkan 1–2 area yang perlu ditinjau manusia (misalnya arsitektur)
• Ini bukan birokrasi, melainkan cara untuk menghormati waktu reviewer dan memperjelas tanggung jawab penulis
• Jika Anda tidak bisa menuliskan hal-hal ini, berarti Anda belum cukup memahami perubahan Anda sendiri untuk meminta orang lain menyetujuinya

Prinsip-prinsip utama

• Minta bukti, bukan janji: jadikan “kode yang benar-benar berjalan” sebagai baseline, minta AI agent menjalankan kode atau unit test setelah menghasilkan kode, periksa bukti seperti log, screenshot, dan hasil, serta jangan ajukan PR tanpa test baru atau demo yang membuktikan kode berjalan
• Gunakan AI sebagai reviewer pertama, bukan arbitrer akhir: perlakukan output review AI sebagai nasihat, biarkan satu AI menulis kode dan AI lain meninjaunya, lalu manusia mengarahkan revisi; gunakan review AI setingkat pemeriksa ejaan, bukan editor
• Human review fokus pada hal yang AI lewatkan: apakah ada kerentanan keamanan yang diperkenalkan, duplikasi pada kode lama (cacat umum AI), dan apakah pendekatannya mudah dirawat; AI menyaring masalah mudah, manusia mengambil keputusan sulit
• Terapkan pengembangan bertahap: pecah pekerjaan menjadi unit kecil agar mudah dihasilkan AI dan mudah direview manusia, gunakan commit kecil dengan pesan jelas sebagai checkpoint, dan jangan pernah commit kode yang tidak bisa Anda jelaskan
• Pertahankan standar testing yang tinggi: developer yang efektif memakai coding agent mempertahankan praktik testing yang kuat, dan meminta AI membuat draft test untuk menghasilkan test edge case yang mudah terlewat manusia

Pandangan ke depan: bottleneck berpindah

• AI sedang menggeser code review dari gatekeeping per baris ke kontrol kualitas tingkat tinggi, tetapi penilaian manusia tetap merupakan unsur keselamatan yang esensial
• Ini adalah evolusi alur kerja, bukan penghapusan code review
• Cakupan code review tidak lagi hanya diff kode, tetapi juga percakapan atau rencana antara AI dan penulis
• Peran reviewer manusia semakin mirip editor atau arsitek, fokus pada keputusan penting sambil mempercayakan pemeriksaan rutin pada otomatisasi
• Bagi developer solo, jalan ke depan memang menarik, tetapi sebanyak apa pun alat baru muncul, developer yang bijak tetap memegang prinsip ‘percaya, tapi verifikasi’
• Di tim skala besar, penguatan tata kelola AI diperkirakan akan terjadi
  • memformalkan kebijakan kontribusi AI dan mewajibkan persetujuan bahwa review dilakukan langsung oleh karyawan
  • muncul peran seperti ‘auditor kode AI’
  • platform enterprise akan berevolusi untuk lebih mendukung konteks multi-repository dan penegakan kebijakan kustom
• Prinsip intinya tidak berubah: code review memastikan software memenuhi kebutuhan, aman, tangguh, dan mudah dirawat
• AI tidak mengubah dasar ini; yang berubah hanya cara mencapainya
• Bottleneck pengembangan berpindah dari penulisan kode ke proses membuktikan bahwa sesuatu berjalan
• Reviewer kode yang hebat di era AI akan menerima perubahan ini, sambil membiarkan AI mempercepat pekerjaan mekanis namun tetap menjaga garis tanggung jawab
• AI bisa mempercepat (accelerate) proses, tetapi tidak boleh membuat kita melepaskan tanggung jawab (abdicate)
• Para engineer makin menekankan ‘bukti di atas vibe (proof over vibes)’
• Code review tidak hilang; ia sedang berubah menjadi peran yang lebih strategis
• Baik Anda developer solo yang deploy pada pukul 2 pagi, maupun team lead yang menyetujui perubahan penting pada sistem, faktanya sama: tanggung jawab akhir atas hasil buatan AI ada pada manusia
• Rangkul AI, tetapi tetap pertahankan kebiasaan memeriksa ulang pekerjaan

[tested]

https://www.coderabbit.ai/
Ada yang pernah pakai CodeRabbit? Harganya lumayan mahal, jadi saya kurang yakin apakah sepadan dengan nilainya.

[developerjhp]

Kalau pakai ekstensi Chrome di bawah ini, Anda bisa dengan mudah meminta GPT melakukan review berdasarkan GitHub PR Diff~!
https://github.com/developerjhp/Diffinity