Kenapa AI Sering Salah Pas Refactor Codebase Gede

AI coding tools lumayan bagus buat perubahan lokal. Tapi begitu refactor menyentuh implicit dependency, naming ambigu, dan business rule tersembunyi, kualitasnya cepat turun.

· · 9 min read

Gue suka AI buat coding. Bukan karena dia ajaib, tapi karena dia berguna kalau lo tau batasnya. Masalahnya, banyak orang baru sadar batas itu pas nyuruh AI refactor codebase gede lalu hasilnya kelihatan rapi di diff, tapi aneh waktu dijalankan. AI sering bagus di perubahan lokal, tapi goyah di perubahan yang bergantung pada konteks implisit.

Gue udah beberapa kali lihat pola yang sama: rename function aman, pecah komponen kecil aman, bikin test sederhana aman. Tapi begitu task-nya berubah jadi "rapikan modul ini dan sesuaikan semua call site yang relevan", kualitasnya mulai turun. Bukan karena modelnya malas. Tapi karena codebase besar punya banyak aturan yang gak tertulis.

---

Masalah utamanya bukan syntax

AI jarang gagal karena lupa syntax dasar. Dia gagal karena gak sepenuhnya melihat:

• dependency tersembunyi
• side effect lintas modul
• business rule yang hidup di kepala tim
• naming lama yang ternyata punya makna historis
• coupling yang gak kelihatan dari satu file

Di codebase kecil, semua itu masih muat di konteks. Di codebase besar, sebagian aturan cuma kebaca kalau lo pernah maintain sistem itu berbulan-bulan. AI bisa baca file. Tapi dia belum tentu ngerti kenapa fungsi tertentu jelek tapi sengaja dibiarkan seperti itu.

---

Refactor itu bukan sekadar ubah bentuk

Banyak orang meremehkan refactor karena kelihatannya cuma "rapihin code". Padahal refactor yang baik mempertahankan behavior sambil mengubah struktur internal. Di situ jebakannya. AI sering terlalu percaya diri memodernisasi pola tanpa sadar ada kontrak lama yang diam-diam harus dipertahankan.

Contoh klasik: helper lama kelihatan redundant, lalu AI gabung jadi util baru. Secara DRY terlihat bagus. Tapi ternyata dua helper itu sengaja dipisah karena satu dipakai di jalur audit dan satu lagi di jalur user-facing yang punya format berbeda. Di diff, perubahan itu terlihat elegan. Di production, bug-nya muncul seminggu kemudian.

---

Kenapa context window bukan jawaban penuh

Orang sering bilang, "ya udah kasih context lebih banyak." Itu membantu, tapi bukan obat total. Masalah codebase besar bukan cuma panjang token. Masalahnya adalah prioritas konteks. Mana yang penting? Mana file pendukung? Mana kontrak yang tidak tertulis? Mana test yang benar-benar merepresentasikan behavior inti?

Bahkan kalau model bisa membaca banyak file, belum tentu dia bisa menyusun peta mental yang sama seperti maintainer manusia. Jadi long context itu peningkatan, bukan pembebasan dari review.

---

Cara pakai AI yang lebih waras buat refactor

Setelah beberapa kali ketipu, gue jadi lebih suka pola begini:

1. Pecah refactor jadi unit kecil

Jangan minta "rapikan module billing". Minta lebih spesifik: ekstrak function A, rename konsep B, tambahkan test regression untuk flow C.

2. Minta AI jelaskan asumsi

Kalau dia gak bisa menyebut asumsi, itu tanda dia sebenarnya belum ngerti cukup dalam.

3. Wajib pakai test sebagai pagar

AI yang ngerjain refactor tanpa test itu seperti intern yang disuruh bongkar panel listrik sambil ditebak-tebak.

4. Fokuskan AI ke kerja mekanis

Rename konsisten, update import, nulis test dasar, cari call site. Biarkan manusia pegang keputusan arsitektur dan behavioral risk.

---

Yang sering disalahpahami

"Kalau diff kecil berarti aman" - belum tentu. Diff kecil bisa tetap mengubah kontrak penting.

"Kalau model baca seluruh repo, berarti dia ngerti repo" - membaca bukan berarti memahami.

"AI jelek buat refactor" - terlalu kasar. AI cukup bagus untuk refactor terlokalisasi. Yang jelek adalah ekspektasi bahwa dia bisa menggantikan maintainer senior untuk perubahan lintas domain.

"Masalahnya di model, bukan di prompt/task design" - dua-duanya. Model punya batas, tapi task yang terlalu kabur juga bikin hasilnya makin rawan.

---

Referensi yang layak dibaca

• SWE-bench
• Anthropic Engineering / Product docs
• OpenAI Docs
• Martin Fowler - Refactoring

---

Gue tetap pakai AI buat refactor. Tapi sekarang ekspektasinya lebih waras. Gue pakai dia buat mempercepat pekerjaan yang jelas batasnya, bukan buat menggantikan intuisi tentang codebase yang dibangun dari konteks, incident, dan bekas luka.

Kalau lo mulai merasa AI "bodoh" karena salah refactor sistem besar, mungkin masalahnya bukan sekadar kualitas model. Mungkin lo lagi minta sesuatu yang sebenarnya butuh lebih dari sekadar kemampuan baca file. Itu butuh judgment. Dan sampai sekarang, judgment itu masih mahal.

---

*ditulis setelah beberapa diff AI kelihatan bersih banget di editor, tapi bikin gue buka test, blame, dan history commit buat cari tahu kenapa sesuatu yang "harusnya aman" ternyata gak aman sama sekali.*