Jika jago code review, Anda juga bisa lebih mahir memanfaatkan agen AI

• Untuk menjadi mahir dalam memanfaatkan agen AI, kemampuan code review sangat penting
• Model bahasa besar unggul dalam menghasilkan kode, tetapi sering kekurangan daya penilaian yang mendalam, sehingga kerap membuang waktu ke arah yang salah
• Review remeh yang hanya menunjuk detail sintaks kecil atau review stempel yang menyetujui tanpa kritik tidak membantu dalam pemanfaatan AI
• Code review yang baik mempertimbangkan apakah ada cara yang lebih baik dari sudut pandang struktural, dan membantu menghindari desain yang terlalu kompleks
• Pada akhirnya, coding dengan AI adalah model yang menggabungkan penilaian manusia dan produktivitas mesin seperti "centaur chess", dan kemampuan code review langsung terkait dengan kemampuan memanfaatkan AI

---

Hubungan antara agen AI dan code review

• Menggunakan agen AI dengan benar pada dasarnya adalah bagian dari proses code review
• Orang yang jago code review juga dapat memanfaatkan alat kode AI secara efektif seperti Claude Code, Codex, dan Copilot

Mengapa kemampuan code review penting

• Model bahasa besar mahir dalam menghasilkan kode dalam jumlah besar, tetapi masih kurang dalam daya penilaian seperti software engineer berpengalaman
• Karena itu, jika dibiarkan tanpa pengawasan, model ini cenderung memboroskan banyak sumber daya pada desain yang tidak perlu atau buruk

Batasan agen AI dan kesalahan desain

• Sebagai contoh, saat mengembangkan proyek VicFlora Offline, Codex menghabiskan banyak upaya untuk merekayasa balik kode frontend
  • Padahal sebenarnya ada pendekatan akses data yang lebih sederhana
  • Saat menggunakan agen AI, kira-kira sekali dalam sejam akan terlihat ada pekerjaan mencurigakan yang sedang dilakukan
  • Jika masalah seperti ini ditemukan dan arahnya diubah secara langsung, kita bisa menghemat berjam-jam kerja
• Dalam pengalaman lain saat mengembangkan aplikasi, AI mengusulkan pembangunan infrastruktur backend yang berlebihan bahkan untuk pekerjaan pemrosesan paralel yang sederhana
  • Padahal cukup diproses secara non-blocking di frontend, tetapi AI justru mencoba memperkenalkan arsitektur yang kompleks
  • Penting untuk terus mengendalikan AI agar kesederhanaan tetap terjaga
• Jika non-ahli hanya percaya pada AI untuk mengembangkan, kompleksitas dan inefisiensi codebase akan menumpuk, dan justru kemampuan memecahkan masalah bisa menurun drastis

Hakikat dan efek code review

• Berkolaborasi dengan AI mirip dengan bekerja bersama developer junior yang antusias tetapi minim pengalaman
  • Karena AI tidak mengalami pertumbuhan daya penilaian seiring waktu, pengamatan berkelanjutan tetap diperlukan
• Kesalahan terbesar dalam code review adalah hanya melihat kode yang sudah ditulis, tanpa memikirkan apakah ada alternatif yang lebih baik
  • Code review terbaik mempertimbangkan konteks seluruh sistem secara terpadu dari sudut pandang struktural
  • Daripada membuat sistem baru yang tidak perlu, pendekatan untuk menggunakan kembali sistem yang sudah ada harus menjadi prioritas
• Reviewer yang terlalu 'nitpicky' dan hanya terobsesi pada gaya kode yang detail bisa kehilangan pemanfaatan sejati dari alat AI
• Jika bersikap seperti reviewer 'rubber-stamp' yang meloloskan semuanya tanpa kritik, kolaborasi efektif dengan AI/developer junior akan sulit tercapai

Pemikiran tentang keterampilan memanfaatkan alat AI

• Alat tradisional seperti git memiliki struktur dan cara pengoperasian yang jelas, tetapi struktur dasar AI bersifat tidak transparan
  • AI dapat melakukan hampir semua jenis komputasi
• Sebagian orang menganggap bahwa menggunakan alat AI secara serba bisa adalah kemampuan memanfaatkan AI itu sendiri
  • Pada praktiknya, pengguna berpengalaman justru bisa menarik lebih banyak kemungkinan dari alat tersebut
• Sampai saat ini, agen kode AI memang dapat membantu berbagai tugas, tetapi tetap memerlukan pengawasan ketat
• Seperti model "centaur chess", ketika arah dari manusia yang terampil digabungkan dengan usulan AI, produktivitas optimal bisa dicapai
• Pada akhirnya, kemampuan memanfaatkan AI bergantung pada kemampuan code review dan penilaian desain yang kritis
• Semakin baik skill code review, semakin maksimal efektivitas penggunaan alat AI agentic

Pemikiran akhir dan prospek

• Agen AI seiring waktu dapat memberi kesan seolah makin berkembang menjadi engineer yang lebih terampil
• Dalam beberapa tahun ke depan, pengalaman berkolaborasi dengan AI bisa berevolusi hingga setara bekerja dengan engineer tingkat menengah
• Saat ini, pendekatan yang baik adalah bereksperimen dengan berbagai alat AI (Codex, Claude Code, Copilot, dan lainnya), dan kemampuan pengawasan kritis adalah pembeda yang paling penting

Pendapat tambahan

• Di Hacker News dan tempat lain, ada diskusi tentang “sampai sejauh mana agen AI benar-benar berguna”
  • Penulis tidak melihat bahwa AI dapat berkontribusi di tingkat kernel Linux hanya dengan code review
  • Sebagian orang juga berpendapat bahwa metode code review seperti gaya penulisan dan penamaan itu penting
  • Ada pandangan kritis terhadap pembahasan desain dalam code review, tetapi penulis tidak memandangnya secara negatif

[GN⁺]

Pendapat Hacker News

• Aku cukup meragukan gagasan bahwa hasil bagus bisa muncul dari proses yang buruk asalkan kontrol kualitasnya ketat; itu seperti bilang, "tidak apa-apa terus memuntahkan sampah selama ada yang memeriksa," dan di dunia nyata aku belum pernah melihat itu benar-benar berhasil. Industri otomotif Amerika pernah mencoba pendekatan seperti ini, tapi aku tidak bisa langsung mengingat contoh suksesnya. Bayangkan jika atasan berkata kepadaku sebagai lead tim, "alih-alih 5 orang kompeten, aku akan kasih kamu 25 pemula total dan menunggu semoga ada sesuatu yang kebetulan jadi benar; kamu tinggal review semuanya." Itu jelas tidak masuk akal. Tapi begitu AI masuk ke skenario ini, anehnya banyak orang jadi berpikir, "hmm, mungkin bisa ya?"

  • Mereview kode dari orang yang kurang berpengalaman atau kurang termotivasi juga sangat melelahkan. Secara mental dan emosional itu menguras energi besar. Kalau fitur yang sama harus direview sampai 4 kali, pada titik tertentu kita jenuh dan menyerah saat kualitasnya sudah mentok tidak bisa naik lagi.

  • Ini sepenuhnya berlawanan dengan teladan pengelolaan kualitas ala Deming (Edward Deming) yang dikembangkan di Jepang lalu disebarkan ke Barat. Kualitas tidak lahir dari individu, melainkan dari proses. Jika kita sengaja memilih proses yang penuh cacat lalu berharap manusia akan menangkap kesalahannya, itu bukan pendekatan yang baik bila tujuan kita adalah kualitas. LLM bisa dipakai dengan banyak cara, tetapi hanya sebagian yang benar-benar memberi keuntungan. Manajemen terjebak fantasi bahwa AI bisa menyelesaikan semua masalah, tampaknya tanpa memahami kelebihan dan batasannya, atau sudah melupakan pelajaran Deming.

  • Evolusi terjadi lewat mutasi acak dan seleksi, dan keberadaan seluruh kehidupan kompleks sendiri adalah contohnya. Itu bukan metode yang aku sukai, tetapi memang ada kecenderungan untuk tergila-gila pada buzzword populer lalu mencoba memaksakannya ke tempat yang tidak cocok. Dalam produksi sebagian komponen plastik alat dapur, masih ada praktik mencetak barang dengan kualitas buruk lalu pekerja harian membetulkannya secara manual dengan pisau sebelum dikemas; aku sendiri pernah mengerjakan kerja temporer seperti itu. Chip binning/yield management di semikonduktor juga bisa dilihat sebagai contoh dengan tingkat kegagalan yang sangat tinggi. Kalau melihat sekitar, proses meragukan seperti ini bukan hal aneh, malah keseharian.

  • Begitu kita mulai menilai diri sendiri sebagai orang yang "pandai memakai AI", muncul ilusi bahwa "cakupan masalah yang bisa kuselesaikan sekarang jadi luar biasa luas." Ini terjadi pada semua teknologi serbaguna. Dulu saat hype genetic algorithm, hal serupa juga terjadi. Semua orang mencari alat yang "serbaguna" lalu salah paham bahwa semua hal bisa diselesaikan dengannya. Padahal kenyataannya mereka mencoba mengoptimalkan sesuatu tanpa konteks sama sekali. AI adalah contoh paling ekstrem dari fenomena ini.

  • Sehebat apa pun prosesnya, itu tidak otomatis mengajarkan cara membangun sistem yang benar-benar bekerja. Pola yang terus berulang adalah tim tersesat cukup lama, lalu akhirnya seorang engineer yang benar-benar tahu cara menyelesaikan masalah turun tangan dan mengarahkan semuanya dengan benar.

• Sangat sulit membuat AI tetap mematuhi parameter yang diminta. Ia selalu melenceng secara acak ke arah yang aneh. Saat mengerjakan highlighting nftables, ada lebih dari 230 token, 2.500 state, dan 50 ribu transisi state. Bahkan kalau AI diberi lima aturan yang jelas berikutnya, semuanya tetap menyimpang di titik acak. Bukan cuma hasil coding, Vimscript yang sangat sederhana pun tidak bisa dibuat dengan benar. Akhirnya aku hanya memakai AI untuk dokumentasi. Meski begitu, AI mulai lumayan bagus untuk memecah dan menjelaskan hal-hal seperti rule, chain_block stmt, dan map_stmt_expr. Aku tinggal copy-paste pola sintaks yang kuinginkan.

• Pembuatan kode dengan AI cukup berguna pada tahap awal proyek, tetapi ada hal yang mengkhawatirkan untuk proyek yang sudah matang. Baru-baru ini parser Postgres dengan 280 ribu+ LOC di-merge ke Multigres tanpa review publik. Di ekosistem open source, ini sesuatu yang perlu diwaspadai. Banyak orang bergantung pada proyek seperti ini untuk belajar dan sebagai referensi; kalau kode AI masuk tanpa review yang layak, nilai edukasinya dan kepercayaan terhadap dependensi tersebut bisa melemah. Code review bukan cuma untuk menangkap bug, tetapi juga inti dari cara kolaborator belajar, memahami alasan desain, dan membangun pengetahuan kolektif. Masalahnya bukan kecepatan, melainkan proses transfer pengetahuan. Sebagai catatan, untuk urusan waktu sampai PR dipublikasikan, lihat tautan ini

  • Aku yang mengawasi pekerjaan ini, dan masukan soal arah yang lebih baik selalu diterima. Yang membuat situasi ini khusus adalah bahwa kami menerjemahkan parser C Postgres dengan bantuan LLM. Pada skala seperti ini, tidak mungkin mereview semuanya baris demi baris, jadi kami membuat prosedur terpisah untuk menjamin konsistensi. Kami memeriksanya secara cermat setiap hari selama dua bulan. Kami juga membawa sebagian besar test Postgres dan berhasil mem-porting-nya, jadi keandalan operasionalnya sudah cukup terjamin. Tahap Multigres saat ini masih sangat awal, jadi kami berencana mencoba penyalinan/penerjemahan skala besar lagi dari lebih banyak proyek seperti Vitess. Perbaikan akan kami terima. Penulisnya juga sedang menyiapkan blog yang menjelaskan seluruh proses, jadi silakan nantikan. Secara pribadi aku sangat terkejut dengan capaian yang bisa diraih dengan bantuan LLM. Tentu tetap dibutuhkan tingkat keahlian tertentu, dan orang ini melampaui semua kriteria yang dijelaskan di sini.

• Prosesku kira-kira seperti ini

  1. Berikan requirement ke AI
  2. Minta AI mengajukan pertanyaan tentang bagian yang belum jelas
  3. Jika tidak ada pertanyaan lagi, minta AI menjelaskan ulang requirement dalam bentuk PRD formal
  4. Aku mengkritiknya
  5. Minta AI mengusulkan dua arsitektur alternatif
  6. Aku memilih salah satu lalu mengkritiknya
  7. Minta AI mengusulkan dua daftar TODO terperinci
  8. Aku memilih salah satu lalu mengkritiknya
  9. Untuk salah satu TODO, minta AI mengajukan dua opsi implementasi
  10. Aku memilih salah satu lalu mengkritiknya
  11. Ulangi dari langkah 9
      Di tengah proses, aku juga mengambil snapshot agar bisa kembali ke titik sebelumnya.
      Dengan cara ini, meski belum sampai level luar biasa, setidaknya aku mendapat hasil yang bisa menjadi baseline untuk implementasiku.
      Kekurangannya: ini memakan waktu sangat besar, dan dalam 80% kasus aku merasa akan lebih cepat kalau dari awal aku kerjakan sendiri.

  • Kelihatannya lebih lambat daripada mengerjakan sendiri. Saat coding dengan AI, rasanya seperti melihat hasil kerja developer level menengah yang bilang, "sambil minum aku coba bikin kira-kira dari catatan yang kamu kasih, gimana?" lalu menghabiskan malam minggu membuat sesuatu secara improvisasi. Kita tinggal bilang, "NO, aku tidak suka," dan kalau arahnya kurang lebih benar, mungkin tetap sedikit lebih cepat untuk merapikan dan refactor daripada memulai dari nol pada Senin pagi.

  • Setiap kali melihat panduan bertahap seperti ini, rasanya kita hanya menambahkan kerepotan besar sehingga efisiensi yang tadinya diharapkan dari AI jadi hilang. Dalam pengalamanku sendiri, itu hampir benar. Tentu ada saat-saat AI membantu, tetapi menurutku kemampuan penting justru adalah menilai kapan dan di mana ia berguna.

  • Aku bekerja di layer yang lebih rendah, dan biasanya melakukannya seperti ini:

    • Buat sendiri interface dasarnya, atau kalau sudah ada lanjut ke tahap berikutnya
    • Gunakan LLM sebagai alat autocomplete
    • Jelaskan requirement dan beri tahu file entry point yang harus diubah
    • Jangan berikan tujuan sekaligus; kasih satu langkah per satu waktu
    • Begitu terlihat tanda-tanda salah arah, langsung intervensi untuk menghentikan atau mengarahkan ulang AI jika keliru
      Secara umum, kalau diberi tujuan yang terlalu luas dan panjang sekaligus, agen sering salah menilai kapan pekerjaan sebenarnya selesai.

  • Mirip, tapi aku pakai proses yang lebih sederhana. Aku memberi PRD, menjelaskan arsitektur garis besarnya, lalu menyuruh AI mengimplementasikan tiap komponen sesuai yang kuinginkan. Tetap makan banyak waktu, dan mungkin lebih cepat kalau dikerjakan sendiri, tapi sekarang aku sudah terlalu malas mengetik semuanya manual, jadi terpikir untuk menyuruh LLM mengerjakan per fungsi.

  • Kalau AI hanya kupakai untuk memberi tahu pendekatan kasar, library, atau karakteristik bahasa, lalu pekerjaan utamanya kukerjakan sendiri, sepertinya itu akan jauh lebih cepat.

• Kalau kamu pandai code review, mungkin lebih baik tidak memakai agen AI sama sekali.

  • Dari pengalaman mereview kode rekan-rekan yang jatuh cinta pada agen seperti Claude Code sambil memperbaiki bug-nya, aku merasa kodenya sering terasa ngawur seperti ditulis saat berhalusinasi, dan pembuatnya sendiri sering tidak bisa menjelaskannya sama sekali. Aku tetap percaya mungkin ada orang yang bisa menghasilkan kode sangat bagus dengan ini, tetapi semua yang kulihat langsung sejauh ini mengecewakan. Untungnya beberapa orang sadar sendiri lalu kembali ke cara kerja yang lebih benar. Kalau menilai hasil workflow berbasis agen zaman sekarang secara kritis, menurutku jawabannya sudah jelas. Orang yang pandai mereview kode akan sampai pada kesimpulan ini jauh lebih cepat.

  • Kalau aku pandai code review, aku ingin terus meningkatkan kemampuan itu.

• Orang yang teliti dalam code review cenderung kesulitan memakai tool AI, sedangkan orang yang review-nya asal-asalan cenderung terlalu bergantung pada AI.
  Artinya, orang yang pandai code review lebih baik menulis kode sendiri, dan apalagi untuk proyek seperti ini yang pada akhirnya harus mereka rawat sendiri dalam jangka panjang, menulis langsung terasa jauh lebih alami. Kalau coding bukan hal yang merepotkan dan kamu memang mahir melakukannya, tidak ada kebutuhan besar untuk AI. AI paling cocok untuk sedikit-sedikit mencari tahu saat mempelajari tool yang belum dikenal atau hal baru. Aku akui, berkat LLM sekarang ringkasan dari mesin pencari jadi lebih baik. Waktu terbuang untuk tersesat menafsirkan dokumentasi yang tidak perlu atau terpancing hal-hal yang tidak esensial praktis jadi nol.

• Code review memang bagian dari pekerjaan, tapi itu bukan bagian yang paling menyenangkan. Developer mendapat kepuasan dari momen saat benar-benar menulis kode. Tool AI memang membantu, tetapi karena hasilnya tidak bisa diprediksi sekaligus tampak meyakinkan, kita justru harus mereview lebih teliti sehingga beban malah bertambah. Kenapa kita membuat alat yang mengambil bagian serunya dan hanya menambah bagian yang tidak seru? Aku jadi penasaran, di mana agen khusus "code review"?

  • Sebenarnya aku sendiri tidak terlalu menikmati tindakan 'menulis' kode itu sendiri. Yang lebih menyenangkan adalah memecahkan masalah, membuat hal baru, memecah sistem lalu menyusunnya kembali menjadi struktur yang lebih baik. Dengan memakai LLM untuk coding, rasanya jauh lebih cepat memindahkan ide menjadi sesuatu yang nyata dan bisa disentuh. Kode lama juga jadi lebih type-safe, lebih terdokumentasi, dan refactor kompleks terasa lebih mudah. Aku tidak mengharapkan LLM untuk memecahkan masalah, melainkan untuk mengumpulkan konteks, menerapkan ulang pola, dan mengotomatisasi boilerplate. Terutama saat kode tersebar di banyak file, sangat nyaman kalau AI yang membuatkannya lalu aku tinggal memeriksa tiap perubahan.

  • OpenAI Codex Cloud sudah menambahkan fitur code review, dan model GPT-5-Codex baru dilatih khusus untuk code review [pengantar upgrade Codex]. Gemini dan Claude juga sudah punya fitur code review terintegrasi dengan GitHub Actions atau integrasi GitHub untuk Claude. GitHub juga meluncurkan fitur Copilot Code Review sendiri. Ada juga banyak startup khusus seperti CodeRabbit, Greptile, dan Qodo Merge.

  • Momen yang benar-benar membuatku merinding adalah saat, ketika mengimplementasikan sesuatu, aku menemukan struktur sangat elegan yang tersembunyi di bawahnya dan itu mengubah cara aku memprogram, bahkan cara aku menjalani hidup (meski kejadian seperti ini sangat jarang).

  • Developer junior cenderung lebih suka menulis kode secara langsung, sedangkan senior justru suka mengurangi jumlah kode. Secara pribadi, code review adalah bagian paling menyenangkan dari pekerjaanku (selama deadline pekerjaanku sendiri tidak sedang menekan). Aku tidak setuju dengan anggapan bahwa code review itu tidak menyenangkan.

  • Di pembukaan tadi ada pernyataan bahwa "kebanyakan developer suka membuat hal baru", tetapi kenyataannya banyak juga yang lebih suka memahami pola dan struktur di atas codebase yang dibuat orang lain lalu memperbaikinya. Ada juga orang yang justru merasa proses membuat sesuatu yang benar-benar baru—desain awal sampai iterasi tanpa akhir—lebih berat. Untuk pertanyaan "kenapa hanya menghilangkan bagian seru dan menambah bagian tidak seru", mungkin karena peningkatan produktivitas paling terasa memang ada di area itu. Untuk AI review, pilihannya sudah banyak seperti CodeRabbit, GitLab Duo, dan lain-lain. Bahkan hal seperti memasukkan Git diff ke RooCode untuk minta review kode juga bukan sesuatu yang sulit.

• Judul tulisan ini terasa terlalu menyederhanakan. Code review dan design review itu berbeda, dan yang dicoba dengan AI juga bukan cuma dua hal itu. Untuk memanfaatkan AI, tetap dibutuhkan keahlian domain terkait. Bahkan kalau hanya bicara coding, kemampuan review saja tidak cukup; apa pun bidang tugas yang diberikan ke AI, kita tetap perlu kemampuan untuk memverifikasinya. Ironisnya, AI justru paling membantu saat aku berhadapan dengan bahasa atau framework yang belum begitu kukuasai, tetapi pada saat itu juga aku tidak bisa melakukan review kode secara mendalam. Menarik juga bahwa kata "coding" kembali populer di era AI/LLM. Belakangan ini perusahaan tampaknya lebih menyukai engineer yang bisa melakukan segalanya—arsitektur, analisis requirement, full-stack development, sampai operasional—daripada sekadar coder.

  • Jabatan resmiku adalah "Software Engineer", tetapi dalam 5 tahun terakhir aku:

    1. Menyiapkan dan mengoperasikan sendiri cluster Kubernetes untuk tim kami
    2. Sangat sering memakai Docker
    3. Mengembangkan pipeline CI/CD
    4. Tak terhitung kali mengerjakan integrasi dan testing
    5. Sangat banyak membuat dokumentasi requirement termasuk berbagai diagram sistem
    6. Menangani pekerjaan IT lain-lain yang tidak dikerjakan tim infrastruktur
    7. Sesekali juga menulis kode

  • Memanfaatkan agen AI dengan benar itu sama seperti proses review.
    Karena LLM bisa menghasilkan kode dalam jumlah sangat besar, tetapi belum memiliki kedalaman penilaian seperti software engineer yang kompeten.
    Jauh lebih baik mengoreksi arah lebih awal daripada membiarkan kode menumpuk lama ke arah yang belum jelas. Seperti saat membimbing developer junior, lebih bijak mendiskusikan gambaran besar/desain lebih dulu lalu meluruskan arah setiap kali mulai melenceng. Kalau baru sadar setelah 100K token kode menumpuk bahwa 100 baris pertamanya salah, pada akhirnya semua harus dibongkar ulang.

• Aku sangat suka gagasan bahwa lewat code review bersama rekan kerja, pengetahuan kolektif dan standar tim bisa meningkat. Tapi membayangkan harus mereview kode AI yang keras kepala dan tidak kooperatif saja rasanya sudah cukup untuk membuat burnout.

• Kadang aku berpikir, kalau aku jadi sangat ahli di bagian pekerjaan yang paling membosankan, apakah itu berarti aku akan mengerjakan bagian itu seumur hidup? Jujur saja, aku tidak mau. Dan seperti yang dibilang di tulisan itu, bug memang selalu lebih baik dicegah agar tidak masuk sejak awal. Menangkapnya setelah terlanjur masuk tetap membawa risiko.