Vibe Coding's Project vs Long Lived Software

Belakangan ini kita dibombardir demo AI yang terdengar gila:
“AI bisa bikin compiler.”
“AI bisa bikin OS.”
“AI bisa bikin app lengkap dari satu prompt.”

Di slide presentasi, semua terlihat mulus.
Tapi sebagai engineer, kita perlu bedain: demo yang impressif vs sistem yang realible.

Yang sering terjadi sekarang:
coding project dari AI dipresentasikan seolah-olah itu sudah setara dengan software yang siap hidup 5–10 tahun di real life.
Padahal kenyataannya, apa iya?

Di artikel ini, gue pengen bedain dengan jelas:

• apa itu “vibe coding's project”,
• apa itu “long-lived software”,
• dan kenapa treat yang satu seolah yang lain itu bahaya — baik buat engineer, bisnis, maupun user.

1. Ilusi Vibe Coding's project.

Vibe Coding's bukan berarti jelek.
Vibe Coding's itu:

• kecil,
• fokus ke showcase kemampuan,
• biasanya dibuat cepat untuk demo atau eksperimen.

Contoh pola vibe coding's project yang sering kita lihat:

• “Compiler” yang bisa parse beberapa syntax sederhana dan jalan sekali di satu contoh input.
• “OS” yang bisa boot sampai prompt, tapi:
  • gak punya ekosistem driver,
  • gak jelas model security-nya,
  • gak ada cerita soal update & maintenance.
• Web app “end-to-end” yang:
  • UI-nya asal jadi,
  • business rule-nya minimal,
  • gak ada logging, monitoring, atau backup.

Coding project ini punya nilai edukasi dan nilai marketing.
Mereka nunjukin:

• “AI bisa generate struktur kode.”
• “AI bisa bantu bikin prototipe dengan cepat.”

Masalahnya mulai muncul kalau coding project ini disamakan dengan software production.

2. Long-lived Software.

Sekarang bandingin dengan software yang bener-bener harus hidup tahun-an:

• sistem pembayaran,
• aplikasi healthcare,
• core banking,
• platform SaaS yang dipakai ratusan/bahkan ribuan user,
• internal tools yang tiap hari dipakai satu tim/organisasi.

Software jenis ini punya karakteristik:

1. Stabilitas jangka panjang
   Bukan cuma “bisa jalan sekali saat demo”.
   Harus bisa di-deploy, di-rollback, di-update berkali-kali.

2. Maintainability
   Engineer lain harus bisa:

   • baca,
   • paham,
   • dan modif kode tanpa ngebakar semuanya.
     Dokumentasi, struktur, dan naming jadi penting.

3. Observability

   • Logging yang bener,
   • monitoring,
   • alerting,
   • kalau ada bug di 2 pagi, ada jejaknya.

4. Security & compliance
   Bagian ini hampir selalu absen di demo AI:

   • authentication/authorization yang bener,
   • proteksi data,
   • audit trail,
   • rate limiting,
   • mitigasi abuse.

5. Evolusi requirement

   • Kebutuhan user berubah,
   • regulasi baru,
   • integrasi baru,
   • dependency deprecate.
     Software harus bisa tumbuh, bukan cuma sekali generate, lalu ditinggal.

Coding project gak dirancang untuk menahan semua itu.
Long-lived software harus.

3. Kenapa “AI Bikin X Sekali Jadi” Itu Gak Cukup?

Kalau AI hari ini bisa generate:

• 3.000 baris kode backend,
• 1 set route REST API,
• 1 halaman admin panel,

itu masih baru satu langkah: “implementation draft”.

Yang belum kejawab:

• Apakah desain datanya sehat?
• Gimana migrasi kalau skema DB berubah?
• Gimana cara rollback kalau release rusak?
• Gimana sistem recover kalau ada partial failure?
• Gimana audit kalau ada incident security?

Coding project sering berhenti di:

“Liat, bisa jalan kalau kita klik ini.”

Long-lived software harus bisa jawab:

“Kalau ini di-deploy ke ribuan user, apa yang terjadi 6 bulan ke depan?”

4. Contoh: Compiler dan OS “Made by AI”

Klaim “AI bikin compiler dan sistem operasi” itu contoh yang menarik.

Supaya disebut bener-bener compiler/OS, hal minimum yang kita ekspekt:

• Compiler:
  • bisa compile berbagai program, bukan cuma contoh trivial,
  • punya error handling masuk akal,
  • punya behavior konsisten antarskenario.
• OS:
  • bisa boot stabil,
  • bisa menjalankan program nyata,
  • resource management-nya jelas,
  • ada cerita soal driver, storage, jaringan, dll.

Kalau:

• compiler yang dipamerkan gak bisa compile hello world dengan benar, atau errornya kacau,
• OS yang dipamerkan gak bener-bener usable,

maka itu bukan “AI sudah menggantikan engineer yang bikin compiler/OS”,
tapi:

“AI bisa bantu kita bikin demo tentang compiler/OS.”

Itu beda jauh.

5. Kualitas Kode: Dari Sekali Jalan ke Bisa Di-maintain

AI model saat ini bagus di:

• pattern matching,
• niru gaya kode,
• ngasih solusi cepat untuk masalah yang sudah umum.

Tapi masalah kode jangka panjang itu bukan cuma soal “jalan atau enggak”.
Ada beberapa level lain:

1. Konsistensi gaya & struktur
   Kalau kode di-generate di hari yang berbeda, prompt yang berbeda, hasilnya bisa:

   • beda style,
   • beda pattern,
   • beda cara error handling.
     Ini bikin codebase patchwork.

2. Abstraksi & boundary desain
   AI sering:

   • campur semua hal dalam satu layer,
   • lepas boundary clean antara domain logic, infra, dan UI.
     Ini bikin refactor jangka panjang susah.

3. Hidden coupling dan side effect
   Code generate cepat sering gak memikirkan kontrak jangka panjang,
   sedikit ubahan di satu sisi bisa break bagian lain.

Engineer lah yang kemudian harus:

• bersihin,
• refactor,
• bikin boundary jelas,
• ngejaga jangka panjangnya.

Kalau bagian “boring but important” ini gak dilakukan,
software yang lahir dari AI akan kelihatan impressive di awal,
tapi pelan-pelan jadi technical debt yang toxic.

6. Risiko Bisnis: Demo yang Keren vs Sistem yang Layak Dipercaya

Dari sisi bisnis, over-selling kemampuan vibe coding's project bisa bahaya:

• Manajemen melihat demo, lalu berpikir:

  “Kalau bisa generate app dalam 1 jam, kenapa kita butuh tim engineer besar?”

• Padahal:

  • 1 jam bikin kode,
  • berbulan-bulan bikin sistemnya bener.

Kalau kita treat coding project sebagai proof bahwa “AI bisa ganti engineer”, konsekuensinya:

• Sistem yang lahir:
  • riskan,
  • susah dioperasikan,
  • bikin friction dengan tim non-teknis ketika terjadi bug/incident,
• trust user turun begitu ada incident pertama yang serius.

Pendekatan yang lebih sehat:

• Vibe Coding's Project dipakai sebagai alat eksplorasi & prototyping,
• Engineer yang:
  • memutuskan mana yang layak diterusin,
  • mendesain ulang bagian penting,
  • menambah layer keamanan & observabilitas,
  • memastikan software layak hidup jangka panjang.

7. AI Sebagai Power Tool, Bukan Shortcut ke Production Tanpa Engineer

Yang lebih realistis (dan powerful) adalah memposisikan AI sebagai power tool untuk engineer, bukan “pengganti engineer”:

• Buat ideation: coba 3–4 pendekatan desain awal.
• Buat scaffolding: generate boilerplate, wiring, contoh test.
• Buat refinement: minta saran optimasi, edge case, skenario testing.
• Buat eksplorasi domain baru: baca paper, summary, coba snippet.

Tapi:

• keputusan desain,
• tanggung jawab kualitas,
• pertimbangan jangka panjang,

masih di tangan engineer.

Bedanya di era AI:

• Engineer yang ngerti cara memanfaatkan AI akan jauh lebih produktif,
• Engineer yang cuma bisa ngetik manual tanpa mikir desain akan sulit bersaing,
• Orang non-teknis bisa ikut bermain di level prototyping — tapi untuk production, mereka tetap butuh sparring partner seorang engineer.

8. Kesimpulan: Jangan Tertipu Vibe Coding's Project

Vibe coding's project itu keren dan inspiring.
Dia nunjukin “kemampuan mentah” model membuat kode dan sistem.

Tapi dia:

• bukan bukti bahwa AI siap menggantikan seluruh proses software engineering,
• bukan alasan untuk mengabaikan desain, security, observability, dan maintainability.

Long-lived software butuh:

• engineer yang mikir jangka panjang,
• proses yang disiplin,
• dan yes, AI sebagai asisten yang kuat.

Jadi lain kali lo lihat demo:

“AI bikin X yang biasanya makan waktu berbulan-bulan, sekarang jadi sehari!”

Tanya hal ini ke diri lo:

• Kalau ini di-deploy ke production,
• dipakai 5 tahun ke depan,
• dan dipegang beberapa generasi engineer berbeda,

masih bisa jalan dan diurus dengan waras… atau cuma bagus di slide presentasi?