Kita Harus Berhenti Menyebut Semua Hal sebagai Vibe Coding

Saya kembali ke pemrograman setelah jeda panjang, dan Lovable adalah tempat saya memulainya lagi. Aplikasinya terlihat bagus, berfungsi pada pandangan pertama, dan selesai dalam beberapa jam. Pada awalnya, hal itu terasa luar biasa. Namun itu tidak cukup lagi ketika saya ingin tahu apa yang dilakukan kode – dan mengapa. Saat itulah pendekatan saya mulai berubah.

Perbedaannya bukan tentang alat, atau seberapa banyak kode yang ditulis AI untuk Anda. Ini tentang kontrak yang Anda terima dengan output Anda: apakah Anda dapat menjelaskan apa yang baru saja Anda dirilis ke dunia, atau tidak.

Vibe coding, dalam arti aslinya, berarti menerima perangkat lunak yang dihasilkan AI tanpa memeriksa atau memahami apa yang berada di bawahnya secara tepat. Pengembangan yang dibantu AI berbeda. Model tersebut masih dapat menulis sebagian besar kode, tetapi orang yang membangun sistem tetap bertanggung jawab untuk memahami perilakunya, menguji asumsi-asumsinya, dan memutuskan apakah sudah siap untuk dirilis.

Untuk percobaan sekali pakai yang tidak pernah keluar dari mesin Anda, perbedaan ini mungkin memiliki sedikit konsekuensi. Begitu perangkat lunak dideploy, digunakan orang lain, atau terhubung ke data nyata, hal ini menjadi sangat penting.

Bagaimana “Vibe Coding” Kehilangan Maknanya

Istilah “vibe coding” diciptakan pada Februari 2025 oleh Andrej Karpathy, salah satu pendiri OpenAI. Contohnya sengaja dibuat santai: sebuah “proyek akhir pekan sekali pakai” yang dibangun dengan mengeklik “Terima Semua” secara otomatis, mengabaikan perbedaan kode, dan membiarkan kode berkembang melampaui pemahamannya.

Beberapa minggu kemudian, pengembang dan pembuat alat Simon Willison melihat istilah itu digunakan dengan arti yang sangat berbeda: sebagai pengganti untuk semua pemrograman yang dibantu AI, yang menurutnya mengaburkan makna istilah dan memberi kesan keliru tentang hasil yang dapat dicapai oleh pengembangan berbantuan AI yang bertanggung jawab.

Hal yang menarik adalah Karpathy akhirnya setuju. Setahun kemudian, ia memperkenalkan istilah yang berbeda untuk pekerjaan yang lebih disiplin dengan agen pemrograman. Ia menggambarkan “rekayasa agentik” sebagai alur kerja tempat pengembang mengarahkan dan mengawasi agen, bukan sekadar menerima hasilnya. Perbedaan ini penting: pengembangan profesional berbantuan AI memerlukan perencanaan, pemeriksaan, dan pertanggungjawaban yang tidak dimiliki vibe coding kasual.

Garisnya Adalah Tanggung Jawab

Aturan Willison sederhana dan dapat menjadi ujian bagi siapa pun: jangan commit kode yang tidak dapat Anda jelaskan kepada orang lain. Itu bukan berarti membaca setiap baris; ketika agen menghasilkan ratusan baris sekaligus, pengembang berpengalaman pun tidak lagi melakukannya. Artinya memahami logika inti dan mampu menjelaskan tepatnya mengapa kode melakukan apa yang dilakukannya. Jika bisa, tidak penting apakah model atau Anda yang menulisnya: itu bukan vibe coding, melainkan menggunakan alat untuk membangun perangkat lunak.

Penelitian yang dipublikasikan pada Desember 2025 mendukung perbedaan tersebut. Berdasarkan pengamatan lapangan dan survei kualitatif terhadap pengembang profesional, para peneliti menemukan bahwa praktisi berpengalaman mempertahankan kendali atas desain dan penerapan perangkat lunak, alih-alih menyerahkan seluruh proses kepada AI. Mereka memperlakukan agen sebagai rekan kerja, merencanakan pekerjaan dengan cermat, dan tetap terlibat dalam pengawasan.

Jadi, pengalaman saja tidak menjelaskannya. Persoalannya adalah apakah Anda bersedia bertanggung jawab atas apa yang dihasilkan AI. Setiap pengembang kembali membuat keputusan itu pada setiap proyek.

Apa yang Terjadi Ketika Kontrol Hilang

Konsekuensi merilis perangkat lunak tanpa memahami atau memverifikasi keamanannya bukan hal abstrak. Tea, aplikasi yang dimaksudkan untuk membantu perempuan tetap aman saat berkencan, mengungkapkan puluhan ribu foto ID dan lebih dari satu juta pesan pribadi dalam dua insiden keamanan. Kegagalannya mencakup bucket penyimpanan yang tidak diamankan dan basis data terpisah yang dapat diakses tanpa autentikasi.

Masalah mendasar yang sama — perangkat lunak tampak berfungsi sementara logika otorisasinya tetap salah dan berbahaya — muncul dalam aplikasi yang dibangun pada platform Lovable: penelitian keamanan menemukan logika otorisasi terbalik, mengunci pengguna yang sudah masuk tetapi membiarkan penyerang tanpa autentikasi masuk dengan bebas. Lebih dari 18.000 pengguna, termasuk pelajar, terdampak.

Ini bukan kasus terpisah yang hanya terjadi pada proyek “buruk”. Menurut laporan DORA Google 2025, 90% pengembang kini menggunakan AI di tempat kerja, sementara sekitar sepertiga melaporkan sedikit atau sama sekali tidak percaya pada hasil yang dibuatnya.

Penggunaan AI kini meluas meski tingkat kepercayaan tetap terbatas. Karena itu, peninjauan cermat sangat penting saat kode yang dihasilkan menangani autentikasi, izin, atau data sensitif.

Kontrol Dibangun Berlapis, Bukan Sekaligus

Dalam kasus saya, saya tidak memulai dengan audit keamanan formal. Saya hanya menolak melanjutkan setiap kali tidak dapat menjelaskan mengapa sesuatu berperilaku seperti itu — naluri alami dari pekerjaan saya sebagai analis. Saya lebih peduli apakah hasilnya sesuai dengan kebutuhan awal daripada sintaksnya. Jika tidak sesuai, saya terus menyelidiki.

Alur kerja saya menjadi lebih terstruktur seiring proyek makin serius. Alih-alih hanya mengandalkan prompt, saya mulai menyiapkan spesifikasi sebelum menghasilkan apa pun. Saya mendokumentasikan kebutuhan bisnis, tumpukan teknologi, dan integrasi. Setelah itu saya menambahkan pengujian unit dan pengujian Playwright untuk perjalanan pengguna utama.

Pemeriksaan keamanan ditambahkan dengan cara serupa. Saya meninjau pustaka yang dipilih AI dan menambahkan pemindaian malware untuk berkas yang diunggah. Setiap pemeriksaan lahir dari pertanyaan tentang apa yang bisa salah berikutnya, bukan dari daftar kontrol yang disiapkan sejak awal.

Kebiasaan itu menemukan masalah pada satu proyek. AI memasukkan pustaka yang tidak kompatibel dengan versi framework yang saya gunakan. Aplikasi tidak langsung gagal total, sehingga ketidakcocokan itu mudah terlewat. Menemukannya belakangan akan membuat penyebabnya jauh lebih sulit ditentukan.

Dibandingkan kasus Tea dan Lovable, ini masalah biasa. Saya menemukannya lebih awal, memperbaikinya, lalu melanjutkan. Begitulah peninjauan biasanya terlihat dalam praktik. Sebagian besar waktu, peninjauan mencegah masalah kecil berkembang menjadi masalah besar.

Saya tidak mencurigai kode hanya karena AI yang membuatnya. Saya juga tidak memercayainya hanya karena aplikasi dapat berjalan. Pengujian dan peninjauan adalah cara saya memastikan perilakunya sesuai tujuan.

Dari Vibe Coding ke Agentic Engineering

Peralihan Karpathy dari “vibe coding” ke “rekayasa agentik” bukan sekadar perubahan istilah. “Rekayasa agentik” memberi nama yang lebih berguna bagi arah pengembangan profesional. Pengembang mungkin menulis lebih sedikit baris sendiri, tetapi tanggung jawab mereka tidak berkurang. Pekerjaan bergeser ke penetapan apa yang harus dilakukan sistem, pengarahan agen, pengujian hasil, dan penentuan apa yang aman dirilis.

Bahaya bukan bahwa AI menghasilkan kode dengan cepat. Bahayanya adalah bahwa generasi dapat bergerak lebih cepat daripada pemahaman. Ketika hal itu terjadi, produktivitas yang tampak menyembunyikan risiko yang tidak ada yang memeriksanya dengan tepat.

Aturan yang Patut Dipertahankan

Berhentilah memakai “vibe coding” sebagai label untuk semua bentuk pengembangan berbantuan AI; hal itu mengaburkan istilah dan menghapus perbedaan kendali yang penting. Tetapkan aturan sederhana: jangan rilis sesuatu yang tidak dapat Anda jelaskan. Bangun kendali seiring proyek tumbuh, lapis demi lapis, dengan menambahkan pemeriksaan mengikuti risiko yang muncul.

AI dapat menulis sebagian besar kode. Ia tidak dapat mengambil tanggung jawab untuk merilisnya. Itu tetap menjadi tanggung jawab kami.