Sebuah aplikasi kini dapat terlihat “selesai” hanya dalam hitungan jam. Dashboard telah terbentuk, tombol dapat digunakan, data berhasil disimpan, dan laporan sudah bisa diunduh. Dalam sesi demonstrasi, hampir tidak ada alasan bagi manajemen untuk meragukan hasilnya.

Namun, sebuah pertanyaan penting sering kali tidak sempat diajukan: siapa yang akan memahami, mengamankan, dan memelihara aplikasi tersebut ketika kebutuhan bisnis mulai berubah?

Inilah dilema yang muncul dari perkembangan vibe coding di perusahaan. Kecerdasan buatan telah memperpendek jarak antara ide dan kode secara signifikan. Tim yang sebelumnya harus menunggu jadwal developer kini dapat membuat prototipe hanya dengan menjelaskan kebutuhan menggunakan bahasa alami.

Kemampuan tersebut menawarkan efisiensi yang sulit diabaikan. Akan tetapi, kecepatan menghasilkan aplikasi tidak selalu berjalan seimbang dengan kemampuan organisasi dalam memahami apa yang sebenarnya telah dibangun.

Vibe coding tidak otomatis menjadi praktik yang buruk. Persoalan baru muncul ketika perusahaan menganggap kode yang dapat dijalankan sebagai bukti bahwa sebuah sistem sudah siap digunakan. Di titik itulah kecepatan pengembangan dapat berubah menjadi technical debt baru yang dampaknya baru terlihat setelah aplikasi terlanjur menjadi bagian penting dari operasional.

Perusahaan Sedang Membeli Kecepatan, tetapi Belum Tentu Membeli Kesiapan

Daya tarik vibe coding cukup mudah dipahami. Melalui AI coding tools, ide dapat diterjemahkan menjadi antarmuka, alur kerja, API, hingga struktur basis data dalam waktu yang jauh lebih singkat.

Bagi perusahaan, kemampuan tersebut dapat mengurangi biaya eksperimen. Tim bisnis dapat menguji konsep tanpa harus langsung menjalankan proyek pengembangan aplikasi dalam skala besar. Product owner juga dapat menunjukkan visualisasi kebutuhan kepada manajemen sebelum mengalokasikan anggaran lebih lanjut.

Dalam konteks tersebut, vibe coding memiliki nilai yang nyata. Pendekatan ini dapat digunakan untuk membuat proof of concept, prototipe antarmuka, visualisasi data, atau otomasi sederhana.

Masalahnya, hasil awal yang terlihat meyakinkan sering menciptakan persepsi bahwa sebagian besar pekerjaan telah selesai.

Padahal, terdapat perbedaan besar antara kode berhasil dibuat, fitur berhasil dijalankan, aplikasi berhasil didemonstrasikan, dan sistem siap digunakan dalam lingkungan perusahaan.

Sebuah dashboard mungkin mampu menampilkan data, tetapi belum tentu memiliki kontrol akses yang tepat. Sebuah aplikasi mungkin berhasil memproses transaksi, tetapi belum tentu dapat menangani transaksi yang berlangsung secara bersamaan. Fitur login dapat berfungsi, tetapi belum tentu memiliki pengelolaan sesi, pembatasan percobaan masuk, dan mekanisme pemulihan akun yang aman.

Keberhasilan demonstrasi hanya membuktikan bahwa aplikasi dapat bekerja dalam skenario tertentu. Hal tersebut belum membuktikan bahwa aplikasi aman, stabil, mudah dipelihara, dan mampu berkembang mengikuti kebutuhan organisasi.

Masalah Dimulai Ketika Prototipe Dipromosikan Menjadi Sistem Produksi

Banyak technical debt tidak bermula dari keputusan teknis yang sepenuhnya keliru. Technical debt justru sering lahir dari keputusan bisnis untuk tidak memberikan batas yang jelas antara eksperimen dan operasional.

Tim pada awalnya hanya membuat aplikasi sederhana untuk menguji sebuah gagasan. Karena hasilnya terlihat menjanjikan, manajemen meminta aplikasi tersebut segera digunakan oleh beberapa pegawai.

Setelah itu, data operasional mulai dimasukkan. Pengguna bertambah. Fitur persetujuan ditambahkan. Aplikasi mulai dihubungkan dengan sistem lain. Permintaan laporan baru terus muncul.

Tanpa disadari, prototipe yang awalnya dibuat untuk penggunaan sementara telah berubah menjadi aplikasi internal perusahaan.

Masalahnya, fondasi prototipe tersebut belum pernah dirancang untuk menerima beban tersebut. Struktur kode dibuat berdasarkan rangkaian prompt yang terus bertambah, bukan berdasarkan arsitektur yang mempertimbangkan perkembangan sistem dalam jangka panjang.

Perusahaan akhirnya menghadapi situasi yang cukup rumit. Aplikasi terlalu penting untuk dihentikan, tetapi terlalu rapuh untuk dikembangkan dengan aman.

Setiap perubahan memerlukan waktu lebih lama. Perbaikan pada satu bagian menimbulkan gangguan pada bagian lain. Developer baru kesulitan memahami struktur aplikasi. Dokumentasi tidak tersedia, sedangkan percakapan yang digunakan untuk menghasilkan kode mungkin sudah tidak tersimpan.

Pada tahap ini, penghematan waktu pada awal proyek mulai dibayar dengan biaya pemeliharaan yang lebih besar.

Kecepatan Menulis Kode Tidak Sama dengan Kecepatan Memahami Sistem

Salah satu konsekuensi utama AI-assisted development adalah meningkatnya volume kode yang dapat dihasilkan dalam waktu singkat.

Namun, kemampuan manusia untuk memeriksa kode tidak meningkat dalam kecepatan yang sama.

AI dapat membuat beberapa modul, menambahkan library, mengubah struktur basis data, dan menulis integrasi API hanya dalam beberapa menit. Sementara itu, developer tetap perlu memahami hubungan antarbagian, memeriksa logika bisnis, menguji kondisi tidak normal, serta memastikan bahwa perubahan tersebut tidak menimbulkan risiko baru.

Di sinilah muncul review bottleneck.

Semakin cepat kode dihasilkan, semakin besar pula pekerjaan yang harus diverifikasi. Apabila perusahaan mengukur produktivitas hanya berdasarkan jumlah fitur atau kecepatan penyelesaian, proses peninjauan dapat dianggap sebagai hambatan.

Akibatnya, kode hasil AI mulai diterima tanpa pemeriksaan mendalam. Developer hanya memastikan aplikasi dapat dijalankan, sementara kualitas arsitektur, keamanan, dan maintainability tidak memperoleh perhatian yang cukup.

Penelitian terhadap ratusan ribu commit yang teridentifikasi sebagai hasil AI menunjukkan bahwa lebih dari 15 persen commit dari setiap AI coding assistant yang diteliti memperkenalkan setidaknya satu masalah. Sebagian masalah tersebut juga tetap bertahan dalam repositori hingga versi terbaru.

Temuan ini tidak berarti bahwa kode buatan AI selalu buruk. Namun, data tersebut memperlihatkan bahwa kecepatan menghasilkan kode dapat menciptakan biaya pemeliharaan apabila tidak disertai quality assurance yang memadai.

Technical Debt Baru Tidak Selalu Berbentuk Kode yang Buruk

Technical debt sering dipahami sebagai kode yang tidak rapi atau penggunaan teknologi yang sudah usang. Dalam lingkungan vibe coding, bentuknya jauh lebih luas.

Sebuah aplikasi bahkan dapat memiliki kode yang terlihat cukup bersih, tetapi tetap menyimpan utang teknis karena tidak ada orang yang memahami alasan di balik keputusan pembuatannya.

Utang arsitektur

Vibe coding cenderung berlangsung secara bertahap berdasarkan kebutuhan saat itu. Pengguna meminta sebuah fitur, AI menghasilkan kode, lalu fitur berikutnya ditambahkan melalui prompt baru.

Tanpa arsitektur yang jelas, setiap fitur dapat dibangun menggunakan pola yang berbeda. Logika autentikasi mungkin diterapkan berulang kali. Pengelolaan error tidak konsisten. Komunikasi antar modul terbentuk secara spontan.

Aplikasi tetap dapat berjalan, tetapi perubahan kecil mulai memengaruhi banyak bagian yang tidak berkaitan langsung.

Inilah architectural debt. Sistem terlihat berfungsi dari luar, tetapi sulit dikembangkan karena struktur internalnya tidak memiliki batas yang jelas.

Utang pengetahuan

Kode bukan sekadar kumpulan instruksi. Di dalamnya terdapat keputusan mengenai proses bisnis, struktur data, pembagian kewenangan, dan cara sistem merespons kegagalan.

Ketika sebagian besar kode dihasilkan melalui percakapan dengan AI, konteks keputusan tersebut dapat hilang. Developer mungkin mengetahui apa yang dilakukan suatu fungsi, tetapi tidak memahami mengapa fungsi itu dibangun dengan cara tertentu.

Apabila tidak tersedia dokumentasi, keputusan penting hanya tersimpan di dalam prompt atau bahkan tidak pernah dicatat.

Ketika anggota tim berpindah, perusahaan tidak hanya kehilangan developer. Perusahaan juga kehilangan konteks yang diperlukan untuk mengembangkan sistem.

Utang pengujian

AI coding tools umumnya sangat efektif dalam menghasilkan happy path, yaitu alur ketika seluruh input benar dan sistem bekerja sesuai kondisi yang diharapkan.

Akan tetapi, aplikasi perusahaan tidak hanya beroperasi dalam kondisi ideal.

Pengguna dapat memasukkan data yang tidak lengkap. Koneksi dapat terputus di tengah transaksi. Dua pengguna dapat mengubah data yang sama pada waktu bersamaan. Integrasi pihak ketiga dapat memberikan respons yang berbeda dari dokumentasinya.

Tanpa pengujian unit, integrasi, regresi, dan skenario kegagalan, aplikasi hanya terlihat stabil karena belum menghadapi kondisi nyata.

Utang keamanan

Security debt muncul ketika kontrol keamanan ditambahkan setelah aplikasi selesai.

Autentikasi dibuat sekadar agar pengguna dapat masuk. Otorisasi diterapkan hanya dengan menyembunyikan tombol pada antarmuka. Kredensial disimpan langsung di source code. Dependency digunakan tanpa pemeriksaan kerentanan.

Penelitian terhadap ribuan file yang secara eksplisit dikaitkan dengan beberapa AI coding tools menemukan ribuan kelemahan yang dapat dipetakan ke kategori Common Weakness Enumeration. Pola kerentanannya juga berbeda berdasarkan bahasa pemrograman dan alat yang digunakan.

Studi lain terhadap ratusan ribu sampel kode menunjukkan bahwa kode buatan AI cenderung memiliki karakteristik masalah tersendiri, termasuk konstruksi yang tidak digunakan, konfigurasi debugging yang tertinggal, dan kerentanan berisiko tinggi.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Aplikasi dapat terlihat normal dalam penggunaan sehari-hari, tetapi pengujian lebih lanjut memperlihatkan bahwa otorisasi dapat dilewati, API mengekspos data secara berlebihan, atau input tertentu dapat mengubah perilaku sistem.

Utang dokumentasi

Dokumentasi hampir selalu tertinggal ketika kode dihasilkan dengan cepat.

Diagram arsitektur tidak diperbarui. API specification tidak mencerminkan implementasi terbaru. Penjelasan konfigurasi hanya terdapat dalam percakapan tim. Proses deployment bergantung pada satu orang.

Ketika dokumentasi tidak diperlakukan sebagai bagian dari hasil pekerjaan, perusahaan memperoleh aplikasi tanpa pengetahuan yang diperlukan untuk mengoperasikannya.

Utang tata kelola

Penggunaan AI coding di perusahaan juga dapat melahirkan governance debt.

Perusahaan mungkin tidak mengetahui data apa yang dimasukkan ke AI, tool apa yang digunakan, siapa yang mengizinkan penggunaannya, serta apakah kode yang dihasilkan telah melalui pemeriksaan lisensi dan keamanan.

Risiko menjadi lebih besar apabila pegawai non teknis membuat aplikasi sendiri menggunakan layanan eksternal, kemudian menggunakannya untuk mengolah informasi perusahaan.

Fenomena tersebut dapat menciptakan bentuk baru shadow IT. Sistem digunakan untuk membantu pekerjaan, tetapi tidak terdaftar, tidak diawasi, dan tidak masuk dalam proses pengelolaan keamanan organisasi.

AI Tidak Memahami Proses Bisnis Hanya karena Mampu Menulis Kodenya

Salah satu kesalahpahaman dalam vibe coding adalah anggapan bahwa kebutuhan bisnis dapat sepenuhnya diterjemahkan melalui satu atau beberapa prompt.

AI memang mampu menghasilkan kode berdasarkan deskripsi. Namun, deskripsi fitur tidak selalu mewakili keseluruhan proses bisnis.

Sebagai contoh, sebuah perusahaan meminta AI membuat fitur persetujuan biaya. Sistem dapat dengan cepat menghasilkan formulir pengajuan, tombol setuju, tombol tolak, dan notifikasi.

Fitur tersebut terlihat lengkap. Namun, masih ada banyak pertanyaan yang belum terjawab.

Siapa yang dapat menyetujui pengeluaran berdasarkan nilai transaksi? Apakah pengaju diperbolehkan menjadi pemberi persetujuan? Bagaimana proses berjalan ketika pejabat terkait sedang cuti? Apakah persetujuan dapat dibatalkan? Siapa yang boleh mengubah data setelah disetujui? Apakah setiap perubahan harus disimpan dalam audit trail?

AI dapat menghasilkan alur yang tampak masuk akal secara teknis, tetapi belum tentu benar secara organisasi.

Proses bisnis perusahaan sering mengandung pengecualian, pembagian kewenangan, kebutuhan audit, aturan retensi, dan konsekuensi hukum. Seluruh konteks tersebut tidak muncul secara otomatis hanya karena sebuah fitur dapat dibuat.

Karena itu, requirement engineering tetap dibutuhkan. Perusahaan harus memetakan proses, pelaku, data, risiko, serta kondisi kegagalan sebelum meminta AI menerjemahkannya menjadi kode.

Keamanan Tidak Dapat Ditambahkan dengan Perintah “Buat Lebih Aman”

Sebagian pengguna mencoba mengatasi risiko dengan menambahkan instruksi keamanan ke dalam prompt. Misalnya, meminta AI membuat autentikasi yang aman, menambahkan enkripsi, atau menghilangkan seluruh vulnerability.

Instruksi tersebut terdengar tepat, tetapi tidak cukup.

Keamanan aplikasi bukan atribut tunggal yang dapat ditambahkan ke source code. Keamanan bergantung pada konteks sistem.

Developer perlu memahami jenis data yang diproses, siapa yang dapat mengaksesnya, bagaimana aplikasi dioperasikan, dimana aplikasi ditempatkan, sistem apa yang terhubung, dan dampak yang muncul apabila kontrol tertentu gagal.

Permintaan “tambahkan autentikasi” tidak menjelaskan kebutuhan multi-factor authentication, pengelolaan sesi, kebijakan kata sandi, pembatasan percobaan masuk, atau integrasi identity provider.

Permintaan “gunakan enkripsi” juga belum menjelaskan data apa yang perlu dienkripsi, kapan proses enkripsi dilakukan, serta bagaimana kunci disimpan dan dirotasi.

Kode hasil AI seharusnya diperlakukan sebagai kontribusi yang belum dipercaya sampai melalui pemeriksaan. Prinsip ini bukan bentuk penolakan terhadap teknologi, melainkan penerapan pengendalian yang sama seperti ketika perusahaan menerima kode dari sumber eksternal.

Tidak Semua Aplikasi Memiliki Tingkat Risiko yang Sama

Perusahaan tidak perlu melarang seluruh penggunaan vibe coding. Pendekatan yang lebih realistis adalah menentukan batas berdasarkan dampak kegagalan.

Vibe coding dapat digunakan secara lebih fleksibel untuk membuat mockup, proof of concept, visualisasi data non-sensitif, prototipe antarmuka, atau alat bantu sementara yang tidak terhubung dengan sistem utama.

Pengawasan lebih ketat diperlukan untuk aplikasi operasional internal, workflow persetujuan, dashboard manajemen, sistem inventaris, serta integrasi API.

Sementara itu, engineering formal harus menjadi persyaratan utama untuk sistem pembayaran, pengelolaan identitas, data pribadi, infrastruktur kritis, sistem kesehatan, aplikasi pemerintahan, dan layanan yang memiliki konsekuensi hukum atau finansial.

Batas penggunaan tidak seharusnya ditentukan hanya berdasarkan seberapa mudah sebuah fitur dibuat.

Pertimbangan utamanya adalah dampak yang muncul apabila aplikasi gagal, disalahgunakan, atau mengekspos data.

Sebuah formulir sederhana dapat menjadi sistem berisiko tinggi apabila digunakan untuk mengumpulkan data pribadi. Sebaliknya, aplikasi yang secara teknis terlihat kompleks dapat memiliki risiko lebih rendah apabila hanya digunakan untuk eksperimen menggunakan data tiruan.

Dari Vibe Coding Menuju AI-Assisted Engineering

Perusahaan membutuhkan perubahan cara pandang. AI seharusnya diposisikan sebagai alat bantu engineering, bukan pengganti seluruh disiplin software development.

Pendekatan ini dapat dimulai dengan menetapkan akuntabilitas manusia. Setiap kode yang dihasilkan AI harus memiliki penanggung jawab yang memahami fungsi, risiko, dan konsekuensinya.

Prompt juga tidak boleh menggantikan requirement. Sebelum pengembangan dimulai, tim tetap perlu menentukan tujuan bisnis, acceptance criteria, model data, hak akses, kebutuhan integrasi, serta kondisi kegagalan.

Perusahaan kemudian perlu membuat architecture guardrails. Ketentuan tersebut dapat mencakup teknologi yang boleh digunakan, struktur proyek, pola integrasi, standar API, mekanisme autentikasi, pengelolaan error, dan logging.

Setiap perubahan harus melalui code review. Kode hasil AI tidak seharusnya langsung digabungkan ke production branch hanya karena dapat dijalankan.

Automated testing juga perlu menjadi bagian dari proses. Unit testing, integration testing, regression testing, dependency scanning, dan pengujian keamanan membantu memastikan bahwa kecepatan pengembangan tidak mengorbankan kualitas.

Seluruhnya perlu ditempatkan dalam Secure SDLC. Keamanan harus masuk sejak tahap perencanaan, desain, development, testing, deployment, hingga maintenance.

Dengan pendekatan tersebut, perusahaan tetap memperoleh manfaat kecepatan dari AI tanpa menyerahkan kendali atas kualitas sistem.

Checklist Sebelum Aplikasi Hasil Vibe Coding Masuk Production

Sebelum aplikasi digunakan untuk memproses data dan mendukung operasional, perusahaan perlu memastikan beberapa hal berikut.

Konteks bisnis

• Kebutuhan dan proses bisnis telah divalidasi.
• Pengecualian proses sudah didokumentasikan.
• Pemilik sistem dan penanggung jawab teknis telah ditetapkan.
• Dampak kegagalan aplikasi telah dianalisis.

Arsitektur dan kualitas

• Struktur aplikasi telah ditinjau oleh engineer.
• Dependency telah diinventarisasi dan diperiksa.
• Kode telah melalui peer review.
• Unit testing dan integration testing tersedia.
• Dokumentasi teknis dan proses deployment telah disusun.
• Aplikasi dapat diambil alih oleh developer lain.

Keamanan

• Autentikasi dan otorisasi telah diuji.
• Kredensial tidak disimpan di dalam source code.
• Data sensitif dilindungi saat disimpan dan dikirimkan.
• Dependency scanning telah dilakukan.
• SAST dan DAST telah dijalankan sesuai kebutuhan.
• Aplikasi telah melalui penetration testing berdasarkan tingkat risikonya.

Operasional

• Logging dan monitoring tersedia.
• Backup dan pemulihan telah diuji.
• Terdapat mekanisme patching.
• Tim memahami prosedur penanganan insiden.
• Kapasitas dan performa aplikasi telah diuji.

Tata kelola

• Penggunaan AI coding tool telah memperoleh persetujuan.
• Informasi sensitif tidak dikirimkan ke platform yang tidak disetujui.
• Source code tersimpan dalam repositori milik perusahaan.
• Kepemilikan dan lisensi kode telah diperiksa.
• Riwayat perubahan dapat ditelusuri.

Checklist tersebut bukan sekadar prosedur administratif. Setiap poin membantu memastikan bahwa aplikasi tidak hanya selesai dibuat, tetapi juga dapat dipercaya.

Pertanyaan yang Seharusnya Diajukan Manajemen

Dalam banyak proyek teknologi, pertanyaan pertama yang muncul adalah seberapa cepat aplikasi dapat diselesaikan.

Pada era vibe coding, pertanyaan tersebut perlu dilengkapi dengan pertanyaan yang lebih strategis.

Siapa yang memahami keseluruhan source code? Siapa yang bertanggung jawab ketika kode AI gagal? Apakah aplikasi dapat dikembangkan oleh tim lain? Berapa biaya pemeliharaannya setelah satu atau dua tahun? Apakah data perusahaan pernah dikirim ke platform AI eksternal? Bagaimana sistem akan dipantau setelah deployment?

Manajemen juga perlu menanyakan apakah prototipe harus dibangun ulang sebelum digunakan secara luas.

Membangun ulang bukan selalu tanda kegagalan. Dalam banyak kasus, prototipe memang dibuat untuk membuktikan ide, bukan menjadi fondasi akhir.

Keputusan yang berbahaya justru muncul ketika perusahaan mempertahankan prototipe karena merasa sudah mengeluarkan waktu dan biaya, meskipun fondasinya tidak layak untuk kebutuhan jangka panjang.

Kecepatan Bukan Masalah, Ketidaksiapanlah yang Mahal

Vibe coding dapat memperpendek jarak antara gagasan dan prototipe. Teknologi ini membuka peluang bagi perusahaan untuk bereksperimen, memvalidasi kebutuhan, dan mempercepat inovasi.

Namun, perusahaan tidak bergantung pada prototipe. Perusahaan bergantung pada sistem yang harus tetap berfungsi ketika pengguna bertambah, kebutuhan berubah, integrasi berkembang, dan ancaman keamanan muncul.

AI dapat mempercepat penulisan kode, tetapi tidak menghapus kebutuhan terhadap arsitektur, code review, testing, dokumentasi, dan keamanan. Technical debt tidak muncul semata-mata karena perusahaan menggunakan AI. Technical debt muncul ketika kecepatan menggantikan disiplin engineering.

Pertanyaan terpenting bukan lagi apakah perusahaan boleh menggunakan vibe coding. Pertanyaan yang lebih relevan adalah apakah perusahaan memiliki tata kelola yang cukup kuat untuk menghentikan sebuah eksperimen sebelum eksperimen tersebut diam-diam berubah menjadi infrastruktur bisnis.

Bangun Aplikasi Cepat Tanpa Mengorbankan Keamanan

Pengembangan aplikasi dengan bantuan AI tetap membutuhkan fondasi arsitektur, pengujian, dan keamanan yang memadai. Perusahaan perlu memastikan bahwa sistem tidak hanya dapat digunakan hari ini, tetapi juga aman dan dapat dipelihara dalam jangka panjang.

Fourtrezz merupakan perusahaan keamanan siber dan IT development yang menyediakan layanan penetration testing, vulnerability assessment, pelatihan keamanan siber, serta pengembangan aplikasi dan sistem sesuai kebutuhan perusahaan.

Melalui pendekatan yang menggabungkan pengembangan aplikasi dengan perspektif cybersecurity, Fourtrezz membantu perusahaan membangun, menilai, dan mengamankan sistem sejak tahap perencanaan hingga sebelum digunakan di lingkungan produksi.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]