Membongkar Ilusi Ajaib Vibe Coding

• Produksi massal kode kompleks yang dihasilkan AI makin meluas, dan fenomena membuat kode yang tidak dibaca manusia menyebar di seluruh industri
• Pihak manajemen menggunakan pengurangan tenaga kerja akibat AI sebagai pembenaran, sementara para developer mendapat tekanan untuk memenuhi porsi kode buatan AI
• ‘Vibe coding’ semacam ini memicu kondisi ‘dark flow’ yang mirip dengan mekanisme kecanduan judi, sehingga menimbulkan ilusi produktivitas
• Ada hasil riset yang menunjukkan bahwa saat memakai alat coding AI, orang merasa produktivitas naik 20%, tetapi sebenarnya justru 19% lebih lambat
• AI memang berguna, tetapi kemampuan manusia dalam berpikir, berkreasi, dan software engineering tidak tergantikan, dan melepaskannya justru berisiko membuat kita mundur

---

Penyebaran vibe coding dan kesadaran akan masalahnya

• Vibe coding adalah tindakan memproduksi massal kode kompleks yang dihasilkan AI, sehingga kode menjadi sulit dibaca atau dipelihara oleh manusia
  • Beberapa perusahaan membenarkan PHK dengan alasan AI dapat menggantikan pekerjaan manusia
  • Para developer mendapat tekanan bahwa jika gagal memenuhi porsi kode hasil AI, mereka bisa dirugikan dalam evaluasi kinerja
  • Baik pelajar maupun pekerja mengalami gejala enggan mengembangkan diri karena cemas bahwa “AI akan segera menggantikan pekerjaanku”
• AI memang berguna, tetapi vibe coding perlu diwaspadai dan dapat menimbulkan konsekuensi negatif bila digunakan dengan cara yang keliru

Perbedaan antara ‘flow’ dan ‘dark flow’

• ‘Flow’ yang didefinisikan oleh psikolog Mihaly Csikszentmihalyi adalah kondisi tenggelam dalam aktivitas ketika tantangan dan keterampilan berada dalam keseimbangan
• Sebaliknya, rasa tenggelam juga bisa muncul pada aktivitas yang tidak terkait keterampilan, seperti judi, dan ini tergolong ‘flow palsu’
  • Seperti kasus Loss Disguised as a Win (LDW) pada mesin slot, padahal sebenarnya rugi tetapi dibuat terasa seolah menang
  • Menurut riset, LDW memicu respons fisiologis yang mirip dengan kemenangan nyata, sehingga memperkuat keterlibatan yang adiktif
• Fenomena ini disebut ‘dark flow’ atau ‘junk flow’, yaitu keterhanyutan adiktif tanpa pertumbuhan

Kemiripan antara vibe coding dan judi

• Developer Armin Ronacher menyebut bahwa setelah memakai alat coding AI, ia menghasilkan banyak kode tetapi nyaris tidak bisa benar-benar menggunakannya
  • Ini mirip dengan struktur ilusi ‘kemenangan palsu’ dalam judi
• Vibe coding melanggar syarat-syarat flow dalam beberapa hal berikut
  • Tidak ada umpan balik yang jelas atas hasil, justru memberi rasa pencapaian yang keliru
  • Ketidakseimbangan antara tingkat tantangan dan tingkat keterampilan
  • Membuat pengguna percaya bahwa mereka mengendalikan hasil lewat illusion of control
• Kualitas kode yang dihasilkan AI sering kali baru disadari bermasalah beberapa minggu kemudian, ketika bug dan kompleksitas yang tak bisa dipelihara mulai terlihat
• Baik LLM maupun mesin slot sama-sama dirancang untuk memaksimalkan respons psikologis pengguna, sehingga mendorong pemakaian berkelanjutan

Ilusi produktivitas dan ‘narator yang tidak dapat diandalkan’

• Menurut riset METR, developer yang memakai alat AI merasa 20% lebih cepat, tetapi sebenarnya 19% lebih lambat
  • Ini berarti ada selisih 40% antara efisiensi yang dirasakan dan efisiensi yang nyata
• Tulisan yang dibuat dengan AI juga bisa tampak serupa dari luar, tetapi kualitasnya lebih rendah
  • Sebuah tulisan blog milik peneliti AI, setelah ditulis dengan AI, berubah menjadi gaya bahasa yang kurang mudah dibaca dibanding sebelumnya
• Manusia sulit menilai produktivitasnya sendiri secara objektif, dan cenderung melebih-lebihkannya setelah menggunakan AI

Prediksi yang keliru dan risiko karier

• Prediksi bahwa AI akan sepenuhnya menggantikan coding berulang kali meleset
  • Geoffrey Hinton pernah memprediksi bahwa pada 2021 AI akan menggantikan radiolog, tetapi hal itu tidak terjadi
  • Sundar Pichai dan Jeff Dean dari Google pernah mengatakan bahwa pada 2023 semua data scientist akan memakai alat desain jaringan saraf otomatis, tetapi itu juga tidak terwujud
  • Dario Amodei dari Anthropic memprediksi bahwa pada akhir 2025 AI akan menulis 90% dari seluruh kode, tetapi tidak ada dasar yang kuat untuk klaim itu
• Karena itu, menghentikan pengembangan kemampuan diri berdasarkan prospek yang dibesar-besarkan adalah langkah berisiko
  • Laju perkembangan AI selama ini terus dinilai terlalu tinggi dibanding kenyataannya

Pentingnya pemikiran dan kreativitas manusia yang tetap bertahan

• Agen coding AI memang dapat menghasilkan kode yang benar secara sintaksis, tetapi
  • tidak mampu melakukan abstraksi yang berguna, modularisasi, dan perbaikan struktur kode
  • artinya, coding telah terotomatisasi, tetapi software engineering belum
• Teks yang dihasilkan AI juga terdengar alami secara tata bahasa, tetapi tidak mampu mempertajam pemikiran atau menangkap inti persoalan
• Jeremy Howard memperingatkan, “jika berpikir sepenuhnya didelegasikan kepada AI, kita akan kehilangan kemampuan untuk belajar dan bertumbuh”
  • AI berguna sebagai alat, tetapi tidak menggantikan kompetensi inti manusia

[kiga183]

Saat menilai kemampuan kerja seseorang, ada unsur yang disebut 'sikap'. Selain pedoman kerja dan perintah atasan, sikap seseorang sendiri dalam menghadapi pekerjaannya juga penting. Sikap itu terlihat melalui perhatian yang berkelanjutan, wawasan, dan rasa tanggung jawab terhadap pekerjaan. Di antaranya, rasa tanggung jawab sangat penting. Kecerdasan buatan mungkin bisa meniru hal-hal lain, tetapi tidak memiliki rasa tanggung jawab. Kecerdasan buatan mungkin bisa menilai hasil, tetapi tidak bisa menilai rasa tanggung jawab dalam prosesnya.

[kiga183]

AI memahami dengan baik 'bagaimana (How)', tetapi tidak mengetahui mengapa sesuatu harus dilakukan. Hasrat untuk memahami tujuan mendasar dari suatu pekerjaan, berani menempuh trial and error demi mencari jalan baru, dan menentukan arah menuju tujuan hanyalah hal yang bisa dilakukan manusia. Tanggung jawab bukan sekadar mengejar hasil, melainkan sikap untuk tidak kehilangan tujuan dalam prosesnya serta terus bertanya dan bereksplorasi.

[kiga183]

Kemampuan untuk secara kreatif menemukan cara lain di luar manual dan instruksi juga berasal dari sikap yang bertanggung jawab.

[dieafterwork]

Saya sangat setuju.

[GN⁺]

Komentar Hacker News

• Saya sedang memikirkan mana yang lebih berbahaya: terlalu banyak memakai AI atau terlalu sedikit memakai AI
  Saat ini rasanya yang pertama jauh lebih berbahaya. Ada bug halusinasi, arsitektur buntu, masalah keamanan, menurunnya rasa kepemilikan atas kode, dan hilangnya kesempatan belajar
  Sebaliknya, jika AI dipakai lebih sedikit, produktivitas memang turun, tetapi pemahaman mendalam atas codebase dan latihan yang didapat bisa menjadi aset yang lebih besar dalam jangka panjang
  Secara pribadi, saya merasa ide-ide kreatif yang muncul saat bergulat langsung di dalam kode adalah hal yang paling berharga
  Sangat disayangkan kalau kesempatan seperti ini hilang karena terlalu cepat menyerahkannya pada AI
  • Bahkan saat melakukan coding dengan bantuan AI, kalau standar tidak diturunkan, justru bisa membuat kita tenggelam lebih dalam
    Karena pekerjaan repetitif berkurang, kepala tidak terlalu lelah, dan kita bisa fokus pada masalah sulit sehingga ide yang lebih baik pun muncul
    Kuncinya adalah menjaga selera dan standar yang baik
  • Saya pernah mencoba agentic coding lalu diarahkan ke arsitektur buntu
    Kalau desain dan dokumentasi disiapkan dengan rinci sejak awal, tingkat keberhasilannya lebih tinggi
    Bagian yang benar-benar sulit bukan pembuatan kodenya, melainkan tahap perencanaan dan desain
    Sebaliknya, memakai LLM untuk dokumentasi atau menulis boilerplate sangat menghemat waktu
  • Cara tiap orang memakai AI untuk coding sangat berbeda-beda
    Ada yang mencoba menyelesaikan aplikasi sekaligus, ada juga yang hanya memakainya setingkat autocomplete sederhana
    Karena cara baru terus muncul, yang terbaik adalah tetap terbuka dan mencoba berbagai pendekatan
  • Saya rasa kerangka “terlalu banyak AI vs terlalu sedikit AI” adalah pendekatan yang keliru
    Teknologi baru seharusnya selalu divalidasi dalam unit kecil lalu diperluas secara bertahap
    Jumlah penggunaan AI yang benar adalah ‘sebatas yang sudah tervalidasi’
    Menyeret diskusi seperti ini ke arah taruhan Pascal itu menyedihkan, dan biasanya merupakan logika orang yang sedang berusaha menjual sesuatu
• Dari sudut pandang orang yang membuat alat otomasi akuntansi, vibe coding adalah bencana
  Walaupun AI bisa menulis kode dengan baik, mode kegagalan yang tidak terlihat seperti kesalahan halus dalam perhitungan pajak adalah yang paling berbahaya
  Angka yang salah bisa diam-diam tercermin ke sistem akuntansi nyata
  Karena itu AI hanya dipakai sebagai alat autocomplete tingkat lanjut — arsitektur dan logika domain saya rancang sendiri, dan AI hanya dipakai untuk kode repetitif atau scaffolding test
  Pada akhirnya, masalahnya bukan “kode yang ditulis AI”, melainkan kode yang tidak benar-benar saya pahami sendiri
  • Mode kegagalan yang tak terlihat juga berlaku pada kode buatan manusia
    • Justru risiko seperti ini bisa menjadi kesempatan untuk menyingkap ketiadaan manajemen risiko
  • Masalah seperti ini pada akhirnya adalah masalah kurangnya test
    • Baik kode buatan manusia maupun AI, kalau tidak ada test, kegagalan tidak akan terlihat
  • Ada juga yang bertanya apakah kesalahan perhitungan pajak tidak akan tertangkap oleh sistem pembukuan berpasangan
  • Ada yang berkata, “Saya memproses tugas kompleks dengan AI tanpa masalah,” dan mengklaim bahwa pada akhirnya ini soal kemampuan membuat prompt
  • Orang lain berkata, “Masalah seperti itu harus diselesaikan lewat arsitektur,” dan menekankan bahwa yang penting adalah auditabilitas dan struktur rollback
• Saya sangat setuju dengan kalimat, “Coding sudah terotomatisasi, tetapi rekayasa perangkat lunak belum”
  LLM pandai menulis fungsi, tetapi tidak bisa memutuskan fungsi apa yang sebenarnya dibutuhkan
  Arsitektur proyek nyata terbentuk dengan bertabrakan langsung dengan bottleneck dunia nyata
  Yang dibantu AI hanyalah kecepatan implementasi; keputusan struktural sepenuhnya tetap menjadi tugas manusia
  Terutama, bug domain sama sekali tidak akan bisa ditangkap LLM
  Pada akhirnya, arsitektur dan pengetahuan domain tetap harus menjadi tanggung jawab manusia
  • Ada yang balik bertanya, “Sudah pernah minta LLM merancang arsitektur itu sendiri?”
    Kalau yang diminta hanya ‘menulis kode’, tentu dia gagal karena itu memang bukan tujuannya
  • Orang lain menyebut manfaat yang sangat praktis: berkat AI, nyeri pergelangan tangan berkurang
• Saya rasa tidak perlu berhenti berinvestasi pada pertumbuhan diri hanya karena prediksi para peneliti AI
  Selama setahun terakhir saya mempelajari desain perangkat lunak dan vibe coding secara bersamaan
  Dengan mempelajari berbagai buku tentang DDD, Clean Architecture, Agile, dan lainnya, saya menjadi engineer yang jauh lebih baik
  Meskipun memakai AI, tanggung jawab atas kode tetap ada pada saya
  Kedua bidang itu bisa berkembang bersama
  • Mampu memakai bantuan coding AI dengan baik juga merupakan keterampilan yang terasah
    Ini butuh investasi waktu dan latihan, tetapi sangat layak dipelajari dan tidak menggantikan keterampilan lain
  • Saya juga mirip begitu, memilih membaca buku seperti filsafat desain perangkat lunak dan desain yang berpusat pada data
    Karena hal yang tidak dikuasai LLM adalah penilaian tingkat tinggi dan desain struktur
    Sistem yang dirancang dengan baik memaksimalkan efisiensi AI
    Selain itu, mempelajari paradigma baru membantu kita menilai dan memperbaiki kode buatan LLM dengan lebih baik
    Teknik seperti BDD, PBT, dan verifikasi model adalah alat untuk membuat AI coding lebih aman
  • Sementara itu, seorang veteran 20 tahun pengalaman memberi saran berani: “DDD itu tidak berguna,” jadi buang saja
  • Ada juga yang bertanya, “Dari tiga buku DDD itu, mana yang paling berguna?”
• Saya sudah dua kali menjalankan proyek kompleks dengan Claude Code; awalnya kecepatannya luar biasa, tetapi pada akhirnya kesalahan asumsi yang fatal menghapus semua keuntungan itu
  Dari luar terlihat seperti kemenangan, tetapi sebenarnya itu adalah kemenangan yang menyamar sebagai kekalahan
  Menanggapi ini, ada yang berkata gambaran itu terasa seperti euforia dan jatuhnya obat-obatan, sebagai sebuah metafora
• Menjadi programmer yang bagus tidak otomatis berarti menjadi arsitek, desainer, atau PM yang bagus
  Untuk memanfaatkan LLM dengan benar, otot dari ketiga peran itu semua dibutuhkan
  • Orang lain membantah, “Kalau engineer itu bagus, seharusnya dia sudah menjadi PM dan arsitek yang bagus juga”
  • Ada juga yang mengkritik budaya desain yang seragam, dengan mengatakan bahwa ‘desain bagus’ versi UI designer sering meleset dari pengguna nyata
  • Ada yang menyindir bahwa pada akhirnya mereka mengerjakan pekerjaan arsitek, desainer, dan manajer, tetapi tetap hanya diperlakukan sebagai developer
• Kunci keberhasilan adalah kemampuan mendefinisikan kriteria sukses secara konkret
  Jika bisa membayangkan UI/UX yang diinginkan dengan jelas, model saat ini pun sudah cukup untuk menghasilkan hasil yang baik
  Sebaliknya, prompt model “pokoknya bikinkan saja” itu berbahaya
  AI harus diperlakukan seperti mecha suit tingkat lanjut — manusia harus tetap ada di dalam loop agar benar-benar cepat
• Pada 2017 GPT membuat teks palsu yang terdengar meyakinkan, tetapi pada 2023 situasinya benar-benar berbeda
  Kecepatan perkembangan teknologi begitu cepat sehingga hal yang tahun lalu sulit kini menjadi sepele
  Bahkan alat AI internal yang dulu dipakai kini sedang digantikan oleh model open source
  Sekarang rasanya seperti masa Don’t Look Up versi AI — semua orang harus menempatkan ulang dirinya agar cocok dengan era AI sebelum terlambat
• Pendekatan tiap orang terhadap AI coding berbeda-beda, tetapi seperti kata Armin, vibe coding tanpa arah itu berbahaya
  Seorang teman membuat produk selama 3 bulan dengan Cursor, tetapi hasilnya penuh fitur dan tidak berguna
  Pada akhirnya masalahnya adalah tidak adanya orang yang benar-benar memahami kodenya
  • Saya hanya memakai AI untuk pekerjaan repetitif dan brainstorming bug
  • AI punya konsistensi yang bagus untuk menangani corner case, jadi saya fokus pada desain dan arsitektur
• Mengejutkan bahwa ada developer yang menghasilkan kode lalu bahkan tidak meninjaunya
  Sulit memahami bagaimana mereka bahkan tidak melakukan sanity check mental yang paling dasar
  • Ada yang berkata, “Karena sebagian besar kode AI memang benar, pada akhirnya muncul kelelahan meninjau”
    • Masalahnya justru tersembunyi bukan di kodenya, melainkan pada pola arsitektural
  • Orang lain menyarankan validasi sejak awal, dengan mengatakan bahwa menurut penelitian IBM, memperbaiki masalah pada tahap desain itu 15 kali lebih murah
  • Ada yang dengan tegas berkata, “Orang seperti itu bukan developer sungguhan”
  • Orang lain menganalisis bahwa mungkin itu karena lapisan bawah sudah menjadi terlalu tepercaya,
    • seperti kita tidak memeriksa langsung binary hasil kompilasi, lalu salah mengira AI juga akan sama

[shakespeares]

Tidak mampu melakukan abstraksi yang berguna, modularisasi, atau perbaikan struktur kode

Saya setuju.