Panduan Review Kode AI: Kapan Harus Menolak Meski Berjalan

Implementasi kode semakin cepat berkat AI coding agent, tapi bottleneck baru muncul di tahap review. Bukan hanya PR dari rekan tim, tapi diff di lokal setelah coding agent selesai bekerja. Meski sudah menerapkan best practices seperti plan mode dan small changes, cognitive overload tetap terasa saat mereview kode yang tidak kita tulis sendiri. Artikel ini membahas kapan sebaiknya kita menolak kode AI meskipun technically works.

Dalam pengalaman yang dibagikan Vini Brasil, seringkali perubahan besar dari AI ditolak dan dikerjakan ulang dari awal. Perbedaannya bukan pada model LLM, tapi pada engineer yang mengendarai agent. Semakin banyak waktu untuk memahami masalah, semakin baik solusi yang dihasilkan. Berikut adalah checklist praktis yang bisa kamu terapkan sebelum menyetujui kode AI masuk ke production.

Alasan Utama Menolak Kode AI

Tidak semua kode yang berjalan layak masuk production. Ada beberapa red flags yang sering muncul pada output AI:

• Tidak bisa dijelaskan dengan kata-kata sendiri: Jika kamu tidak paham approach yang dipilih, jangan merge.

• Diff lebih besar dari masalahnya: Perubahan yang terlalu luas meningkatkan risiko regression.

• Abstraksi tanpa bukti kebutuhan: AI suka membuat generalisasi prematur yang malah mempersulit maintenance.

• Bekerja lokal tapi mempersulit sistem: Code yang green di CI bisa saja meningkatkan complexity secara keseluruhan.

• Trust output lebih dari pemahaman sendiri: Ini adalah tanda bahaya paling besar. Engineering adalah tentang adequate, scalable, dan extensible solutions.

Langkah 1: Pahami Masalah Sebelum Lihat Solusi

Jangan langsung baca diff. Tuliskan dulu dalam satu paragraf: masalah apa yang sedang diselesaikan, constraint apa yang ada, dan success criteria-nya. Jika kamu tidak bisa menjelaskannya dengan jelas, minta agent untuk berhenti dan ulangi dari plan. Proses ini mirip dengan rubber duck debugging, tapi dilakukan sebelum review kode.

Langkah 2: Bandingkan dengan Beberapa Alternatif

AI cenderung memberikan solusi pertama yang ditemukannya. Sebagai engineer, tugas kita adalah mengevaluasi trade-off. Tanyakan pada agent: apa alternatif approach lainnya? Mengapa approach ini dipilih? Apa downside-nya dalam jangka panjang? Diskusi ini bisa dilakukan dalam chat interface sebelum kode ditulis.

Langkah 3: Perkecil Scope Diff

Aturan praktis: jika diff lebih dari 200 baris untuk bug fix sederhana, ada sesuatu yang salah. Pecah task menjadi fase-fase kecil. Setiap fase harus menghasilkan PR yang independen dan reviewable. Ini tidak hanya memudahkan review, tapi juga memudahkan rollback jika terjadi masalah.

Langkah 4: Verifikasi Context Awareness

AI seringkali tidak memiliki konteks penuh dari codebase. Periksa apakah kode yang dihasilkan:

• Mengikuti convention yang sudah ada di repo.

• Tidak menduplikasi utility yang sudah tersedia.

• Menangani edge cases yang relevan dengan domain bisnis.

• Tidak mengimport library baru tanpa justifikasi.

Langkah 5: Jalankan Test Manual dan Automated

Jangan hanya andalkan CI green. Jalankan test secara lokal dan lakukan smoke test pada fitur yang berubah. AI terkadang membuat test yang lemah atau bahkan mock behavior yang salah. Pastikan test benar-benar memvalidasi behavior, bukan hanya mencapai coverage threshold.

Langkah 6: Document Decisions

Jika ada keputusan arsitektur yang diambil berdasarkan rekomendasi AI, dokumentasikan di code comment atau ADR (Architecture Decision Record). Ini membantu tim di masa depan memahami mengapa kode ditulis demikian, terutama ketika AI model berubah dan rekomendasinya berbeda.

Kesimpulan

Coding agent adalah alat yang powerful, tapi mereka masih memerlukan engineer hebat untuk mengarahkannya ke solusi yang great. Menolak kode AI bukan tanda kegagalan, tapi indikasi discipline engineering. Dengan menerapkan checklist di atas, kamu bisa memastikan bahwa kode yang masuk production tidak hanya berjalan, tapi juga maintainable dan scalable. Ingat: code that runs is not always good code.

Tools Pendukung Review Kode AI

Selain manual review, ada beberapa tools yang bisa membantu memfilter output AI secara otomatis:

• Static analysis: Gunakan SonarQube atau Semgrep untuk menangkap code smell, security vulnerability, dan complexity metrics yang mungkin terlewat saat manual review.

• AI review assistant: GitHub Copilot Code Review atau CodeRabbit bisa memberikan second opinion pada diff yang dihasilkan agent.

• Diff size limiter: Konfigurasi pre-commit hook atau CI rule yang menolak PR dengan diff lebih dari threshold tertentu, misalnya 300 baris.

Metrik Code Quality yang Perlu Diperhatikan

Jangan hanya andalkan gut feeling. Gunakan metrik objektif untuk menilai kualitas kode AI:

• Cyclomatic complexity: Idealnya di bawah 10 per function. AI sering menghasilkan nested conditional yang dalam.

• Code duplication: Periksa dengan tools seperti jscpd atau pylint. AI sering copy-paste pattern yang sama di beberapa file.

• Test coverage delta: Setiap baris kode baru harus diikuti test yang relevan. Coverage yang stagnan adalah red flag.

Studi Kasus: Refactor yang Berawal dari Penolakan

Sebuah tim backend menemukan bahwa AI-generated API endpoint bekerja dengan baik saat load test ringan, tapi mengalami memory leak saat concurrency tinggi. Setelah ditelaah, ternyata AI menggunakan closure yang menangkap variabel besar tanpa cleanup. Solusi akhirnya adalah rewrite manual dengan explicit resource management. Kasus ini menunjukkan bahwa functional testing saja tidak cukup untuk menyetujui kode AI.

Membangun Kebiasaan Review yang Konsisten

Konsistensi adalah kunci. Buat checklist review sebagai bagian dari Definition of Done setiap ticket. Dengan waktu, tim akan mengembangkan nose untuk mendeteksi kode AI yang superficially correct tapi architecturally flawed. Ini adalah investasi jangka panjang yang membayar dividen dalam bentuk codebase yang tetap sehat meski volume kode AI terus meningkat.