- Di era AI menulis kode, metode review pull request (PR) harus berubah secara mendasar, dan proses review saat ini tidak cocok untuk workflow coding berbasis AI
- Saat reviewer bertanya, "mengapa dilakukan seperti ini?", strukturnya menjadi developer bertanya lagi ke AI lalu menyalin-tempel jawabannya, sehingga muncul inefisiensi karena manusia hanya berperan sebagai perantara (middleman)
- Decision log AI harus disertakan ke source control bersama kode agar reviewer bisa memeriksa konteksnya secara langsung
- Workflow di mana AI menerima komentar reviewer secara langsung lalu secara otomatis membuat patch dan respons sudah dimungkinkan saat ini lewat kombinasi webhook GitHub/GitLab dan server MCP
- Dokumen desain dan diagram arsitektur juga harus disertakan ke source control dalam format yang bisa di-parse LLM seperti Markdown atau Mermaid, karena "Context is king"
Masalah code review di era AI
- Saat mengajukan pertanyaan dalam review PR, sering kembali jawaban yang terasa seperti dibuat AI, karena memang AI yang menulis kodenya
- Untuk pertanyaan seperti "mengapa memilih library ini?", developer manusia tidak bisa menjawab, sehingga polanya menjadi bertanya ulang ke AI lalu menyalin jawabannya
- Sebelum era AI, kita bertanya langsung ke developer (penulis kode), bukan ke manajernya, jadi perantara harus dihilangkan
- Semua pihak yang menulis kode harus ikut dalam review, dan pendekatan memakai agen AI terpisah yang menebak balik alasan setelah fakta adalah pendekatan yang sepenuhnya keliru
Pentingnya decision log
- Saat kita bertanya "mengapa?" kepada manusia, yang sebenarnya ditanyakan adalah proses berpikir internal yang tidak tercantum dalam PR
- Chain-of-thought AI dapat diaudit secara eksternal (externally auditable), dan catatan interaksi dengan AI juga bisa diaudit, jadi konteks ini harus dimasukkan ke review dan source control
- Tidak perlu meng-commit semua token yang dihasilkan selama pembuatan PR; terinspirasi dari konsep episodes milik Random Labs, cukup sertakan transkrip panggilan tool yang berhasil dan kesimpulannya
- Ini juga bisa diskalakan di lingkungan agent swarm, dengan decision log dirangkai sebelum tahap PR lalu diformat di tahap akhir
Batasan komentar inline
- Perubahan pada file sumber mengharuskan pipeline build dijalankan ulang (linting, kompilasi, testing) bahkan jika yang berubah hanya komentar
- Transkrip decision jauh lebih besar daripada panjang yang biasanya diizinkan dalam komentar inline
- Komentar yang ada menjelaskan bagaimana kode bekerja saat ini, bukan proses yang mengarah pada keputusan tersebut
Workflow review terintegrasi AI
- Saat reviewer memberi komentar, AI milik developer harus bisa menerimanya langsung lalu secara otomatis membuat patch dan respons
- Ini sudah bisa diimplementasikan saat ini dengan kombinasi webhook GitHub/GitLab dan server MCP
- Mirip dengan Devin AI atau Claude Code via GitLab Duo
- Bisa diatur agar developer harus memberi izin terlebih dahulu kepada AI, atau agar AI menilai sendiri lalu langsung bertindak
- Developer manusia juga tetap bisa menulis komentar dan melakukan perubahan sendiri
- Ini bisa secara signifikan mengurangi masalah komentar review yang baru ditindaklanjuti beberapa jam atau beberapa hari kemudian, atau bahkan tidak ditindaklanjuti sama sekali
Kebutuhan tool untuk reviewer
- Reviewer juga harus bisa meninjau PR dengan bertanya langsung ke AI, seperti saat menjelajahi codebase
- Decision log harus ikut di-check in bersama kode agar tujuan ini tercapai
- Tetap memakai antarmuka PR yang ada, tetapi di sampingnya harus terintegrasi jendela untuk bercakap dengan Codex atau Claude seperti lingkungan pengembangan IDE
- Belum ada tool yang benar-benar rapi, jadi akan bagus jika ada yang membuatnya
- Di diff, reviewer bisa bertanya jawab secara privat dengan AI tentang library yang tidak dikenal, bahasa yang asing, atau best practice, lalu memutuskan apakah komentar code review memang diperlukan
- Jika komentar memang diperlukan, itu adalah sinyal bahwa ada bagian kosong (gap) dalam decision log, sehingga log tersebut harus diperbarui sebelum PR disetujui
Pentingnya dokumen desain dan konteks
- Dalam review terintegrasi AI, reviewer juga jadi jauh lebih mudah untuk mengusulkan patch secara langsung
- Dokumen desain, decision records, dan diagram arsitektur harus ditambahkan ke source control dalam format yang bisa di-parse LLM seperti Markdown atau Mermaid
- "Context is king"
10 komentar
Alasan PR mati tampaknya bukan karena PR itu sendiri, melainkan karena komunikasi para vibe coder yang terlalu semrawut.
Diimplementasikan dengan flow seperti apa, metode lain apa yang sempat dipertimbangkan dan kenapa tidak dipilih, kenapa
package.lockharus berubah. Bukankah semua itu memang hal-hal yang seharusnya dijelaskan terlebih dahulu?Kalau memang bisa ditulis di deskripsi PR, rasanya lebih baik yang mati itu coder yang sengaja memaksa orang lain bertanya soal itu.
Saya setuju. Dulu, PR terasa seperti saya bertanggung jawab atas hasil yang saya buat sendiri,
namun PR dari vibe coder terasa seperti, "Saya bahkan tidak tahu apa yang saya buat, tapi bagaimanapun hasilnya sudah ada, jadi kamu yang menilai dan menemukan masalahnya."
Saya setuju.
Awalnya dibicarakan lebih dulu, lalu berakhir menjadi bentuk di mana tidak ada yang bertanggung jawab di kemudian hari.
Saya setuju. Sampai bikin kesal.
Saya setuju.
Dalam satu PR, ada sampai 500 file yang berubah, tapi yang mengajukan malah banyak mengeluh karena review tidak dilakukan dalam 30 menit. Di kolom penjelasan cuma ditulis lima-enam baris lalu selesai, jadi apakah saya harus percaya begitu saja dan menyetujuinya...?
Tesnya sudah semua, kan?
Ya
Oke, yang benar ya
Kenapa sih dibilang mati terus
Kalau begini, kita semua mati!
Rasanya belakangan ini terlalu banyak tulisan dengan judul yang bilang sesuatu sudah mati hanya karena sedikit-sedikit begitu.
Jadi terasa cukup melelahkan.
Saya juga berpikir sebaiknya kita berhenti membunuh semuanya.
"Sudah mati; hidup lama"
Tulisan dengan gaya seperti itu memang jadi terlalu banyak. Tapi saya setuju bahwa AI memang sedang mengubah segalanya.