"Vibe Coding" vs Realitas

• Pernyataan Andrej Karpathy belakangan menjadi sorotan: "Serahkan diri pada Vibe, terima pertumbuhan eksponensial, dan lupakan saja bahwa kode itu ada."
• "Vibe Coding" mengacu pada kecenderungan mendelegasikan pemecahan masalah kepada alat AI tanpa rencana yang jelas atau penulisan kode secara langsung
• Melalui agen LLM (large language model), pengguna dapat memberi perintah dalam bahasa alami untuk menghasilkan dan memodifikasi kode
  • 2022: di ChatGPT, kode bisa disalin dan dimodifikasi
  • 2023: di Copilot yang terintegrasi dengan IDE, review dan modifikasi kode dimungkinkan
  • 2024~2025: dapat memodifikasi banyak file dalam proyek serta melakukan pengujian dan perbaikan sendiri

Cara kerja "Vibe Coding"

• Baik pengguna teknis maupun nonteknis dapat menyiapkan proyek melalui agen berbasis LLM
• Dengan perintah sederhana, situs web atau aplikasi bisa dibuat (misalnya: "buat situs web resor ski")
• Setelah penyiapan awal, perbaikan dan pengujian otomatis dapat dilakukan

• Contoh:

  • Cursor, GitHub Copilot Agent Mode, dan lainnya dapat memodifikasi file serta menjalankan perintah
  • Menjalankan perbaikan dan pengujian otomatis → dapat menimbulkan error karena kurangnya konsistensi

Masalah otonomi agen

• Agen dapat menjalankan tugas secara otomatis, tetapi belum sepenuhnya otonom
• Jika dijalankan tanpa persetujuan pengguna, risiko dapat muncul (misalnya: menjalankan perintah dalam mode YOLO)
• Masalah kualitas dan akurasi kode dapat terjadi

• Masalah utama:

  • Gagal menggunakan ulang kode yang sudah ada → berulang kali membuat komponen yang sama
  • Mencoba menjalankan logika sisi server di sisi klien
  • Error muncul setelah memperbaiki kode yang salah → gagal saat mencoba memperbaikinya
  • Gagal menulis unit test atau justru merusak kode

Keterbatasan yang realistis

• Model seperti Claude 3.7 Sonnet tidak dapat melampaui batas data pelatihannya
• Jika kehilangan konteks dalam codebase, modifikasi yang konsisten menjadi tidak mungkin
• Saat ukuran kode membesar, performa menurun dan konteks tidak bisa dipertahankan
• Jika ukuran context window LLM terlampaui, masalah konsistensi akan muncul

• Contoh kasus spesifik:

  • Duplikasi interface TypeScript
  • Menjalankan logika server di klien
  • Gagal memperbaiki komponen duplikat
  • Gagal menulis unit test
  • Gagal memperbaiki error setelah refactoring kode

Upaya mengatasi masalah

• Claude Plays Pokémon: agen bermain game melalui interaksi real-time
• Gagal mempertahankan memori dan memperbaiki error yang berulang
• Gagal membangun memori jangka panjang → error terus terjadi

• Potensi perbaikan:

  • Perlu peningkatan pada MCP(Model Context Protocol) dan manajemen memori
  • Saat memodifikasi kode, LLM harus dapat secara akurat mencerminkan perubahan sebelumnya
  • Perlu penyimpanan memori spesifik domain dan riwayat pekerjaan

Kesimpulan

• "Vibe Coding" dapat mencapai hingga 80% dalam mengimplementasikan konsep yang fungsional, tetapi untuk membuat produk yang andal dan aman tetap dibutuhkan upaya manusia yang berpengalaman
• Agen AI memungkinkan orang yang terampil menciptakan lebih banyak hal secara mandiri, tetapi tidak dapat menggantikan orang-orang yang mampu menyelesaikan masalah sulit yang memerlukan pengalaman dan intuisi.
• Pada level saat ini, "Vibe Coding" sulit benar-benar menghasilkan produk yang berguna, dan bantuan developer berpengalaman tetap esensial
• "Vibe Coding" hanyalah sarana bantu untuk menulis kode, bukan pengganti sepenuhnya

[nicewook]

Bagian "tingkat saat ini" itu yang paling menarik perhatian saya. Bukankah kita sedang melihat LLM dengan konsep waktu milik manusia?

[ng0301]

Yang saya rasakan saat ngoding bersama AI adalah, kalau kita memecah unit dengan nuansa prinsip tanggung jawab tunggal + TDD agar AI bisa memahami konteks hanya dengan diberi sebagian kode, ternyata kita memang harus menyusunnya sedemikian rupa sehingga tidak perlu membaca konteks besar, dan konteks parsial saja sudah cukup untuk menangkapnya.

[ifmkl]

Saya paling sering memakai AI untuk hobi membuat game web, dan saya setuju. Begitu skalanya melewati tingkat tertentu, ada titik di mana AI tampak mengalami penurunan yang cukup jelas pada aspek yang bisa dibilang sebagai tingkat fokusnya. Saya memanfaatkannya dengan cara berikut: seluruh tree dan source code dalam game saya gabungkan menjadi satu file yang mencakup TOC, lalu saat membuat thread baru saya mengunggah file tersebut dan melanjutkan pekerjaan. Dan ketika mengajukan pertanyaan, saya selalu secara eksplisit menyebutkan nama project saat ini sambil meminta jawaban. Meski begitu, masih ada bagian-bagian yang belum memuaskan... tetapi saya sangat puas dengan kenyataan bahwa saya bisa menyelesaikan hobi yang dulu, karena sibuk dengan kehidupan nyata, bahkan tak berani saya mulai, dalam waktu yang relatif singkat.

[pcj9024]

Pola membuatnya secara kasar lalu merapikan sisa detailnya sangat bagus.

[psguny9]

Saya mencoba berbagai hal, tetapi batasan memori jelas ada. Untuk tingkat PoC, ini bagus. Dari sisi kemungkinan/kegunaan yang bisa dicapai dengan cepat, ini juga bagus.

Masalahnya, justru semakin membutuhkan orang yang berpengalaman.

[colus001]

Kalau sebagian besar waktu dalam coding dihabiskan untuk debugging dan membaca kode, menurut saya ini agak terlalu dibesar-besarkan. Orang-orang yang membuat AI memang semuanya berbicara dengan nada seperti ini, tetapi setidaknya kalau melihat situasi saat ini, sepertinya belum begitu. Jika sudah sampai pada titik tidak membutuhkan campur tangan manusia, apakah coding masih perlu? Bukankah lebih baik cukup memasukkan penjelasan API lalu memakai LLM sebagai backend.

[reagea0]

Dalam praktiknya, banyak yang memang menggunakannya seperti itu dengan menetapkan skema lalu menerimanya.

[nowdoit7]

Saya setuju. Di awal, kecepatannya memang tampak nyaris ajaib, tetapi semakin besar skalanya dan semakin banyak file, jika pihak yang bertanggung jawab mengelolanya (dalam hal ini manusia) tidak mampu mengaturnya secara efektif, pada akhirnya yang didapat hanyalah hasil yang membengkak dan penuh kesalahan. Jika sudah sampai pada titik yang tidak bisa diselamatkan, yang terbuang hanya kredit (Windsurf) atau request (Cursor). Ke depannya pasti akan semakin membaik, tetapi untuk saat ini, kode AI tidak boleh dipercaya 100%.

[GN⁺]

Opini Hacker News

• Perbedaan besar antara "hype AI vs. realitas" terletak pada angka produktivitas yang sering disebut orang. Misalnya, partner YC mengutip sebuah perusahaan yang mengklaim "peningkatan kecepatan 100x" dalam performa coding. Klaim seperti ini seharusnya akan terlihat jelas bagi pengamat luar, sehingga tidak perlu bergantung pada laporan diri.

  • Batch musim panas YC berlangsung selama 84 hari dan berakhir dengan Demo Day. Peningkatan kecepatan 100x setara dengan tim membuat aplikasi dengan fitur setingkat Demo Day dalam waktu kurang dari sehari. Jika angka 100x itu benar, para partner akan mengatakan bahwa batch baru "sarapan dengan pelanggan, mempelajari sesuatu yang baru, mendapat inspirasi, lalu menulis ulang aplikasi pada hari yang sama, dan hasilnya memiliki fitur setingkat Demo Day". Namun tidak ada cerita seperti itu, jadi angka 100x tidak akurat.
  • Bahkan jika peningkatannya 10x, para partner akan mengatakan "di batch kali ini orang-orang sudah men-deploy aplikasi setingkat Demo Day ke production pada minggu pertama". Para partner memiliki ukuran sampel yang besar tentang seberapa banyak pekerjaan yang diselesaikan tim dalam rentang waktu tertentu. Karena itu, 10x juga bukan fakta.

• Saat ini kita sedang mengikuti gelombang outsourcing. Dengan semua klaim yang berlebihan itu, realitasnya berbeda. Sulit membedakan pembahasan tentang agen coding LLM.

• Ini seperti komunitas Go yang mengatakan komputer tidak mungkin bisa mengalahkan pemain Go manusia. Sudah ada contoh model yang menemukan sorting yang performanya lebih baik. Jika diberi insentif dan waktu yang tepat, komputer akan mengalahkan kita.

  • "Vibe coding" masih belum menjadi kenyataan. Kita tetap harus membetulkan kesalahan dan memberi arahan dengan pengalaman dan keterampilan. Namun, arah peningkatannya sudah terlihat.

• Berbagi masalah baru soal LLM untuk coding. Developer offshore sudah sepenuhnya terintegrasi ke dalam tim. Namun penggunaan LLM begitu sembrono dan sporadis sehingga pull request yang diajukan menjadi mimpi buruk.

  • Saya menggunakan LLM untuk membantu menulis kode, tetapi memakainya dengan sangat hati-hati. Ada penghematan waktu, tetapi bukan peningkatan kualitas. Waktu yang dibutuhkan untuk mencari cara memberi prompt yang benar, memverifikasi output, dan memperbaiki bug kecil mengimbangi manfaatnya.
  • Jangan melakukan "vibe coding" dan berhati-hatilah agar tidak kehilangan pekerjaan.

• "Vibe Coding" bisa mengimplementasikan 80% dari sebuah konsep. Namun untuk membuat sesuatu yang andal, aman, dan bernilai, tetap dibutuhkan manusia yang berpengalaman.

  • Dalam skenario terbaik, 80% itu hanyalah proof of concept. 80% itu seperti QA yang masuk ke bar.

• Baru-baru ini saya mencoba memakai Claude dan OpenAI o3-mini untuk mengonversi kode Matlab ke Python, tetapi hasilnya sangat buruk. Hampir setiap baris penting mengandung kesalahan. Ini tugas yang seharusnya perlu diotomatisasi, tetapi gagal.

• Melakukan "Vibe-TDDing" masih lebih baik daripada tidak punya test sama sekali. Jika Anda memahami coding dan testing, Anda bisa memakai LLM untuk mengurangi efek eksternal yang negatif.

• Setelah membagikan cara membangun SaaS, hal aneh mulai terjadi. Penggunaan API key mencapai batas maksimum, subscription dibypass, dan hal-hal acak dibuat di DB. Ini mungkin ulah iseng.

• Saya merasa tenang soal pekerjaan ketika melihat banyak engineer meremehkan kemampuan dan produktivitas alat coding AI. Saya tidak akan melepas Cursor.

  • Hal yang dilakukan alat AI dengan baik: menulis kode yang repetitif, pekerjaan DSA yang kompleks, tugas sederhana dan membosankan, refactoring terbatas
  • Hal yang tidak dilakukan alat AI dengan baik: memetakan produk/bisnis ke dalam kode, refactoring skala besar
  • Kualitas kode bukan masalahnya. AI tetap sangat membantu untuk meningkatkan produktivitas.