Aplikasinya jalan, demo-nya mulus, kelihatan aman. Sampai suatu hari ada yang menemukan API key perusahaan nongkrong di source code publik.
Kalimat di atas bukan skenario, Escape.tech mengaudit 5.600 aplikasi hasil vibe coding yang sudah live di internet, dan menemukan lebih dari 2.000 kerentanan kritis, 400 kredensial atau API key yang bocor, serta 175 kasus data pribadi yang terekspos ke publik, mulai dari rekam medis sampai data rekening bank.
Selama ini, risiko vibe coding di lingkungan enterprise sering dibahas sebagai proyeksi, sesuatu yang mungkin terjadi kalau perusahaan tidak hati-hati. Data terbaru menunjukkan proyeksi itu sudah jadi kejadian nyata, bukan lagi skenario buruk semata.
Artikel ini disusun dari wawancara tertulis dengan dua engineer di balik Mekari Officeless, Ridha Ramadhansyah (Engineer Manager Mekari) dan Dody Alfian (Head of Information Security, VP Infosec and Compliance Mekari), dipadukan dengan riset dan data dari sumber-sumber keamanan siber serta software engineering terpercaya.
- 5.600 aplikasi vibe coding yang sudah live diaudit: ditemukan 2.000+ kerentanan kritis, 400+ kredensial bocor, dan 175 kasus data pribadi terekspos.
- Kode AI 61% berfungsi dengan benar, tapi hanya 10,5% yang juga lolos review keamanan.
- 35% tim enterprise sudah memakai vibe coding, sementara 61% IT leader menyebut AI tanpa governance sebagai risiko keamanan utama mereka.
Penyebab Vibe Coding Berisiko dalam Pengembangan Software
Sebelum bicara skala enterprise, penting dipahami dulu akar risikonya di level praktik sehari-hari. Menurut Ridha Ramadhansyah, ada tiga hal mendasar yang membuat vibe coding rawan bermasalah.
Developer sering tidak benar-benar memahami kode yang dihasilkan AI, sehingga pengembangan fitur lanjutan, debugging, dan pemeliharaan menjadi lebih sulit serta menyimpan risiko bug atau celah keamanan yang tidak disadari.
Di saat yang sama, penggunaan token menjadi kurang efisien karena developer cenderung mengirim prompt singkat secara berulang ketika hasil awal belum sesuai harapan. Ditambah, kode yang dihasilkan AI berpotensi memiliki celah keamanan yang bisa dimanfaatkan untuk peretasan maupun penyalahgunaan sistem.
Dody Alfian melihat akar masalahnya dari sudut yang sedikit berbeda.
“Risiko terbesar bukan terletak pada AI yang menulis kode, melainkan pada perubahan skala dan kecepatan pengembangan yang dihasilkannya.”
Hari ini organisasi bisa menghasilkan software jauh lebih cepat daripada kemampuan mereka melakukan review, pengujian, dokumentasi, dan governance. Ketika kapasitas engineering tidak berkembang secepat kemampuan menghasilkan kode, risiko kualitas, keamanan, dan maintainability ikut naik.
Karena itu, menurut Dody, output AI tetap harus divalidasi, diintegrasikan, dan dikelola melalui proses software engineering yang sama seperti kode buatan manusia.
Kode yang Jalan Bukan Berarti Aman, Menurut Riset
Data eksternal mengkonfirmasi kekhawatiran ini secara telak. Riset SusVibes dari Carnegie Mellon University, yang menguji coding agent pada 200 tugas nyata dari proyek open-source, mendapati bahwa 61% kode yang dihasilkan AI berfungsi dengan benar, tapi hanya 10,5% yang juga lolos review keamanan.
Artinya, dari setiap 10 fitur yang “jalan”, sekitar 9 di antaranya masih membawa celah yang bisa dieksploitasi. (Endor Labs, mengutip riset SusVibes Carnegie Mellon University)
Ini persis yang dimaksud Ridha soal ilusi aman: kode yang lolos uji fungsional bukan berarti sudah aman untuk dipakai di production.
Vibe Coding Makin Berisiko dalam Skala Enterprise
Ridha menjelaskan bahwa di skala enterprise, empat hal yang tadinya sekadar mengganggu berubah jadi masalah serius.
- Prediktabilitas rendah, requirement yang tidak detail, hal yang lumrah dalam praktik vibe coding, membuat proses pengembangan sering mengalami perubahan berulang atau back-to-back adjustment. Padahal perusahaan enterprise sangat mengutamakan kepastian timeline dan delivery.
- Risiko kualitas ikut naik karena perubahan berulang tanpa pengujian otomatis meningkatkan biaya dan waktu regresi testing, yang berpotensi mengganggu stabilitas aplikasi dan proses bisnis.
- Biaya token AI sulit diprediksi, sebab developer perlu melakukan banyak prompt untuk menyesuaikan hasil, sehingga biaya terlihat rendah di awal tapi total penggunaan token dan biaya pengembangan sulit diperkirakan, padahal efisiensi biaya jadi perhatian utama perusahaan enterprise.
- Risiko keamanan bisa berdampak langsung pada kerugian finansial dan reputasi, dua hal yang paling dihindari perusahaan skala besar.
Dody menambahkan bahwa AI memang mampu mempercepat pengembangan dan menghasilkan kode yang secara teknis baik, tapi kualitas sebuah aplikasi tidak ditentukan oleh cara kode tersebut dibuat, melainkan oleh proses engineering yang memastikan kode itu aman, andal, dan siap dipakai di lingkungan produksi.
Di perusahaan enterprise, tantangannya jauh lebih kompleks karena aplikasi harus memenuhi kebutuhan bisnis, terintegrasi dengan banyak sistem, melindungi data sensitif, mematuhi regulasi, serta bisa dipelihara oleh banyak tim dalam jangka panjang.
Dody merangkumnya dengan sederhana.
AI dapat mempercepat setiap tahapan pengembangan, tetapi tidak menggantikan disiplin engineering maupun tata kelola yang diperlukan untuk menghasilkan perangkat lunak yang aman, andal, dan memenuhi kebutuhan bisnis maupun regulasi.
Data lapangan menunjukkan kesenjangan ini nyata. Survei JetBrains yang dikutip DigitalApplied mencatat sekitar 35% tim enterprise sudah memakai vibe coding untuk menghasilkan blok kode besar dari prompt bahasa natural pada awal 2026.
Di sisi lain, Keyhole Software mencatat 61% IT leader menyebut penggunaan AI tanpa governance sebagai hambatan keamanan utama mereka. (Keyhole Software; DigitalApplied) Adopsi berjalan lebih cepat daripada kesiapan tata kelola untuk mengimbanginya.
Risiko dan Potensi Masalah Vibe Coding yang Paling Sering Muncul
Dody memetakan empat area yang paling perlu diwaspadai, ketika perusahaan ingin merilis aplikasi hasil vibe coding ke production:
1. Kualitas perangkat lunak
AI dapat mempercepat penulisan kode, tapi tidak menghilangkan kebutuhan akan desain yang baik, validasi, maupun pengujian. Kerentanan seperti injection, broken access control, atau kesalahan business logic tetap bisa muncul apabila proses engineering tidak dijalankan dengan baik.
2. AI Slop
AI kerap merekomendasikan dependency yang usang, bahkan yang sebenarnya tidak pernah ada. Praktik ini dikenal sebagai “slopsquatting” karena halusinasi AI soal nama package cenderung dapat ditebak dan konsisten, penyerang bisa mendaftarkan nama-nama itu lebih dulu di package repository publik seperti npm dan PyPI. (BeyondScale) Karena itu, organisasi tetap perlu menerapkan dependency governance dan software composition analysis.
3. Tata kelola data
Penggunaan AI di luar platform resmi perusahaan berpotensi menyebabkan source code, credential, atau informasi sensitif diproses oleh layanan yang tidak berada dalam kendali organisasi, semacam versi baru dari shadow IT. Ini bukan risiko teoretis: laporan GitGuardian yang dikutip IBM mencatat commit yang dibantu AI coding assistant membocorkan kredensial lebih dari dua kali lipat dibanding commit manual. Salah satu kasus nyata, kunci akses AWS milik Football Australia, terekspos di source code selama lebih dari 700 hari sebelum akhirnya ditemukan. (IBM)
4. Maintainability
AI meningkatkan kecepatan menghasilkan kode secara signifikan, tapi kemampuan organisasi melakukan review, dokumentasi, pengujian, dan pemeliharaan tidak selalu ikut naik dengan laju yang sama. Kalau tidak dikelola dengan baik, kesenjangan ini akan mempercepat akumulasi technical debt dalam jangka panjang.
Menurut Dody, dari keempat area itu, satu benang merahnya sama.
Perusahaan perlu menyediakan AI platform kelas enterprise dengan perlindungan data dan tata kelola yang jelas.
Risiko Keamanan yang Paling Jarang Disadari Perusahaan Enterprise
Selain empat area di atas, terdapat beberapa risiko keamanan yang jarang disadari perusahaan, hanya karena aplikasi bisa dipakai dengan mulus dan
Ilusi Aplikasi yang Berjalan = Aman
Ridha menyoroti satu pola yang menurutnya paling berbahaya justru karena tidak terlihat: ilusi bahwa aplikasi sudah aman hanya karena berjalan dengan baik dan lulus pengujian dasar. Celah keamanan dan bug yang tidak terdeteksi di balik ilusi itu bisa dimanfaatkan untuk peretasan maupun fraud, dan biasanya baru ketahuan setelah insiden terjadi, bukan sebelum.
Pola ini persis yang ditemukan di lapangan. Salah satu insiden yang paling banyak dibicarakan sepanjang 2025 adalah aplikasi Tea, yang sebagian besar dibangun dengan kode hasil AI dan mengekspos pesan pribadi penggunanya ke pengguna lain karena logika broken access control yang tidak pernah melalui review keamanan.
Insiden serupa terjadi pada Moltbook, jejaring sosial berbasis AI agent, yang membocorkan sekitar 1,5 juta token autentikasi API, lebih dari 35.000 alamat email, dan 4.060 pesan pribadi. (Getautonoma)
Ownership dan Risiko Keamanan dari Evolusi Agentic Coding
Dody menyoroti dua risiko lain yang menurutnya masih jarang dibahas secara terbuka, karena tidak muncul secara langsung di dashboard security manapun.
Erosion of code ownership
Ketika tim secara bertahap kehilangan pemahaman mendalam terhadap codebase yang mereka miliki karena terlalu bergantung pada AI. Dalam kondisi normal, hal ini tidak langsung terlihat. Tapi begitu terjadi bug, insiden keamanan, atau gangguan produksi, kemampuan organisasi merespons sangat bergantung pada seberapa baik engineer memahami sistem yang mereka bangun sendiri.
Ini merupakan risiko organisasional yang tidak akan muncul di dashboard keamanan mana pun, karena yang terdampak bukan aplikasinya, melainkan kemampuan organisasi untuk memahami, memelihara, dan memulihkan sistem ketika terjadi masalah.
Evolusi dari vibe coding menuju agentic coding
Ketika AI agent mulai diberi akses ke repository, pipeline, cloud environment, atau sistem internal lain, AI itu pada dasarnya menjadi identitas digital baru yang memiliki hak akses untuk bertindak atas nama organisasi, sekaligus memperluas attack surface perusahaan.
Prinsip keamanan yang sama seperti least privilege, identitas terpisah, kredensial dengan cakupan terbatas, audit logging, dan environment terisolasi perlu berlaku juga untuk AI agent ini. Menurut Dody, tantangan terbesarnya bukan membangun teknologi baru, melainkan memperluas tata kelola IAM yang sudah ada agar mencakup AI sebagai bagian dari identitas yang perlu dikelola dan diawasi.
Bagaimana Perusahaan Enterprise Seharusnya Menggunakan Output Vibe Coding Sebelum Menyentuh Data Internal?
Ridha punya beberapa langkah konkret. Meskipun AI sudah menghasilkan working software, perusahaan tetap harus melakukan pengujian end-to-end secara menyeluruh, termasuk security testing, sebelum aplikasi dipakai di production.
Kebijakan AI tools yang dipakai juga perlu ditinjau, pastikan ada ketentuan bahwa data dan kode yang dipakai selama proses vibe coding tidak dimanfaatkan untuk pelatihan model atau tujuan lain tanpa izin.
Prinsip least privilege wajib diterapkan saat memberi akses ke AI, hindari memberi akses ke seluruh direktori komputer developer, dan untuk akses ke database internal, gunakan akun dengan hak akses terbatas serta hindari koneksi langsung ke database production.
Dody merangkum semua ini dengan satu analogi sederhana.
Perlakukan kode AI seperti kode dari engineer baru yang berbakat tapi belum paham konteks perusahaan.
Berbakat, menurut Dody, artinya outputnya layak dipakai. Belum paham konteks artinya wajib melewati pipeline yang sama dengan kode buatan manusia, mulai dari review oleh engineer yang menguasai domainnya, pemindaian keamanan otomatis, sampai pengujian sebelum rilis.
Sebelum aplikasi hasil vibe coding menyentuh data internal, ada prasyarat minimum yang perlu dipenuhi: berjalan dengan dedicated service account berprinsip least privilege, diuji di environment non-production dengan data sintetis, hanya mengakses data yang benar-benar diperlukan, dan dilengkapi audit logging yang memadai. Kalau aplikasi mulai memproses data pribadi, kewajiban dalam UU PDP juga otomatis berlaku.
Peran Mekari Officeless dalam Vibe Coding App
Membangun aplikasi lewat vibe coding, artinya tim harus menanggung sendiri semua risiko yang sudah dibahas di atas: kode yang tidak melalui review keamanan, dependency yang tidak divalidasi, akses data yang tidak dibatasi, dan tidak ada audit trail kalau suatu hari terjadi insiden.
Dengan menggunakan Mekari Officeless, aplikasi custom untuk proses bisnis spesifik, tetap bisa dipenuhi dengan gesit, di atas fondasi yang sudah memiliki role-based access control, pemisahan environment antara development dan production, audit logging otomatis untuk setiap perubahan, serta komponen dan integrasi yang sudah divalidasi lebih dulu sehingga risiko dependency yang usang atau tidak sah jauh lebih kecil.
Kepatuhan terhadap ISO 27001, UU PDP, dan POJK juga jadi bagian bawaan platform, bukan sesuatu yang harus dipikirkan belakangan setelah aplikasi terlanjur dipakai.
Mekari Officeless juga dapat digunakan sebagai extended ERP, pelengkap dari sistem inti seperti SAP, Oracle, atau ERP lain yang sudah lebih dulu dipakai perusahaan enterprise.
Sistem ERP besar biasanya kuat untuk proses inti seperti finance, procurement, atau HR, tapi kebutuhan kustomisasi lanjutan, dashboard khusus, workflow approval yang unik untuk satu divisi, atau integrasi dengan sistem lain, sering kali lambat untuk dipenuhi lewat jalur resmi vendor ERP tersebut.
Jadi, Apa yang Perlu Dipastikan Sebelum Vibe Coding App Menyentuh Data Perusahaan?
Kalau dirangkum dari seluruh percakapan ini, benang merahnya jelas: risiko vibe coding di skala enterprise bukan lagi hipotesis; insiden seperti kredensial bocor, data pribadi tersebar sudah cukup terbukti dari beberapa riset di atas.
Bagi manager, VP, dan C-level yang timnya sedang atau berencana memakai vibe coding, ada tiga pertanyaan yang sebaiknya dijawab lebih dulu sebelum aplikasi itu menyentuh data perusahaan:
- Apakah output vibe coding ini sudah melalui pengujian end-to-end dan security testing yang setara dengan kode buatan manusia?
- Siapa yang benar-benar memahami codebase ini dan bisa bertanggung jawab ketika terjadi insiden atau bug di production?
- Data apa saja yang boleh diakses aplikasi ini, dan lewat kontrol apa akses tersebut dibatasi?
Kalau jawabannya belum jelas, kemungkinan besar aplikasi itu belum siap menyentuh data perusahaan, secepat apapun proses development-nya.
