Saya bisa mengenali saat Anda melakukan 'vibe coding'

• Akhir-akhir ini, di tim, saya bisa dengan mudah mengenali kode yang dihasilkan oleh LLM
• Kode ini tetap jelas dan teruji dengan baik meski tidak mengikuti konvensi proyek
• Mereka mengabaikan berbagai pola atau pustaka yang sudah ada dan menulis implementasi baru sendiri
• Kekhawatiran meningkat bahwa dalam pengembangan perangkat lunak ada kecenderungan mengejar hanya kecepatan
• Pada akhirnya yang penting adalah kualitas dan konsistensi serta kemampuan untuk dipelihara

---

Jejak 'vibe coding'

• Beberapa kode yang ditulis anggota tim akhir-akhir ini terlihat jelas dan fungsional sempurna, tetapi karena tidak mematuhi konvensi khas proyek, langsung terlihat bahwa itu dihasilkan oleh LLM
• Misalnya, meskipun proyek sudah memiliki pustaka pengambilan data, mereka tetap menulis sendiri implementasi permintaan HTTP yang menangani semua kasus pengecualian
• Mereka berulang kali membuat ulang fungsi utilitas dari modul yang sudah ada, dan meski ada mekanisme perubahan konfigurasi per modul, mereka malah mengubah pengaturan global
• Meski budaya menulis kode secara fungsional sudah matang, mereka menulis kode berbasis kelas yang baru
• Kode seperti ini adalah gaya penulisan kode yang manusia tidak akan buat beberapa tahun lalu

Pentingnya Pemeliharaan dan Prinsip Perangkat Lunak

• Dalam pengembangan perangkat lunak, kita sudah lama berupaya merumuskan pola dan standar yang dapat dipertahankan dalam jangka panjang
• Sebenarnya siapa pun bisa membuat kode yang berfungsi, tetapi tantangan sejati adalah membuat kode yang mudah dikelola dan diperbaiki dalam jangka panjang
• Bukan sekadar implementasi fitur, melainkan basis kode yang dapat dipelihara dari waktu ke waktu yang menjadi kuncinya
• 'Vibe coding' dapat meruntuhkan filsafat dan standar semacam itu

Apakah Kecepatan yang Paling Diutamakan?

• Dengan analogi barista baru di kedai kopi yang terburu-buru lalu menumpahkan kopi, ditekankan bahwa obsesi terhadap kecepatan tidak menghasilkan hasil yang benar
• Tim pengembang saat ini juga sama, karena mengejar pembuatan perangkat lunak baru terlalu cepat sehingga terjadi penurunan kualitas
• Pada akhirnya, orang sebenarnya menginginkan hasil yang benar, meskipun menunggu sedikit lebih lama
• Saya dulu mengira mengejar kecepatan itu hanya masalah orang dari profesi non-pengembang, tetapi saya kecewa melihat rekan pengembang juga meninggalkan prinsip dan mengejar kecepatan

Yang Benar-Benar Diinginkan

• Tidak penting bagaimana kode dimasukkan ke IDE
• Yang penting adalah sikap pengembang yang peduli pada kualitas
• Walau diakui LLM adalah inovasi teknis yang besar, tetap ditegaskan bahwa tanggung jawab membuat perangkat lunak nyata ada pada pengembang
• Disarankan untuk memahami dan memanfaatkan prinsip-prinsip yang sudah ada secara tepat, seperti "prompt yang lebih baik", "pemilihan pustaka yang benar", "menyediakan contoh", dan "bekerja dalam file kecil"
• Kami mengingatkan agar kualitas dan kemudahan pemeliharaan kode tidak diserahkan hanya pada "bobot" model

[GN⁺]

Opini Hacker News

• Tidak ada orang yang akan membuat implementasi HTTP fetching baru jika library pengambilan data yang sudah ada di proyek sudah mencakup semua edge case, tidak akan membuat ulang jika modul fungsi utilitas yang dibutuhkan sudah ada, tidak akan mengubah konfigurasi global dari modul individual padahal itu bisa dilakukan, dan tidak akan tiba-tiba membuat class baru di tim yang mayoritas memakai pendekatan fungsional; saya ingin bekerja di tim seperti itu, tetapi kenyataannya banyak developer sering mengulangi hal-hal semacam ini

  • Sejujurnya, di proyek besar hal seperti itu sangat mudah terjadi kalau dokumentasinya buruk; dokumentasi kode di proyek riset akademik tempat saya bekerja pada dasarnya berkata bahwa kodenya sudah cukup self-documenting, lalu hanya menyinggung singkat soal konfigurasi CMake, build, dan cara benchmarking; aturan internal atau konvensi harus dipahami sambil jalan lewat pengalaman langsung; ketika orang baru masuk, mereka sering membuat ulang fitur yang sebenarnya sudah ada atau malah mengubah konfigurasi global; pada akhirnya, mengindeks codebase dan langsung bertanya ke LLM adalah cara terbaik (orang-orang kunci proyek sudah pergi atau baru membalas jauh belakangan)

  • Saya rasa banyak yang melewatkan poin penulis; kalau kecepatan adalah kebajikan tertinggi, hal-hal seperti itu akan terus berulang; jika kecepatan adalah nilai absolut, maka output harus meningkat secara eksponensial untuk menutupi utang teknis; jika ada faktor lain selain kecepatan yang juga penting, maka utang harus dikelola dan dilunasi dengan bijak; tetapi belakangan ini rasanya orang hanya menumpuk utang besar dan berharap semuanya akan baik-baik saja, dan banyak orang memang buruk dalam mengelola utang

  • Banyak orang akan terus menemukan kembali roda jika ada kesempatan, mengabaikan konvensi yang diharapkan, atau memakai pola campuran; penulis mungkin menyebut ini sebagai 'vibe coding', tetapi sebenarnya ini bukan masalah khas LLM saja, melainkan sesuatu yang bisa terjadi pada siapa pun saat terburu-buru mengejar hasil atau saat kurang pengalaman; frasa 'kode yang tidak akan pernah ditulis oleh siapa pun di tim' memberi kesan bahwa ini mungkin keluhan yang diarahkan pada orang tertentu; kita perlu hati-hati saat menerapkan sudut pandang seperti ini ke konteks lain

  • Saya juga pernah melihat developer menambahkan ORM library tambahan; ORM pertama sudah cukup, tetapi mereka tetap menambahkan yang kedua karena 'sedang populer'; baik developer maupun LLM punya bias masing-masing; memahami aturan dan pola dalam proyek lalu bekerja di dalam kerangka itu sangat penting; membangun sesuatu dengan caramu sendiri tanpa mempertimbangkan konteks itu sangat berbahaya; untuk manusia, ini bisa diatasi dengan budaya code review dan mendorong kebiasaan membaca kode, tetapi untuk LLM, semua pola dan aturan harus dipandu dengan jelas; kalau tidak, risikonya tinggi untuk menghasilkan kode yang tidak selaras dengan proyek; yang penting adalah menetapkan nilai dan standar yang jelas secara eksplisit

  • Saya pernah bekerja di tim sebagus itu; banyak proyek yang sangat penting dijalankan dalam skala kecil (2-4 orang); di lingkungan seperti itu, lebih mudah membangun budaya pengembangan dan kesepakatan yang menyeimbangkan kualitas dan kecepatan; di tim seperti itu, siapa pun, manusia maupun LLM, tidak akan pernah mendapat persetujuan PR untuk kode seperti di atas

• Secara pribadi saya menganggap LLM sebagai developer yang sangat junior; ia berusaha bekerja dengan baik dan mengikuti instruksi, tetapi kurang memahami codebase dan pola-pola yang ada; kita harus membimbing setiap langkah secara langsung dan bahkan menjelaskan potensi kesalahan, memberi tugas yang spesifik dan kecil, lalu meninjau kodenya dengan cermat; seperti saya, ia perlu lebih dulu memetakan model data di kepala sebelum masuk ke kode; penjelasan yang konkret itu penting; satu aturan tidak tertulis saya adalah selalu menaruh komentar blok di bagian atas file untuk menjelaskan isi file; ini berfungsi sebagai prompt kedua saat sesi dimulai ulang; pendekatan ini bekerja dengan baik tanpa terasa 'ajaib', tetapi di tengah jalan sekitar 30% pekerjaan tetap perlu berupa perapian kode, rename, dan refactor agar hasilnya enak dilihat; meski begitu, dengan adanya LLM saya bisa bekerja jauh lebih cepat daripada menulis semuanya sepenuhnya dengan tangan

  • Ungkapan "developer junior" atau "copilot" kadang tidak sepenuhnya menangkap kelebihan dan kekurangan LLM; tidak seperti manusia biasa, ia mudah lupa dan bisa membuat kesalahan yang sangat mendasar, tetapi ada juga hal yang ia lakukan lebih baik daripada saya (misalnya isu off-by-one terkait array), dan ia juga mengetahui hampir semua hal di internet secara ensiklopedis; setelah benar-benar memakainya, saya merasa LLM itu mirip anjing pemburu; pemiliknya yang harus memimpin perburuan dan menyelesaikannya sendiri

  • Perbedaan LLM dan developer junior ada pada kemampuan belajar; developer junior bisa terus belajar dan berkembang, tetapi LLM tidak; semakin banyak instruksi yang dimasukkan ke prompt, semakin besar kemungkinan ia malah melupakan hal-hal itu dan kembali ke jawaban generik; setiap kali prompt baru dimulai, kita harus membimbingnya lagi dari nol

  • Menurut saya LLM tidak jauh berbeda dari mencari kode di internet lalu copy-paste; pada akhirnya developer tetap harus memeriksa sendiri apakah kodenya benar-benar berfungsi; belakangan ini, karena kesehatan mata, saya harus bekerja dan beristirahat dalam interval 20 menit, jadi efisiensi jadi makin penting; LLM jauh lebih cepat daripada manusia dalam menghasilkan kode, jadi bahkan jika hanya dipakai untuk menangani area yang dasar pun itu sudah sangat menguntungkan; saat ini saya sedang membuat struct untuk SIMD dengan Unity C# dan LINQ, dan cukup dengan memberi tahu syarat yang saya inginkan ke LLM, saya bisa mendapatkan kode atau string yang diinginkan jauh lebih cepat daripada copy-paste manual; konsep memakai AI seperti HUD terasa sangat nyata; yang dibutuhkan bukan AI pembuat seluruh program, melainkan alat bantu pengembangan kuat untuk unit kerja kecil

  • Bagi saya LLM adalah pengganti StackOverflow yang jauh lebih baik; saya bisa langsung menanyakan apa yang ingin saya tahu dan mendapat jawaban yang akurat; dari jawaban itu saya menulis ulang ke kode saya sendiri atau hanya menghasilkan fungsi tertentu; sebelum menyalin apa pun, saya selalu berusaha memahami kodenya sepenuhnya; kadang saya bahkan pernah bertanya-tanya apakah secara karier lebih menguntungkan untuk mengirim PR 400 ribu baris ke proyek open source dalam bahasa yang tidak terlalu saya kuasai daripada bekerja dengan jujur dan berorientasi kualitas; ini karena kenyataannya tahun pengalaman sering dinilai lebih penting daripada skill

  • Agar LLM bisa bekerja dengan sukses, menurut pengalaman saya lebih baik membatasi perannya pada tahap coding nyata, bukan tahap berpikir; tugas perlu dipecah kecil-kecil dan spesifikasi, file yang akan diubah, lokasi contoh referensi, dan sebagainya harus dijelaskan sedetail mungkin agar tingkat keberhasilan tinggi; tidak harus terlalu remeh, tetapi semakin banyak petunjuk, semakin besar peluang berhasil; kode yang dihasilkan pun saya periksa sendiri potong demi potong dengan git add -p; memang butuh waktu untuk persiapan dan review, tetapi tetap jauh lebih hemat waktu dan energi daripada menulis semuanya sendirian atau membiarkan kode yang berantakan apa adanya

• Risiko terbesar dari vibe coding adalah developer yang sudah mahir hanya menjadi sedikit lebih cepat, sedangkan developer yang kurang kompeten bisa menghasilkan jauh lebih banyak kode buruk dengan jauh lebih cepat; pertanyaannya adalah apakah developer seperti itu bisa benar-benar berkembang lewat vibe coding, atau justru hanya akan mandek di situ

  • Dari pengalaman saya, bahkan developer mediocore pun bisa sangat cepat berubah menjadi developer yang buruk; alasannya adalah rasa percaya diri yang keliru dan lonjakan output kode; kode buatan AI hampir tidak mempertimbangkan arsitektur keseluruhan, aliran informasi, atau prinsip single responsibility; ia cenderung dikonstruksi agar aman dengan mengembalikan placeholder alih-alih melempar exception; akibatnya kode pemanggil harus terus-menerus memeriksa apakah nilai hasil itu placeholder atau bukan; kalau parameter input awalnya jelek, AI juga akan berusaha 'memperbaikinya sendiri', sehingga struktur gather_parameters → call → process_results diabaikan; dan ketika masuk ke pengujian, masalahnya menjadi jauh lebih besar

  • Sekarang banyak developer akan menemukan kembali konsep net-negative programmer, yaitu programmer yang keberadaannya justru menurunkan kualitas proyek

• Menurut saya, sumber daya yang paling kurang di sini adalah kepedulian; vibe coding sendiri bukan penyebab kurangnya kepedulian, AI hanyalah alat; semua isu yang disebut penulis juga berlaku sama pada developer junior manusia dan bisa diperbaiki dengan pengarahan atau komunikasi yang lebih baik; saya tidak melihat AI sebagai penyebab menurunnya kepedulian terhadap kualitas (orang yang memang tidak peduli dari dulu juga begitu); sanggahan yang sering muncul adalah bahwa ini menghilangkan peluang melatih junior, tetapi sering kali AI dipakai sebagai solusi sementara karena memang tidak ada kapasitas lain (startup saya juga begitu, sulit merekrut); alat AI bisa mengubah standar kualitas software, dan saya rasa bagian ini masih sangat mungkin terus berubah ke depan

• LLM seharusnya memakai bukan hanya konteks kondisi saat ini, tetapi juga riwayat commit sebelumnya; banyak codebase sedang bermigrasi bertahap dari pola A ke B dan berbagai pola hidup berdampingan; karena migrasi tidak bisa dilakukan sekaligus, biasanya yang lama dan yang terbaru akan terus bercampur; seperti contoh HTTP tadi, meskipun LLM mengenali polanya, pilihan mana yang harus diikuti sering bergantung pada keberuntungan

  • Saya pernah bekerja di codebase besar yang selama lebih dari 20 tahun mengalami merger, pergantian nama, akuisisi, dan sebagainya; masih ada contoh pemanggilan API yang sangat lama, sementara sebenarnya ada kode yang lebih baru di tempat lain, tetapi banyak yang dibiarkan tetap ada untuk pelanggan tertentu; ada juga banyak API serupa tanpa dokumentasi sama sekali, jadi saya harus mencari satu per satu mana yang harus dipakai untuk mendapatkan data yang saya inginkan

  • Salah satu caranya adalah memakai file seperti CLAUDE.md untuk memberi arahan jelas seperti "ikuti pola ini, hindari yang itu"

  • Tetapi menurut saya, yang lebih efektif adalah memberi tahu dengan sangat konkret bagaimana cara kerja tiap bagian beserta contohnya

  • Masalahnya, kemampuan memahami konteks seperti ini sendiri sering sangat kurang pada orang yang melakukan vibe coding; banyak orang memang sudah kurang pengalaman coding bahkan sebelum ada LLM

  • Ini hanya mungkin kalau commit message ditulis dengan baik; pada praktiknya kebanyakan isinya hanya seperti "ubah file ini" atau "perbaiki bug"

• Saat memanfaatkan LLM, alat otomatis seperti linter, formatter, dan strict type check sangat membantu; terutama ketika kontribusi kode datang dari orang yang tidak memahami style kode atau aturan implisit, atau dari agen LLM, sistem bisa memeriksa kode secara otomatis dan langsung memperbaiki hal-hal yang bisa diperbaiki; hal yang sama berlaku untuk testing; sistem verifikasi otomatis sangat berguna untuk menjaga kualitas, baik untuk manusia maupun agen

  • Saya rasa alat-alat seperti itu pada kenyataannya tidak mencegah sebagian besar contoh vibe coding yang disebut di artikel

  • Alat-alat itu juga kadang hanya merapikan permukaan sambil menyembunyikan masalahnya

• Semua AI assistant utama pada dasarnya sudah punya cara bawaan untuk meredakan masalah ini, seperti /init di Claude Code, /Generate Cursor Rules di Cursor, dan sebagainya; penerapannya juga bisa dilakukan ke seluruh organisasi dengan cara yang lebih otomatis daripada sekadar context engineering sederhana; pada akhirnya menarik juga melihat bagaimana alat-alat ini membelah komunitas developer

  • Pada praktiknya, sejelas apa pun aturan di CLAUDE.md, sering kali CC (Claude Code) tetap mengabaikannya; semakin panjang percakapannya, terasa seperti masalah yang sama terus berulang, dan sampai sekarang saya belum menemukan solusi yang benar-benar memuaskan; karena itu saya rasa tidak tepat menganggap artikel ini sekadar bernada anti-AI

  • Saya sedang mengevaluasi ulang Cursor; alasan kenapa kecepatannya tidak sebaik yang diharapkan bukan cuma error kecil (seperti LM mengubah : menjadi ,), tetapi juga karena codebase-nya terlalu besar, tua, dan kualitasnya sangat bervariasi; pada akhirnya LLM lebih sering meniru pola yang paling umum dipakai (= pola yang buruk); bahkan ketika diberi instruksi jelas seperti "jadikan bagian ini referensi", ia tetap terpengaruh oleh keseluruhan codebase; sekalipun ditetapkan sebagai rule, rasanya tidak jauh berbeda dari menuliskannya langsung di prompt; saya penasaran apakah ada solusinya

  • Inti masalahnya bukan pada alat, melainkan pada 'coder' yang lebih mementingkan vibe; tidak ada kepedulian, dan penulisan kodenya pun longgar

• Menurut pengalaman saya, hampir semua isu ini adalah akibat context window yang terbatas dan 'context engineering' yang suboptimal; jika LLM benar-benar diberi konteks penting seperti fungsi global, ia relatif bisa memanfaatkannya dengan baik; masalahnya adalah bagaimana menyediakan dan menjaga konteks yang tepat itu secara terus-menerus tanpa terputus; saya berharap akan ada banyak kemajuan ke depan dalam bentuk seperti sub-agent

  • Tadi dibilang "kalau agen tahu penjelasan fungsi global, ia bisa memakainya dengan baik", tetapi sebenarnya tidak ada entitas bernama 'agen'; itu hanyalah fungsi matematis yang menghubungkan input dan output; membandingkan LLM dengan manusia itu tidak akurat; manusia dan mesin benar-benar berbeda

• Saya rasa semua ini benar; cara terbaik memakai LLM adalah seperti compiler yang menyediakan satu tingkat abstraksi di atas assembly: jika kebutuhan serta input-output dijelaskan dengan jelas, ia bisa membuat kode sebagai terjemahan logis; karena itu, kebingungan atau entropy pada input harus diminimalkan; pada dasarnya LLM adalah translation engine; ia lebih efisien dipakai untuk 'menerjemahkan' daripada untuk 'menghasilkan'; meski begitu, model-model baru terus muncul secara berkala dengan kecerdasan dan intuisi yang semakin baik, sehingga hasilnya makin bagus meski kita tidak terlalu banyak campur tangan; pada akhirnya akan datang masa ketika LLM menghasilkan hasil yang lebih baik daripada developer manusia untuk tugas apa pun, dan hal yang sama akan berlaku untuk peran manusia lainnya

  • Itu analogi yang keliru; LLM bukan mesin yang 'mengompilasi' bahasa alami menjadi kode tingkat tinggi; bahasa pemrograman dan bahasa mesin menuntut sistem makna yang jelas dan konsisten, sedangkan bahasa alami sejak awal berada di lapisan abstraksi yang berbeda; LLM yang sama pun bisa menghasilkan output berbeda bila seed atau versinya berubah, sedangkan compiler untuk input yang sama harus selalu menghasilkan output yang sama

  • Saya tidak bisa setuju bahwa LLM adalah lapisan abstraksi seperti compiler; pada praktiknya LLM hanyalah generator token acak; saya belum pernah melihat hasil yang dibuat dengan bantuan LLM yang benar-benar layak dipakai; optimisme teknologi seperti singularity atau keyakinan bahwa data bisa didapat tanpa batas tidak punya dasar yang realistis; pada akhirnya, memperoleh data berkualitas tinggi itu sangat mahal; untuk saat ini, prediksi optimistis seperti itu tidak banyak berarti

• Saya terlambat menyadari dibanding penulis bahwa "banyak orang lebih menginginkan kopi yang cepat dan murah daripada kopi yang enak"; di dunia nyata, mayoritas memang lebih mementingkan kecepatan dan harga daripada kualitas

  • Melihat populernya mesin kopi Keurig saja sudah cukup untuk memahami kecenderungan itu

[dkmin]

Tulisan di HN malah lebih manis daripada artikelnya.