AI bisa bikin kode jauh lebih cepat. Tapi kalau tiap perubahan berikutnya bikin lu takut nyentuh codebase, itu bukan murah. Itu cuma utang desain yang invoice-nya datang belakangan.
Artikel ini membahas kenapa refactoring tetap penting di era AI coding agent. Intinya: AI menurunkan biaya mengetik kode, bukan otomatis menurunkan biaya memahami, mengubah, mengetes, dan memiliki software. Buat developer yang mulai pakai Claude Code, Cursor, GitHub Copilot, atau agent lain, refactoring perlu diperlakukan sebagai loop kerja utama, bukan polish setelah fitur selesai.
Kenapa topik refactoring jadi makin penting di era AI coding?
Giles Edwards-Alexander dari Thoughtworks menulis eksperimen menarik di artikel The Economic Benefit of Refactoring. Ia membangun aplikasi sekitar 150.000 baris kode, mayoritas Rust, ditambah TypeScript dan Terraform. Kode itu ditulis agent, terutama Claude Code dan sebagian Cursor. Ia juga menulis bahwa ia tidak membaca atau me-review semua kode, kecuali sesekali.
Hasilnya bukan sekadar cerita “AI bisa bikin aplikasi besar”. Bagian yang lebih menarik justru smell yang muncul di tengah jalan: satu data access layer tumbuh dari lebih dari 6.000 baris sampai akhirnya 17.155 baris dalam satu file Rust. Banyak query mengulang setup HTTP request, encoding, decoding, dan pola yang sama.
Menurut gua, ini contoh yang sangat sehat buat dibaca tanpa panik dan tanpa anti-AI. Masalahnya bukan “AI pasti bikin kode jelek”. Masalahnya: kalau output kode jadi lebih murah dan lebih cepat, peluang codebase menumpuk desain setengah matang juga ikut naik. Developer tetap butuh mekanisme buat menjaga bentuk sistem.
Apa itu refactoring?
Refactoring adalah proses memperbaiki struktur internal kode tanpa mengubah perilaku luarnya. Definisi klasik dari Martin Fowler menekankan transformasi kecil yang behavior-preserving: kode tetap melakukan hal yang sama, tapi desainnya dibuat lebih mudah dipahami dan diubah.
Dengan kata lain, refactoring bukan “bikin kode kelihatan cantik”. Refactoring itu cara menjaga biaya perubahan tetap rendah. Kalau fitur baru makin lama makin mahal dibuat karena developer harus menebak efek samping di banyak tempat, masalahnya sering bukan kurang cepat mengetik. Masalahnya desain sistem mulai mahal dirawat.
AI menurunkan biaya produksi kode, bukan biaya kepemilikan software
Sebelum AI coding agent, menulis 1.000 baris kode butuh waktu, fokus, dan tenaga manusia yang lumayan besar. Sekarang, agent bisa menghasilkan banyak file dalam hitungan menit. Ini berguna banget kalau task-nya jelas, boundary-nya kecil, dan hasilnya gampang diverifikasi.
Tapi software tidak berhenti di momen kode pertama kali jalan. Ada fase setelah itu:
- developer lain harus membaca perubahan;
- bug perlu dicari dan diperbaiki;
- fitur berikutnya harus masuk tanpa merusak yang lama;
- test perlu dipercaya;
- arsitektur harus tetap masuk akal saat scope membesar.
Ini yang gua maksud dengan biaya kepemilikan software. Lu bukan cuma membayar waktu saat kode dibuat. Lu membayar semua keputusan desain yang dibawa kode itu selama berbulan-bulan atau bertahun-tahun.
AI coding agent membuat bagian “create” lebih murah. Tapi bagian “own” tetap mahal kalau tidak dijaga.
Smell yang perlu lu cari saat agent menulis kode
Kalau lu pakai AI buat nulis fitur, jangan cuma tanya “apakah test hijau?”. Test hijau penting, tapi belum cukup. Ada beberapa smell yang menurut gua perlu dicek sebelum merge.
1. File membesar karena agent terus menambal di tempat yang sama
Kalau agent selalu menambah logic ke file yang sama, itu sinyal awal. File besar tidak otomatis buruk, tapi kalau pertumbuhannya terjadi karena semua perubahan ditempel di satu tempat, lu perlu berhenti sebentar.
Pertanyaan praktisnya: “Apakah file ini punya satu alasan jelas untuk berubah, atau dia sudah jadi tempat pembuangan semua kasus?”
2. Pola request, parsing, atau validasi diulang berkali-kali
Kasus data access layer di artikel Thoughtworks relevan di sini. Repetisi setup HTTP request dan JSON encoding/decoding bisa terlihat harmless di awal. Tapi saat jumlah endpoint bertambah, repetisi itu bikin perubahan kecil jadi mahal.
Kalau lu harus mengubah cara auth header dikirim, error handling, atau timeout, apakah cukup ubah satu tempat? Kalau jawabannya tidak, desainnya mungkin sudah mulai mahal.
3. Abstraction muncul terlalu cepat atau terlalu telat
Ini bagian yang tricky. Duplikasi kecil kadang lebih murah daripada abstraction yang salah. Tapi menunda abstraction terlalu lama juga bikin perubahan makin berat. AI agent sering kuat di pola lokal, tapi belum tentu paham kapan desain perlu dipisah jadi boundary yang lebih sehat.
Guardrail yang gua pakai: jangan refactor cuma karena “kelihatan bisa diabstraksi”. Refactor saat ada perubahan nyata yang berulang, ada konsep domain yang jelas, atau ada biaya maintenance yang mulai terasa.
Refactoring loop buat workflow AI coding
Kalau lu pakai agent buat kerja harian, refactoring sebaiknya masuk ke loop, bukan jadi aktivitas akhir yang selalu ditunda. Format sederhana yang bisa lu coba:
- Batasi scope task. Jangan minta agent membangun fitur besar sekaligus kalau hasilnya sulit dicek.
- Minta rencana perubahan dulu. Lu perlu tahu file mana yang akan disentuh dan kenapa.
- Generate kode dalam potongan kecil. Satu perubahan = satu tujuan yang bisa diverifikasi.
- Review smell desain. Cek file yang membesar, duplikasi pola, boundary yang kabur, dan test yang terlalu sempit.
- Refactor sebelum lanjut fitur berikutnya. Jangan tunggu sampai rasa takut menyentuh kode muncul.
- Pecah PR jadi layer. Pisahkan refactor, logic fitur, test, dan cleanup.
Poin terakhir nyambung dengan fitur GitHub Stacked Pull Requests yang diumumkan sebagai public preview. GitHub menjelaskan stacked pull requests sebagai rangkaian PR berurutan, masing-masing mewakili layer perubahan yang fokus. Ini membantu tim me-review perubahan besar sebagai bagian kecil yang lebih masuk akal, bukan satu bongkahan raksasa.
Buat era AI coding, pendekatan ini makin relevan. Agent bisa menghasilkan perubahan besar, tapi manusia tetap butuh review boundary yang kecil.
Kapan refactoring sebaiknya dilakukan?
Refactoring tidak harus dilakukan setiap kali ada duplikasi dua baris. Lu juga tidak perlu mengubah semua kode lama hanya karena agent menemukan pola yang bisa “dirapikan”. Fokus ke titik yang akan sering berubah.
Checklist cepatnya:
- Refactor sekarang kalau bagian itu sering disentuh dan mulai bikin perubahan kecil terasa mahal.
- Refactor sekarang kalau duplikasi membuat bug fix harus diulang di banyak tempat.
- Refactor sekarang kalau agent mulai salah karena struktur kode memberi contoh yang buruk.
- Tunda refactor kalau area itu stabil, jarang disentuh, dan risiko perubahan lebih besar dari manfaatnya.
- Tunda refactor kalau abstraction-nya belum jelas dan lu cuma ingin kode terlihat lebih “clean”.
Takeaway buat developer yang pakai AI agent
AI coding agent itu tetap berguna. Gua sendiri melihat value paling besar saat agent dipakai buat mempercepat draft implementasi, eksplorasi, test awal, dokumentasi, dan kerja repetitif. Tapi semakin cepat kode dibuat, semakin penting juga disiplin memilah mana output yang layak dimiliki jangka panjang.
Kalimat yang menurut gua perlu diingat: AI menurunkan biaya mengetik, bukan biaya tanggung jawab.
Kalau lu ingin codebase tetap sehat, jangan treat refactoring sebagai kegiatan mewah. Treat refactoring sebagai biaya menjaga opsi tetap murah. Bukan supaya kode terlihat elegan, tapi supaya fitur berikutnya tidak terasa seperti masuk hutan tanpa peta.
FAQ singkat
Apakah kode dari AI selalu perlu di-refactor?
Tidak selalu. Kalau scope kecil, test jelas, dan boundary sehat, cukup review seperti biasa. Refactor saat struktur mulai membuat perubahan berikutnya lebih mahal.
Apakah refactoring harus dilakukan manusia?
Tidak harus semua diketik manusia. Agent bisa membantu refactor, tapi manusia tetap perlu menentukan intent, boundary, dan kriteria aman. Refactoring tanpa arah bisa berubah jadi rewrite kecil yang tidak perlu.
Apakah stacked PR wajib dipakai?
Tidak wajib, tapi idenya penting: pecah perubahan besar jadi layer yang bisa direview. Kalau tim lu belum pakai stacked PR, lu tetap bisa meniru polanya lewat commit kecil, branch terpisah, atau PR bertahap.
