Vibe coding dan treadmill kebanggaan: berlari di tempat?

Kapan terakhir kali kamu benar-benar memahami setiap baris kode yang kamu deploy ke production?

Bukan sekadar "tau ini bekerja", tapi benar-benar mengerti why dan how di baliknya. Jujur saja, era vibe coding yang dipopulerkan Andrej Karpathy telah mengubah cara kita memandang programming. Prompt, generate, deploy. Loop berulang. Produktivitas meroket, tapi sesuatu yang fundamental mulai hilang dari perjalanan kita sebagai engineer.

Ilusi Kecepatan di Atas Treadmill

Kellyn Gorman dari Redmonk pernah menulis esai tajam berjudul "AI Slop & the Vulnerability Treadmill". Intinya sederhana: AI membuat kita menghasilkan kode lebih cepat dari sebelumnya, tapi kecepatan itu bukan tanpa biaya. Setiap baris yang di-generate tanpa pemahaman mendalam menambah technical debt yang tersembunyi, dan kita terus berlari di atas treadmill yang justru kita sendiri yang mempercepatnya.

Gambaran treadmill ini begitu pas. Bayangkan: kamu berlari kencang, keringat bercucuran, merasa produktif. Tapi posisimu tidak berubah. Begitu pula dengan codebase yang dipenuhi AI-generated snippets. LoC (Lines of Code) naik drastis. PR merge lebih cepat. Sprint velocity terlihat mengesankan di dashboard. Tapi apakah software-nya jadi lebih andal? Lebih mudah di-maintain? Lebih aman?

Data dari berbagai penelitian keamanan menunjukkan bahwa code yang dihasilkan LLM memiliki tingkat vulnerability yang lebih tinggi dibanding code yang ditulis manusia yang benar-benar memahami konteks. Bukan karena AI-nya bodoh, tapi karena kita sebagai operator seringkali tidak punya bandwidth untuk memverifikasi outputnya secara kritis. Dalam konteks startup Indonesia yang bergerak cepat dan sering kekurangan tenaga senior, risiko ini berlipat ganda.

Kita sering bangga dengan berapa banyak fitur yang kita ship dalam satu sprint. Stakeholder memberi thumbs up. Investor melihat growth yang menggiurkan. Tapi di balik dinding server dan repository Git, complexity yang tidak terawat sedang mengendap seperti plaque di pembuluh darah. Suatu hari nanti, bisa saja terjadi serangan jantung sistem yang fatal.

Ketika "Works on My Machine" Menjadi "Works on My Prompt"

Filosofi lama "works on my machine" kini berevolusi menjadi "works on my prompt." Kita semakin jarang melakukan deep debugging. Stack Overflow jadi kunjungan nostalgia. Sebaliknya, kita berkutat dengan prompt engineering, mencoba formulasi magic words yang membuat model menghasilkan output yang lebih baik.

Hillel Wayne dalam esai klasiknya "Are We Really Engineers?" mempertanyakan identitas profesi kita. Apakah kita benar-benar engineer yang memahami sistem yang kita bangun, atau sekadar teknisi yang mengeksekusi ritual tanpa memahami prinsip di baliknya? Era AI telah memperkuat pertanyaan itu. Jika sistem kita gagal di tengah malam, apakah kita masih punya mental model yang cukup untuk mendiagnosis root cause-nya?

Saya sendiri pernah menghabiskan tiga hari memperbaiki bug yang sebenarnya berasal dari satu baris AI-generated regex yang "terlihat benar" tapi salah dalam edge case Unicode. Tiga hari untuk satu baris. Ironisnya, jika saya menulis regex itu sendiri dari awal, mungkin saya hanya butuh 30 menit. Tapi karena saya melewatkan fase thinking dan langsung ke fase generating, saya membayar mahal dengan waktu dan frustrasi.

Agentic Workflow dan Pengabdian Tanpa Pemahaman

Kini muncul tren baru: agentic workflow. AI tidak lagi sekadar autocomplete, tapi aktor independen yang menulis kode, menjalankan test, bahkan deploy ke production. Konsep ini menarik dan menjanjikan efisiensi luar biasa. Tapi ia juga membawa delegasi tanggung jawab yang berbahaya. Ketika AI agent membuat keputusan arsitektural tanpa supervisi manusia yang kompeten, kita sedang membangun sistem yang bahkan pembuatnya tidak mengerti.

Di banyak startup Jakarta dan Bandung, saya melihat fenomena yang sama: tim tech yang sangat bergantung pada AI untuk scaffolding, integrasi, bahkan code review. Hasilnya? MVP yang terlihat polished tapi foundation-nya rapuh. Ketika user scale naik dari ratusan ke ribuan, sistem mulai runtuh di tempat-tempat yang tidak pernah diperhitungkan. Bukan karena AI-nya salah, tapi karena manusia di belakangnya tidak pernah benar-benar memahami trade-off yang diambil.

Kehilangan Kemampuan Berpikir

Nicholas Carr dalam bukunya The Shallows pernah mengingatkan bahwa setiap teknologi kognitif membentuk ulang cara kita berpikir. Internet membuat kita jadi scanner superficial. Apakah AI coding assistant sedang membuat kita jadi prompt typist yang kehilangan kemampuan architectural thinking?

Software engineering yang baik bukan tentang mengetik kode paling cepat. Itu tentang memodelkan masalah kompleks, mempertimbangkan trade-off, memahami constraints sistem, dan merancang solusi yang bisa bertahan dari perubahan requirement. Proses berpikir ini terjadi sebelum jari menyentuh keyboard. Sayangnya, vibe coding seringkali memotong proses ini. Kita langsung minta solusi, tanpa benar-benar memahami masalah.

Sebuah studi dari UC San Diego menunjukkan bahwa programmer yang terlalu bergantung pada AI cenderung memiliki pemahaman yang lebih dangkal tentang algoritma fundamental. Mereka bisa menyelesaikan tugas dengan cepat, tapi gagal ketika dihadapkan pada masalah yang memerlukan adaptasi kreatif di luar pattern yang sering muncul di training data model.

Menemukan Keseimbangan

Ini bukan artikel anti-AI. Saya sendiri menggunakan Copilot, Cursor, dan berbagai AI tools setiap hari. AI adalah force multiplier yang luar biasa. Tapi multiplier dari apa? Jika yang kamu kalikan adalah nol, hasilnya tetap nol. Jika yang kamu kalikan adalah pemahaman yang dangkal, yang kamu dapatkan adalah daging tanpa tulang: software yang terlihat solid tapi rapuh di dalamnya.

Kuncinya bukan menolak AI, tapi menggunakan AI sebagai sparring partner, bukan replacement. Biarkan AI menangani boilerplate, repetitive tasks, dan draft awal. Tapi tetap luangkan waktu untuk membaca, memahami, dan mempertanyakan setiap outputnya. Jangan biarkan vibe coding mengubahmu dari engineer menjadi operator vending machine.

Seperti yang sering diingatkan dalam komunitas developer, prinsip "complexity bad" dari grugbrain.dev jadi semakin relevan: AI-generated complexity yang tidak dipahami adalah malapetaka ganda. Setiap kali kamu menyetujui AI-generated code tanpa verifikasi, kamu sedang menandatangani surat utang teknis yang suatu hari harus dilunasi dengan bunga berlipat.

Pertanyaan untuk Renungan

Jika AI bisa menghasilkan 90% kode yang kamu butuhkan, apa yang tersisa untuk 10% yang membedakan engineer senior dari junior? Jika kita semua menjadi prompt engineer, siapa yang akan merancang arsitektur untuk AI yang akan menggantikan kita?

Mungkin sudah waktunya kita melambat sedikit, berhenti berlari di treadmill, dan mulai bertanya: bukan "berapa banyak kode yang saya hasilkan hari ini?", tapi "berapa banyak yang saya pahami hari ini?"