Kode AI lu jalan? Bagus. Tapi itu belum otomatis berarti aman buat di-merge.
Masalah baru di era AI coding bukan cuma “modelnya bisa nulis kode atau nggak”. Masalah yang lebih mahal adalah: lu sanggup review hasilnya dengan ngerti, atau lu cuma percaya karena test hijau? Artikel ini ngebahas kapan developer sebaiknya menolak kode AI, meski kodenya terlihat bekerja. Fokusnya bukan anti-AI, tapi bikin workflow AI coding tetap punya ownership manusia, review yang jelas, dan risiko yang bisa dijelaskan.
Kenapa kode AI yang jalan tetap bisa berbahaya?
Kode yang “jalan” cuma membuktikan satu hal: dia berhasil melewati skenario yang lu coba. Itu belum membuktikan dia cocok dengan arsitektur, gampang dirawat, aman di edge case, atau bisa dijelaskan ke tim.
Vinicius Brasil nulis poin yang menurut gua sangat ngena: saat implementasi makin cepat karena coding agent, bottleneck pindah ke review volume kode yang dihasilkan AI. Bahkan kalau lu sudah pakai plan mode, pecah task, dan bikin perubahan kecil, tetap ada beban kognitif waktu membaca diff yang tidak sepenuhnya lu pikirkan dari awal.
Ini problem yang sering nggak kelihatan di demo AI coding. Demo biasanya berhenti di “lihat, fiturnya jadi”. Di kerja nyata, pertanyaannya lanjut: apakah lu bisa maintain ini 3 bulan lagi?
Definisi singkat: apa itu AI-generated code dalam konteks artikel ini?
AI-generated code adalah kode yang sebagian besar dihasilkan atau diubah oleh AI coding assistant/coding agent seperti GitHub Copilot, Claude Code, Cursor, Codex, atau tool sejenis. Lu tetap bisa memberi instruksi, review, dan edit manual, tapi ide implementasi awal banyak datang dari model.
Masalahnya bukan karena kode itu “buatan AI”. Masalahnya muncul saat developer kehilangan pemahaman atas keputusan desain yang masuk ke diff.
5 tanda kode AI harus lu tolak dulu
1. Lu nggak bisa menjelaskan pendekatannya dengan bahasa sendiri
Ini filter paling sederhana. Kalau lu nggak bisa menjelaskan kenapa agent memilih pendekatan itu, jangan buru-buru merge. Bukan berarti solusi agent salah, tapi berarti ownership lu belum cukup kuat.
Code review yang sehat bukan cuma “test pass”. Lu perlu bisa jawab:
- Problem apa yang diselesaikan?
- Kenapa pendekatan ini dipilih?
- Tradeoff apa yang dikorbankan?
- Bagian mana yang paling berisiko?
- Kalau bug muncul, area mana yang perlu dicek dulu?
Kalau semua jawabannya masih “karena AI yang bikin”, itu sinyal buat pause.
2. Diff lebih besar daripada masalahnya
AI coding agent kadang terlalu rajin. Bug kecil bisa berubah jadi refactor setengah modul. Satu tombol error bisa memicu abstraksi baru, helper baru, type baru, dan test yang sebenarnya nggak nyentuh risiko utama.
Diff besar bukan otomatis buruk. Tapi diff besar harus punya alasan besar juga.
Checklist cepatnya:
- Apakah semua file yang berubah benar-benar perlu?
- Apakah ada rename/refactor yang nggak berhubungan dengan task?
- Apakah perubahan bisa dipecah jadi dua PR: fix utama dan refactor terpisah?
- Apakah reviewer lain bisa memahami diff ini tanpa baca novel?
Kalau jawabannya banyak “nggak yakin”, minta agent ulang dengan scope lebih sempit.
3. AI bikin abstraksi sebelum problem-nya terbukti
Ini penyakit klasik, cuma sekarang bisa muncul lebih cepat. AI sering suka bikin pattern yang kelihatan rapi: service layer, adapter, strategy, config-driven everything. Padahal problem-nya mungkin cuma satu edge case.
Abstraksi yang terlalu cepat bikin codebase terlihat sophisticated, tapi sering bikin debugging makin berat. Prinsip YAGNI tetap kepakai di era AI: jangan bangun struktur masa depan sebelum kebutuhan masa depannya jelas.
Kalau kode AI memperkenalkan abstraction layer baru, tanya:
- Ada minimal dua use case nyata yang butuh abstraksi ini?
- Apakah abstraksi mengurangi kompleksitas, atau cuma memindahkannya?
- Apakah developer baru bisa baca alur ini tanpa lompat ke 7 file?
4. Test hijau, tapi risiko sebenarnya nggak dites
Test pass itu penting, tapi test bisa menipu kalau skenarionya salah. AI bisa bikin test yang cuma mengunci implementasi, bukan behavior. Lebih parah lagi, test bisa terlalu dekat dengan kode yang baru dibuat sehingga tidak benar-benar menangkap bug.
Untuk kode AI, gua biasanya lebih percaya test kalau dia mencakup:
- happy path dan failure path,
- edge case yang relevan dengan bug/fitur,
- regression test untuk masalah awal,
- case input aneh atau data lama,
- dan minimal satu test yang akan gagal di implementasi lama.
Kalau test cuma membuktikan “fungsi baru mengembalikan value yang sama seperti mock yang baru dibuat”, itu belum cukup.
5. Kodenya bikin sistem lebih susah dipikirkan
Ada kode yang benar secara lokal, tapi bikin mental model sistem rusak. Misalnya: side effect pindah ke tempat yang nggak jelas, error handling jadi tersebar, state makin susah dilacak, atau naming terlihat rapi tapi maknanya kabur.
Ini bagian yang sering nggak tertangkap benchmark. AI bisa menghasilkan kode yang sintaksnya bagus, tapi desainnya bikin manusia berikutnya bayar biaya pemahaman lebih mahal.
Kalau sebuah diff bikin lu butuh waktu lama buat menjawab “data ini mengalir dari mana ke mana?”, itu sinyal desainnya perlu disederhanakan.
Kenapa ini penting buat maintainer dan tim kecil?
GitHub pernah membahas pull request limits sebagai cara mengurangi noise untuk maintainer open-source. Intinya: bikin PR makin gampang bukan berarti waktu reviewer ikut jadi gratis. AI memperbesar masalah ini karena volume diff bisa naik jauh lebih cepat daripada kapasitas review manusia.
Di tim kecil, efeknya mirip. Satu developer bisa menghasilkan lebih banyak perubahan dengan bantuan AI, tapi kalau tim nggak punya guardrail review, codebase bisa berubah jadi tumpukan keputusan yang nggak benar-benar dipahami siapa pun.
Menurut gua, ini skill baru yang perlu dilatih developer: bukan cuma “cara prompt AI”, tapi cara menolak hasil AI dengan alasan engineering yang jelas.
Workflow praktis sebelum merge kode AI
Lu bisa pakai checklist ini sebelum approve atau merge diff dari AI coding agent:
- Jelaskan ulang problem-nya. Kalau lu nggak bisa menjelaskan problem, jangan review solusi.
- Minta agent tulis plan pendek. Maksimal 5 poin: file yang disentuh, alasan, risiko.
- Batasi scope diff. Satu task, satu PR kecil. Refactor besar dipisah.
- Baca diff tanpa percaya komentar agent dulu. Lihat perubahan nyata, bukan narasi.
- Cek test yang gagal di versi lama. Kalau nggak ada, test-nya mungkin cuma kosmetik.
- Cari abstraksi yang belum perlu. Hapus atau tunda kalau belum ada kebutuhan nyata.
- Tulis alasan merge/reject. Ini bikin judgement lu makin tajam dari waktu ke waktu.
Tabel cepat: merge, minta revisi, atau tolak?
| Kondisi diff AI | Keputusan sehat | Alasan |
|---|---|---|
| Small diff, problem jelas, test relevan | Merge setelah review | Risiko bisa dipahami |
| Kode jalan, tapi diff terlalu besar | Minta pecah task | Review cost terlalu tinggi |
| Abstraksi baru tanpa kebutuhan jelas | Tolak atau sederhanakan | Potensi tech debt |
| Test pass, tapi edge case utama tidak dites | Minta test tambahan | Confidence palsu |
| Lu nggak bisa menjelaskan pendekatannya | Tolak dulu | Ownership belum cukup |
AI coding tetap berguna, asal judgement manusia nggak ikut di-outsource
Gua nggak melihat ini sebagai argumen buat berhenti pakai AI. Justru sebaliknya: AI coding makin berguna kalau lu punya rem yang jelas.
Charity Majors juga pernah menulis bahwa AI menuntut lebih banyak disiplin engineering, bukan lebih sedikit. Itu masuk akal. Saat biaya membuat perubahan turun, disiplin untuk memilih perubahan mana yang layak masuk justru makin penting.
AI bisa bantu eksplorasi, generate alternatif, menulis test awal, atau mempercepat boilerplate. Tapi keputusan terakhir tetap harus balik ke developer: apakah perubahan ini membuat sistem lebih baik, atau cuma membuat diff terlihat produktif?
Takeaway buat developer
- Kode AI yang jalan belum tentu layak merge.
- Kalau lu nggak bisa menjelaskan diff-nya, jangan approve dulu.
- Diff besar harus punya alasan besar.
- Test hijau harus membuktikan behavior penting, bukan cuma mengulang implementasi.
- Skill penting di era AI coding adalah judgement: tahu kapan menerima, menyederhanakan, atau menolak.
FAQ singkat
Apakah semua kode AI harus dicurigai?
Iya dalam arti sehat: semua kode perlu review, termasuk kode manusia. Bedanya, kode AI bisa datang lebih cepat dan lebih banyak, jadi disiplin review harus lebih ketat.
Kalau test sudah hijau, kenapa masih perlu review manual?
Karena test cuma mencakup skenario yang ditulis. Review manual tetap perlu untuk melihat desain, maintainability, security, dan efek samping yang belum dites.
Apakah AI code review cukup untuk mengganti human review?
Belum. AI review bisa bantu menangkap pattern, typo, atau risiko umum. Tapi keputusan arsitektur, product tradeoff, dan ownership tetap perlu manusia yang paham konteks sistem.
Apa prompt paling sederhana buat memperbaiki workflow ini?
Minta agent menjawab: “jelaskan problem, pendekatan, file yang berubah, risiko, dan test yang membuktikan perubahan ini benar.” Kalau jawabannya kabur, diff-nya belum siap.
