- Saat jumlah dan skala kode yang dihasilkan AI meningkat secara eksponensial, metode code review manual yang lama tidak lagi efektif
- Tim dengan tingkat adopsi AI yang tinggi mengalami kenaikan 21% dalam penyelesaian pekerjaan dan 98% lebih banyak PR yang di-merge, tetapi secara paradoks waktu review PR meningkat 91%
- Alih-alih meninjau kode secara langsung, peran manusia perlu bergeser ke validasi hulu dengan mereview spec dan acceptance criteria
- Bukan satu gerbang validasi tunggal, melainkan struktur kepercayaan berlapis berbasis model Swiss cheese seperti persaingan multi-agent, guardrail deterministik, BDD, sistem izin, dan validasi adversarial
- Pendekatan "deploy cepat, amati semuanya, rollback lebih cepat" menjadi paradigma baru yang menggantikan review lambat lalu debugging di production
Manusia sudah tidak mampu menangani code review
- PR dibiarkan berhari-hari, persetujuan formalitas tetap diberikan, dan reviewer pada kenyataannya hanya memindai diff 500 baris
- Code review dianggap sebagai quality gate, tetapi ada tim yang telah merilis software selama puluhan tahun tanpa review per baris, dan code review baru menjadi umum sekitar 2012~2014
- Meski ada review, insiden tetap terjadi, sehingga tim membangun sistem seperti feature flag, rollout bertahap, dan rollback instan untuk menanganinya
Kita harus berhenti berusaha membaca semua kode
- Pada tim dengan adopsi AI tinggi, jumlah perubahan dan ukuran perubahan sama-sama meningkat secara eksponensial
- Berdasarkan data dari lebih dari 10.000 developer dan 1.255 tim (analisis Faros)
- Developer merasa review kode buatan AI membutuhkan lebih banyak usaha daripada review kode rekan kerja
- Dengan code review manual, pertarungan ini tidak bisa dimenangkan; code review adalah gerbang persetujuan masa lalu yang tidak cocok dengan bentuk kerja saat ini
AI code review tetap saja hanyalah 'review'
- Jika AI menulis kode dan AI juga yang mereview, tidak ada alasan untuk menampilkan UI review yang cantik
- Tool AI code review hanya menghemat waktu, dan review semacam ini akan berpindah ke sisi kiri siklus pengembangan (shift left)
- Tidak ada alasan membuang resource CI dan melakukan versioning di antara siklus review
- Di lingkungan tempat agent menulis kode, "mata baru" hanyalah agent lain dengan blind spot yang sama; nilainya bukan pada approval gate melainkan pada loop iterasi
- Naluri "saya pernah melihat AI melakukan hal bodoh, jadi harus selalu dicek" dulu rasional ketika verifikasi manual masih mungkin, tetapi pada skala sekarang hal itu tidak lagi dapat dijalankan
Beralih dari review kode ke review intent
- Checkpoint manusia harus dipindahkan ke hulu (upstream)
- Sudah ada preseden perpindahan checkpoint dalam pengembangan software: sign-off waterfall → continuous integration (CI)
- Spec-driven development muncul sebagai cara utama kolaborasi dengan AI
- Manusia harus mereview spec, rencana, constraint, dan acceptance criteria; tidak perlu mereview diff 500 baris
- Dalam paradigma baru, spec menjadi source of truth, dan kode hanyalah keluaran dari spec
- Yang direview bukan kode, melainkan langkah-langkah, verification rules, dan contract yang harus dipenuhi kode
- Persetujuan human-in-the-loop bergeser dari "apakah ini ditulis dengan benar?" menjadi "apakah kita menyelesaikan masalah yang benar dengan constraint yang benar?"
- Penilaian manusia yang paling bernilai muncul bukan setelah kode dihasilkan, melainkan sebelum baris pertama dibuat
Membangun kepercayaan berlapis — model Swiss cheese
- LLM tidak selalu patuh pada instruksi, sering menyimpang, dan bahkan tidak dapat dipercaya untuk memverifikasi dirinya sendiri (saat kode sedang terbakar pun tetap yakin menjawab "ini bekerja")
- Solusinya bukan meminta LLM melakukan verifikasi, tetapi menyuruhnya menulis skrip yang memverifikasi — berpindah dari penilaian ke artefak
- Kepercayaan dibangun secara berlapis, dan menurut model Swiss cheese, filter yang tidak sempurna ditumpuk agar lubangnya tidak sejajar
Layer 1: Membandingkan banyak opsi
- Alih-alih meminta satu agent memberi jawaban benar, tiga agent mencoba dengan cara berbeda lalu dipilih hasil terbaik
- Pemilihan tidak harus manual; bisa diperingkat menurut kriteria seperti paling banyak lolos tahap verifikasi, diff terkecil, atau tidak menambah dependency baru
- Biaya untuk memiliki beberapa opsi kini berada di tingkat terendah dalam sejarah software engineering
Layer 2: Guardrail deterministik
- Diperlukan cara deterministik untuk memverifikasi pekerjaan — test, type check, verifikasi contract, dan hal lain yang berurusan dengan fakta, bukan opini
- Alih-alih bertanya ke LLM, "apakah ini sudah beres?", definisikan tahap verifikasi yang menghasilkan artefak pass/fail
- Hierarki guardrail:
- Coding guideline — bisa diimplementasikan dengan linter kustom
- Aturan invarian seluruh organisasi — hal yang tidak bisa dinegosiasikan seperti larangan hardcoded credential, API key, token
- Domain contract — aturan per framework, service, atau area codebase (mis. di domain pembayaran, semua nominal harus memakai tipe Money)
- Acceptance criteria — kriteria unik untuk tiap tugas
- Tahap verifikasi harus didefinisikan sebelum kode ditulis, bukan dibuat belakangan hanya untuk memeriksa sesuatu yang sudah ada
- Jika agent menulis kode sekaligus test, itu hanya memindahkan masalah; kriteria verifikasi harus berasal dari spec, bukan implementasi
Layer 3: Manusia mendefinisikan acceptance criteria
- Titik nilai tambah manusia adalah mendefinisikan keberhasilan di hulu
- BDD (Behavior-Driven Development) kembali relevan
- Cara ini mendeskripsikan perilaku yang diharapkan dalam bahasa alami lalu mengotomatiskannya menjadi test
- Dulu menulis spec terasa seperti pekerjaan tambahan karena kode juga harus ditulis, tetapi di lingkungan agent, spec adalah artefak utama
- Manusia menulis spec, agent mengimplementasikan, dan framework BDD yang memverifikasi — selama tidak gagal, implementasinya tidak perlu dibaca
- Hal yang manusia kuasai: mendefinisikan "kebenaran", mengenkode business logic dan edge case, serta memikirkan apa yang bisa salah
- Acceptance criteria yang ditulis manusia dan diverifikasi mesin adalah gate yang benar-benar penting
Layer 4: Sistem izin sebagai arsitektur
- Apa yang boleh disentuh agent dan apa yang memerlukan eskalasi harus menjadi keputusan arsitektur
- Kebanyakan framework agent menangani izin secara all-or-nothing, padahal granularitas itu penting
- Agent yang memperbaiki bug fungsi utilitas tidak perlu akses ke konfigurasi infrastruktur
- Agent penulis test tidak perlu izin untuk mengubah pipeline CI
- Cakupan harus dibuat sesempit mungkin selama agent masih bisa mengerjakan tugas yang berguna
- Contoh: untuk tugas "memperbaiki bug parsing tanggal di utils/dates.py", cukup izinkan akses ke file itu dan file test terkait
- Trigger eskalasi juga penting: mengubah logika autentikasi, mengubah skema database, menambah dependency baru, dan pola tertentu lain harus secara otomatis memicu review manusia, terlepas dari tingkat kepercayaan diri agent
Layer 5: Validasi adversarial
- Pisahkan tanggung jawab: satu agent mengerjakan, agent lain memverifikasi — kuncinya adalah mereka tidak saling percaya
- Ini serupa dengan pola lama: tim QA tidak boleh melapor ke engineering manager, dan penulis kode tidak boleh menjadi satu-satunya reviewer
- Ini bisa dipaksakan secara arsitektural: agent coding tidak tahu apa yang akan diperiksa agent verifikasi, dan agent verifikasi tidak bisa memperbaiki kode — adversarial by design
- Lebih jauh lagi, agent ketiga bisa mencoba menghancurkan hasil agent pertama dengan menargetkan edge case dan failure mode — otomatisasi red team/blue team untuk setiap perubahan
Arti "kode yang baik" sedang berubah
- Insentif sistem agent itu sederhana: menyelesaikan tugas yang diberikan dan memuaskan pemberi instruksi — akurasi jangka panjang atau kebutuhan bisnis bukan motivasi intrinsik
- Peran manusia adalah mengenkode hal itu ke dalam constraint
- Dalam dunia tempat agent menghasilkan kode dan agent pula yang membacanya, bentuk "kode yang baik" akan menjadi lebih terstandarisasi, dan codebase baru membutuhkan lebih sedikit pengarahan
- Arah masa depan: "deploy cepat, amati semuanya, rollback lebih cepat"
- Kebalikannya: "review pelan, tetap kecolongan bug, lalu debugging di production"
- Kita tidak akan menang dengan membaca lebih banyak hasil kerja mesin; yang dibutuhkan adalah cara berpikir yang lebih unggul di hulu tempat keputusan benar-benar penting dibuat
- Jika agent sudah mampu menangani kode dengan baik, apakah manusia bisa membaca kode itu atau tidak tidak lagi penting
25 komentar
Karena code review jadi bottleneck, terus bilang saja jangan lakukan review itu lucu juga ya wkwkwkwk
Saya penasaran apakah code review benar-benar berjalan dengan baik sebelum era AI.
Sangat jarang ada organisasi yang melakukan code review dengan cepat dan sungguh-sungguh.
Bahkan sebelum AI, banyak developer juga menjalankan code review dengan malas, menumpuk, dan asal-asalan.
Berdasarkan pengalaman saya, perusahaan teknologi di AS berjalan sesuai pakem, sedangkan luar negeri termasuk domestik berantakan. Sebaliknya, bisa dibilang semakin ketat review-nya, semakin berat stres kerjanya, sementara review yang berantakan relatif lebih santai
Ini memang ide yang layak dicoba, tetapi tampaknya pandangan yang dominan masih menganggap bahwa saat ini masih terlalu dini.
Saya rasa hilangnya review adalah hasil dari insentif perilaku.
Kalau yang dituntut perusahaan adalah
tingkat error yang rendah, mereka akan menuntut review dengan lebih ketat
dan kalau yang diutamakan adalah peluncuran fitur yang cepat, review akan makin sering diabaikan
Kalau sampai review menghilang, rasanya itu berarti perusahaan lebih menyukai peluncuran fitur yang cepat
Tapi kalau saya jadi investor, saya juga mungkin akan menuntut hal seperti itu, haha
Saya kurang yakin. Hanya karena review menjadi bottleneck lalu menyarankan untuk tidak melakukan review terasa seperti melupakan esensi utamanya. Menurut saya, akan lebih baik jika waktu review dialokasikan secara wajib sebesar waktu implementasi yang berhasil dihemat.
Terus menumpuk black box?
Idenya kurang lebih seperti menjadikan kode sebagai black box dan hanya melihat hasilnya saja... entah apakah ini benar-benar arah yang diinginkan.. Saya rasa pada akhirnya pasti akan datang saatnya ketika semua kode lama yang ditulis AI dibongkar total.
Ini mirip dengan anggapan, "karena FSD sudah makin pintar, pengemudi boleh tidur."
Secara teknis, sepertinya kita memang akan semakin menuju era seperti itu, tetapi yang penting adalah bagaimana kita akan melewati ambang batas tanggung jawab.
Saya rasa code review setidaknya adalah perangkat pengaman minimum.
Kalau begitu, kenapa verifikasi niat sebagai konsep yang lebih tingkat tinggi masih dilakukan manusia..?
Sebenarnya, bahkan tidak perlu menyuruh untuk menulis kode dengan bahasa pemrograman.
Kalau prompt yang sama diberikan ke AI, rasanya meninjau hasilnya itu bukankah mirip seperti menguji performa modelnya?
Terasa seperti kesimpulannya sudah ditentukan lalu minta LLM menuliskannya. Sofisme.
Sepertinya sama sekali tidak punya pengalaman produksi
Cuma terdengar seperti mimpi belaka.
Seiring waktu, dokumentasi juga terasa tidak ada artinya, dan review malah jadi makin ketat, bukan?
Iya~ maksudnya sudah cukup tersampaikan hanya dengan tulisan yang dibuat dari perdebatan seperti ini
Ini adalah tulisan terjemahan: https://rosetta.page/post/…
Ini sebenarnya masalah yang bisa disaring sejak awal pada tahap perencanaan.
Dalam proses menulis kode secara manual, pengembang secara alami juga sekaligus melakukan perencanaan, perancangan, eksplorasi, pemahaman, pengujian, self-review, dan secara implisit serta paralel memikirkan proses tindak lanjut ketika masalah terjadi, sehingga tiap aspek itu biasanya menyesuaikan diri secara alami. Jadi saya rasa meskipun testing atau review kurang, tetap bisa berjalan sampai tingkat tertentu.
Namun, jika proses menulis manual itu dihilangkan, proses-proses yang sebelumnya implisit harus diberi batasan secara eksplisit. Karena pihak yang menulis kode dan pihak yang meninjaunya menjadi semakin terpisah, inefisiensi komunikasi meningkat. Karena tingkat kepercayaan terhadap pihak yang menulis kode juga menurun, biaya review pun ikut naik.
Saya merasa ini mirip dengan konsep doorman's fallacy.
Ini juga topik yang sering saya pikirkan di perusahaan, dan ini bagus. Secara pribadi, saya rasa saya juga harus mencoba menerapkannya pada Harnes yang sedang saya buat.
Sepertinya arahnya akan makin menyederhanakan review dan memperketat pengujian.
Sepertinya maksudnya bukan sekadar menghapus code review, melainkan melakukan review berdasarkan artefak yang berada satu tingkat di atasnya, sehingga niat di balik perubahan dan apakah niat tersebut benar-benar berjalan bisa diverifikasi secara eksplisit.
Pada titik saat ini, saya rasa menjaga detail implementasi kode sebagai black box, alih-alih di level desain atau arsitektur, adalah hal yang diinginkan.
Saya pikir kotak hitam itu bisa terus menumpuk sampai pada titik di mana bahkan AI pun tidak bisa berbuat banyak. Rasanya semua orang terlalu terlena oleh kenyamanan. Saya pikir suatu hari nanti akan terjadi kecelakaan besar.
Saya juga setuju dengan pendapat di atas. Bagaimana kalau suatu hari tiba-tiba ditemukan bahwa model salah mempelajari bagian tertentu dari kode buatan manusia, lalu kita sadar kalau itu selama ini sudah tercermin dalam kode? Hari itu bisa jadi hari ketika semuanya dibalikkan..
Sehebat apa pun model terbaru, kalau tidak bisa selalu mendapat nilai sempurna di benchmark SWE (6 nine, 0.999999), saya rasa kemungkinannya tetap terbuka.
Review niat. Istilah yang bagus.
Saya sempat berpikir bagaimana harus merespons era yang makin cepat berkat AI,
ini tulisan yang bagus karena memberi sudut pandang baru tentang code review!