Legacy Code Refactor: Kapan AI Layak Dipakai?

Beberapa waktu lalu saya ngobrol dengan seorang engineer yang lagi pusing beresin codebase lama, umurnya sudah delapan tahun, tanpa dokumentasi yang jelas. Dia sempat coba pakai AI coding assistant buat bantu legacy code refactor, dengan harapan prosesnya jadi lebih cepat. Hasilnya malah bikin frustrasi, karena AI-nya ngasih saran yang kelihatan rapi tapi nggak nyambung sama konteks bisnis yang ada di kode itu.

Cerita ini kedengaran familiar buat saya, karena saya sendiri pernah ada di posisi serupa. Masalahnya bukan AI-nya jelek, tapi kita sering lupa bahwa legacy code refactor itu soal memahami konteks, bukan cuma soal mengganti syntax lama jadi yang lebih modern. Di tulisan ini saya mau bahas kapan AI beneran membantu, kapan justru bikin kerjaan tambah lama, dan bagaimana cara saya mikirin ini secara lebih realistis.

Kenapa Legacy Code Refactor Beda dari Nulis Kode Baru

Waktu nulis kode baru, kamu punya kanvas kosong. Kamu bisa desain struktur sesuai kebutuhan sekarang, tanpa harus mikirin sejarah keputusan yang sudah dibuat orang lain lima tahun lalu. Legacy code refactor itu kebalikannya. Kamu masuk ke rumah orang lain yang sudah ditinggali lama, dan setiap dinding yang kelihatan aneh biasanya ada alasannya, meskipun alasan itu nggak selalu tertulis di mana-mana.

Ini yang bikin AI kadang kurang pas dipakai di tahap awal. AI bisa baca kode, tapi dia nggak tahu bahwa fungsi yang kelihatan redundant itu sengaja dibuat begitu karena ada requirement khusus dari klien tertentu. Saya pernah lihat AI menyarankan simplifikasi yang secara teknis benar, tapi secara bisnis salah total, karena menghapus edge case yang justru krusial.

Jadi sebelum mikirin tools apa yang dipakai, pertanyaan yang lebih penting adalah: apakah saya sudah cukup paham konteks kode ini sebelum minta AI bantu ubah strukturnya? Kalau jawabannya belum, AI cuma akan mempercepat kesalahan, bukan mempercepat solusi.

Bagian Mana yang Cocok Dibantu AI

Bukan berarti AI nggak berguna sama sekali di proses ini. Ada beberapa area yang menurut saya justru pas banget dibantu AI, terutama yang sifatnya mekanis dan berulang. Misalnya mengubah gaya penulisan kode biar konsisten, menambahkan komentar penjelasan di fungsi yang minim dokumentasi, atau mengidentifikasi pola duplikasi di file yang jumlahnya ratusan.

Saya juga sering pakai AI buat brainstorming pendekatan refactor, bukan buat eksekusi langsung. Saya kasih AI potongan kode, minta dia jelaskan alur logikanya dengan bahasa saya sendiri, lalu saya bandingkan pemahaman itu dengan yang saya tangkap. Kalau ada gap, biasanya di situ letak bagian yang perlu saya gali lebih dalam sebelum ubah apapun.

Poin pentingnya, AI paling efektif untuk legacy code refactor ketika scope-nya kecil, terisolasi, dan risikonya rendah kalau salah. Begitu masuk ke logic bisnis yang menyangkut banyak dependency, saran AI harus diperlakukan sebagai hipotesis, bukan keputusan final.

Testing Tetap Jadi Tanggung Jawab Kamu

Ini bagian yang sering diremehkan. Banyak orang mengira kalau AI sudah bantu tulis ulang kodenya, berarti kodenya otomatis lebih aman. Padahal AI nggak tahu apakah hasil refactor-nya benar-benar menghasilkan output yang sama seperti sebelumnya, kecuali ada test yang memverifikasi itu.

Saya belajar ini dengan cara yang agak menyakitkan. Waktu itu saya minta AI bantu simplifikasi fungsi kalkulasi harga yang lumayan kompleks. Kodenya jadi lebih pendek, lebih rapi, kelihatan lebih "profesional". Tapi setelah dites, ada satu kondisi khusus, diskon untuk pelanggan lama, yang ternyata hilang dari logic barunya. Untungnya ketahuan sebelum masuk production.

Dari situ saya jadi lebih disiplin: setiap kali legacy code refactor melibatkan AI, saya pastikan ada test case yang jalan sebelum dan sesudah perubahan, dengan hasil yang harus identik untuk skenario yang sama. Kalau kodenya belum punya test sama sekali, saya anggap itu tanda bahaya, bukan alasan buat langsung refactor besar-besaran.

Pendekatan Bertahap Lebih Realistis

Godaan terbesar saat pakai AI untuk legacy code refactor adalah pengin beresin semuanya sekaligus. Kelihatannya efisien, tapi praktiknya sering berantakan, karena kamu jadi review ratusan baris perubahan dalam satu waktu tanpa benar-benar paham semua implikasinya.

Pendekatan yang lebih masuk akal buat saya adalah pecah jadi bagian kecil. Mulai dari satu modul, satu fungsi, atau satu file yang risikonya paling rendah kalau salah. Setelah itu jalan dengan baik dan sudah divalidasi, baru lanjut ke bagian berikutnya. Prosesnya lebih lambat kelihatannya, tapi jauh lebih terkontrol.

AI di sini berfungsi sebagai asisten yang mempercepat bagian mekanis, sementara keputusan tentang urutan mana yang direfactor dulu, seberapa besar scope-nya, dan kapan berhenti tetap ada di tangan kamu. Legacy code refactor yang berhasil biasanya bukan yang paling cepat, tapi yang paling minim menimbulkan bug baru di tengah jalan.

Jadi kalau ditanya apakah AI membantu proses legacy code refactor, jawabannya iya, tapi dengan catatan. Dia mempercepat bagian yang mekanis dan repetitif, tapi nggak bisa gantikan pemahaman konteks dan judgment soal risiko. Langkah paling praktis adalah mulai dari scope kecil, pastikan ada testing yang memadai, dan pakai AI sebagai alat bantu berpikir, bukan pengganti keputusan.