Tinjauan Kode Agentik

• Dengan peningkatan kinerja agen coding yang sangat cepat, titik tersulit dalam engineering bergeser dari menulis kode ke menilai apakah kode itu bisa dipercaya, sehingga review menjadi pekerjaan dengan leverage tertinggi
• AI sangat meningkatkan output, tetapi menurunkan kualitas dan kemudahan untuk direview, dengan kesenjangan terukur di mana 4x lebih banyak kode hanya menghasilkan sekitar 10% peningkatan nilai nyata
• Tingkat intensitas review yang dibutuhkan berbeda menurut blast radius (cakupan dampak) dari perubahan, dan pengembang solo serta tim pemelihara sistem besar berusia 10 tahun memiliki batasan yang sama sekali berbeda
• Agen memang bernalar, tetapi penalaran itu tidak dilampirkan ke PR dan dibuang begitu saja, sehingga reviewer harus menanggung beban merekonstruksi intent (niat) yang hilang dari nol
• Menulis menjadi lebih murah, tetapi memahami tetap mahal, sehingga tim yang membangun sistem review yang dapat dipercaya akan unggul ke depan

---

Apa yang benar-benar ditunjukkan data 2026

• Klaim yang selama bertahun-tahun hanya berupa anekdot dan perdebatan kini telah diukur dalam skala besar oleh organisasi dengan kepentingan berbeda-beda (sebagian bahkan saling bersaing), dan menghasilkan kesimpulan yang sama: AI memang melonjakkan output, tetapi menurunkan kualitas serta kemudahan review

• Pengukuran Faros AI (data Maret 2026)

  • Melacak transisi dari adopsi AI rendah ke adopsi AI tinggi pada 4.000 tim dan 22.000 developer
  • Sisi positif: developer me-merge lebih banyak PR dan menyelesaikan lebih banyak pekerjaan, sehingga throughput per engineer naik
  • Angka sisi negatif
    • Code churn naik 861%
    • Rasio insiden per PR naik 242,7%
    • Tingkat defect per developer 9% → 54%
    • Waktu review median naik 441,5% (waktu ke review pertama dan waktu review rata-rata masing-masing sekitar 2x)
    • PR yang di-merge tanpa review naik 31,3%
  • Merge tanpa review bukan pilihan siapa pun, melainkan akibat reviewer tak mampu mengejar volume sehingga kode yang bahkan belum dibaca menjadi hal yang biasa di-merge
  • Bahkan tim dengan praktik engineering yang matang dan disiplin terkena dampak yang sama; proses yang baik tidak cukup melindungi (volume datang lebih cepat daripada kecepatan desain proses beradaptasi)

• Riset CodeRabbit (Desember 2025)

  • Menganalisis 470 PR open source (320 ditulis bersama AI, 150 murni manusia), dan perubahan yang dibuat AI disertai sekitar 1,7x lebih banyak issue
    • Masalah logika dan correctness naik sekitar 75%
    • Isu keamanan naik 1,5–2x
    • Masalah keterbacaan naik lebih dari 3x
  • Direktur AI David Loker: "Ini kelemahan yang dapat diprediksi dan diukur, dan organisasi harus secara aktif memitigasinya" — karena kelemahannya sudah diketahui dan bisa dilokalisasi, proses review dapat diarahkan secara tepat

• Data produktivitas GitClear (hingga 2025)

  • Pengguna harian AI memiliki sekitar 4x output mentah dibanding non-pengguna, tetapi peningkatan produktivitas nyata dibanding diri mereka sendiri setahun sebelumnya hanya sekitar 12%
  • Strukturnya adalah 4x lebih banyak kode yang tetap harus direview sepenuhnya oleh manusia
  • Bill Harding menyatakan bahwa bahkan 12% itu sebagian mungkin berasal dari bias seleksi (developer kuat lebih terkonsentrasi di kelompok pengguna AI)

• Laporan GitHub

  • Review Copilot telah dijalankan lebih dari 60 juta kali secara kumulatif, naik 10x hanya dalam setahun, dan lebih dari 1 dari 5 review di platform melibatkan agen
  • Ini bukan lagi praktik niche, melainkan sudah menjadi bagian dari cara kode dibuat
• Empat dataset dan empat metodologi yang berbeda bertemu pada satu kesimpulan: bottleneck tidak hilang, tetapi berpindah ke tahap verification

Semua orang sebenarnya sedang memecahkan masalah yang berbeda

• Sebagian besar data peringatan di atas berasal dari telemetry enterprise dan maintainer open source yang kewalahan, sehingga banyak di antaranya tidak begitu berlaku bagi pengembang tunggal yang membangun sesuatu dengan sedikit pengguna

• Tiga variabel yang menentukan posisi

  • blast radius: apa yang terjadi kalau rusak — mungkin tidak terjadi apa-apa, atau justru ada pengguna marah, kerugian uang, dan kebocoran PII
  • umur kode: apakah ini prototipe sekali pakai yang minggu depan sudah tidak dipakai lagi, atau codebase yang akan dipelihara selama bertahun-tahun
  • jumlah orang yang harus memahaminya: apakah hanya Anda sendiri yang menyimpan semuanya di kepala, atau sebuah tim yang berbagi kepemilikan seiring waktu

• Solo, greenfield, tanpa pengguna

  • Peran kedua review, yaitu distribusi pengetahuan di dalam tim, tidak ada (karena diri sendiri adalah tim itu)
  • Pilihan yang rasional: sangat bergantung pada testing dan automasi, review mendalam hanya untuk bagian yang benar-benar penting, sisanya dengan sentuhan ringan
  • Namun ini hanya bekerja jika test-nya benar-benar nyata; melewatkan review tanpa jaring pengaman bukan membuat pekerjaan itu hilang, melainkan menundanya (defer) dengan biaya yang lebih mahal
  • "Tanpa pengguna" adalah izin untuk menunda review, bukan izin untuk melewatkan verification

• Titik tengah yang berbahaya

  • Begitu proyek mulai punya pengguna, peran review untuk menangkap bug tiba-tiba menjadi penting (karena bug merugikan orang), dan peran berbagi pengetahuan juga ikut menyala
  • Jika tim mempertahankan kebiasaan masa solo selama beberapa bulan lagi lalu terkena postmortem, angka Faros akan menjadi dashboard mereka sendiri

• Organisasi besar, codebase lama, banyak pengguna

  • Semua angka peringatan tadi berlaku dengan intensitas maksimum; perubahan yang tak dipahami siapa pun akan menjadi comprehension debt (utang pemahaman) dan pada akhirnya berubah menjadi insiden on-call milik seseorang
  • Intinya bukan "perusahaan harus hati-hati, solo boleh santai", melainkan tujuan review berubah tergantung posisi, jadi aturannya juga harus berbeda
  • Menempelkan pipeline multi-agen dan tuntutan bukti ala enterprise ke prototipe dua orang hanya menambah friksi tanpa makna, sementara menerapkan "test lulus, ya deploy" ke sistem pembayaran adalah mesin pembuat insiden dengan centang hijau

Apa yang sebenarnya dilakukan review sekarang

• Ketika manusia menulis kode, intent ikut terbawa secara gratis, dan alternatif yang ditimbang lalu dibuang masih ada di kepala penulis, sehingga review dulunya adalah pekerjaan memeriksa penalaran itu
• Agen modern juga bernalar dan sering kali bahkan menampilkan thinking trace secara kasat mata, tetapi penalaran itu dibuang saat diff dibuat dan tidak dilampirkan ke PR
• Lagi pula, itu adalah penalaran agen tentang "bagaimana mengimplementasikannya", bukan penilaian manusia tentang "apakah ini memang pekerjaan yang benar sejak awal"
• Akibatnya, review berubah dari memeriksa penalaran yang terlihat menjadi merekonstruksi intent yang tidak pernah dicatat, sehingga menjadi lebih sulit dan lebih lambat (inilah alasan bisa memakan waktu 441% lebih lama)

• AI Slop and the Software Commons (paper 2026)

  • Menganalisis 1.154 posting dari 15 thread Reddit dan Hacker News
  • Ungkapan seorang developer: review PR agen membuatnya menjadi "manusia pertama yang melihat kode ini"
  • Dalam istilah paper tersebut, review "tidak dirancang untuk memulihkan intent yang hilang"

• Solusinya adalah masalah alat

  • Intent yang hilang sebenarnya bisa dipulihkan — penalarannya memang ada, hanya saja dibuang
  • Jika agen diminta menyatakan apa yang hendak dilakukan dan apa yang sengaja dikesampingkan, lalu itu ditangkap sebagai decision log (log keputusan) pada PR, maka sebagian besar biaya rekonstruksi itu hilang
• Hanya mengandalkan "AI mereview AI" bukan jawaban yang lengkap; model kedua dengan pengetahuan awal yang berbeda memang bisa menangkap banyak bug nyata, tetapi tidak bisa memberi penilaian manusia tentang "apakah perubahan ini layak dibuat"

Alatnya bagus, tapi bukan karena alasan yang mereka iklankan

• Alat review AI khusus kini sudah cukup baik, dan disarankan menjalankan setidaknya agen coding utama (kalau bisa, agen review khusus) untuk semua hal, termasuk side project

• Karakteristik alat-alat utama

  • CodeRabbit: paling luas digunakan, peringkat F1 #1 pada benchmark independen Martian (Jan–Feb 2026), precision sekitar 49% dengan recall terbaik di industri
  • Greptile: menukar precision demi recall, dengan tingkat deteksi bug sekitar 82% pada salah satu benchmark (dibanding 44% untuk CodeRabbit), tetapi dengan lebih banyak false positive
  • Anthropic Code Review: kurang dari 1% hasil yang ditandai oleh engineer internal mereka dianggap salah, dan meningkatkan proporsi PR yang benar-benar mendapat review dari 16% menjadi 54%

• Eksperimen paralel 4 reviewer (hasil di luar vendor)

  • Seorang engineer menerapkan CodeRabbit, Sentry Seer, Greptile, dan Cursor BugBot secara paralel selama tiga setengah minggu pada 146 PR nyata, menghasilkan 679 temuan
  • Dari 617 lokasi flag unik, 93,4% hanya terdeteksi oleh tepat satu alat, 6% oleh dua alat, hampir tidak ada yang oleh tiga, dan tidak ada satu pun yang dideteksi keempatnya
  • Keempat alat itu tidak pernah sekalipun menandai baris yang sama secara bersamaan
  • Kekuatan tiap alat berbeda: Greptile hampir nol false positive pada correctness dan arsitektur, CodeRabbit punya jaring terluas dan perbaikan sekali klik, Seer kuat pada tingkat keparahan gangguan operasional
  • Heterogenitas adalah kuncinya — empat salinan model yang sama hanyalah satu reviewer dengan tagihan lebih mahal, sedangkan empat reviewer yang benar-benar berbeda bisa mengungkap bug yang tak bisa ditemukan satu alat pun sendirian

• Panduan praktik

  • Jangan memikirkan satu alat terbaik tunggal (itu tidak ada)
  • Untuk area berisiko tinggi, sengaja pasangkan dua alat yang sifatnya berbeda (eksperimen di atas memakai Greptile untuk akurasi sehari-hari + Seer untuk tingkat keparahan gangguan operasional)
  • Jika solo, satu reviewer yang bagus plus test yang sungguh-sungguh sudah cukup
  • Terlepas dari marketing, selalu ukur di codebase Anda sendiri, karena semua hasil bergantung pada codebase tertentu

Haruskah lebih banyak review diserahkan ke AI

• Pertanyaan yang setahun lalu terdengar sesat kini mulai muncul dari engineer berpengalaman — apakah mesin seharusnya menangani lebih banyak bagian review, mungkin bahkan sebagian besar

• Fakta tidak nyaman bahwa review AI memang bekerja

  • Kurang dari 1% temuan Anthropic ditandai salah, AI menangkap bug yang terlewat oleh manusia, dan tidak pernah lelah bahkan pada PR ke-30 hari itu (saat keandalan manusia justru paling rendah)
  • Sebaliknya, manusia tidak mampu mengejar — merge tanpa review naik 31%, waktu review naik tiga digit
  • Framing yang jujur bukanlah "haruskah kita menyerahkan lebih banyak ke AI", melainkan "AI sudah melakukannya; pertanyaannya apakah ini akan dilakukan secara sengaja, atau kita pura-pura manusia membaca semuanya sambil membiarkannya begitu saja"

• Sudut pandang loop engineering

  • Premis loop adalah membangun sistem yang memberi prompt ke agen, bukan lagi manusia yang secara langsung memberi prompt ke agen, dan di pusatnya ada agen judge yang menilai apakah pekerjaan selesai
  • Reviewer kemudian menjadi peran berikutnya yang secara sengaja dihapus dari loop internal menurut desain; satu tahun setelah penulisan diotomatisasi, verification juga diotomatisasi dan manusia terdorong ke level yang lebih atas

• Risiko loop tertutup

  • Jika satu agen menulis, agen lain mereview, lalu agen ketiga menilai, maka itu menjadi loop tertutup dari model-model dengan correlated blind spots (titik buta yang saling berkorelasi) — terutama jika masih satu keluarga model dan karena itu cenderung sepakat dengan keyakinan tinggi di titik salah yang sama
  • "looks good" yang percaya diri tanpa manusia sama sekali adalah borrowed confidence (kepercayaan yang dipinjam) — keyakinan sistem berubah menjadi keyakinan saya, padahal tak seorang pun benar-benar memahaminya

• Manusia tidak pergi, hanya naik satu tingkat

  • Peralihan dari membaca setiap diff menjadi memiliki bagian-bagian yang tidak bisa ditransfer ke model, dengan accountability sebagai inti
  • Wilayah yang harus dijaga manusia: penilaian apakah ini perubahan yang tepat untuk dibuat, gate blast radius tinggi ketika salah akan mahal, dan perilaku yang tidak pernah dispesifikasikan siapa pun (model hanya mereview kode yang ada dan hampir tak pernah menandai requirement yang tak pernah ditulis)
  • Dari human in the loop menjadi human on the loop — alih-alih membaca setiap PR, manusia melakukan sampling, spot-check, dan audit atas sistem, lalu memusatkan perhatian terbatasnya pada bagian yang benar-benar menyakitkan ketika salah

• Kasus Kun Chen (mantan engineer Meta L8, solo builder)

  • Mengirim sekitar 40 PR per hari dan praktis menghentikan code review, sambil menjalankan 20–30 agen secara paralel
  • Upaya dipindahkan ke planning (rencana) — menulis rencana detail di awal, lalu agen berjalan selama berjam-jam; kualitas rencana menentukan lamanya eksekusi tanpa pengawasan
  • Ia tidak berhenti melakukan verification, melainkan menuliskan intent lebih dulu sehingga setengah menyelesaikan masalah "manusia pertama yang melihat kode" (manusia memahami alasannya di muka, bukan setelah kejadian)
  • Ia juga tidak bekerja tanpa jaring pengaman — gate review otomatis bernama No Mistakes memeriksa kode sebelum merge, dan jika agen macet maka akan menunggu eskalasi
  • Namun ia adalah solo builder tanpa tim besar dan tanpa sistem ladang ranjau berusia 10 tahun, sehingga kondisinya tidak dimiliki kebanyakan pembaca — jika ditiru oleh tim yang melayani banyak pengguna, hasilnya adalah memutar ulang angka Faros di dashboard sendiri
• Kesimpulan spektrum: untuk solo tanpa pengguna, menyerahkan hampir semuanya ke AI adalah posisi yang masih bisa dipertahankan pada 2026; untuk skala besar dengan banyak pengguna, first pass, second pass, dan 90% bagian yang membosankan bisa dilakukan mesin, tetapi jalur yang menopang beban (load-bearing paths) tetap harus dijaga manusia sungguhan, dan seberapa banyak manusia yang dipakai harus ditentukan oleh blast radius, bukan rasa bersalah

Jadi apa yang benar-benar harus dilakukan

• Prinsip organisasi: sesuaikan upaya review dengan biaya jika salah, tarik pekerjaan deterministik yang murah sejauh mungkin ke depan, dan cadangkan perhatian manusia untuk hal-hal yang memang hanya manusia yang bisa lakukan

• Buat tier berdasarkan risiko, bukan berdasarkan siapa penulisnya (Tier by risk, not by author)

  • Perubahan konfigurasi cukup dengan linter dan satu kali sapuan cepat
  • Perbaikan pada jalur logika bisnis inti perlu paket penuh: tipe, test, dua reviewer AI yang berbeda, manusia pemilik sistem terkait, dan security pass
  • Jangan berikan review berat untuk boilerplate, dan jangan meloloskan perubahan besar hanya karena test hijau

• Gagalkan lebih cepat ekor yang mahal (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (Januari 2026) meneliti 33.707 PR yang ditulis agen
  • Agen kuat pada perubahan kecil yang terdefinisi baik sehingga sekitar 28% hampir langsung di-merge, tetapi begitu menerima feedback subjektif mereka cenderung "ghost" dan meninggalkan bolak-balik yang justru inti dari review
  • Dalam paper pendamping 2026, reviewer abandonment menyumbang 38% dari PR agen yang ditolak
  • Para peneliti membangun "circuit breaker" yang memprediksi PR berbiaya pemeliharaan tinggi sebelum dilihat manusia, memakai sinyal murah seperti jenis file dan ukuran patch, dan hasilnya efektif

• Naikkan standar tentang apa yang layak direview

  • Solusinya bukan mengunci repository, melainkan menolak mereview perubahan yang datang tanpa bukti
  • Sebelum review, harus ada: pernyataan tujuan perubahan, diff yang bukan 3.500 baris tanpa anotasi, output test, dan bukti bahwa perubahan itu benar-benar dijalankan
  • Daripada Anda menyerap biaya mahal untuk merekonstruksi intent, kembalikan pekerjaan itu ke pengusul yang bisa melakukannya lebih murah

• Jaga PR tetap kecil secara sengaja

  • PR agen cenderung besar (pada data Faros, rata-ratanya 51% lebih besar), dan keterlibatan reviewer adalah salah satu prediktor terkuat apakah PR akan di-merge
  • PR besar yang tidak dapat direview seharusnya langsung ditolak atau, lebih buruk lagi, hanya diberi stempel formalitas
  • Instruksikan agen untuk membuat commit kecil; diff yang benar-benar bisa dibaca manusia sekarang bukan lagi soal kesopanan, melainkan kendala desain

• Baca perubahan test lebih hati-hati daripada perubahan kode

  • Failure mode agen yang patut diawasi: ia mengubah perilaku lalu "memperbaiki" test dengan menulis ulang assertion agar cocok dengan perilaku baru yang sebenarnya rusak
  • Centang hijau di atas 200 test yang diedit tidak berarti apa-apa sampai Anda memastikan edit itu benar; diff yang banyak menulis ulang test harus diperlakukan sebagai flag dan dibaca lebih dulu
  • Nilai mutation testing: coverage memberi tahu bahwa baris itu dieksekusi, sedangkan mutation testing memberi tahu apakah test akan sadar jika baris itu salah

• Perlakukan CI sebagai tembok yang tidak bisa digerakkan

  • Perhatikan pola yang diperingatkan GitHub kepada reviewer: test yang dihapus, lint yang dilewati, ambang coverage yang diturunkan, helper duplikat yang sebenarnya sudah ada, serta input tak tepercaya yang mengalir ke prompt
  • Poin terakhir sangat penting — fitur yang dibuat agen menjadi sumber baru prompt injection, dan jika teks yang dikendalikan pengguna diteruskan mentah-mentah ke pemanggilan LLM, kerentanannya tidak tampak di diff tetapi tersembunyi dalam data yang akan datang kemudian
  • Agen dapat melemahkan CI tanpa niat jahat demi bisa lolos (gradient descent mencari jalur termurah menuju hijau), dan gate deterministik adalah satu-satunya bagian yang penilaiannya tidak bisa dibalik oleh paragraf yang terdengar percaya diri, jadi harus dijaga ketat

• Merge tetap dimiliki manusia

  • Model tidak bisa dipanggil saat insiden dan tidak bisa dimintai pertanggungjawaban, jadi orang yang menekan tombol merge-lah yang memiliki tanggung jawab itu
  • Saat review AI berkata "looks good" dengan suara tenang dan yakin, itu selalu berarti ia sedang menyerahkan keyakinan yang belum layak dimiliki
  • Perlakukan semua review AI sebagai sensor, bukan putusan — data, bukan keputusan

Jika Anda memimpin tim, inilah artinya

• Batasan utama pengiriman bukan lagi seberapa cepat Anda bisa menulis kode, melainkan seberapa cepat orang yang dipercaya bisa yakin bahwa perubahan itu benar
• Perencanaan yang menganggap generation sebagai bottleneck dan review sebagai sesuatu yang gratis akan diam-diam macet sambil tetap membuat dashboard kecepatan terlihat hijau
• Laporan Faros secara langsung menyebut bahwa saat output naik, pekerjaan QA dan review juga ikut naik, sehingga memangkas headcount engineering dengan alasan "kita sekarang lebih cepat berkat AI" sebelum menutup kesenjangan review adalah langkah berbahaya
• Pajak engineer senior dalam bentuk waktu review yang naik tiga digit jatuh paling berat justru pada orang yang paling tidak boleh dijadikan bottleneck, dan itu tidak terlihat di metrik yang hanya menghitung PR yang berhasil di-merge
• Maintainer open source menabrak tembok ini paling dulu dan paling keras — arus kontribusi yang tampak meyakinkan tetapi kosong tetap memakan waktu triage nyata meskipun datang dengan niat baik, dan ini adalah canary in the coal mine; giliran perusahaan akan menyusul
• Tempat yang merespons dengan baik adalah yang memperlakukan kapasitas review bukan sebagai kelonggaran yang diberikan AI, melainkan sumber daya nyata yang harus diukur, dilindungi, dan dihabiskan secara sengaja

Menulis menjadi murah, tetapi memahami tidak

• Jangan menerima jawaban seragam dari dua kutub — bagi solo tanpa pengguna, cerita horor enterprise tentang churn dan duplikasi belum tentu jadi kebakaran hari ini, melainkan risiko masa depan, jadi andalkan test dan review hanya hal penting sambil jujur mengakui bahwa pekerjaan yang ditunda tetap menjadi utang
• Jika Anda berada di skala besar dengan banyak pengguna, semua angka peringatan di sini adalah tentang Anda, dan satu-satunya hal yang benar-benar berlaku adalah penjenjangan, tuntutan bukti, proses review yang sengaja heterogen, serta manusia yang memiliki merge
• Di seluruh spektrum, yang tidak berubah adalah ekonomi dasarnya — menulis dibuat murah, sementara memahami tetap semahal biasanya
• Tim yang akan unggul ke depan bukan tim yang menghasilkan kode paling banyak, melainkan tim yang membangun sistem review yang benar-benar bisa dipercaya, dan tidak pernah mencampuradukkan "test lulus" dengan "manusia paham apa yang dilakukan ini dan mengapa"
• Seperti kata Simon Willison, hakikat pekerjaan ini adalah menyerahkan kode yang telah dibuktikan bekerja — agen tidak mengubah hal itu, melainkan menjadikan pembuktian sebagai pusat pekerjaan, bukan tugas sampingan
• Kemampuan untuk cukup memahami sistem sehingga Anda berani berdiri di belakangnya tetap merupakan keterampilan paling tahan lama dan paling menarik dalam software, dan sekarang adalah waktu yang sangat tepat untuk menjadi sangat hebat dalam hal itu