Kode AI yang terlihat rapi kadang justru paling mahal dirawat.
Masalahnya bukan AI coding agent nggak bisa bikin abstraction. Masalahnya: dia sering terlalu cepat merapikan pola yang belum stabil. Artikel ini ngebahas kenapa wrong abstraction makin berbahaya di era AI coding, kapan duplikasi kecil lebih sehat, dan checklist praktis buat review PR yang kelihatannya bersih tapi diam-diam bikin codebase susah diubah.
Apa itu wrong abstraction?
Wrong abstraction adalah abstraction yang dibuat terlalu cepat, sebelum developer benar-benar paham variasi masalahnya. Awalnya terlihat elegan: dua fungsi mirip digabung, helper baru dibuat, parameter ditambah, dan kode jadi lebih pendek.
Tapi beberapa minggu kemudian requirement berubah. Case A dan case B ternyata cuma mirip di permukaan. Supaya helper tadi tetap bisa dipakai, developer mulai menambah if, flag, parameter optional, callback, sampai exception kecil di banyak tempat. Di titik itu, abstraction yang tadinya mau mengurangi kompleksitas malah jadi pusat kebingungan.
Sandi Metz merangkum masalah ini dengan kalimat yang tajam: duplication is far cheaper than the wrong abstraction. Gua rasa kalimat ini makin relevan sekarang, karena AI coding agent sangat jago melihat pola tekstual, tapi belum tentu paham kapan pola itu matang secara domain.
Kenapa ini makin sering muncul di era AI coding?
AI coding agent punya kecenderungan natural buat “membantu lebih banyak”. Lu minta bikin fitur kecil, dia sekalian refactor file, bikin utility baru, rename variable, dan menggabungkan logic yang terlihat mirip. Dari luar, PR-nya tampak produktif. Banyak file berubah, struktur lebih rapi, dan komentar agent terdengar yakin.
Masalahnya, abstraction bukan cuma soal kode yang mirip. Abstraction adalah keputusan desain. Dia menjawab pertanyaan: “apakah dua hal ini akan berubah bersama, dengan alasan yang sama?” Kalau jawabannya belum jelas, abstraction itu spekulasi.
Di sinilah AI bisa bikin jebakan baru. Agent melihat bentuk kode, bukan selalu konteks bisnisnya. Dua function bisa sama-sama memformat data, tapi satu buat invoice customer dan satu lagi buat audit internal. Hari ini sama. Bulan depan beda aturan pajak, beda format ekspor, beda retention policy. Kalau sudah digabung terlalu cepat, setiap perubahan kecil harus negosiasi dengan helper yang makin gemuk.
Duplikasi kecil kadang lebih murah
Ini bukan ajakan buat membiarkan copy-paste liar. Duplikasi tetap punya biaya. Tapi duplikasi kecil sering memberi ruang belajar. Lu bisa melihat pola berubah beberapa kali sebelum memutuskan abstraction yang benar.
Bayangin ada dua komponen React yang sama-sama menampilkan kartu status. Agent mungkin langsung bikin StatusCard generik dengan 12 prop. Awalnya kelihatan clean. Tapi kalau satu kartu dipakai buat billing, satu buat deployment, dan satu buat security alert, kebutuhan visual dan interaksinya bisa beda arah. Akhirnya StatusCard punya prop seperti variant, compact, showReason, dangerMode, billingMode, dan lain-lain.
Kode memang tidak duplikat, tapi mental model-nya mahal. Setiap developer baru harus memahami matrix prop sebelum berani ubah satu tampilan. Di kondisi seperti ini, tiga komponen kecil yang sedikit mirip bisa lebih mudah dirawat daripada satu komponen generik yang terlalu pintar.
Cara gua membaca PR AI yang terlalu rapi
Kalau agent mengirim PR yang isinya fitur plus refactor besar, gua biasanya berhenti dulu. Bukan karena refactor jelek, tapi karena dua jenis perubahan itu punya risiko berbeda.
- Fitur harus menjawab kebutuhan user atau product.
- Refactor harus menjaga behavior tetap sama sambil menurunkan biaya perubahan berikutnya.
- Abstraction baru harus membuktikan bahwa pola yang digabung memang stabil.
Kalau tiga hal itu dicampur dalam satu diff besar, review jadi kabur. Lu susah bedain bug datang dari requirement baru, perubahan struktur, atau abstraction yang salah. Martin Fowler sering menekankan bahwa internal quality penting karena membuat software lebih mudah diubah. Tapi internal quality bukan berarti setiap duplikasi harus langsung dibasmi. Tujuannya adalah kemudahan perubahan, bukan sekadar kode terlihat indah.
Checklist sebelum menerima abstraction dari AI
Sebelum merge helper, base class, hook, utility, atau component generik buatan AI, coba pakai checklist ini:
- Apakah case yang digabung berubah karena alasan yang sama? Kalau cuma bentuknya mirip, tahan dulu.
- Apakah abstraction ini menghapus kompleksitas atau cuma memindahkannya? Kalau logic pindah ke parameter matrix, itu belum tentu menang.
- Apakah nama abstraction-nya jelas tanpa baca implementasi? Nama yang terlalu generik seperti
handleData,BaseManager, atauCommonHelpersering jadi tanda bahaya. - Apakah diff ini mencampur fitur dan refactor? Kalau iya, minta agent pisahkan PR.
- Apakah ada test yang membuktikan behavior lama tetap aman? Refactor tanpa test itu optimisme, bukan engineering.
- Apakah abstraction ini masih gampang dihapus? Kalau butuh ubah 30 file buat membatalkannya, biaya salahnya terlalu tinggi.
Prompt praktis buat ngerem agent
Gua lebih suka memberi batas eksplisit ke AI coding agent daripada berharap dia “paham sendiri”. Contohnya:
Kerjakan fitur ini dengan diff sekecil mungkin. Jangan refactor file lain kecuali wajib. Kalau melihat duplikasi, catat sebagai saran di akhir, tapi jangan buat abstraction baru tanpa konfirmasi.
Atau buat task refactor terpisah:
Analisis duplikasi di modul ini. Jangan ubah kode dulu. Beri 2 opsi: biarkan duplikasi sementara, atau ekstrak abstraction. Jelaskan tradeoff dan risiko salah abstraction.
Prompt seperti ini bikin agent lebih mudah dikontrol. Lu memisahkan fase observasi, desain, dan eksekusi. Ini juga bikin review lebih cepat karena reviewer nggak harus membongkar niat agent dari diff yang terlalu besar.
Kapan abstraction layak dibuat?
Abstraction layak dibuat saat pola sudah cukup stabil dan biaya duplikasi mulai jelas. Beberapa sinyal yang sehat:
- Perubahan di beberapa tempat selalu terjadi bersama.
- Nama domain-nya jelas, bukan cuma nama teknis generik.
- Test bisa menjelaskan behavior bersama yang benar-benar penting.
- Abstraction mengurangi jumlah keputusan yang harus dipikirkan developer berikutnya.
- Kalau requirement baru datang, abstraction tetap sederhana, bukan makin penuh pengecualian.
Di Google, perubahan skala besar pun dianggap punya biaya koordinasi, eksekusi, dan migrasi. Pelajaran buat tim kecil: refactor yang tampak “cuma bersih-bersih” tetap punya cost. Kalau agent bikin perubahan lintas file tanpa alasan kuat, lu tetap harus bayar biaya review dan risiko regresinya.
Takeaway buat developer
AI coding bikin kita bisa menghasilkan kode lebih cepat. Tapi kecepatan bikin abstraction salah juga ikut naik. Jadi skill penting berikutnya bukan cuma prompt engineering, tapi review taste: kemampuan membedakan clean code yang benar-benar menurunkan kompleksitas dari clean code kosmetik yang cuma terlihat rapi.
Menurut gua, aturan sederhananya begini: biarkan duplikasi kecil hidup sedikit lebih lama kalau domain-nya belum jelas. Minta AI bikin diff kecil. Pisahkan fitur dari refactor. Dan kalau sebuah abstraction butuh banyak flag buat bertahan, mungkin yang perlu dihapus bukan duplikasinya, tapi abstraction-nya.
FAQ singkat
Apakah ini berarti duplikasi selalu lebih baik?
Nggak. Duplikasi besar tetap berbahaya. Poinnya: duplikasi kecil bisa jadi fase belajar sebelum lu tahu abstraction yang benar.
Apakah AI coding agent buruk buat refactor?
Nggak juga. AI bisa sangat membantu buat refactor mekanis, rename konsisten, atau memecah fungsi panjang. Yang perlu dijaga adalah refactor spekulatif yang mengubah desain tanpa konteks cukup.
Apa tanda abstraction mulai salah?
Biasanya muncul banyak flag, conditional, pengecualian, nama makin generik, dan developer takut mengubahnya karena efek sampingnya susah ditebak.
