Vibe Engineering

• "Vibe Engineering" adalah sebutan baru untuk cara pengembangan profesional yang memanfaatkan alat coding AI. Berbeda dari 'vibe coding' yang cepat dan tidak bertanggung jawab, ini merujuk pada pendekatan di mana insinyur berpengalaman memanfaatkan LLM sambil tetap menjaga kualitas kode dan akuntabilitas
• Dengan kemunculan agen coding seperti Claude Code, OpenAI Codex CLI, dan Gemini CLI, penggunaan LLM dalam proyek nyata meningkat pesat, dan beberapa insinyur menjalankan beberapa agen secara bersamaan untuk pekerjaan paralel
• Untuk memanfaatkan LLM secara efektif, dibutuhkan praktik software engineering kelas atas yang sudah mapan seperti pengujian otomatis, perencanaan di awal, dokumentasi yang komprehensif, version control, dan budaya code review
• Alat AI memiliki sifat memperkuat keahlian yang sudah ada; semakin banyak keterampilan dan pengalaman yang dimiliki insinyur senior, semakin cepat dan semakin baik hasil yang bisa diperoleh saat memanfaatkan LLM
• Istilah ini menekankan bahwa, dengan pembedaan yang jelas dari 'vibe coding', ini adalah cara memanfaatkan AI yang lebih sulit dan lebih canggih untuk pengembangan software produksi; gabungan kontradiktif antara engineering dan vibe justru memberi kelebihan karena mudah diingat (menyoroti perubahan proses pengembangan seiring kemajuan alat AI dan pentingnya keahlian)

---

Perbedaan antara vibe coding dan vibe engineering

• Vibe coding adalah pendekatan pengembangan software dengan AI yang cepat, longgar, dan tidak bertanggung jawab, sepenuhnya digerakkan oleh prompt, serta tidak memperhatikan bagaimana kode bekerja
• Di sisi lain spektrum, ada cara kerja para profesional terampil yang mempercepat pekerjaan dengan LLM sambil tetap bangga, percaya diri, dan bertanggung jawab atas software yang mereka hasilkan, dan ini disebut vibe engineering
• Yang kurang dikenal adalah kenyataan bahwa bekerja secara produktif dengan LLM sebagai software engineer dalam proyek nyata, bukan proyek mainan, itu sulit; ada banyak kedalaman dalam memahami cara memakai alat ini dan banyak jebakan yang harus dihindari

Kemunculan agen coding dan dampaknya

• Munculnya alat agen coding seperti Claude Code yang dirilis pada Februari 2025, Codex CLI dari OpenAI yang dirilis pada April, dan Gemini CLI yang dirilis pada Juni, membuat kegunaan LLM untuk masalah coding nyata meningkat drastis
  • Alat-alat ini berulang kali memperbaiki kode dan secara aktif mengujinya sampai target yang ditentukan tercapai
• Software engineer yang berpengalaman dan andal menjalankan banyak agen sekaligus untuk menangani beberapa masalah secara paralel dan memperluas cakupan pekerjaan
  • Penulis awalnya skeptis, tetapi setelah mencoba sendiri agen coding paralel, ia mendapati bahwa cara ini melelahkan secara mental tetapi sangat efektif
• Sebagian besar koleksi di tools.simonwillison.net dibangun dengan pendekatan vibe coding yang klasik, tetapi beriterasi bersama agen coding untuk menghasilkan kode berkualitas produksi yang bisa dipelihara di masa depan terasa seperti proses yang sama sekali berbeda

Praktik software engineering yang diperkuat oleh LLM

• Pengujian otomatis: jika ada test suite yang kuat, komprehensif, dan stabil, alat agen coding dapat bekerja cepat. Tanpa tes, agen bisa mengklaim sesuatu berjalan tanpa benar-benar mengujinya, atau perubahan baru bisa merusak fitur lain yang tidak terkait
  • Test-first development sangat efektif khususnya untuk agen yang dapat beriterasi dalam loop
• Perencanaan di awal: saat duduk untuk merangkai sesuatu bersama, memulai dari rencana tingkat tinggi membuat semuanya berjalan jauh lebih baik, dan ini menjadi lebih penting lagi saat bekerja dengan agen
  • Anda bisa mengiterasikan rencana terlebih dahulu lalu menyerahkannya ke agen untuk menulis kode
• Dokumentasi yang komprehensif: seperti programmer manusia, LLM juga hanya bisa mempertahankan sebagian codebase dalam konteks pada satu waktu. Jika diberi dokumentasi yang relevan, model dapat memakai API di area lain tanpa harus membaca kodenya dulu
  • Jika Anda menulis dokumentasi yang baik lebih dulu, model bisa membangun implementasi yang sesuai hanya dari input tersebut
• Kebiasaan version control yang baik: menjadi jauh lebih penting untuk membatalkan kesalahan dan memahami kapan serta bagaimana sesuatu berubah ketika agen coding mungkin telah melakukan perubahan
  • LLM sangat mahir menggunakan Git, dapat menelusuri history sendiri untuk melacak asal bug, dan sering lebih baik daripada kebanyakan developer dalam memakai git bisect
• Otomasi yang efektif: continuous integration, formatting dan linting otomatis, serta continuous deployment ke environment pratinjau juga membantu alat agen coding
  • LLM mempermudah penulisan skrip otomasi cepat sehingga pekerjaan berikutnya bisa diulang dengan akurat dan konsisten
• Budaya code review: jika Anda cepat dan produktif dalam code review, pengalaman bekerja dengan LLM akan jauh lebih baik
  • Jika Anda lebih ingin menulis kodenya sendiri daripada meninjau sesuatu yang ditulis orang lain (atau sesuatu yang lain), ini akan terasa sulit
• Bentuk teknik manajemen yang sangat aneh: mendapatkan hasil baik dari agen coding terasa mirip secara tidak nyaman dengan mendapatkan hasil baik dari kolaborator manusia
  • Anda harus memberi instruksi yang jelas, memastikan konteks yang dibutuhkan tersedia, dan memberikan umpan balik yang dapat ditindaklanjuti terhadap hasil kerja
  • Ini jauh lebih mudah daripada bekerja dengan orang sungguhan karena Anda tidak perlu khawatir menyinggung atau membuat mereka patah semangat, tetapi pengalaman manajemen yang sudah dimiliki ternyata sangat berguna
• QA manual yang benar-benar bagus: selain pengujian otomatis, Anda juga harus sangat piawai menguji software secara manual, termasuk mengantisipasi dan menggali edge case
• Kemampuan riset yang kuat: selalu ada puluhan cara untuk menyelesaikan masalah coding tertentu, dan mengidentifikasi opsi terbaik serta membuktikan pendekatannya selalu penting. Ini tetap menjadi hambatan sebelum melepas agen untuk menulis kode nyata
• Kemampuan deploy ke environment pratinjau: setelah agen membangun fitur, jika ada cara untuk meninjaunya dengan aman tanpa langsung deploy ke produksi, review menjadi jauh lebih produktif dan risiko merilis sesuatu yang rusak berkurang drastis
• Naluri tentang apa yang bisa di-outsource ke AI dan apa yang harus ditangani manual: seiring model dan alat menjadi lebih efektif, ini terus berkembang
  • Bagian besar dari bekerja efektif dengan LLM adalah menjaga intuisi yang kuat tentang kapan alat ini paling tepat digunakan
• Rasa estimasi yang diperbarui: memperkirakan berapa lama proyek akan berlangsung selalu menjadi salah satu bagian tersulit sekaligus terpenting dari menjadi insinyur senior, terutama di organisasi yang keputusan anggaran dan strategi bergantung pada estimasi tersebut
  • Coding berbantuan AI membuat ini semakin sulit; hal-hal yang dulu memakan waktu lama kini jadi jauh lebih cepat, tetapi estimasi sekarang bergantung pada faktor baru yang masih coba dipahami semua orang

Hakikat dan makna vibe engineering

• Untuk benar-benar memanfaatkan kemampuan alat-alat baru ini, Anda harus beroperasi di level tertinggi permainan, yaitu bukan hanya bertanggung jawab menulis kode, tetapi juga mencakup
  • riset pendekatan,
  • keputusan arsitektur tingkat tinggi,
  • penulisan spesifikasi,
  • pendefinisian kriteria keberhasilan,
  • perancangan loop agen,
  • perencanaan QA,
  • pengelolaan pasukan digital intern aneh yang terus bertambah dan akan mencoba menipu bila diberi kesempatan,
  • serta menghabiskan banyak waktu untuk code review
• Hampir semua hal di atas sudah merupakan ciri insinyur software senior
• Alat AI memperkuat keahlian yang sudah ada, dan semakin banyak keterampilan serta pengalaman yang Anda miliki sebagai software engineer, semakin cepat dan semakin baik hasil yang bisa diperoleh dengan bekerja bersama LLM dan agen coding

“Vibe engineering”, benarkah? : pemikiran tentang pilihan istilah

• Apakah nama "vibe engineering" terdengar konyol? Mungkin iya; konsep "vibe" dalam AI pada titik ini terasa agak melelahkan, dan "vibe coding" sendiri dipakai secara merendahkan oleh banyak developer
  • Namun, saya siap merebut kembali vibe untuk sesuatu yang lebih konstruktif
• Saya tidak pernah menyukai pembedaan artifisial antara "coder" dan "engineer" karena selalu terasa seperti semacam penghalang masuk, tetapi dalam kasus ini sedikit penghalang masuk justru memang dibutuhkan
  • Vibe engineering menegaskan pembedaan yang jelas dari vibe coding, dan memberi sinyal bahwa ini adalah cara lain yang lebih sulit dan lebih canggih untuk bekerja dengan alat AI guna membangun software produksi
• Saya suka bahwa istilah ini berpotensi terdengar lancang dan kontroversial; seluruh ruang ini memang masih absurd dalam berbagai hal
  • Sambil mencari cara paling produktif untuk menerapkan alat-alat baru ini, kita tidak boleh menganggap diri sendiri terlalu serius
• Dulu pernah ada upaya untuk memopulerkan istilah seperti AI-assisted programming, tetapi hasilnya nyaris nol; kali ini, menggosokkan vibe dan melihat apa yang terjadi rasanya tidak masalah
• Saya sangat menyukai ketidakselarasan yang jelas antara "vibe" dan "engineering", yang membuat istilah gabungannya terasa main-main dan, semoga, mudah diingat karena kontradiktif secara internal

[m00nlygreat]

Setahuku, belum lama ini juga sempat diberi nama semacam “coding apa sih?” lalu gagal, jadi sepertinya istilah yang paling tepat adalah AI pair programming.

Memberi nama demi bisa mengklaim, “Nama itu yang bikin saya.”

[m00nlygreat]

Seseorang pernah menyebutnya sebagai augmented coding, lalu istilah itu cepat menghilang.

[GN⁺]

Komentar Hacker News

• Belakangan setiap membaca topik seperti ini entah kenapa rasanya murung; dulu aku merasa punya skill pemrograman yang sulit didapat, sangat dibutuhkan, dan dibayar bagus, dan meskipun bahasa atau framework berubah cepat, aku merasa cukup pintar untuk bisa mengejarnya. Tapi ketika orang seperti Simon Willison mengatakan bahwa cara coding baru berbasis agen dan alur kerja paralel seperti ini adalah masa depan, rasanya akan butuh usaha yang luar biasa besar, jadi terasa berat. Aku sudah mencoba agen coding, tetapi justru lebih banyak waktu menunggu, dan mengelola banyak tugas sekaligus juga sulit untuk menjaga flow, jadi terasa kurang menyenangkan. Sampai terpikir ingin pindah ke bidang yang benar-benar berbeda seperti sales.
  • Aku juga sungguh sangat relate dengan perasaan itu. Sebenarnya salah satu tujuanku adalah membantah gagasan bahwa "skill pemrograman akan menjadi tidak berguna dan siapa pun bisa menulis kode dengan LLM". Aku justru percaya bahwa ketika orang yang sudah punya pengalaman development bekerja bersama agen coding atau LLM, nilainya menjadi jauh lebih tinggi. Kita bisa memakai apa yang sudah dipelajari selama ini untuk menghasilkan dampak yang lebih besar dengan alat baru. Seperti yang disebut di post, alat AI berperan memperkuat kemampuan para ahli yang sudah ada. Pemula mungkin bisa membuat UI yang keren dengan ChatGPT, tetapi untuk desain arsitektur, automated testing atau CI/CD, deployment Kubernetes, menjalankan banyak agen secara bersamaan, dan hal-hal semacam itu, mereka tidak bisa begitu saja melakukannya, jadi peran engineer berpengalaman menjadi jauh lebih penting.
  • Aku juga merasa "mengelola banyak agen paralel berskala besar" itu membebani. Dari luar memang terlihat sangat kuat, jadi banyak developer pasti tertarik, tetapi kenyataannya rasanya seperti stres besar dan pekerjaan manajerial. Saat aku pertama kali jatuh cinta pada development, yang menyenangkan adalah coding itu sendiri, dan aku belajar banyak dengan coding seharian. Sekarang setelah punya pengalaman lebih dari 10 tahun, pola pikirku berubah menjadi lebih bisnis: "sebenarnya kenapa kita harus coding ini?" Di rapat, selama divisi-divisi lain hanya bertanya "ini bisa dibuat?", jawabannya hampir selalu "YA". Secara teknis hampir semuanya bisa. Tetapi pertanyaan yang benar-benar penting adalah "seberapa sulit?" atau "kenapa kita harus melakukan ini?" Menurutku, yang penting tetap bukan sekadar kemampuan melakukan iterasi dan merilis banyak hal, melainkan melihat esensinya.
  • Ini benar-benar mewakili perasaanku. Aku juga sama sekali tidak suka pekerjaan menjaga dan mengawasi AI. Ditambah lagi, menakutkan bahwa coding berbasis AI ini membuat kita menganggap wajar kenyataan bahwa kita harus bergantung pada akun perusahaan besar yang tidak jelas dan tak tervalidasi untuk bisa bekerja.
  • Tidak perlu terlalu khawatir. Aku juga sedang membimbing engineer junior di tim kami. Anak ini sangat kesulitan memperbaiki kode, karena begitu sesuatu berjalan, dia langsung puas. Strukturnya buruk, dan ada masalah kecil maupun isu keamanan tersembunyi di banyak sudut. Hal-hal seperti ini bisa terjadi bahkan hanya dengan 3 file Python. Di tim kami ada 10 developer, dan jika memakai LLM bersama-sama, perbedaan kualitas kode justru makin besar sesuai perbedaan pengalaman. Dari yang kurasakan selama 6 bulan sebelum penggunaan LLM diresmikan, jarak antara junior, senior, dan orang yang benar-benar berpengalaman justru makin melebar. Pandanganku mirip dengan Simon.
  • Pada dasarnya, orang yang punya pengetahuan justru akan mendapat kekuatan lebih besar dari alat, bukan sebaliknya. Itu saja yang perlu diingat.
• Di awal 2023, sekitar saat GPT-4 dirilis, ada perubahan serupa juga di industri penerjemahan. Dalam penerjemahan Inggris-Jepang, bidang yang selama ini kutekuni, machine translation untuk pertama kalinya mendekati level manusia. Waktu itu aku berdiskusi dengan banyak penerjemah profesional dan berdebat soal ini dari berbagai sudut, dan seperti di sini, banyak yang mengungkapkan rasa kecewa karena khawatir kemampuan menerjemahkan yang susah payah dibangun akan kehilangan makna. Banyak juga yang merasa bahwa jika LLM dipakai sebagai asisten, bahkan kesenangan intelektual dalam prosesnya ikut hilang. Kebanyakan penerjemah yang kutemui adalah freelancer yang bekerja dengan hati-hati, menerjemahkan kalimat demi kalimat. Mereka tidak terlalu tertarik menjadi pengelola proyek terjemahan skala besar, dan meskipun mereka punya kemampuan komunikasi budaya/konteks tingkat tinggi, motivasinya tetap rendah. Sekarang aku tidak banyak mengambil pekerjaan terjemahan, tetapi aku terus mengikuti perkembangan AI, dan kadang menguji berbagai model lewat pekerjaan terjemahan. Belakangan ini aku bereksperimen dengan sistem terjemahan berbasis multi-LLM, menjalankan beberapa LLM sekaligus agar saling cross-check dan memperbaiki hasil terjemahan satu sama lain. Untuk sebagian dokumen, hasilnya benar-benar sangat mirip dengan terjemahan manusia kelas atas. Biaya API memang tidak murah, tetapi untuk terjemahan penting rasanya sangat layak diinvestasikan. Saat merancang sistem "vibe translation" seperti itu, pengalamanku sebagai penerjemah jelas sangat membantu. Ini mirip dengan vibe engineering yang dibicarakan Simon. Di usiaku sekarang (68), ini tidak apa-apa, tetapi kalau LLM dan sejenisnya muncul di awal karierku, mungkin pada tahun ke-5 sampai ke-10, kurasa aku mungkin akan menyerah menjadi penerjemah.
  • Cerita tentang penerjemahan adalah bahan yang sangat bagus untuk diskusi LLM, terima kasih sudah berbagi pengalaman. Di sisi lain, kebanyakan orang memang tidak memberi nilai yang dalam pada penerjemah. Misalnya, hampir tidak ada yang ingat siapa yang menerjemahkan sebuah buku. Sekarang orang juga tidak membaca buku sebanyak dulu, jadi itu mungkin makin terasa. Dan karena alasan seperti itu, secara tradisional penerjemahan juga cenderung dikontrak/dibayar berdasarkan jumlah kata atau baris, seperti software security yang diperlakukan sebagai pemeriksaan tahap akhir. Bidang terjemahan yang benar-benar punya daya saing masa depan mungkin hanya hukum—karena tetap perlu ada manusia yang memikul tanggung jawab atau risiko gugatan—atau simultaneous interpretation/onsite interpretation, karena perlu tatap muka langsung dan pertemuan nyata.
• Belakangan aku agak heran melihat komunitas teknologi terlalu mendorong klaim bahwa "coding jadi lebih cepat dan produktivitas naik". Suasananya seperti hanya hasil cepat yang penting. Dalam pengalamanku sendiri, LLM sering menghasilkan kode yang bertele-tele dan berantakan. Tentu mungkin lebih cepat dariku, tetapi justru aku merasa kode yang kutulis pelan-pelan jauh lebih baik. Atmosfer sekarang yang menuntut semua hal harus cepat ditanyakan lewat chat, cepat menghasilkan sesuatu, dan cepat masuk production adalah salah satu penyebab menjamurnya produk web seadanya di masa lalu. Daripada main istilah keren seperti vibe coding/engineering, kita seharusnya mendiskusikan dengan serius kenapa kecepatan tetap dibutuhkan meskipun kualitas rendah, dan kenapa otomatisasi/proses itu sendiri tidak bisa diperbaiki lebih jauh. Sebagai contoh, memang kita bisa membuat unit test sangat cepat, tetapi kita juga harus bertanya kenapa dari awal kita memerlukan begitu banyak unit test. Jelas memang diperlukan, tetapi meskipun abstraksi atau sudut pandang tingkat atas berkembang, rasanya alat-alat tingkat bawah justru berkembang lambat.
  • Masalah mendasar dalam perdebatan software engineering adalah bahwa meskipun alat dan bahasa tampak sama, pada kenyataannya perbedaan toleransi, keamanan, compliance, dan standar maintenance itu sangat besar. Ada yang hanya ingin cepat membuat prototipe sederhana, ada juga yang menangani roadmap 10 tahun atau data sensitif. Karena dua sudut pandang ini bercampur, muncullah satu pandangan bahwa kemampuan itu adalah membuat sesuatu dengan cepat, sementara di sisi lain ada kekhawatiran bahwa ini akan berujung pada hasil yang mengerikan. Kedua pihak tidak salah, tetapi rasanya diskusi selalu mengabaikan konteks kerja nyata dan tingkat risikonya.
  • Secara realistis, memang benar LLM sangat membantu kecepatan development. Aku sudah coding lebih dari 20 tahun sejak kelas 5 SD, dan orang-orang di sekitarku juga mengakui kecepatanku, tetapi setelah mengadopsi LLM, skala kerjaku benar-benar membesar drastis. Peta permainannya sudah berubah; sekarang tinggal soal bisa beradaptasi atau tidak. Aku juga punya banyak ketidakpuasan terhadap ketidakpastian masa depan, tetapi kalau kamu engineer dalam posisi serupa, aku sangat paham perasaan itu.
  • Aku ingin mencoba memaparkan logika kenapa kecepatan begitu penting dalam software development. Aku tidak bilang pendapatku pasti benar atau punya data nyata, dan definisi istilahnya pun bisa saja kabur. Untuk sementara, "software trivial" bisa dipahami sebagai sesuatu yang nilai dan solusinya sudah diketahui jelas oleh semua orang, bisa diverifikasi secara otomatis, atau hanya punya satu cara implementasi. Namun kebanyakan software di dunia nyata itu non-trivial. Selalu ada bug, requirement yang terlewat, abstraksi yang bocor, fitur yang tidak berguna, masalah integrasi, isu performa, masalah keamanan, kompleksitas, dan sakit kepala maintenance. Sehebat apa pun developernya, sebaik apa pun kode yang ditulis, masalah-masalah seperti ini tidak terhindarkan. Hal-hal seperti ini baru muncul dan perlahan membaik lewat feedback berulang, pemakaian nyata, maintenance, dan banyak eksperimen. Artinya, kita tidak bisa membuat kode sempurna sekaligus dalam satu kali jadi; kualitas meningkat lewat banyak iterasi. Kualitas software secara keseluruhan ditentukan oleh jumlah "feedback loop" ini. Jumlah total iterasi juga dibatasi oleh waktu yang dibutuhkan untuk menyelesaikan satu loop. Pada akhirnya, makin tinggi kecepatan produksi, makin banyak feedback loop yang bisa dialami, dan menurutku itulah yang membuat software berkembang menjadi lebih baik. Kode yang lambat tetapi berkualitas tinggi pun punya batas jika hanya sempat satu iterasi; sebaliknya, bahkan kualitas rendah pun, jika bisa diiterasi tanpa henti, bisa mencapai hasil yang lebih baik.
  • Lima tahun lagi ini sepertinya akan jadi contoh sunk cost fallacy terbaik di dunia.
• Menurutku, daripada "vibe coding", nama seperti "agentic coding" atau "agentic software engineering" lebih tepat. Alur development-ku dimulai dari code plan Claude, dan langkah pertama selalu membuat spesifikasi yang jelas. Aku memakai TDD dan juga memaksa aturan kualitas kode tersembunyi yang kutetapkan melalui alat otomatisasi. Misalnya, jika melanggar design system maka kode tidak bisa di-commit, dan pengecekan pemisahan layer agar HTTP handler wajib melewati service layer juga diotomatisasi. Aku juga secara berkala mengingatkan model agar mematuhi TDD dengan baik, dan Claude 4.5 mengingat ini jauh lebih baik daripada 4.1. Berkat dasar TDD, code review untuk PR juga jadi sangat mudah. Aku bahkan membuat alat sederhana yang menyerahkan PR dan spec ke Gemini untuk otomatis menunjukkan ketidaksesuaian, kelalaian, dan error. Itu alat cadangan yang bagus. Tetapi pada akhirnya yang terpenting adalah kemampuan menilai sendiri hasil seperti apa yang kuinginkan dan di mana agen mulai menyimpang. Ujung-ujungnya, "input buruk menghasilkan output buruk, input bagus menghasilkan output bagus".
  • Kamu bilang mengingatkan model soal TDD; aku penasaran, dalam vibe coding apakah agen benar-benar menjalankan loop red-green-refactor TDD secara berulang? Atau dia hanya menghasilkan satu hasil akhir sekaligus dalam sekali jalan?
  • Menurutku, alih-alih disebut vibe based, istilah yang lebih cocok adalah "slop-coding".
• Aku ragu apakah nama "vibe engineering" benar-benar tepat. Kenyataannya, ini adalah cara kerja yang memberi agen segala macam constraint: automated testing, perencanaan awal, dokumentasi rinci, formatting/linting kode, QA manual, dan lain-lain. Aku juga mulai vibe coding setelah membaca tulisan Karpathy, dan awalnya sempat mengalami alur seperti mempercayai seluruh proses sambil menjalankan ulang berkali-kali meskipun kode berhenti di tengah. Tetapi setelah menumpuk pengalaman, aku sadar bahwa pada akhirnya model tetap harus dikendalikan. Mengoperasikan agen itu mirip kart racing: perlu ada banyak batasan seperti ban di tepi lintasan. Constraint harness adalah intinya, dan kode itu sendiri menjadi lebih mudah dihasilkan/dihasilkan ulang. Ke depan, yang penting adalah membangun testing dan constraint yang baik untuk hasil kerja AI.
  • Istilah "vibe engineering" terdengar terlalu ringan dan tidak serius. Bukankah istilah netral yang benar-benar menjelaskan fungsinya, seperti "LLM-assisted programming", lebih baik? Memang dampaknya tidak sekuat itu.
• "Perencanaan awal" mungkin juga bisa disebut spec-driven development. Sebenarnya semua development, kalau disederhanakan, mungkin memang berbasis spesifikasi awal. Tetapi inti sebenarnya adalah "bentuk manajemen yang sangat aneh"—yakni memberi instruksi yang jelas, konteks yang cukup, dan feedback yang bisa dieksekusi. Kalau dilihat hanya dari teks, ini malah terasa lebih dekat ke waterfall daripada agile.
• Sekarang tampaknya istilah vibe-coding sudah bergeser makna menjadi istilah umum untuk seluruh coding berbasis AI. Saat bekerja bersama AI, aku sendiri juga merasa lebih mirip pair programming, dan rasanya seperti benar-benar sedang "vibe-ing". Namun, vibe-coding dalam arti aslinya—yang asal menyerahkan semua begitu saja seperti "Take the wheel, LLama of God"—sepertinya akan tetap sering dipakai, jadi menurutku perlu ada istilah baru yang terpisah. Aku ingin mengusulkan “Yolo-Coding”. Ini juga pas dengan alur no-code, low-code, yolo-code.
  • Menurutku lebih baik vibe coder tetap punya citra negatif seperti no-code. Aku juga kurang suka istilah vibe engineer, tetapi bagaimanapun ke depannya nama engineer/developer itu sendiri bisa jadi akan mengandaikan penggunaan agen sebagai hal default, dan developer yang "mengerjakan manual" justru menjadi pengecualian.
  • Di $enterprise, sambil mencari nama baru untuk membedakan "responsible vibing" dan "YOLO vibe coding", kami akhirnya sampai pada istilah "agent assisted coding". Soalnya kami benar-benar butuh singkatan tiga huruf.
  • Makna asli "vibe coding", seperti yang pernah diunggah Ilya Sutskever di Twitter, adalah sekadar memasukkan prompt lalu copy-paste hasilnya untuk dijalankan tanpa review sama sekali. Tanpa analisis atau verifikasi.
  • Secara pribadi, menurutku AI-assisted coding itu levelnya seperti autocomplete atau membantu membaca dokumentasi yang tidak ramah. Sedangkan vibe coding adalah
  • developer sama sekali tidak memahami kode yang ditulis LLM
  • technical debt langsung muncul tanpa code review
  • secara hukum sangat rentan di EU/US karena isu perlindungan hak cipta Menurutku titik paling fatal dari vibe coding adalah bahwa kode yang dihasilkan LLM pada dasarnya tidak bisa dilindungi/tidak bisa didaftarkan hak ciptanya. Memang ada beberapa pengecualian seperti Inggris, tetapi di kebanyakan negara kelihatannya tidak ada harapan.
  • Aku juga pernah membuat slash command seperti /yolo di claude dan menjalankannya begitu saja tanpa panduan berarti.
• Ada eksperimen ketika merpati berinteraksi dengan alat yang mengeluarkan makanan secara acak; karena merasa mendapat hadiah akibat tindakannya sendiri, mereka jadi mengulang berbagai tarian dan gerakan lucu.
  • Bisa jadi tarian lucu itu tak lain mirip seperti "menulis test" atau "membuat rencana".
  • Apakah ada paper atau penelitian yang jadi dasar hal ini? Kalau cari "merpati lucu" yang keluar malah video SNS, jadi susah menemukannya.
• Nama "Augmented Engineering" (AE) lebih bagus. Dengan kekuatan AI kita bisa memperluas kapabilitas dan menghasilkan hasil terbaik, jadi ini "engineering yang diperkuat". AE juga bisa ditafsirkan sebagai "Advanced Engineering". Karena AI memungkinkan kita langsung mengakses pengetahuan teknis terbaru, tentu ini engineering yang lebih maju. Sebaliknya, vibe terasa kurang bagus.
  • Tidak perlu terlalu peduli pada istilah; kalau diberi nama tersendiri justru bisa terasa seolah AI coding hanya relevan untuk sebagian developer. Ke depan, coding tradisional akan menjadi cara yang pengecualian, dan istilah vibe sekarang pun akan segera hilang.
  • Aku keberatan dengan kalimat terakhir itu. AI bukan hanya memungkinkan kita memahami pengetahuan engineering terbaru; ada juga risiko bahwa ia "langsung" menyerap kesalahan berulang, error, miskonsepsi, cacat desain, dan sebagainya dari 1–10 tahun terakhir. Artinya, informasi yang diberikan AI sama sekali tidak boleh dipercaya tanpa kritik; sumbernya harus selalu dicek, dan bahkan perlu dipastikan juga bahwa sumber itu sendiri bukan hasil buatan AI. Dataset terus terkontaminasi, jadi kita harus makin berhati-hati.
  • Aku ingin bertanya apakah "Augmented Engineering" memang harus jadi nama terpisah. Sebenarnya ya cuma "engineering" saja; seperti halnya kalau bekerja sambil melihat buku referensi kita tidak menyebutnya "book-assisted engineering", vibe pun sama. Kalau mau, kita bisa saja menyebutnya "Yolo engineering", atau "Machine Outsourced Irresponsible LMAO Engineering". Dan "Advanced Engineering" di bagian akhir juga terasa seperti membesar-besarkan.
• Simon selalu tepat sasaran, tetapi masalah sebenarnya adalah kata "vibe", bukan "coding". Meski diubah menjadi vibe engineering, nuansanya tetap seperti "jalan terus tanpa tahu apa yang sedang dilakukan". Menurutku, istilah seperti "AI-assisted software engineering" yang membedakan batas-batasnya dengan jelas di kedua ujung jauh lebih baik.

[kimjoin2]

Menciptakan istilah yang tidak bermakna;