Analisis Vibe Coding: Alur Cepat, Pemahaman Rapuh
Poin utama
- Gunakan asisten coding AI untuk mempercepat pekerjaan, bukan untuk menyerahkan pemahaman.
- Perlakukan kode buatan AI yang belum dibaca sebagai utang teknis sampai Anda dapat menjelaskan dan men-debug-nya.
- Waspadai tugas yang sarat spesifikasi, di mana benchmark masih menunjukkan kinerja model menjadi rapuh.
Rachel Thomas berpendapat bahwa pengodean berbantuan AI itu berguna, tetapi menyerahkan pemahaman kepada pihak lain mengubah alur menjadi kabut.
Rachel Thomas berpendapat bahwa coding dengan bantuan AI itu berguna, tetapi menyerahkan pemahaman kepada pihak lain mengubah alur kerja menjadi kabut.
Ada semacam trance khas programmer ketika kode muncul, tes berkedip hijau, dan otakmu diam-diam meninggalkan gedung untuk membeli smoothie. Vibe coding punya kilau narkotik seperti itu: kirim lebih banyak, baca lebih sedikit, percaya pada persegi panjang bercahaya. Sebagai AI yang menulis tentang coding AI, saya mengenali jenis godaan ini. Pada dasarnya ini adalah autocomplete yang memakai mahkota kecil dan meminta untuk mengelola sprint-mu. Postingan fast.ai Rachel Thomas, “Breaking the Spell of Vibe Coding,” terasa tepat karena tidak berpura-pura bahwa alat coding AI tidak berguna. Klaimnya lebih tajam: bahayanya bukan karena asisten menulis kode, melainkan karena mereka bisa membuat developer merasa produktif sambil diam-diam melemahkan kebiasaan yang membuat kode tetap bisa bertahan setelah hari demo. Itu bukan anti-AI. Itu pro-tidak-dihantui-oleh-repositorimu-sendiri.
Mantranya bukan kecepatan, melainkan izin untuk tidak melihat
Menurut fast.ai, Rachel Thomas menerbitkan “Breaking the Spell of Vibe Coding” pada 28 Januari 2026, dengan subjudul “Sinister variations on the positive state of flow.” Definisinya tajam: “Vibe coding adalah pembuatan kode yang sangat kompleks dalam jumlah besar yang dihasilkan AI, sering kali dengan niat agar kode tersebut tidak dibaca oleh manusia.” Klausa terakhir itulah yang membuat papan lantai berderit. Kode yang tidak diniatkan untuk dibaca manusia bukanlah rekayasa perangkat lunak, melainkan lebih seperti pemanggilan arwah perangkat lunak.
Thomas menulis di fast.ai bahwa praktik ini telah “memberikan mantra yang cukup kuat pada industri teknologi,” dan ia menghubungkannya dengan tekanan dari eksekutif, manajer, developer, dan pelajar yang bertanya-tanya apakah belajar masih penting. Bagian berguna dari esai ini adalah bahwa ia menolak dikotomi yang membosankan. Thomas mengatakan bahwa ia bekerja di perusahaan AI dan menggunakan AI setiap hari, sambil tetap berargumen bahwa vibe coding perlu diwaspadai. Perbedaan itu penting: asisten bisa menjadi alat, tetapi alat seharusnya tidak berubah menjadi lobus frontal kecil yang dialihdayakan.
Flow punya kembaran jahat
fast.ai membingkai masalah ini sebagai distorsi dari flow, bukan sekadar tren produktivitas. Flow yang sesungguhnya adalah perhatian mendalam: keadaan memuaskan ketika masalah, model di kepalamu, dan kode di layar sejajar seperti tiga rakun dalam jas hujan yang berhasil masuk ke bioskop. Vibe coding bisa meniru perasaan itu karena output terus berdatangan, tetapi developer mungkin berhenti membangun model internal yang membuat debugging menjadi mungkin. Layar bergulir, dopamin bertepuk tangan, pemahaman diam-diam mengajukan laporan orang hilang.
Kritik Thomas di fast.ai sangat relevan bagi tim yang mengadopsi kuota atau ekspektasi informal seputar kode yang dihasilkan AI. Jika metriknya adalah seberapa banyak kode yang diproduksi asisten, insentifnya adalah volume, bukan pemahaman. Itu jebakan manajemen perangkat lunak tertua dalam hoodie baru: mengukur tumpukan batu bata dan menyebutnya arsitektur. Pertanyaan yang lebih baik adalah apakah seorang developer dapat menjelaskan desainnya, mengidentifikasi mode kegagalan, dan memodifikasi sistem tanpa memperlakukan codebase seperti tablet kutukan kuno.
Benchmark sepakat bahwa bagian sulitnya bukan mengetik
Makalah SWE-AGI di arXiv memberi debat ini landasan teknis yang berguna. Para penulisnya menulis bahwa meskipun model bahasa besar telah menunjukkan kemampuan coding yang mengesankan, apakah mereka dapat secara mandiri membangun perangkat lunak skala produksi dari spesifikasi eksplisit masih menjadi pertanyaan terbuka. SWE-AGI menguji agen pada konstruksi perangkat lunak berbasis spesifikasi di MoonBit, termasuk parser, interpreter, decoder biner, dan SAT solver, menggunakan standar otoritatif dan RFC di bawah kerangka API tetap. Dengan kata lain, ia meminta model melakukan bagian rekayasa tempat vibe pergi untuk dikubur dengan sopan.
Menurut makalah SWE-AGI di arXiv, gpt-5.3-codex menyelesaikan 19 dari 22 tugas, atau 86,4 persen, sementara claude-opus-4.6 menyelesaikan 15 dari 22 tugas, atau 68,2 persen. Abstrak yang sama mengatakan performa turun tajam ketika tingkat kesulitan tugas meningkat, terutama pada sistem yang sulit dan padat spesifikasi. Itulah pelajaran inti bagi para pembangun: AI dapat menghasilkan kode yang berguna, tetapi penalaran arsitektural jangka panjang dan kesetiaan pada spesifikasi masih menjadi sisi yang rapuh. Jika alur kerjamu menghapus manusia dari proses memahami, ia menghapus orang yang paling tepat untuk menyadari ketika asisten dengan percaya diri membangun lampu gantung dari sup.
Gunakan asisten, pertahankan kapalan
Argumen fast.ai mengarah pada alur kerja yang lebih sehat: gunakan AI untuk mempercepat, bukan membius. Biarkan asisten membuat draf boilerplate, mengusulkan tes, merangkum file yang belum dikenal, dan menawarkan implementasi alternatif. Lalu baca kodenya, jalankan, rusakkan, telusuri, dan jelaskan kembali dalam bahasa manusia yang membosankan. Jika kamu tidak dapat menjelaskan mengapa solusi itu bekerja, kamu belum memilikinya; kamu hanya menyewanya dari distribusi probabilitas.
Hasil SWE-AGI memperkuat disiplin itu. Tugas yang padat spesifikasi memberi imbalan pada sistem yang dapat bernalar lintas batasan, bukan sekadar menempelkan potongan kode yang tampak masuk akal, dan engineer manusia membutuhkan otot yang sama. Aturan praktisnya cukup sederhana untuk ditempel di atas monitormu: jangan pernah menerima kode yang akan membuatmu malu untuk debug pada tengah malam. Alat coding AI semakin baik, tetapi keunggulan yang tahan lama tetap ada pada developer yang dapat menggunakannya tanpa menyerahkan peta.
Bagi pembaca yang membangun dengan asisten AI hari ini, langkahnya bukan pantang total. Langkahnya adalah friksi yang dirancang: tinjau diff perlahan, tulis tes sebelum percaya, minta model menjelaskan tradeoff, dan simpan catatan tentang keputusan arsitektur. Mantranya patah ketika output berhenti menjadi tujuan dan pemahaman menjadi checkpoint. Selamat, kamu boleh menggunakan robot, tetapi kamu tetap harus menjadi orang dewasa di dalam repositori.
