Kembali ke Blog

Panik 'Utang Teknis' Vibe Coding: Yang Beneran Saya Lihat di Lapangan

#ai#vibe-coding#opinion
Panik 'Utang Teknis' Vibe Coding: Yang Beneran Saya Lihat di Lapangan

Kalau kamu baca newsletter dev bulan ini, pasti ketemu headline kayak gini: vibe coding diam-diam ngubur perusahaan-perusahaan dalam utang teknis, dan bakal ada “reckoning” dalam 90 hari, enam bulan, setahun — pilih aja angkanya. Saya ngerti kenapa narasi ini nyebar cepet. Ceritanya enak didengerin: orang jadi males, ngebiarin AI nulis semuanya tanpa dicek, terus sekarang mereka nanggung akibatnya. Tapi setelah tahun ini lumayan sering jadi freelancer yang dipanggil buat beresin codebase kayak gitu, pendapat saya sebenarnya lebih membosankan dari headline-nya: ini bukan masalah baru, ini masalah lama yang jalan 10x lebih cepat.

Codebase yang saya warisin nggak keliatan “baru”. Dua bulan lalu saya ambil kontrak buat nambahin fitur di aplikasi Next.js yang, setahu saya, hampir semuanya dibikin agent tanpa review manusia sama sekali. Enam API route, masing-masing ngulang logic validasi yang mirip tapi dikit-dikit beda. Error handling yang atau nggak ada sama sekali, atau cuma dibungkus try/catch kosong yang nelen error aslinya. Nama komponen yang nggak nyambung sama fungsi komponennya, karena nggak pernah di-rename lagi setelah draft pertama. Saya pengen bilang ini parah karena AI, tapi jujur? Saya udah pernah liat pola mess yang persis sama dari junior dev yang kerja solo tanpa review, atau dari vendor outsource murah yang ngejar deadline — jauh sebelum tooling AI kayak gini ada. Polanya bukan hal baru. Yang baru cuma alatnya.

Yang beneran baru itu volumenya. Ini bagian yang menurut saya artikel-artikel “vibe coding menghancurkan software” itu setengah bener setengah salah. Bener kalau utangnya numpuk lebih cepat dari yang pernah kelihatan sebelumnya. Junior dev tanpa review mungkin nulis beberapa ratus baris kode berantakan sehari. Agent yang jalan tanpa pengawasan bisa nulis ribuan baris di waktu yang sama, di belasan file, sebelum orangnya sempet ngopi. Kalau disiplin tim kamu emang udah lemah dari awal — nggak ada review wajib, nggak ada test, “nanti aja dibenerin” jadi proses beneran — AI nggak nyiptain kelemahan itu, cuma ngejalanin kelemahan yang udah ada lewat amplifier. Utangnya emang bakal kejadian cepat atau lambat. Sekarang cuma kejadiannya di timeline yang jauh lebih pendek, makanya kerasa kayak krisis mendadak, bukan pembusukan pelan-pelan kayak biasanya.

Terus saya sendiri ngapain beda kalau pakai agent? Bukan generate lebih dikit — review yang lebih terstruktur, bukan review asal-asalan juga. Setiap diff yang dihasilin agent buat saya, saya baca baris per baris sebelum masuk commit, sama kayak cara saya review PR-nya junior. Beberapa minggu lalu saya nemu bug di mana agent reuse nama variabel loop dari outer scope di dalam callback — secara teknis valid di JavaScript, tapi behavior-nya salah total, dan itu bakal ke-ship diam-diam kalau saya cuma skim bukan baca beneran. Ini bukan kekhawatiran hipotetis, ini bug beneran dari minggu yang beneran. Agent-nya nggak “halusinasi” dalam arti dramatis yang sering dikhawatirin orang — dia cuma pede salah, dengan cara yang keliatan normal banget kalau cuma dilirik sekilas. Makanya skim diff dari AI itu lebih bahaya dibanding skim diff dari manusia: manusia biasanya ninggalin kode yang keliatan canggung atau mencurigakan pas dia sendiri ragu-ragu. Agent ninggalin kode yang rapi dan pede, meskipun dia sebenarnya salah. Bau-bauan yang biasanya bikin kita mau berhenti dan liat lebih detail, itu nggak ada di kode AI.

Solusinya bukan “pakai AI lebih dikit”. Buat freelancer solo yang ngerjain beberapa proyek sekaligus, itu saran yang nggak realistis, dan jujur saya sendiri nggak bakal ngikutin itu. Solusinya yang membosankan tapi selalu bener dari dulu: kerja dalam potongan kecil yang bisa direview, bukan drop-an gede yang nggak sempet dicek; test yang beneran jalan sebelum merge, bukan test yang ditulis belakangan cuma buat bikin angka coverage keliatan bagus; dan nganggep setiap baris yang dihasilin agent sebagai draft dari junior yang cepat, capable, tapi kadang salah — bukan hasil kerja yang udah final. Nggak ada satu pun dari itu yang disiplin baru buat era AI. Itu disiplin yang emang selalu dibutuhin tim yang bagus, cuma sekarang ruang buat salahnya lebih sempit karena volume kode yang lewat pipeline-nya jauh lebih banyak.

Bagian yang saya beneran setuju sama kepanikan ini itu soal insentifnya. Banyak codebase paling parah yang saya warisin bukan dibikin sama orang yang nggak tahu cara yang bener — tapi dibikin di bawah tekanan deadline di mana “ship aja, nanti dibenerin” itu instruksi beneran dari atasan, dan AI cuma bikin “ship aja” itu lebih gampang di-iya-in. Itu masalah manajemen yang pakai kostum AI. Nyalahin model buat codebase yang emang sengaja nggak direview sama businessnya, itu ngelepasin tanggung jawab orang yang beneran ambil keputusan. Kalau organisasi kamu emang nggak punya proses review sebelum tooling agentic coding ini muncul, kamu bukan lagi “bakal punya masalah utang teknis” — kamu udah punya dari dulu. Tooling-nya cuma bikin itu keliatan lebih cepat.

Ada juga versi argumen ini dari arah sebaliknya — orang yang nyepelein semua kekhawatiran soal kode hasil AI karena “review dari dulu selalu nangkep kode jelek, jadi sebenernya nggak ada yang beda.” Saya juga nggak setuju sama itu. Volume ngubah ekonomi dari review itu sendiri. Reviewer manusia punya budget perhatian yang kira-kira tetap dalam sehari, dan budget itu nggak otomatis nambah cuma karena kode yang direview jadi 10x lebih banyak. Kalau satu tim tetep pakai proses review yang persis sama sementara jumlah kode yang lewat situ berlipat ganda, hasil realistisnya bukan “review tetep nangkep semuanya kayak dulu,” tapi “review diam-diam jadi lebih dangkal tanpa ada yang sengaja mutusin itu.” Itu mekanisme sebenarnya di balik kepanikan utang teknis ini, dan itu argumen yang valid — cuma bukan yang biasanya dijelasin di headline-headline doom itu. Masalahnya bukan AI nulis kode jelek. Masalahnya AI bisa lebih cepat dari proses review yang ukurannya dari era yang lebih lambat, dan nggak ada yang sengaja nge-resize proses itu.

Saya nggak mikir vibe coding itu ancaman yang belum pernah ada buat kualitas software. Menurut saya ini lebih kayak stress test yang ngungkapin tim mana yang disiplin engineering-nya emang udah lemah dari awal, cuma dengan kecepatan yang bikin itu nggak bisa lagi diabaikan. Buat proyek-proyek yang saya kerjain sendirian, ini justru bikin saya lebih hati-hati, bukan makin santai — saya percaya agent buat nulis cepat, tapi saya nggak percaya apapun yang dia tulis sampai saya baca sendiri.