Vibe code adalah legacy code

• Vibe coding adalah cara menulis kode dengan cepat mengikuti intuisi dengan bantuan AI, yang pada akhirnya meninggalkan kode yang tidak dipahami, yaitu legacy code
• Legacy code adalah kode yang tidak dipahami siapa pun, yang memicu utang teknis dan masalah pemeliharaan serta meningkatkan kemungkinan terjadinya kesalahan saat menambahkan fitur baru
• Vibe coding bisa menjadi sarana pengembangan cepat untuk prototipe atau proyek jangka pendek, tetapi tidak cocok untuk proyek yang harus dipelihara dalam jangka panjang
• Jika nonahli melakukan vibe coding untuk proyek besar, risikonya seperti memberikan kartu kredit kepada anak kecil
• Bahkan pada 2025, saat mengembangkan bersama AI, penting untuk tetap berhati-hati dan menjaga pemahaman

---

Apa itu vibe coding

• Andrej Karpathy mendefinisikan istilah "vibe coding" sebagai gaya pemrograman di mana AI menulis kode, dan pengguna nyaris tidak memedulikan keberadaan kode itu sendiri
• Pendekatan ini berbeda dari pengembangan perangkat lunak tradisional karena pengembang bisa mendapatkan hasil tanpa sama sekali memahami bagian dalam kode yang ditulis

Masalah legacy code dan utang teknis

• Kode yang tidak dipahami siapa pun pada dasarnya sudah menjadi legacy code
• Kode seperti ini memerlukan banyak waktu untuk dipelihara dan diperbaiki, dan masalahnya meningkat besar saat muncul bug atau ketika fitur baru ditambahkan
• Ditekankan bahwa esensi pemrograman bukanlah membuat banyak kode, melainkan membangun teori konseptual

Vibe coding dan prototyping

• Vibe coding memberi jalan masuk cepat dan pengembangan cepat untuk membuat prototipe atau proyek sekali pakai
• Jika tidak perlu pemeliharaan lanjutan, tidak memahami bagian dalam kode bukanlah beban besar
• Karena itu, pendekatan ini dapat sangat meningkatkan kecepatan pengembangan dan sangat cocok untuk menguji ide-ide baru

Spektrum pemahaman dalam vibe coding

• Vibe coding berada pada spektrum di mana semakin rendah pemahaman pengembang terhadap kode, semakin banyak vibe yang diikuti
• Pada dasarnya, semakin jelas seorang engineer memahami kebutuhan, semakin berkurang vibe coding
• Jika nonprogrammer meminta coding tanpa mengetahui perbedaan antara web dan aplikasi native, atau bagaimana data disimpan, biasanya akan terjadi lebih banyak vibe coding

Vibe coding skala besar oleh nonahli: mirip kartu kredit

• Ketika nonahli mencoba membuat dan memelihara proyek besar dengan vibe coding, situasinya mirip memberikan kartu kredit kepada anak tanpa memahami konsepnya
• Pada awalnya semuanya mungkin terlihat mudah, tetapi kemudian biaya pemeliharaan dan berbagai masalah besar akan mengikuti
• Pada akhirnya, saat 'tagihan' datang, jika kemampuan menyelesaikan masalah tidak memadai, keadaan justru bisa memburuk

Pengembangan serius di era AI 2025

• Andrej Karpathy menekankan bahwa dalam pengembangan bersama AI, kehati-hatian dan kecermatan, serta sikap untuk terus belajar tentang kode yang sudah ada, benar-benar diperlukan
• Penting untuk bertahan dari rasa percaya diri berlebihan AI, dan menggunakan penilaian manusia untuk membedakan kode yang baik dari yang buruk
• Jangan hanya menyerahkan semuanya kepada AI; kode tetap harus dibaca dan dipahami secara langsung

Pemanfaatan alat AI di Val Town

• Val Town mengotomatisasi proses penulisan, eksekusi, pemeriksaan, dan perbaikan berulang kode melalui asisten AI bernama Townie
• Townie adalah alat yang cocok untuk vibe coding, dan bisa digunakan secara bebas atau dikendalikan secara ketat sesuai kebutuhan
• Cara mengembangkan bersama AI berkembang sangat cepat, dan pentingnya landasan teoretis dalam pengembangan perangkat lunak kompleks akan tetap bertahan

Peringatan terhadap vibe coding yang serampangan oleh nonahli

• Bagi nonprogrammer, menghabiskan ribuan dolar untuk melakukan vibe coding atas ide aplikasi raksasa bukanlah cara yang baik
• Pada akhirnya, siapa pun tetap membutuhkan mata manusia untuk membaca dan menganalisis bagian dalam kode secara langsung, dan sering kali merancang ulang dari awal lebih efektif daripada memperbaiki legacy code yang tidak bisa dipahami

Kesimpulan dan saran

• Saat membangun perangkat lunak yang kompleks, fondasi teoretis adalah inti
• Walau cara pemrograman berubah cepat karena kemajuan AI, keahlian pengembang manusia tetap penting
• Jika nonahli mencoba membuat aplikasi skala besar dengan AI, pada akhirnya mungkin lebih baik membaca seluruh kode dan membuatnya ulang

[servent2616]

Ini seperti memberi kartu kredit kepada anak kecil
Perumpamaan yang tepat.
Atau mungkin juga bisa diibaratkan seperti memberi pisau kepada anak kecil.

[actofvalor]

Kalau muncul AI pembuat kode yang sekaligus menambahkan komentar pada kode dan menggambar diagram alur kode, itu akan cukup membantu.

[draupnir]

Ini cerita yang sangat mudah dipahami. Saya sendiri juga benar-benar sedang mengalami sebagian di antaranya…
Sambil penasaran juga bagaimana bagian ini akan berubah seiring perubahan performa model.

[optionzero]

Saya sangat setuju sampai rasanya ingin menepuk lutut. Orang yang tidak paham kode akan berkata "wow" saat melakukan vibe coding, tetapi orang yang paham kode akan berkata "kenapa harus seperti ini?"

[qscwdv531]

Kondisi komentarnya sungguh memprihatinkan.

[kgun9]

Lalu, apakah mobil tidak akan pernah bisa dikendarai sampai kita memahami sepenuhnya struktur internalnya?

[onetoday]

Membuat mobil tanpa memahami struktur internalnya = vibe coding

[hackerst]

Bisa dipakai. Tapi tidak akan bisa membuatnya.

[sinbumu]

Saya rasa ini soal metode dan teknologi; orang-orang yang bilang jangan pakai AI dan harus ngoding manual secara organik itu rasanya seperti orang yang bilang kebenaran sejati adalah mengetuk sempoa alih-alih memakai kalkulator teknik, atau menulis manual alih-alih memakai fungsi Excel.

[elbanic]

Itu analogi yang keliru. Kalkulator teknik, sama seperti kalkulator biasa atau Excel, menghasilkan output yang akurat sesuai nilai input. Jika AI menampilkan persis hasil yang diperkirakan pengguna, mungkin itu tidak akan menjadi teknologi yang begitu berbeda dari banyak teknologi baru yang sudah bermunculan selama ini. Itulah juga alasan mengapa kekhawatiran terhadap keamanan dan halusinasi semakin besar seiring waktu. Artinya, Gen AI tidak bisa dikendalikan. Keterbatasan LLM saat ini harus dipahami dan digunakan di tempat yang tepat.

[tensun]

Saat ini vibe coding masih berada pada tahap awal, dan saya melihat bahwa pada tahun depan atau dua tahun lagi ini akan menjadi metodologi pengembangan yang matang. Seperti devops yang menjadi aidevops, saya pikir ini juga akan menjadi aiagile atau vibeagile.

[GN⁺]

Opini Hacker News

• Ini cerita tentang seorang teman non-developer. Tahun lalu dia meluncurkan SaaS dengan coding sendiri, dan mulai menghasilkan pendapatan hampir tanpa marketing, hanya dari word-of-mouth dan inbound. Dia memakai Replit dan Supabase untuk pengembangan, dan mengingat aplikasi itu makin lama makin kompleks seiring masuknya feedback pelanggan, menurutku itu benar-benar mengesankan. Menurutku, di pasar ini sudah ada dua pemain lama, dan karena temanku menawarkan produk yang jauh lebih modern dengan biaya bulanan yang lebih murah, tampaknya mereka tidak senang dengan itu (produk lama mereka semuanya software desktop untuk Windows). Jadi mereka menyewa hacker untuk menyerang SaaS milik temanku, dan para hacker ini menyerang tanpa meminta uang. Sayangnya, karena temanku ngoding cepat tanpa pengalaman, ada banyak celah keamanan. Pertama, daftar pengguna terekspos di kode frontend sehingga hacker mengirim email ke semua pelanggan. Kedua, hacker mendapatkan kunci Stripe dan memproses refund ke semua pelanggan. Ketiga, hacker masih terus mencoba serangan XSS, dan kadang tag seperti <script>alert()</script> masih muncul di beberapa field. Kesimpulanku adalah, ketika orang tanpa pengalaman melakukan vibe-coding, utang teknis langsung menumpuk. Tapi di saat yang sama, tetap mengejutkan bahwa teman ini bisa membuktikan adanya kelayakan bisnis untuk produknya hanya dalam beberapa bulan tanpa pengalaman engineering. Sekarang dia sedang merekrut developer untuk memperbaikinya. Dia berhasil membuktikan potensi bisnis yang lumayan dengan hanya investasi beberapa ratus dolar, meskipun kodenya rapuh dan rentan secara keamanan, jadi pada akhirnya aku rasa proses itu tetap bernilai

  • Menurutku justru menganggap ini ulah pesaing itu semacam pengalihan tanggung jawab. Yang lebih masuk akal, situs itu terdeteksi oleh pemindai kerentanan otomatis, lalu karena terlalu rapuh, hacker masuk dan iseng. Orang yang sering melihat traffic exploit pada layanan yang terhubung ke internet pasti tahu ini sering terjadi

  • Secara moral ini sama seperti seseorang membangun rumah tanpa pengalaman engineering lalu ada orang datang dan menendangnya sampai roboh. Masalahnya bukan pada vibe coding itu sendiri, melainkan kurangnya pengetahuan yang dibutuhkan untuk mengambil keputusan penting. Masalah seperti ini bahkan bisa berujung pada tanggung jawab hukum

  • Kalau di pasar sudah ada pemain lama, apakah MVP seperti ini benar-benar diperlukan untuk membuktikan kelayakan bisnis? Pada dasarnya tidak perlu menguji apakah orang akan pindah dari penyedia lama jika ditawari harga yang lebih murah. Pelajaran yang didapat temanmu adalah bahwa sebagian pelanggan memang mau membayar di awal (tanpa data retensi), tetapi pada akhirnya dia tetap harus merekrut orang untuk membangun produk sungguhan, dan saat itu keunggulan harga juga akan hilang. Ketika nanti harus serius berinvestasi di marketing, tantangannya akan makin banyak. Pada akhirnya kita kembali sadar bahwa ide saja tidak punya nilai; yang penting adalah kemampuan eksekusi

  • Fakta bahwa temanmu masih bisa terus menjalankan bisnis hampir tanpa tanggung jawab apa pun adalah masalah mendasar di industri ini. Kalau software diatur seketat bidang engineering lain, developer atau perusahaan pasti sudah harus menanggung tanggung jawab hukum atas kebocoran data pelanggan

  • Walaupun bisnisnya terbukti ada, dari sudut pandang pelanggan ini bisa jadi bukan keuntungan melainkan kerugian. Mereka membayar sambil mengekspos data penting ke sistem yang lemah secara keamanan, dan bahkan belum jelas apakah produknya benar-benar bekerja dengan baik. Sekarang katanya akan merekrut developer untuk memperbaikinya, tapi itu tidak akan semudah yang dibayangkan. Aku mendukung AI jika dipakai untuk bahan belajar, produktivitas, atau alat pembelajaran, tapi tanpa campur tangan manusia di tengahnya, hasilnya bisa sangat buruk

• Dulu juga sering ada non-developer atau developer junior yang dengan mudah membuat lalu menyebarkan aplikasi memakai Microsoft Access, Excel, dan sebagainya. Waktu itu juga ada banyak batasan, masalah skalabilitas, dan mimpi buruk pemeliharaan, tetapi pada saat yang sama gelombang seperti itu mendorong developer profesional untuk mempercepat pengembangan solusi yang lebih baik. Hal yang sama terjadi saat PC mulai populer; developer mainframe terkejut melihat betapa kacaunya kode di dunia PC

• Aku sudah bekerja sebagai software engineer hampir tiga puluh tahun, dan sudah membaca semua komentar di tulisan ini. Menurutku, hampir semua argumen yang mengkritik vibe coding juga berlaku sama pada semua codebase yang selama ini kutemui yang ditulis manusia (tentu ada pengecualian)

  • Aku tidak paham kenapa prototipe yang memang dibuat untuk dibuang dianggap buruk. Itu justru tahap paling penting saat memulai bisnis. Hal yang sama berlaku untuk legacy code. Faktanya, sebagian besar kode yang benar-benar menghasilkan uang kemungkinan besar sudah dianggap legacy oleh para developer di organisasi itu sendiri

  • Ada lelucon bahwa begitu sesuatu di-merge ke trunk, saat itu juga ia menjadi legacy code

  • Aku agak setuju, tapi masalah vibe coding adalah ia memungkinkan pendekatan serampangan tanpa riset yang layak, tanpa memahami struktur codebase yang ada, atau meneliti solusi apa yang sebenarnya dibutuhkan. Baru kemarin saja, seorang rekan yang tidak terbiasa dengan Rust membuat fitur baru dengan vibe coding, dan meski di permukaan “berjalan”, sebenarnya hasilnya sangat berantakan (I/O sinkron di dalam konteks async tokio, lock, implementasi channel sendiri, dan sebagainya). Padahal sudah ada abstraksi async yang aman. Dia malah membuat abstraksi baru yang salah. Kalau dia mencari sendiri atau minta bantuan lebih dulu, dia bisa melihat contoh di kode yang sudah ada

• Semua kode pada akhirnya akan menjadi legacy code. Dari sejak aku masih junior, dan dari pengalaman mereview begitu banyak script produksi dan kode service yang ditulis rekan-rekan junior, menurutku pandangan absolut seperti ini terlalu berlebihan. Masalah ini terus berulang di sebagian besar organisasi. Aku paham menulis kritik terhadap kualitas kode berbasis LLM, tetapi developer yang sepanjang kariernya memperbaiki, memperluas, atau me-refactor sistem buatan orang lain pasti sudah sangat paham realitas ini. Selama dunia software engineering belum mengadopsi standar ketat, sertifikasi, tanggung jawab, konsekuensi nyata, dan risiko hukum seperti di mechanical engineering, perdebatan ini tidak terlalu berarti. Industri TI modern justru dibangun di atas filosofi yang sepenuhnya berlawanan: ‘agile’, ‘bangun cepat dan tidak apa-apa kalau rusak’. Rilis cepat, desain minim, deploy sering, kalau salah tinggal rollback, kalau ada outage ya ‘mau bagaimana lagi’. Software diperlakukan seperti mainan. Mungkin 1% orang akan bangga mengaku melakukan semuanya dengan benar, tapi sebagian besar tidak seperti itu

  • Semua yang kamu bilang benar, dan untuk menambahkan, kode pada akhirnya bukanlah sains. Standar tentang kode yang “benar” pada akhirnya selalu bergantung pada situasinya. Kode hanyalah alat untuk mencapai tujuan

• Ada hal menarik yang sedang terjadi sekarang. Orang-orang yang tidak terlalu paham engineering, dan sebagian yang cukup paham tapi tidak menjelaskannya dengan benar, sedang menyebarkan narasi yang salah di internet. Mereka bilang developer junior sekarang 10 kali lebih produktif, bahkan PM pun bisa deploy kode sendiri. Tapi kalau kita tutup mata sejenak dan membayangkan kode yang dihasilkan dalam situasi seperti itu, itu 100% adalah legacy code sekaligus throwaway code. Inti masalahnya bukan AI, atau kemampuan PM mengeluarkan kode langsung dari Figma, atau junior yang asal spam prompt. Alasan sebenarnya mengapa ekspektasi dan kenyataan begitu jauh adalah karena orang gagal membedakan istilah dan konsep yang selama bertahun-tahun dibahas dan didefinisikan.
  Lean prototype dan disposable prototype (bahkan bukan MVP) itu berbeda. MVP hanya bisa dibuat setelah lean prototype berhasil tervalidasi. Produk juga berbeda lagi dari MVP.
  Tool vibe coding sangat bagus untuk cepat membuat disposable prototype, sedangkan IDE dengan LLM lebih cocok untuk membangun produk sungguhan. Pada tahap sekarang, hanya engineer sungguhan yang bisa memakai prompt LLM untuk mengodekan lean prototype, sementara yang lain hanya membuat software sederhana yang berjalan di atas disposable code

  • Kamu bilang “produk itu berbeda dari MVP”, dan rasanya aku ingin mengatakan itu ke hampir semua perusahaan tempatku pernah bekerja. Sekarang dewan direksi dan level C terlalu sering punya sikap “asal ada sesuatu yang keluar kuartal ini”, sehingga developer membuat MVP lalu langsung pindah ke proyek berikutnya. Terlepas dari apakah ini benar-benar vibe coding atau bukan, kenyataannya metrik bisnis naik selama fiturnya terlihat kaya, tak peduli kualitas nyatanya. Faktanya, lingkungan di mana engineer sungguhan (yang sekarang tampaknya mulai disebut ‘developer’) memimpin prototyping itu jarang. Mungkin hanya terlihat di industri game atau sebagian perusahaan tech. Sebagian besar hanya fokus membuat MVP. Vibe coding hanya mempercepat produksi massal MVP, dan kualitas dikorbankan sebesar itu juga

  • Tren penggunaan “definisi istilah” secara campur aduk tanpa substansi tampak makin besar di industri selama 10 tahun terakhir. Istilah-istilah ini awalnya punya konteks yang terbentuk dari banyak buku, diskusi, dan perdebatan panjang selama bertahun-tahun. Saat developer berpengalaman memakai satu istilah, seluruh pengalaman dan konteks perdebatannya ikut terbawa. Tapi pegawai baru menyalin kata-kata itu secara dangkal tanpa konteks, lalu memakainya begitu saja tanpa definisi makna. Akibatnya, tak seorang pun benar-benar memahami apa arti asli tiap istilah, atau kenapa istilah itu cocok untuk situasi tertentu. Misalnya, "'agile', 'technical debt', 'DevOps', dan yang terbaru, ‘vibe coding'" dan seterusnya. Di HN juga ada tulisan tentang semantic drift. Ini fenomena yang umum di industri software.
    Contoh teknisnya bisa dilihat di JavaScript, ketika 'object', 'JSON', 'dictionary', dan 'hashmap' dipakai campur aduk. Masing-masing sebenarnya punya makna berbeda, tetapi bagi developer JS semuanya disamakan menjadi ‘object’. Akibatnya, resolusi bahasa dan konsep itu seperti diremukkan jadi satu ‘piksel’ saja

  • Dulu developer biasa bilang bahwa tiap orang punya ‘sikap mental’ yang berbeda terhadap kode. Tapi sekarang kelelahan developer akibat tidak ada yang benar-benar memahami kode sudah meningkat drastis. Dulu saat situasi seperti ini terjadi, engineer akan maju dan memperbaiki bagian yang rusak agar kembali berguna, sementara arsitek mengurangi kompleksitasnya. Sekarang, di era LLM, kode yang mengalir jumlahnya 100 kali lebih banyak, tetapi engineer dan arsitek justru sepenuhnya tersingkir dari arus itu. Inilah situasi yang kita rasakan langsung saat ini.
    Kalau ada yang bisa menemukan metode pengujian untuk menyelesaikan masalah ini (server MCP untuk TDD, server MCP untuk DDD, atau workflow/arsitektur apa pun), potensinya bisa jadi startup bernilai triliunan. Kita sangat butuh alat yang bisa sangat meningkatkan dan menskalakan efisiensi code review

  • Menurutku kita perlu memperjelas dulu definisi “software yang bekerja”. Misalnya, UI yang dibuat LLM semuanya terlihat sama, dan ada saja yang sedikit salah atau menyembunyikan error. Sekali diuji ke pengguna, masalahnya langsung kelihatan. Selain itu, UI generatif sudah terlalu terobsesi pada tren dan gagal menciptakan sesuatu yang benar-benar baru

  • Pernah lihat cara perusahaan besar menulis kode internal? Tidak jauh berbeda dari vibe coding. Malah kalau LLM dituning agar bisa lolos pentest, setidaknya dia akan mencoba berbuat sesuatu. Perusahaan besar bahkan tidak peduli sama sekali

• Sebenarnya semua kode adalah legacy. Jadi bukan berarti vibe coding itu istimewa hanya karena menghasilkan banyak kode dengan cepat. Pada akhirnya, kode “buatan tanganku sendiri” yang nanti tak bisa dipahami siapa pun juga sama kacaunya. Dari sudut pandang pemeliharaan, semua kode pada akhirnya hanyalah beban. Library juga cuma bisa mengurangi sebagian masalah; yang terlalu sering berubah atau punya antarmuka usang justru menjadi legacy terburuk.
  Orang yang sudah lama menulis kode biasanya sampai pada kesimpulan bahwa jawabannya adalah membuat lebih sedikit, yaitu mengurangi kebutuhan secara keseluruhan. Semua kompleksitas pada akhirnya menjadi ‘masalah yang tidak akan diingat diriku di masa depan’. Faktanya, requirement pun selalu berubah-ubah, dan bahkan requirement yang diucapkan ahli pun bisa salah (dan ‘ahli’ itu bisa jadi diri kita sendiri)

  • Aku tidak setuju dengan klaim bahwa “semua kode adalah legacy”. Ada kode yang kecil, dan developernya masih memegang seluruhnya di kepala sehingga benar-benar tetap ‘live’ sepenuhnya. Definisi legacy yang lebih nyata adalah kode yang sangat besar dan tidak lagi punya pemilik aktif di dalam organisasi. Vibe code memenuhi dua syarat itu begitu ia dihasilkan

  • Legacy berarti saat tidak ada lagi stakeholder yang tersisa, sehingga maintenance maupun memahami konteksnya menjadi sulit

  • Aku ingin bisa menyelesaikan masalah dengan kode sesedikit mungkin. Kuncinya adalah membuat kode itu tidak menjadi masalahku. Yang penting adalah seberapa ‘bocor’ abstraksinya, dan abstraksi yang dibuat LLM saat ini sangat buruk. Masih belum jelas seberapa jauh ini akan membaik.
    Aku ingin berinvestasi pada alat yang membuat pemahaman kode jadi lebih menyenangkan, lebih mudah, dan lebih murah. Temanku Glen sedang mengerjakan proyek yang mungkin relevan: https://glench.github.io/fuzzyset.js/ui/
    Seperti kata Geoffrey Litt, LLM mungkin jauh lebih berguna untuk membuat visualisasi sementara, debugger, dan alat lain yang membantu kita memahami kode kita

  • Semua kode punya risiko, tapi tidak semuanya legacy. Kode hasil vibe coding terasa langsung menjadi legacy karena sejak awal tidak punya konteks atau pemilik

  • Menanggapi keberatan soal apakah semua kode itu legacy: kalau aku bisa langsung menunjuk penyebab bug dalam proyek yang kupahami sangat dalam, dan bisa membayangkan implementasi fitur baru di kepala, itu bukan legacy

• Menurutku era “melihat kode sebagai matematika” sudah berakhir. Software yang cukup besar dan terhubung ke dunia nyata tidak bisa dijamin benar secara sempurna seperti bukti matematis. Sistem di dunia nyata adalah artefak engineering yang bergantung pada jaminan formal, desain berbasis pengalaman, pengujian eksperimental, know-how, dan standar performa.
  Kecenderungan ini akan meluas sampai ke script yang paling kecil sekalipun. Sebagian besar software bahkan tidak perlu dibuktikan secara matematis. Cukup selama ia mencapai tujuannya. Aku tetap menghargai craftsmanship dalam pemrograman, tapi mungkin sudah waktunya melepaskan sebagian dari itu.
  Pada akhirnya, masa depan tampaknya mengarah ke dua pilihan berikut

• Program 100.000 baris dengan 50.000 test yang menjamin semua requirement tetapi sulit dibaca siapa pun, total biaya $50.000 (biaya token API)

• Program 30.000 baris yang dirancang manusia, 3.000 test, abstraksi yang elegan, memenuhi requirement yang sama, total biaya $300.000 (gaji developer)
  Kalau aku adalah konsumen software, tidak peduli detail di balik layar dan hanya melihat harga, aku pasti memilih yang 6 kali lebih murah

  • Kita harus memikirkan saat perubahan dibutuhkan karena requirement eksternal baru. Dalam kasus seperti ini, kalau software itu inti bisnis, mau tak mau harus ganti pemasok. Itulah sebabnya maintenance dan support selalu penting, baik di B2B maupun B2C. Software harus selalu bisa beradaptasi terhadap perubahan

  • Jadi muncullah lelucon seperti, “kode ini hanya kupahami aku dan Copilot. Sekarang hanya Copilot yang masih paham”

  • Untuk pernyataan “sistem yang cukup besar dan terhubung ke dunia nyata tidak bisa dibuktikan benar secara matematis”, orang yang bekerja di bidang formal verification mungkin akan membantah keras, atau diam-diam setuju

  • Dari dua skenario itu, yang perlu ditanyakan adalah mana yang lebih murah dan cepat saat harus di-upgrade versinya. Saat ini aku rasa model developer manusia masih lebih murah, tapi untuk masa depan aku tidak yakin

  • Sebenarnya aku hampir tidak pernah melihat kedua opsi itu dalam dunia nyata

• Tahap perkembangan pamungkas mungkin adalah bahasa pemrograman yang sepenuhnya berorientasi mesin, yang bahkan tidak perlu dibaca manusia. Kenapa LLM harus mengubah sesuatu ke bahasa seperti Python atau Swift yang nyaman dipahami manusia? Bukankah cukup langsung menghasilkan hasil yang bisa berjalan? Kalau begitu, konsep maintenance juga jadi kehilangan makna. Kita memang belum sampai ke sana, tapi rasanya suatu hari akan mengarah ke sana

  • Software yang baik selalu harus berada dalam proses maintenance. Requirement baru akan terus muncul, jadi keyakinan bahwa sekali deploy fitur lalu selesai selamanya itu sendiri sudah seperti lelucon. Itulah mengapa kode, test, dan dokumentasi yang dibuat dengan mempertimbangkan perubahan masa depan sangat penting. Kalau LLM memproduksi massal black-box code yang tak bermakna, menurutku itu hal yang sangat menakutkan. Gagasan bahwa LLM akan mencapai coding setara manusia dan lalu tak ada yang peduli lagi adalah ranah fiksi ilmiah. Coding pada dasarnya hanya satu bagian dari keseluruhan proses membuat software yang benar-benar berguna

  • Bukankah machine code sebenarnya sudah seperti itu? LLM dioptimalkan untuk antarmuka yang dibaca manusia, karena itu ia membuat JSON dan hampir tidak pernah BSON

  • Aku ragu ini sebenarnya menyelesaikan masalah apa. Masalah yang ditimbulkannya justru sangat jelas

  • Rasanya seperti permainan telepon rusak: LLM mempelajari kode untuk manusia, memasukkannya apa adanya, lalu memutar kembali kode itu demi menghasilkan perilaku yang diinginkan. Muncul pertanyaan, apakah tidak mungkin langsung menghasilkan perilakunya saja?

  • Kalau bicara bahasa yang sulit dibaca manusia, Malbolge adalah contoh utamanya. Bahkan program "Hello World" pertamanya pun dihasilkan oleh algoritma genetika

• Saya penulis aslinya. Senang bisa berdiskusi dengan kalian semua

• Istilah ‘vibe coding’ itu terlalu sempurna. Mirip seperti ‘cloud computing’ yang maknanya meluas luar biasa. Awalnya itu berarti menyalakan instance EC2 secara elastis untuk menjalankan pekerjaan lalu mematikannya lagi saat selesai, tetapi karena metaforanya terlalu intuitif, bahkan Gmail pun akhirnya disebut sebagai ‘cloud’.