- Baru-baru ini, kategori layanan baru bernama "pembersihan vibe coding" muncul di industri TI:
Vibe Coding Cleanup as a Service
- Seiring kenyataan bahwa sebagian besar kode yang dihasilkan AI tidak layak untuk production mulai terlihat jelas, muncul pasar layanan baru yang merapikan dan memperbaikinya
- Setelah Andrej Karpathy mendefinisikan "Vibe Coding" pada awal 2025, 92% pengembang menggunakan alat AI, tetapi penurunan kualitas kode dan masalah kerentanan keamanan juga terlihat serius
- Dalam praktiknya, para pengembang kini secara khusus menangani inkonsistensi, duplikasi, dan logika yang tidak masuk akal yang dibuat AI, sementara marketplace khusus dan layanan konsultasi terus meluas
- AI unggul untuk tugas-tugas kecil, tetapi karena tidak mempertimbangkan konteks sistem, AI menghasilkan utang struktural dan masalah keamanan dalam jumlah besar, yang pada gilirannya melahirkan peluang industri baru bernama "ekonomi pembersihan"
- Agar perusahaan berhasil memanfaatkan AI coding, prototipe bisa diserahkan ke AI, tetapi mereka perlu berinvestasi pada tenaga ahli untuk arsitektur, keamanan, dan proses pembersihan pengujian
Muncul dan menyebarnya vibe coding
- Pada awal 2025, Andrej Karpathy menggunakan istilah "vibe coding", sehingga konsep ini mulai mapan
- Cara menghasilkan seluruh fungsi melalui percakapan bahasa alami
- Menyebar cepat bersama harapan bahwa produktivitas bisa meningkat 10 kali lipat
- Menurut GitHub, 92% pengembang menggunakan alat AI untuk coding
- Copilot menghasilkan miliaran baris kode setiap bulan
- Namun, menurut analisis GitClear, penggunaan kode AI menunjukkan tingkat perubahan kode 41% lebih tinggi
- Kode yang dibatalkan atau ditulis ulang dalam 2 minggu meningkat tajam
- Dalam riset Stanford, pengembang yang menggunakan bantuan AI lebih sering menulis kode yang kurang aman sambil cenderung percaya bahwa kode itu lebih aman
- Alat AI memicu berbagai anti-pattern karena tidak ada validasi input, penggunaan dependensi usang, keputusan desain yang ambigu, dan lain-lain
Realitas ekonomi pembersihan
- Belakangan ini, di industri TI mulai muncul diam-diam wilayah layanan baru bernama pembersihan vibe coding
- Awalnya ini bermula sebagai lelucon tentang "memperbaiki kode kacau buatan AI", tetapi kini mulai menjadi peluang bisnis nyata
- Menurut investigasi 404 Media, beberapa pengembang membangun karier hanya dari merapikan kode AI
- Membongkar inkonsistensi, duplikasi, dan logika aneh yang dijuluki "AI spaghetti"
- Ulam Labs mengiklankan Vibe Coding Cleanup sebagai layanan inti
- Marketplace khusus bernama VibeCodeFixers.com juga telah muncul
- Dalam beberapa minggu, lebih dari 300 ahli bergabung dan puluhan proyek berhasil dipasangkan
- Pelanggan tipikal: "startup yang telah menghabiskan kredit OpenAI senilai ribuan dolar dan memiliki prototipe yang hanya setengah jalan berfungsi"
Mengapa kode AI gagal
- Masalahnya bukan AI menulis kode buruk dengan sendirinya, melainkan AI tidak memahami konteks sistem dan menulis kode yang dioptimalkan secara lokal
- Akibatnya, pola inkonsistensi, logika duplikat, dan celah keamanan menumpuk dan menciptakan utang teknis
- Menurut riset Georgetown University, setidaknya 48% kode yang dihasilkan AI mengandung kerentanan keamanan
- Paparan rahasia, penggunaan library lama, race condition yang muncul saat beban tinggi, dan sebagainya
- Yang lebih serius, pengembang sendiri sering tidak cukup memahami kode yang dihasilkan AI sehingga gagal menemukan masalah dengan benar
- Thoughtworks menyebut ini sebagai "utang kapabilitas"
- Fenomena ketika tim kehilangan kemampuan memelihara kode dan jatuh ke ketergantungan pada AI
Peluang pasar
- Pasar pembersihan tumbuh sangat cepat, tetapi sulit mengukur angka pastinya
- Gartner memperkirakan 75% pengembang enterprise akan menggunakan bantuan kode AI pada 2028
- Diperkirakan kebutuhan pembersihan akan muncul di sebagian besar proyek
- Bahkan jika hanya sebagian yang membutuhkan pembersihan, skala pasarnya tetap akan sangat besar
- Dari sisi ekonomi pun menarik
- Startup membuat MVP dengan cepat menggunakan AI, tetapi kemudian tetap harus mengeluarkan waktu dan biaya yang sama untuk merapikannya
- Meski begitu, kecepatannya masih lebih tinggi dibanding pengembangan tradisional
- Para ahli pembersihan menagih $200~400 per jam
- Layanan yang diproduktisasi seperti paket tarif tetap, audit kode AI, dan pipeline "Vibe-to-Production" juga terus meluas
- Menurut Thoughtworks, dalam proyek yang memanfaatkan AI, rasio refactoring menurun, perubahan kode meningkat lebih besar, dan proses pembersihan berskala besar menjadi wajib sebelum benar-benar masuk ke production
- Banyak perusahaan konsultasi mulai merekrut talenta yang khusus menangani pembersihan atau remediasi kode AI
- Kesimpulannya, pasar pembersihan itu nyata, tumbuh cepat, dan masih memiliki banyak area yang belum tergarap
Dampaknya terhadap engineering
- Sedang berlangsung perubahan mendasar dalam metodologi pengembangan software
- Proses pengembangan sedang direstrukturisasi menjadi sistem pembagian kerja: AI mengimplementasikan → manusia menangani arsitektur, pengujian, dan pembersihan
- Gergely Orosz mengibaratkan alat AI sebagai "junior developer yang sangat bersemangat", menekankan bahwa AI menulis kode dengan cepat tetapi selalu membutuhkan pengawasan
- Namun AI selalu berada di level junior dan tidak tumbuh menjadi senior, sehingga peran ahli pembersihan akan selalu dibutuhkan
- Jalur karier baru juga terbuka
- Junior developer yang menguasai keterampilan pembersihan bisa meraih gaji setara senior dalam 2 tahun
- Senior yang memahami kekuatan dan keterbatasan AI dapat menciptakan nilai yang tinggi
- Perusahaan yang berhasil bukanlah yang paling banyak memakai AI, melainkan yang membangun proses pembersihan secara sistematis
- Organisasi yang membangun proses pembersihan yang kokoh bisa memperoleh keunggulan kompetitif di pasar
Posisi Donado Labs
- Berdasarkan banyak pengalaman merapikan vibe code, Donado Labs menekankan bahwa AI berguna untuk akselerasi, tetapi proses pembersihan oleh ahli tetap wajib
- AI digunakan untuk prototyping dan pekerjaan berulang, sementara arsitektur inti, keamanan, dan pengujian ditangani manusia
- Melalui layanan "Vibe to Production", mereka menata prototipe AI hingga setara level enterprise
- Termasuk pengujian, penguatan keamanan, hingga dokumentasi
- Perusahaan yang berhasil memanfaatkan AI coding bukan organisasi yang paling banyak menggunakan AI, melainkan organisasi yang menggunakan AI secara cerdas dan berinvestasi pada pembersihan
- Kuncinya adalah menjalankan pembersihan sebelum utang teknis menumpuk
- Terhadap klaim bahwa AI akan menggantikan programmer, pertanyaan "siapa yang akan merapikan kode itu?" justru menjadi peluang bisnis yang sesungguhnya
4 komentar
Di awal kemunculan GPT, ada orang-orang yang saat memesan jasa coding bilang mereka sudah membuat prototipe dengan AI dan tinggal sedikit penyelesaian lagi, lalu menekan harga habis-habisan.
> Para ahli penataan mengenakan biaya 200~400 dolar per jam
Tapi, sejujurnya, apa benar ada orang yang melakukan ini?
Bahkan sebelum munculnya vibe coding, saya pernah berpikir akan bagus kalau ada layanan yang merapikan kode yang berantakan, dan ternyata ada juga yang membuatnya seperti ini. Tapi, sepertinya perusahaan kami tidak akan mengadopsinya, huhu
Dulu sempat tren jasa freelance untuk membetulkan jari pada gambar AI.. sekarang itu pun sudah tidak dilakukan lagi.
Sepertinya cleanup AI juga akan menempuh jalan yang sama.
Komentar Hacker News
Saya sudah cukup lama menangani proyek “perapihan struktur” lewat bisnis saya.
Dulu sumbernya biasanya kode yang nyaris tidak berjalan dari agensi outsourcing, tapi sekarang tampaknya sumbernya bergeser ke LLM.
Pada akhirnya, masalah yang sama terus berulang.
Yang berubah hanya cara penghematan biayanya.
Memang ada alasan jelas kenapa orang memilih jalan pintas, tetapi masalah yang sebenarnya muncul ketika mereka tidak benar-benar sadar bahwa itu juga bisa menimbulkan biaya.
Entah sumbernya manajer, karyawan, atau tenaga outsourcing, hasilnya mirip-mirip saja.
Saya belum pernah secara khusus mengiklankan layanan perbaikan struktur untuk platform vibe coding, tapi mungkin sekarang memang waktunya untuk mulai mencoba.
Pasar software Australia kecil, jadi hasil eksperimen seperti itu jarang terdengar.
Menurut saya, perbedaan vibe coding dan pengembangan outsourcing ada pada volume kode yang dihasilkan.
Saya pernah sekali membuat helper script sederhana dengan vibe coding; kalau saya tulis sendiri, mungkin panjangnya cuma sekitar sepertiga dari kode sekarang, dan sebagian besar edge case mungkin sama sekali tidak akan saya tangani juga (ada penanganan exception yang tidak perlu, tapi ada juga yang benar-benar membantu).
Yang saya lakukan hanya memindai kodenya dan menghapus satu baris penghapusan file temp karena ada kemungkinan home directory terhapus secara tidak sengaja.
Tapi belakangan, saat saya mengerjakan data yang lebih dalam, saya sadar beberapa file temp tetap hilang, dan ternyata ada dua lokasi lain yang juga berisi kode penghapusan itu.
Sebenarnya jumlah kodenya terlalu banyak untuk dibaca manusia, jadi memeriksa semuanya tidak realistis.
Meski begitu, dari sisi kecepatan memang efisiensinya luar biasa besar.
Ke depannya saya berencana menjalankan pengujian dengan AI di sandbox, alih-alih membaca kodenya dengan teliti.
Ada perbedaan besar, khususnya pada alat yang punya “plan mode” seperti Claude Code.
Akhir-akhir ini saya banyak memakai Claude Code di kantor, dan saya selalu memulai di plan mode dengan bertanya lewat percakapan tentang “bagaimana ini sebaiknya diimplementasikan”, lalu mematangkan rencana detail menjadi desain yang baik lewat beberapa putaran diskusi.
Setelah itu AI menjelaskan dengan tepat kode apa yang akan dihasilkan (beserta code diff), dan setelah saya memberikan persetujuan akhir, barulah kode sebenarnya dibuat.
Sebaliknya, saat dulu saya meninjau kode buatan tim outsourcing, hasilnya benar-benar spaghetti code berantakan yang mustahil dipahami.
Menurut saya, menaruh istilah-istilah terkait vibe-coding di situs setidaknya untuk SEO adalah ide yang cukup bagus.
Saya juga sempat berpikir seperti itu.
Tapi kalau sebuah proyek di-vibe-code hingga jadi penuh bug, lalu saya datang untuk memperbaiki bug dan merapikan strukturnya, apakah itu benar-benar selesai di situ?
Saya penasaran bagaimana perusahaan yang dari awal tidak punya keahlian untuk menyiapkannya bisa melanjutkan maintenance setelahnya.
Menurut saya, outsourcing dan pengembangan berbasis LLM pada akhirnya sama-sama membutuhkan kemampuan yang mirip.
Artinya, fondasi kuat di ranah engineering seperti merapikan requirement, komunikasi, mengelola stakeholder, mendefinisikan spesifikasi, testing, dan dokumentasi tetap diperlukan.
Rasanya agak aneh bahwa konsep "vibe coding" dari Karpathy menjadi populer seperti ini.
Saya rasa mungkin ini hanya terjadi di kalangan orang yang hampir tidak punya pengalaman pengembangan nyata.
Kalau tidak salah, vibe coding itu semacam keadaan flow di mana orang “sekadar ngobrol dengan AI sambil terus maju percaya pada alurnya tanpa benar-benar memeriksa hasil kode yang dihasilkan”, jadi nyaris tidak pernah menengok kembali kodenya.
Kalau kualitas software yang dibuat secara serius punya sedikit saja arti, ini pendekatan yang benar-benar mengerikan.
Mungkin masih bisa dipakai untuk meme Twitter, eksperimen iseng, atau script kecil untuk dipakai di rumah, tapi untuk membangun produk sungguhan menurut saya jelas tidak masuk akal.
Ini menjadi ramai lebih karena penamaannya keren dan datang dari orang terkenal seperti Karpathy; kalau orang lain yang bilang, mungkin sudah tenggelam begitu saja.
Bahkan sebelum AI, developer junior atau yang belum banyak pengalaman sudah lama coding seperti ini.
Mereka copas dari mana-mana, asal jalan, lalu kalau muncul bug aneh atau core dump, mereka cuma mengubah urutan source code supaya gejalanya hilang.
Gaya seperti ini di perusahaan minimal bisa dapat peringatan, masuk performance improvement plan, atau lebih buruk lagi dikeluarkan.
Non-spesialis sering kali gagal mendapatkan hasil yang layak saat berkomunikasi dengan software engineer.
Munculnya vibe coding menurut saya adalah bahan refleksi tentang software seperti apa yang selama ini kita kirimkan.
Memang kualitas software startup yang saya tahu dibuat dengan vibe coding itu berantakan, tetapi selama software itu melakukan hal yang mereka inginkan, kualitasnya belum penting pada tahap sekarang.
Sampai kualitas software benar-benar memberi dampak nyata pada bisnis, mereka tampaknya tidak akan merasa perlu menanggung risiko merekrut developer lalu melihat ide mereka “diubah”.
Pada akhirnya, sesuatu yang jelek tapi bisa langsung dipakai untuk mendapatkan yang mereka mau terasa lebih baik daripada software sempurna yang sebenarnya tidak mereka inginkan.
Suka atau tidak, vibe coding tidak akan hilang.
Saya pribadi juga tidak terlalu setuju dengan konsep ini, tapi di dalam organisasi saya kadang bilang ke rekan kerja, “ini saya buat dengan vibe coding.”
Bagi kami, artinya kira-kira “sebagian besar kode dibuat otomatis oleh AI”.
Tapi saya sama sekali tidak akan pernah berpikir untuk langsung mendorong kode seperti itu ke production tanpa review.
Ini lebih seperti, “saya iseng bikin aplikasi keren dengan vibe coding,” jadi hanya dipakai santai untuk eksperimen.
Sepertinya maksud Karpathy adalah bahwa vibe coding merupakan “eksperimen yang mungkin dilakukan” dan menarik untuk diuji sejauh mana batasnya.
Saya rasa itu bukan anjuran untuk benar-benar membuat produk perusahaan hanya dengan vibe coding.
Orang-orang terlalu bebas menafsirkan konteks ungkapan itu sesuai maunya sendiri.
Karpathy sendiri juga menjelaskan maksud yang dia bicarakan di video YouTube.
Artikel terkait
YouTube Karpathy: Software Is Changing (Again)
Menurut saya, kesalahpahaman itu makin besar karena orang ingin percaya bahwa pekerjaan sulit sekarang akan menjadi mudah.
Saya masih merasa tweet aslinya sendiri juga cuma lelucon atau ekspresi kebebasan ala “YOLO coding”, bukan rekomendasi proses kerja nyata.
Dia hanya menuliskan rasa bebas yang dia rasakan saat itu dengan nada santai.
Sekarang vibe coding rasanya praktis dipakai sebagai istilah untuk merendahkan atau menyindir semua bentuk bantuan coding berbasis AI.
Padahal alat apa pun bisa dipakai dengan baik atau buruk, tetapi belakangan meme “betapa bodohnya vibe coding” cepat sekali dapat dukungan online.
Sekarang sudah sampai terasa melelahkan.
Inti artikel itu adalah klaim bahwa “startup bisa memangkas beberapa minggu untuk membuat MVP berkat vibe coding, dan walaupun nantinya harus melakukan cleanup dengan biaya dan waktu yang mirip, tetap lebih cepat daripada pengembangan tradisional.”
Saya penasaran apakah benar begitu.
Dari yang saya lihat, bahkan kalau developer membuatnya sendiri sambil memakai bantuan AI, selisih kecepatannya mungkin tidak terlalu besar.
Terutama kalau kita tahu MVP atau prototipe itu nantinya akan langsung masuk production, rasanya lebih baik menyiapkan arsitektur yang benar sejak awal dalam jangka panjang.
Namun kebanyakan tim produk dan manajemen menganggap waktu itu sebagai pemborosan.
Keuntungan nyata vibe coding adalah tim produk bisa langsung membuat sendiri apa yang mereka inginkan tanpa perlu menjelaskannya ke developer.
Mungkin alat produk berbasis vibe coding yang fokus pada memperjelas spesifikasi dan prototipe, alih-alih benar-benar membuat kode, justru punya peluang pasar.
Alat seperti itu bisa memberi developer spesifikasi yang lebih baik, sekaligus memberi pihak bisnis kontribusi dan kendali yang lebih besar.
Di startup, kecepatan masuk ke pasar memang sangat penting, jadi meskipun secara total memakan waktu dan biaya lebih besar, tetap masuk akal untuk menanggung utang teknis demi rilis yang lebih cepat.
Itulah sebabnya orang rela menumpuk utang teknis.
Twitter awalnya juga dimulai sebagai web app berbasis Ruby on Rails, dan servernya sering tumbang setiap Justin Bieber men-tweet hingga fail-whale muncul.
Tapi seiring pertumbuhan, mereka akhirnya merekrut para ahli dan membangun ulang semuanya dengan struktur yang lebih kokoh dan lebih skalabel.
Mungkin cocok untuk prototipe ketimbang MVP,
tapi kalau tidak ada disiplin organisasi maupun pribadi untuk tidak menaikkan prototipe ke prod, menurut saya vibe coding sebaiknya dihindari.
Semua orang tahu betapa sulitnya meyakinkan manajemen perusahaan bahwa “kode keren yang sedang dipakai sekarang sebenarnya berantakan di dalam dan harus diganti total.”
Dalam kasus seperti ini, no-code tool justru jauh lebih aman.
Kenyataannya, sebagian besar MVP atau prototipe pada akhirnya segera masuk ke production.
Saya ingat ada orang yang bilang, “kalau kode MVP tidak terasa menjijikkan sampai bikin badan sakit, berarti kamu menghabiskan terlalu banyak waktu untuk kualitas kode.”
Pada akhirnya, kode tambal-sulam itulah yang menjadi tulang punggung perusahaan.
Layanan yang hanya merapikan struktur seperti ini mungkin bisa disebut "C-Suite cleanup as a Service", tapi kalau dipasarkan seperti itu rasanya tidak akan ada yang mau menyewa.
Begitu membaca tulisannya, saya langsung merasa jelas bahwa ini ditulis Claude bahkan tanpa em-dash.
Tentu OP mungkin memberi pemikiran dan bahan miliknya sendiri sebagai prompt, tetapi frasa dan nuansa kalimat khasnya persis seperti keluaran yang umum dari LLM, jadi rasanya agak dipaksakan untuk dibaca.
Saya jadi berpikir apakah gaya seperti ini nanti akan dianggap ketinggalan zaman sebagai “gaya penulisan LLM”.
Sekarang sepertinya vibe-writing cleanup as a service yang akan jadi tren.
Saya sudah lama banyak memakai em-dash, tapi sekarang rasanya zaman menuntut saya untuk menguranginya, meskipun dipaksakan.
Microsoft Word otomatis mengubah hyphen menjadi em-dash.
Menurut saya vibe coding mirip pekerjaan plumbing DIY.
Anda coba kerjakan sendiri, lalu saat air menyembur di kamar mandi, akhirnya Anda harus memanggil tukang ledeng darurat dengan biaya mahal.
Dari proses itu, lain kali Anda jadi belajar sedikit lebih banyak.
Mirip memang, tetapi tukang ledeng profesional juga pandai menggunakan alat yang membantu DIY.
Bedanya, para profesional tahu kapan dan sampai sejauh mana alat itu sebaiknya dipakai.
Menurut saya malah lebih parah.
Pekerjaan tukang ledeng bisa dilihat langsung dengan mata saat dikerjakan, tetapi vibe code bisa tiba-tiba suatu hari berhenti bekerja dan Anda tidak tahu alasannya.
Di YouTube juga banyak tukang ledeng DIY yang justru bekerja lebih teliti daripada profesional.
Mungkin akan bergantung pada apakah vibe coder benar-benar belajar dari pengalaman seperti ini.
Sepertinya baru akan ketahuan seiring waktu.
Saya merasa analogi ini memang sangat tepat.
Seperti agen properti yang tertekan lalu terburu-buru mengerjakan plumbing demi menjual rumah, pendiri startup juga buru-buru mendemokan sesuatu untuk menarik perhatian investor dan pelanggan, lalu nanti memanggil profesional sungguhan untuk membereskan semuanya.
Kalau beruntung, mereka bisa menghindari bencana besar sebelum itu terjadi.
Saya kaget istilah Janitor Engineer ternyata seolah sudah ada di industri.
Selain itu, setelah "Why AI code fails at scale", tautan artikel berikutnya semuanya rusak, yang terasa makin aneh karena ini tulisan yang belum lama.
Sebagai catatan, saya harap tidak ada yang menganggap ini menyinggung.
Sejak vibe coding jadi tren, saya juga setengah bercanda terus menyimpan rencana pensiun untuk menjadi konsultan “all-organic-code” yang mengurai dan merapikan gumpalan kode buatan AI.
Yang benar-benar langka justru proyek baru (greenfield).
Vibe coding dengan cepat melemahkan dokumentasi dan kejelasan arsitektur.
Perusahaan hanya menganggap jumlah token kode yang dihasilkan dan kecepatan prototipe sebagai metrik penting, sambil mengabaikan biaya tersembunyi untuk maintenance dan cleanup.
Sekarang skill yang sesungguhnya bukan lagi menghasilkan, melainkan membersihkan.
Keahlian yang sebenarnya adalah membimbing sejak awal agar software yang dihasilkan benar-benar baik.
Ada orang yang melihat Claude Code lalu mengira “inilah teknologi terkini”, padahal kalau mau melakukannya dengan benar, keterlibatan yang dibutuhkan jauh lebih besar.
Sebenarnya tidak jauh berbeda dari engineering pada umumnya.
Intinya adalah meminimalkan biaya dan memenuhi kebutuhan.
Kalau maintainability tidak diminta secara eksplisit, maka hasil yang keluar ya sesuai niat awal itu juga.
Saya penasaran kenapa ini disebut kematian dokumentasi.
Ada juga pendekatan di mana dokumentasi ditulis terlebih dahulu, lalu pengembangan dilakukan sambil memeriksa apakah kode tetap sesuai dengan dokumen itu.
Atau dokumentasi dibuat dari kode, lalu kita sendiri yang meninjau apakah hasilnya sudah pantas.
Perusahaan kami selama puluhan tahun terus menangani pemulihan darurat untuk sistem kritis pelanggan (misalnya gangguan yang menyebabkan kerugian finansial besar lalu mereka tidak bisa menyelesaikannya sendiri).
Dalam beberapa tahun terakhir, kasus seperti ini meningkat cukup cepat.
Vibe code mirip legacy code dalam banyak hal.
Orang enggan mengubahnya karena tidak percaya diri terhadap kodenya, dan kualitas internal maupun eksternalnya sama-sama rendah.
Tetapi ada juga perbedaannya.
Jumlah kodenya sedikit untuk usianya, tekanan jadwalnya berat, dan ekspektasinya dibesar-besarkan.
Yang paling hemat biaya adalah memindahkan error sebanyak mungkin ke tahap sebelum runtime, yaitu ke desain atau compile time.
Masalahnya, karena AI, semua orang sekarang melaju terlalu cepat sampai ke runtime.
Sebagai referensi, tulisan “Vibe code is legacy code (val.town)” layak dibaca.
Postingan HN terkait
Legacy code tidak selalu buruk.
Biasanya ia kompleks atau kurang terdokumentasi, dan selama bertahun-tahun menumpuk patch operasional besar-kecil.
Sering kali berbagai masalah operasional nyata (seperti requirement baru) sudah tercermin di dalamnya, sehingga ia bisa berjalan cukup baik di layanan produksi sesungguhnya.
Masalahnya muncul ketika orang yang memahami codebase itu menghilang, atau bahkan tidak ada lagi orang yang menguasai bahasa maupun tool yang dipakai saat itu.
Saya penasaran apakah vibe coding bisa diterapkan juga pada bahasa yang strongly typed.
Saya setuju bahwa kode yang dibuat dengan vibe bisa diperlakukan seperti legacy code.
Tapi saya penasaran apakah orang juga benar-benar cenderung enggan mengubah vibe code.
Saya mulai berpikir bahwa code generation oleh LLM mungkin pada akhirnya bisa menghilang.
Artikel itu selalu berasumsi bahwa kode LLM akan terus dibuat dan akan selalu butuh cleanup, tetapi kalau ternyata biaya LLM + biaya cleanup selalu lebih mahal daripada gaji developer, bukankah pada akhirnya kita harus kembali ke manusia yang menulisnya langsung?
Menghasilkan kode dengan LLM lalu memeriksanya sebelum dipakai itu berbeda dari vibe coding.
Vibe coding adalah ketika kode yang sudah jadi dipakai begitu saja tanpa pemeriksaan.
Menurut saya, kedua pendekatan ini tetap tidak akan hilang.
Vibe coding berbasis AI saat ini justru makin kehilangan gaung.
Sebab, tak lama lagi akan ada AI yang lebih hebat lagi.
Kalau seharian hanya vibe coding, pada akhirnya biayanya bisa jadi tidak tertanggungkan.
Bisa jadi euforia semua orang selama ini hanyalah ilusi karena terlalu banyak dukungan dan bantuan, lalu nanti realitas datang dan orang harus menanggung rasa sakitnya.
Tren menuju alat bantu prediksi-lengkap dan pembuatan otomatis yang memuat semua contoh coding tidak akan pernah hilang.
Dulu orang juga coding tanpa syntax highlighting, tetapi sekarang tak ada yang sengaja mau kembali ke cara itu.
Mengetik ulang sesuatu seperti DFS untuk ke-80 kalinya tidak membuat harga diri saya sebagai programmer jadi lebih tinggi.