Vibe Coding Justru Menambah Tech Debt, Bukan Mengurangi

“Masa fitur begini doang butuh dua minggu? Gua semalem coba prompt 10 menit aja udah dapet skeleton-nya.”

Sounds familiar? Anda tidak sendiri. Saya sering mendengar atau melihat fenomena serupa secara langsung ataupun di media sosial, yang membuat software engineer harus memikirkan bandwidth ekstra untuk “bersih-bersih” di kemudian hari.

Vibe coding, cara baru melakukan pemrograman dengan bahasa natural atau bahasa sehari-hari, memungkinkan siapa saja, tidak hanya software engineer, mampu menghasilkan tools, aplikasi, atau sistem sederhana hanya bermodalkan prompt.

Tapi tentu kemudahan ini tetap punya harga yang harus dibayar dalam bentuk tech debt. Sayangnya tidak semua orang memahami hal ini, terlebih para leaders yang baru mengetahui kecanggihan ini sehingga berekspektasi project bakal beres lebih cepat.

Artikel ini ditulis melalui riset dari beberapa sumber terpercaya, dan wawancara tertulis dengan dua Engineering Manager Mekari, Puji Triwibowo dan Muhammad Okfriansyah, dari pengalaman menjalankan tim engineering sungguhan, bukan sekadar opini di permukaan. 

Vibe coding dan kekurangan di baliknya

Vibe coding adalah sebuah cara pemrograman yang digerakkan melalui perintah dalam bahasa sehari-hari. Anda menulis apa yang Anda inginkan melalui LLM, dan AI menghasilkan code, config, bahkan seluruh aplikasi.

Cara ini dipopulerkan oleh Andrej Karpathy di tahun 2025 melalui akun X nya yang menyebutkan “…where you fully give in to the vibes, embrace exponentials, and forget that the code even exist.” 

Vibe coding menawarkan daya tarik yang luar biasa dari segi kecepatan, biaya, dan resource manpower yang jauh lebih kecil. Cara ini memang unggul digunakanan untuk prototipe, proof of concept, dan tools internal sederhana.

Batasannya muncul saat aplikasi vibe coding digunakan untuk production tanpa verifikasi, testing, dan governance yang memadai. Di sini lah kecepatan berubah menjadi hambatan. 

Mengapa vibe coding justru menambah tech debt

Technical debt atau code debt dari proses pemrograman manual, umumnya terjadi karena development yang buru-buru, dokumentasi yang tidak ideal, dan coding yang tidak konsisten.

Berbeda dengan vibe coding, tech debt muncul karena tidak ada yang bisa memahami logika dari code di balik layarnya. Ketika muncul bug, tidak ada yang bisa bertanggung jawab atas code yang ter-generate.

Ilusi yang berpola, terlihat beres di awal tapi revisi menumpuk di akhir

Puji Triwibowo, Engineer Manager Mekari, menggambarkan tech debt dari hasil vibe coding sebagai ilusi yang berpola. 

“Di bulan pertama, semuanya terasa luar biasa karena proses pengembangan dan deployment menjadi jauh lebih cepat. Tetapi beberapa minggu kemudian mulai muncul masalah integrasi, perilaku aplikasi yang tidak konsisten, hingga bug yang sebelumnya tidak terlihat. 

Masuk minggu berikutnya, tidak jarang sebagian besar kapasitas tim justru habis untuk memperbaiki masalah yang berakar dari kode yang dihasilkan AI, dimana seharusnya tim bisa membangun fitur baru.”

Puji Triwibowo

Engineer Manager Mekari

Menurut Puji, kode hasil vibe coding sering memberi kesan seolah pekerjaan sudah selesai, padahal baru sampai di tahap awal. 

Kode bisa terlihat rapi, lolos linting, berhasil di-compile, demo-nya berjalan mulus; tapi di baliknya masih tersimpan banyak technical debt yang menjadi masalah kalau tidak diantisipasi.

Data di lapangan mengkonfirmasi pola ini. Riset dari GitClear berjudul AI Copilot Code Quality, menunjukkan 211 juta baris kode dari repositori Google, Microsoft, Meta, dan sejumlah perusahaan besar lain sepanjang 2020-2025. 

Hasilnya, proporsi kode yang di-refactor (istilah GitClear: “Moved”) anjlok dari sekitar 25% menjadi di bawah 10%, sementara kode hasil Copy-Paste naik dan untuk pertama kalinya melampaui kode yang di refactor. Di saat yang bersamaan angka Churn sebagai definisi code yang ditulis lalu direvisi atau dibuang dalam waktu singkat, juga meningkat drastis 2x lipat.

Seperti yang disampaikan Puji, angka Churn yang naik dari tahun ke tahun secara statistik menunjukkan siklus “tulis, ternyata salah, tulis ulang” yang akhirnya menghabiskan waktu tim engineer untuk memperbaiki code daripada membangun fitur baru.

Minimnya Guardrails dan Konteks 

Selain konteks dan objektif yang jelas, guard rails sebagai aturan dan batasan juga perlu dibuat serinci mungkin.

Menurut Okfriansyah, kurangnya guard rails yang spesifik juga mempengaruhi timbulnya tech debt di kemudian hari. Tanpa ada skill yang spesifik dan penggunaan hook dengan trigger yang jelas, tentu kualitas dari hasil vibe code akan terus menambah tech debt.

Hal ini sejalan dengan Adnan Masood, PhD. dalam publikasinya di Medium yang menyebut akar masalah tech debt yang dihasilkan dari vibe code disebabkan oleh tidak adanya context engineering. 

Masood menjelaskan model AI bersifat stateless (tidak menyimpan memori atau konteks), satu-satunya kontrol yang dimiliki engineer hanyalah apa yang dimasukkan ke context window. Tanpa context engineering, proses tersebut hanya menghasilkan churn dan rework, bukan software yang stabil.

Keterbatasan context window ini juga menjadi alasan pentingnya guard rails yang konkrit. Karena jika output dari AI masih kurang sesuai dengan ekspektasi, maka kita akan terus mengulang beberapa prompt agar mendapat hasil yang pas. 

Masalahnya, semakin banyak prompt dalam satu sesi, AI cenderung kehilangan konteks dan malah menghasilkan kode yang over complicated.

Risiko, Isu, dan Kendala yang Umum dari Hasil Vibe Code

Berbicara tentang risiko, Puji juga memetakan ke mana “utang” ini biasanya bersembunyi. Setidaknya, ada empat hal yang perlu diantisipasi sebelum vibe code dirilis ke production.

1. Keamanan

Risiko yang paling serius dari output vibe coding adalah keamanan. Code yang dihasilkan AI terlihat benar, tapi belum tentu aman. 

Standar keamanan seperti OWASP Top 10 masih jarang dipenuhi dari code AI, seperti temuan dari riset Veracode

2. Kualitas & Maintainability

Code yang tidak benar-benar dipahami developernya akan menjadi beban saat harus diperbaiki atau dikembangkan. 

Sehingga jika dibutuhkan pengembangan lebih lanjut, bug fixing, dan investigasi lainnya jika terjadi masalah; akan sangat memakan waktu.

3. Proses Review & Validasi

“AI memang dapat mempercepat proses menulis kode, tetapi tidak menghilangkan pekerjaan engineering. Bottleneck hanya berpindah ke tahap code review dan validasi.”

Puji Triwibowo

Engineer Manager mekari

Senior engineer yang awalnya berfokus pada desain dan problem solving, sekarang harus menghabiskan waktu untuk review dan validasi. Jika kapasitas review tidak bertambah, maka antrian pull request menjadi bottleneck baru

Analisis CodeRabbit atas 470 pull request memperkuat opini Puji. Kode hasil AI memuat sekitar 1,7 kali lebih banyak isu major dan hingga 2,74 kali lebih banyak kerentanan keamanan dibanding kode tulisan manusia. 

4. Rescue engineering

Banyak tim berhasil membangun produk sangat cepat dengan AI, lalu baru sadar fondasi kodenya tidak cukup kuat untuk dikembangkan lebih jauh, sehingga harus refactor besar-besaran atau bahkan membangun ulang. 

Kecepatan yang diberikan AI, kalau tidak diimbangi pengawasan, hanya akan menunda munculnya masalah, bukan menghilangkannya.

Utang ini punya jatuh tempo. Ketika sebuah codebase menjadi terlalu sulit dipahami, tim sering mempertimbangkan penulisan ulang sebagian atau menyeluruh, bukan karena teknologinya usang, melainkan karena kodenya tak lagi bisa dinalar. Velocity yang dulu terasa meningkat, ujungnya tetap menimbulkan utang.

Jebakan ekspektasi leaders yang berpikir vibe coding = development cepat

Salah satu jawaban yang paling berkesan (menurut saya pribadi) dari Puji Triwibowo adalah, 

“AI meningkatkan kapasitas dan kecepatan menghasilkan kode, tetapi belum tentu meningkatkan kapasitas organisasi untuk menghasilkan software berkualitas.”

Puji Triwibowo

Engineer Manager Mekari

Kita tidak bisa memungkiri bahwa AI mempercepat seluruh proses kerja, termasuk coding. Namun jika organisasi hanya mengukur jumlah fitur atau kecepatan implementasi tanpa mengukur kualitas, stabilitas produksi, kecepatan perubahan yang aman, dan biaya maintenance dalam jangka panjang; maka metriks dari hasil vibe coding bersifat vanity.

Persepsi kecepatan produksi dari penggunaan AI justru dipatahkan oleh studi dari METR pada 16 developer berpengalaman yang mengerjakan 246 task nyata di proyek open-source besar pada periode Februari-Juni 2025, menemukan sesuatu yang kontra intuitif. 

Sebelum mengerjakan tugas, developer memprediksi AI akan mempercepat mereka 24%. Setelah tugas selesai, mereka tetap merasa 20% lebih cepat. Padahal secara faktual, ternyata mereka 19% lebih lambat.

Survey lain yang dilakukan Stack Overflow juga menunjukan kontradiksi dari segi trust akan akurasi dari code yang di-generate AI.

Meskipun adopsi AI dalam proses coding tetap meningkat sekitar 84%, tetapi tingkat kepercayaan pada akurasinya jatuh dari 43% menjadi 29% dalam 18 bulan terakhir (selama 2025).

Mindset yang harus dipahami leaders ketika menggunakan vibe coding

Setelah memahami risiko dan potensi vanity metrics yang dihasilkan dari kecepatan development melalui vibe coding, Puji juga menambahkan beberapa hal yang mesti diadopsi dalam cara berpikir para leader. 

1. Tetap butuh investasi besar setelah MVP sudah dibuat

software yang sustain tetap butuh investasi resource yang besar. AI mempercepat implementasi awal, tapi code review, testing, keamanan, integrasi, observability, dan maintenance tidak ikut terpangkas dengan rasio yang sama. 

Kalau timeline dipangkas dari tiga bulan jadi satu bulan, yang biasanya terpotong bukan implementasi, melainkan tahap validasi yang justru paling menentukan

2. Jangan jadikan demo sebagai tolak ukur produktivitas 

Prototype yang jadi dalam hitungan jam menunjukkan eksplorasi lebih cepat, bukan produk siap production. 

Production engineering punya tantangan berbeda, mulai dari keandalan, keamanan, skalabilitas, integrasi, hingga operasional, sehingga kecepatan demo tidak bisa jadi acuan kecepatan membangun sistem produksi.

3. Ukur dengan metrik, bukan persepsi 

AI kerap terasa jauh lebih cepat, padahal berbagai riset menunjukkan persepsi ini sering lebih optimistis dari kenyataan. 

Produktivitas sebaiknya diukur lewat defect rate, lead time ke production, change failure rate, atau indikator kualitas lain, bukan sekadar kecepatan kode dihasilkan.

4. Skeptisisme senior engineer adalah mekanisme quality control, bukan hambatan. 

Makin berpengalaman seorang engineer, makin hati-hati ia pada kode hasil AI, karena merekalah yang menanggung akibatnya saat production bermasalah. 

Permintaan waktu tambahan untuk review bukan resistensi terhadap AI, melainkan estimasi berbasis pengalaman menghadapi risiko nyata.

5. Keunggulan kompetitif ditentukan oleh siapa yang paling baik mengelola kode, bukan siapa yang paling cepat menghasilkannya. 

Kemampuan generate kode kini mudah diakses semua orang. Yang membedakan satu tim dengan tim lain adalah spesifikasi yang jelas, governance, proses review, pengujian, dan standar keamanan yang konsisten.

Okfriansyah merangkum lima mindset di atas dengan kalimat yang mudah untuk diingat, terutama pada saat diskusi dan meeting,

“We need to think how we can adapt with this AI harness, so as not to replace each other, but synergize together. AI is not supposed to make engineers work harder, but AI is supposed to make engineers work smarter.”

Muhammad Okfriansyah

Engineer Manager Mekari

Bagaimana Mekari Officeless menjadi lapisan governance antara aplikasi vibe coding dan data enterprise

Jika vibe coding digunakan di lingkungan perusahaan, terlebih sekelas enterprise dengan berbagai data sensitif, security, dan compliance yang harus dijaga; maka perusahaan perlu “lapisan” governance.

Mekari Officeless hadir sebagai governed runtime tempat aplikasi hasil AI berlabuh sebelum menyentuh data perusahaan yang sesungguhnya. 

Sederhananya, Mekari Officeless berperan sebagai control plane yang menetapkan “siapa boleh membangun apa,” data apa yang boleh diakses, guard rails apa yang wajib lolos sebelum sebuah workflow, aplikasi, atau report dipublikasikan; melalui kombinasi policy-as-code, approval workflow, dan auditability by default. 

Okfriansyah menyebut Mekari Officeless dapat menjembatani prinsip yang ia sebut “safe-to-move-fast” agar memastikan engineer tetap bisa bereksperimen cepat, tapi seluruh output tetap berada dalam koridor compliance seperti POJK, UU PDP, dan ISO 27001; sehingga kecepatan tidak pernah mengorbankan akuntabilitas.

Puji, yang terlibat langsung dalam Mekari Officeless, menjelaskan bahwa platform ini menjawab keinginan untuk membangun aplikasi dengan cepat dengan vibe coding, namun melalui platform yang sejak awal sudah memiliki standar, governance, dan mekanisme pengamanan yang terintegrasi:

• Secure by design mengikuti standar seperti ISO 27001 sejak fondasi, bukan ditambal setelah insiden
• Sebagian besar kebutuhan bisnis diwujudkan lewat komponen dan konfigurasi yang sudah tervalidasi, sehingga mengurangi duplikasi logika bisnis
• Arsitektur yang tetap konsisten dengan integrasi berbasis OpenAPI, sehingga mengurangi risiko shadow IT
• Adopsi yang bertahap dan terukur, di mana organisasi bisa mulai dari kapabilitas yang sudah tersedia, lalu menambah kompleksitas sesuai kematangan operasionalnya; agar inovasi tetap berjalan cepat tanpa mengorbankan kualitas fondasi teknologi.

Selain sebagai governed runtime, Mekari Officeless juga membantu enterprise sebagai extended ERP untuk menutup gap operasional bisnis, melalui solution accelerators (ready-made apps, custom workflows & dashboards, hingga layanan pengembangan kustom). Didukung dengan No-Code AI app builder, Mekari Officeless menghadirkan solusi yang cepat diimplementasikan, enterprise-grade security, dan efisien secara biaya.

Enterprise yang sudah menggunakan ERP seperti SAP, Oracle, Oodo namun ingin menambah sistem dan fungsi tertentu secara custom, dapat menggunakan Mekari Officeless yang terbukti secure dan governed untuk mengakses data internal perusahaan.

Jadi, Apa yang Perlu Ditanyakan Sebelum Memangkas Timeline Engineering?

Kalau dirangkum dari seluruh percakapan ini dan data pendukungnya, benang merahnya sederhana: vibe coding tidak menghilangkan pekerjaan engineering, ia hanya menunda dan memindahkannya, dari fase development ke fase maintenance, dari junior ke senior, dari sprint sekarang ke incident sprint bulan depan.

Untuk manager, VP, dan C-level yang sedang mempertimbangkan memangkas timeline dengan anggapan “kan sekarang ada AI“, ada baiknya mempertimbangkan tiga pertanyaan ini terlebih dulu:

1. Apa yang sebenarnya dipangkas dari tiga bulan menjadi satu bulan, implementasi atau justru tahap validasinya? 
2. Metrik apa yang dipakai untuk mengukur keberhasilan, jumlah fitur atau defect rate dan change failure rate?
3. Siapa yang akan bertanggung jawab kalau kode ini bermasalah di production, apakah ada orang yang benar-benar memahaminya?

Kalau jawabannya belum jelas, kemungkinan besar tim sedang menambah “utang”, bukan mengurangi beban kerja.