Utang Teknis di Era Vibe Coding: Cepat Jadi, Mahal Dirawat

Bayangkan membangun rumah dalam semalam. Dindingnya berdiri, catnya rapi, lampunya menyala. Masalahnya, tidak ada yang tahu persis di mana pipa air dipasang dan kabel listrik ditarik lewat mana. Selama tidak ada yang bocor, semuanya terlihat baik-baik saja. Begitu ada yang rusak, barulah terasa mahalnya.

Gambaran itu cukup dekat dengan cara banyak aplikasi dibuat hari ini. Dengan asisten AI, satu orang bisa menghasilkan ribuan baris kode dalam sehari. Kecepatan itu nyata dan bermanfaat. Namun ada satu istilah lama di dunia rekayasa perangkat lunak yang kembali relevan: utang teknis (technical debt).

Dari mana istilah "utang teknis" berasal

Istilah ini diperkenalkan oleh Ward Cunningham, programmer yang juga dikenal sebagai pencipta wiki pertama. Pada konferensi OOPSLA 1992, ia menulis laporan pengalaman tentang sistem manajemen portofolio WyCash. Di sana ada kalimat yang kemudian terkenal: "Shipping first time code is like going into debt." Mengirim kode versi pertama itu ibarat berutang.

Maksudnya, berutang tidak selalu salah. Kode yang belum sempurna boleh dirilis supaya produk cepat dipakai dan dipelajari. Syaratnya, utang itu harus segera dibayar dengan menulis ulang dan merapikan kode. Kalau tidak dibayar, setiap menit yang dihabiskan untuk bekerja di atas kode yang "belum benar" terhitung sebagai bunga.

Cunningham sendiri belakangan meluruskan salah kaprah: metafora ini bukan izin untuk menulis kode secara asal-asalan. Utang teknis adalah keputusan sadar yang dicatat dan direncanakan pelunasannya, bukan kekacauan yang dibiarkan.

Vibe coding: ketika kode "dilupakan"

Pada Februari 2025, Andrej Karpathy, peneliti AI yang pernah bekerja di OpenAI dan Tesla, memperkenalkan istilah vibe coding. Ia menggambarkannya sebagai cara memprogram dengan "menyerah sepenuhnya pada vibes" dan "melupakan bahwa kodenya ada". Kita cukup menjelaskan keinginan dengan bahasa sehari-hari, AI menulis kodenya, dan hasilnya diterima selama aplikasinya tampak berjalan.

Untuk prototipe, proyek akhir pekan, atau alat bantu pribadi, cara ini sangat menolong. Orang yang belum pernah belajar pemrograman pun bisa mewujudkan idenya. Persoalan muncul ketika kode yang ditulis dengan cara itu dibawa ke produksi: dipakai banyak orang, menyimpan data penting, dan harus dirawat bertahun-tahun.

Di sinilah utang teknis berubah wujud. Dulu utang lahir karena tenggat waktu. Kini utang bisa lahir karena kode dibuat jauh lebih cepat daripada kemampuan manusia untuk memahaminya.

Apa kata data

Beberapa penelitian memberi gambaran yang patut diperhatikan.

Kode makin sering disalin, makin jarang dirapikan. GitClear menganalisis 211 juta baris kode yang berubah dalam rentang 2020--2024. Hasilnya, 2024 menjadi tahun pertama jumlah baris yang disalin-tempel melampaui jumlah baris yang dipindahkan. Baris yang "dipindahkan" dipakai sebagai penanda kegiatan refactoring, yaitu merapikan kode tanpa mengubah fungsinya. Jumlah blok kode dengan lima baris atau lebih yang terduplikasi naik delapan kali lipat selama 2024. Kode duplikat adalah contoh klasik utang teknis: satu perbaikan harus diulang di banyak tempat, dan satu tempat yang terlewat menjadi sumber bug.

Lebih banyak AI, pengiriman lebih tidak stabil. Laporan DORA 2024 dari Google Cloud mencatat lebih dari 75 persen responden mengandalkan AI untuk setidaknya satu tugas harian. Peningkatan adopsi AI sebesar 25 persen berkaitan dengan kenaikan kualitas dokumentasi 7,5 persen, kualitas kode 3,4 persen, dan kecepatan code review 3,1 persen. Namun pada saat yang sama, adopsi AI disertai perkiraan penurunan throughput pengiriman 1,5 persen dan penurunan stabilitas pengiriman 7,2 persen. Artinya, kode terlihat lebih baik di permukaan, tetapi perubahan yang dikirim ke pengguna lebih sering bermasalah.

Celah keamanan ikut terbawa. Laporan Veracode (30 Juli 2025) menguji lebih dari 100 model bahasa besar pada 80 tugas penulisan kode. Dalam 45 persen kasus, model memilih cara yang tidak aman dan memasukkan celah yang termasuk daftar OWASP Top 10. Untuk cross-site scripting, model gagal mengamankan kode pada 86 persen kasus. Celah keamanan adalah bentuk utang teknis yang bunganya bisa dibayar dengan kebocoran data.

Merasa cepat belum tentu cepat. Uji acak terkendali dari METR (Juli 2025) terhadap 16 pengembang open source berpengalaman dengan 246 tugas nyata menemukan bahwa saat memakai AI mereka justru 19 persen lebih lambat, padahal sebelumnya memperkirakan akan 24 persen lebih cepat. METR sendiri mengingatkan hasil ini tidak bisa langsung digeneralisasi ke semua alat dan situasi, tetapi temuan ini menunjukkan bahwa waktu membaca, memeriksa, dan memperbaiki keluaran AI sering tidak diperhitungkan.

Perlu dicatat, sebagian besar data di atas menunjukkan keterkaitan, bukan sebab-akibat langsung. Tidak setiap baris duplikat ditulis oleh AI. Namun arahnya cukup jelas untuk dijadikan peringatan.

Wujud utang teknis versi AI

Dalam praktik, utang teknis dari kode buatan AI biasanya muncul dalam beberapa bentuk:

Kode yang tidak dipahami pemiliknya. Ketika terjadi galat, tidak ada yang tahu harus mulai dari mana, sehingga perbaikan pun diserahkan lagi ke AI tanpa pemahaman.
Fungsi kembar. AI tidak selalu tahu bahwa fungsi serupa sudah ada di bagian lain, lalu menulis versi baru.
Tanpa tes. Aplikasi "jalan" saat dicoba sekali, tetapi tidak ada pengujian otomatis yang menjaga agar perubahan berikutnya tidak merusak fitur lama.
Dependensi berlebihan. Pustaka tambahan dipasang untuk pekerjaan yang sebenarnya cukup beberapa baris kode, menambah beban pembaruan dan risiko keamanan.
Rahasia dan konfigurasi yang bocor. Kunci API atau kata sandi tertulis langsung di kode.

Memakai AI tanpa menumpuk utang

Kabar baiknya, utang teknis bisa dikelola. Beberapa kebiasaan sederhana membantu:

Pisahkan prototipe dari produksi. Vibe coding cocok untuk mencoba ide. Sebelum dipakai orang banyak, kode harus ditinjau ulang seolah-olah ditulis orang lain.
Baca sebelum menerima. Perlakukan keluaran AI seperti kiriman dari rekan kerja baru: diperiksa, dipahami, baru digabung.
Minta AI menulis tes. Tes otomatis adalah cicilan utang paling murah. Setiap fitur baru sebaiknya datang bersama tesnya.
Buat perubahan kecil. DORA menyoroti bahwa ukuran perubahan yang besar cenderung membuat pengiriman tidak stabil. Perubahan kecil lebih mudah ditinjau dan dibatalkan.
Jadwalkan pelunasan. Sisihkan waktu rutin untuk refactoring, menghapus kode duplikat, dan memperbarui dokumentasi.
Pasang pemeriksa otomatis. Linter, pemindai keamanan, dan pemeriksa dependensi bisa menangkap masalah sebelum sampai ke pengguna.
Catat utangnya. Utang yang disengaja tidak berbahaya selama tertulis: apa yang ditunda, mengapa, dan kapan akan dibereskan.

Penutup

AI tidak menciptakan utang teknis; manusia sudah lama pandai melakukannya sendiri. Yang berubah adalah kecepatannya. Dulu butuh berbulan-bulan untuk menumpuk kode yang sulit dirawat, kini bisa terjadi dalam beberapa hari.

Pesan Ward Cunningham lebih dari tiga dekade lalu masih berlaku: berutang boleh, asal sadar sedang berutang dan segera dibayar. Di era vibe coding, itu berarti tetap memahami kode yang kita kirim, sekalipun bukan kita yang mengetiknya.