17 poin oleh GN⁺ 2025-04-21 | 3 komentar | Bagikan ke WhatsApp
  • Vibe coding berbasis AI memang inovatif, tetapi ada peringatan bahwa kecepatan tanpa kualitas itu berbahaya

"Bergeraklah lebih cepat, dan rusaklah lebih banyak"
"vibe coding, cara dua engineer menciptakan utang teknis setara 50 orang"

  • Ungkapan yang memelintir slogan lama Silicon Valley ini belakangan ramai dibicarakan di komunitas engineering sebagai konsep bernama “vibe coding”
  • Memang benar bahwa pengembangan berbasis AI sedang merevolusi cara pembuatan software, tetapi itu bukan lisensi untuk membuang ketelitian, review, dan craftsmanship
  • "vibe coding" tidak bisa menjadi alasan untuk membenarkan pekerjaan berkualitas rendah
  • Jika mengakui kelebihannya, coding dengan bantuan AI memang bisa menjadi game changer
  • Ia menurunkan hambatan masuk bagi programmer baru maupun nonspesialis, dan memungkinkan mereka membuat software yang berjalan hanya dengan menjelaskan kebutuhan mereka
  • Ini membebaskan kreativitas, serta memungkinkan lebih banyak orang menyelesaikan masalah mereka sendiri langsung dengan software yang dikustomisasi
  • Arus ini dipandang sebagai bagian dari tren unbundling software personal (memakai tool kecil berbasis AI alih-alih aplikasi siap pakai)
  • Engineer berpengalaman pun bisa mendapatkan manfaat
  • Tetapi, seperti yang akan dikatakan engineer berpengalaman mana pun, kecepatan tidak ada artinya jika rodanya copot di garis akhir
  • Dan di sinilah retaknya mulai terlihat — jarak antara vibe dan realitas, yakni perbedaan antara sensasi itu dengan kenyataan membangun software yang maintainable dan tangguh

Kebenaran yang tidak nyaman: kualitas tidak datang dengan sendirinya

  • Hype-nya besar, tetapi skeptisisme developer veteran terhadap vibe coding juga sama besarnya
  • Kritik intinya adalah ini: hanya karena AI bisa memuntahkan kode dengan cepat, bukan berarti kodenya bagus
  • Bahkan, memercayai dan langsung memakai kode buatan AI bisa cukup berbahaya
  • Lelucon bahwa “dua engineer menciptakan utang teknis setara 50 orang” bukan sepenuhnya sekadar lelucon
  • Kode AI yang tidak direview bisa memperbesar utang teknis dalam skala besar
    → Utang ini membuat kode menjadi rapuh dan sulit dirawat, serta menimbulkan biaya besar dalam jangka panjang
  • Proyek yang dibuat dengan vibe coding sering kali tampak bagus di permukaan ("wah, jalan, deploy aja!")
  • Tetapi pada kenyataannya, proyek seperti ini menyembunyikan risiko-risiko berikut:
    • Tidak ada penanganan error
    • Performanya buruk
    • Praktik keamanannya rapuh
    • Struktur logikanya lemah dan mudah rusak
  • Proyek seperti ini ibarat bangunan yang didirikan di atas pasir,
  • dan istilah yang saya pakai adalah "house of cards code"
    terlihat seolah sudah jadi, tetapi mudah runtuh saat menghadapi tekanan dunia nyata
  • Jika Anda pernah melihat fitur besar pertama buatan developer junior yang hampir berfungsi tetapi langsung gagal gara-gara satu input tak terduga, Anda pasti paham rasanya
  • AI memang bisa menghasilkan banyak kode dengan cepat, tetapi kuantitas tidak berarti kualitas
  • "AI itu seperti developer junior yang sangat antusias dan baru bergabung ke tim"
  • → Konsep ini dijelaskan dengan baik melalui ilustrasi Forrest Brazeal
  • Risiko ini bukan sekadar hipotesis, dari sisi maintenance pun masalahnya nyata
  • Jika modul yang dibuat AI terlalu rumit atau sulit dipahami, siapa yang akan merawatnya?
  • Bahkan jika developer yang pertama menulisnya pun tidak sepenuhnya memahami kode buatan AI itu,
    maka kode tersebut bisa menjadi mimpi buruk untuk perubahan atau pengembangan di masa depan
  • Keamanan adalah masalah besar lainnya
  • AI bisa membuat kode yang di permukaan tampak berjalan baik, tetapi di dalamnya mungkin tersembunyi kerentanan fatal seperti SQL injection
  • Atau, penanganan error-nya bisa saja buruk
  • Jika masalah-masalah ini masuk ke production tanpa review menyeluruh, hal itu bisa berujung pada insiden nyata
  • Masalah lain adalah overfitting to the prompt
    → AI akan melakukan persis seperti yang Anda minta, tetapi itu bisa berbeda dari yang benar-benar dibutuhkan
  • Developer manusia biasanya menemukan kesalahan desain atau salah paham saat proses implementasi, lalu memperbaikinya
  • Sebaliknya, AI sama sekali tidak menyadari kesalahpahaman semacam ini, dan jika manusia tidak menemukannya lalu memperbaikinya, masalah itu akan dibiarkan begitu saja
  • Tentu saja, semua ini bukan berarti AI sama sekali tidak bisa menulis kode yang bagus
  • AI kadang-kadang menghasilkan kode yang sangat baik
  • Tetapi untuk menilai apakah kode itu benar-benar layak dipakai, tiga hal berikut mutlak diperlukan:
    • konteks (context)
    • peninjauan kritis (scrutiny)
    • pengalaman dan keahlian (expertise)
  • Per 2025, AI yang kita gunakan saat ini seperti asisten yang penuh semangat tetapi minim pengalaman
  • Seperti halnya kita tidak akan menyerahkan desain seluruh sistem kepada developer baru tahun pertama tanpa pengawasan,
    kode dari AI juga tidak boleh diterima tanpa review
  • Harapan terhadap “AI magic” kini harus diselaraskan dengan realitas software engineering
  • Jadi bagaimana cara menjaga keseimbangannya?
  • Yang penting adalah kita tidak perlu menolak vibe coding sepenuhnya
  • vibe coding kadang bisa sangat berguna
  • Tetapi yang penting adalah mengintegrasikannya dengan cara yang terlatih — yakni memandang AI sebagai alat dengan batasan yang jelas
  • Artinya, manusia harus tetap berada di dalam loop, dan kita harus menggunakan AI dengan cara yang tetap menjaga standar kualitas dan prinsip engineering yang kita miliki

AI bukan pengganti, melainkan intern (manusia harus tetap berada di dalam loop)

  • Agar vibe coding bisa dimanfaatkan secara efektif, perlu ada perubahan mindset untuk memperlakukan AI sebagai ‘intern developer tim yang sangat cepat tetapi masih belum matang’
  • Artinya, Anda — engineer senior atau team lead — tetap menjadi penanggung jawab akhir atas hasilnya
  • AI bisa dengan cepat membuat draft, tetapi Anda tetap harus mereviewnya secara kritis, lalu merevisi dan memastikan apakah ia memenuhi standar kualitas
  • Developer berpengalaman biasanya secara intuitif mengikuti proses ini
  • Saat AI mengusulkan kode, mereka tidak menekan “Accept” lalu langsung lanjut, melainkan merespons seperti ini:
    • Membaca dan memahami dulu kode yang ditulis AI — memperlakukannya seperti kode buatan developer junior
    • Melakukan modularisasi dan refactoring jika kodenya berupa satu blok besar atau berantakan — memecahnya menjadi unit yang lebih kecil dan jelas
    • Menambahkan sendiri exception handling atau edge case yang terlewat — null check, validasi input, dan hal serupa sering luput dari AI
    • Memperkuat typing yang longgar atau abstraksi yang belum matang — mengubah asumsi implisit menjadi kontrak yang eksplisit
    • Menilai apakah arsitektur atau pendekatan yang dipilih AI tidak efisien — misalnya pemrosesan brute-force, penggunaan global state, dan sebagainya
    • Menulis test atau melakukan pengujian manual — jika AI membuat unit test, validitas test itu pun wajib diperiksa
  • Melalui seluruh proses ini, kita menyuntikkan kebijaksanaan engineering ke dalam kode buatan AI

  • Kombinasi ini bisa sangat kuat — AI memberi kecepatan, dan manusia menjamin keandalan

  • Bahkan, menurut riset dan pengalaman kerja nyata, developer senior mendapat nilai lebih besar dari tool coding AI dibanding junior

  • Alasannya, senior punya pengetahuan dan pengalaman untuk mengarahkan output AI dengan benar serta memperbaiki kesalahannya

  • Sebaliknya, junior lebih berisiko keliru memercayai AI sebagai otoritas mutlak

  • Karena itu, lahirlah satu aturan penting:
    Kode yang ditulis AI harus selalu direview sebelum diterapkan
  • Seperti saat meninjau PR dari developer baru, kode itu harus dibaca baris demi baris dan dipahami sepenuhnya sebelum di-merge
  • Jangan berasumsi AI lebih pintar — dalam kebanyakan kasus, tidak begitu
  • Jika ada bagian yang tidak dipahami:
    • lebih baik perjelas lagi lewat prompt yang diperbaiki, atau
    • tulis ulang sendiri kode tersebut
  • Output AI hanyalah ‘draft’ dan wajib melalui review
  • Jika berada dalam lingkungan pengembangan tim:
    • bila seseorang membuat kode dengan bantuan AI,
    • ia harus bisa menjelaskan dan mempertahankan kode itu sendiri saat review
    • “yang penting jalan” tidak berlaku — kode baru benar-benar menjadi kode jika manusia memahaminya dan bisa merawatnya
  • Praktik terbaik lainnya: desain oleh manusia, implementasi oleh AI
  • Artinya, AI digunakan untuk mengimplementasikan dengan cepat tugas yang sudah terdefinisi seperti CRUD API
  • Sebaliknya, permintaan seperti “tolong rancang arsitektur microservices yang skalabel” harus dikerjakan manusia
  • Desain tingkat tinggi dan keputusan inti harus tetap menjadi porsi manusia
  • Singkatnya: serahkan pekerjaan sederhana dan berulang (grunt work) kepada AI, dan pemikiran serta penilaian (brain work) kepada manusia
  • Komunikasi dan dokumentasi juga menjadi sangat penting
  • Jika Anda meminta AI menangani algoritma yang kompleks atau library yang asing,
    • alasan dan niat di balik pilihan itu harus didokumentasikan
    • maintainer di masa depan, atau diri kita sendiri di masa depan, harus bisa memahami mengapa kode itu dibuat dengan cara tersebut
  • Beberapa tim bahkan mencatat prompt itu sendiri yang digunakan saat menghasilkan kode penting dengan AI
    → Ini berguna karena saat debugging, riwayat “percakapan” dengan AI bisa dijadikan referensi
  • Pada akhirnya, keterlibatan manusia bukan pilihan, melainkan keharusan
  • Menggunakan kode AI tanpa keterlibatan manusia sama saja dengan melempar dadu pada kualitas software
  • Kita belum hidup di era ketika AI bisa menggantikan pemahaman menyeluruh seorang senior engineer
  • vibe coding harus menjadi kemitraan
    AI bisa menambah kecepatan, dan manusia bertugas memasangkan sabuk pengaman pada kecepatan itu

Aturan praktis untuk vibe coding berkualitas tinggi

  • Mari rangkum pembahasan sejauh ini menjadi aturan yang bisa langsung dijalankan dan best practice
  • Ini bisa disebut sebagai handbook era baru untuk “bergerak cepat, tapi jangan sampai merusak semuanya”
  • Aturan-aturan ini berfungsi sebagai guardrail untuk menjaga kualitas saat melakukan vibe coding
  • Rule 1: Always Review AI-Generated Code / Selalu review kode hasil AI
    • Tidak ada pengecualian. Semua kode yang ditulis AI harus direview seperti kode yang ditulis developer junior
    • Wajib dilakukan, baik review pribadi maupun peer review
    • Berlaku untuk AI apa pun, termasuk Copilot, ChatGPT, Cursor, dan lainnya
    • Jika tidak ada waktu untuk review, berarti tidak ada waktu untuk memakai kode itu
    • Merge kode AI tanpa review sama saja dengan memeluk risiko apa adanya
  • Rule 2: Establish Coding Standards and Follow Them / Tetapkan standar coding dan patuhi
    • Karena AI mencerminkan gaya kode yang dipelajarinya, tanpa standar tim yang konsisten kualitas akan naik turun
    • Tim harus mendefinisikan dengan jelas style guide, pattern arsitektur, dan aturan coding
    • Contoh: “setiap fungsi harus memiliki JSDoc dan unit test” → kode yang dihasilkan AI juga harus mengikuti ini
    • Dalam proyek yang memakai hierarki atau layered architecture,
      refactoring wajib dilakukan agar AI tidak menaruh pemanggilan DB di dalam kode UI
    • Disarankan menerapkan aturan lint atau static analysis untuk menangkap kesalahan AI yang umum (misalnya fungsi terlalu kompleks, penggunaan API deprecated, dll.)
  • Rule 3: Use AI for Acceleration, Not Autopilot / AI adalah akselerator, bukan autopilot
    • vibe coding sebaiknya digunakan untuk mempercepat pekerjaan yang memang sudah dipahami dengan baik
    • Contoh penggunaan yang baik:
      • menghasilkan boilerplate
      • scaffolding komponen
      • konversi bahasa
      • menyusun kerangka algoritma sederhana
    • Contoh penggunaan yang berisiko:
      • meminta AI merancang seluruh modul hanya dari penjelasan yang ambigu
      • mencoba menghasilkan kode untuk domain yang belum dipahami dengan baik
    • Jika kodenya akan menjadi bagian permanen dari sistem, maka wajib beralih dari mode vibe ke mode engineering
  • Rule 4: Test, Test, Test / Wajib test, tanpa kompromi
    • Hanya karena AI menghasilkan kode, bukan berarti hasilnya otomatis benar
    • Wajib menulis test untuk semua jalur utama
    • Jika AI juga membuat test, perlu diperiksa apakah test itu benar-benar valid
    • Khususnya untuk fitur UI atau bagian dengan banyak input pengguna, wajib klik langsung dan uji input abnormal
    • Aplikasi hasil vibe coding sering kali hanya berjalan baik di happy path dan lemah terhadap input pengecualian
  • Rule 5: Iterate and Refine / Ulangi dan sempurnakan
    • Jika hasil pertama dari AI tidak memuaskan, jangan dibiarkan begitu saja; coba lagi atau refactor
    • vibe coding adalah proses iteratif berbasis percakapan
    • Contoh:
      • “buat kode ini lebih ringkas”
      • “pecah jadi fungsi-fungsi kecil” dan sebagainya dengan menyesuaikan prompt
    • Atau refactor sendiri → tentukan titik perbaikan → prompt lagi → ulangi
    • Strategi memakai siklus interaksi dengan AI terbukti efektif
  • Rule 6: Know When to Say No / Tahu kapan harus berkata tidak
    • vibe coding tidak selalu menjadi pilihan terbaik
    • Untuk desain penting atau situasi yang menuntut keamanan, lebih baik menulisnya sendiri
    • Contoh:
      • modul terkait keamanan dirancang langsung, lalu AI hanya dipakai sebagian
      • jika AI memberi jawaban yang terlalu rumit untuk masalah sederhana, menulis sendiri justru lebih cepat
    • Saat AI tidak bisa menyelesaikan masalah dengan baik, jangan memaksakan; beralihlah ke mode manual
    • “Karena AI yang membuatnya” bukan alasan untuk tidak memahami kode kita sendiri
  • Rule 7: Document and Share Knowledge / Dokumentasikan dan bagikan pengetahuan
    • Kode yang dihasilkan AI juga harus didokumentasikan setara dengan kode yang ditulis sendiri (kadang bahkan lebih banyak)
    • Jika ada keputusan yang tidak intuitif atau implementasi yang tidak biasa, komentar harus ditambahkan
    • Bagian mana yang dihasilkan AI harus dibagikan dengan jelas kepada anggota tim
    • Beberapa tim menyimpan prompt yang dipakai untuk kode AI penting apa adanya → berguna saat debugging
  • Dengan mengikuti aturan-aturan di atas, tim bisa memanfaatkan produktivitas vibe coding semaksimal mungkin sambil meminimalkan risiko
  • Intinya, AI bukan untuk menggantikan manusia, melainkan melengkapinya
  • AI menangani pekerjaan berulang dengan cepat, sementara manusia bertanggung jawab atas pemikiran kritis dan kreativitas
  • Kita hidup di era ketika manusia dan AI menciptakan kode bersama (co-create)

Kapan vibe coding bekerja dengan baik vs kapan ia runtuh

  • Penting juga untuk memahami dengan jelas di mana vibe coding bersinar, dan di mana ia tidak
  • Tidak semua proyek atau tugas sama-sama cocok untuk workflow berbasis AI
  • Berikut adalah pembagian penggunaan yang dirangkum berdasarkan pengalaman dan kasus di industri
  • 👍 Situasi ketika ini bekerja dengan baik (Great Use Cases)
    • Rapid prototyping (pembuatan prototipe cepat)
      → sweet spot dari vibe coding. Saat ada ide aplikasi atau fitur kecil
      → dengan bantuan AI assistant, proof of concept atau prototipe bisa dibuat dengan cepat
      → meski kodenya agak berantakan tidak masalah — yang penting adalah validasi ide
      → sudah banyak contoh proyek akhir pekan yang membuat aplikasi hanya dengan AI lalu menguji konsepnya
    • One-off scripts / Internal tools (skrip sekali pakai, alat internal)
      → seperti parsing file log, otomatisasi pekerjaan pribadi, dashboard internal, dan sebagainya
      → di lingkungan dengan risiko kecil jika gagal, vibe coding efektif untuk menghemat waktu
      → dalam situasi yang tidak membutuhkan kualitas tingkat produksi, kita bisa cepat membuat sesuatu yang “langsung jalan”
    • Learning and exploration (pembelajaran dan eksplorasi)
      → saat mempelajari bahasa baru atau API baru, minta AI membuatkan contoh
      → meski bukan kode yang sempurna, itu sudah cukup sebagai bahan belajar
      → rasanya seperti punya TA virtual (asisten pengajar) yang menunjukkan berbagai pendekatan, lalu manusia menyempurnakannya
    • Boilerplate-heavy tasks (tugas yang penuh boilerplate)
      → contoh: membuat 10 data class yang mirip, mengimplementasikan CRUD
      → selama strukturnya jelas, AI bisa mengikuti pola berulang dengan akurat
      → pekerjaan mekanis bisa diselesaikan cepat, dan manusia dapat fokus pada bagian yang penting
  • 👎 Situasi ketika masalah muncul (Not-So-Great Use Cases)
    • Enterprise software / Complex systems (perangkat lunak tingkat enterprise, sistem kompleks)
      → sistem dengan logika bisnis kompleks, konkurensi, keamanan, dan persyaratan kepatuhan
      → AI tidak memahami kondisi semacam itu jika tidak dijelaskan secara eksplisit, dan bahkan jika tahu pun bisa kurang mampu merefleksikannya
      → contoh: sistem pembayaran fintech, perangkat lunak kontrol kedirgantaraan, dan sejenisnya sama sekali tidak boleh diserahkan hanya kepada AI
      → di lingkungan seperti ini AI hanya cocok sebagai bantuan sebagian, dan kualitas akhir tetap membutuhkan QA manusia serta keahlian manusia
    • Long-term maintainability (kemudahan pemeliharaan jangka panjang)
      → untuk codebase yang akan bertahan bertahun-tahun, struktur sejak awal itu penting
      → kode yang dibuat dengan tambal sulam lewat AI cenderung tidak konsisten dan menjadi beban besar untuk pemeliharaan berikutnya
      → lebih baik meluangkan waktu di awal untuk menetapkan framework dan desain yang jelas
      → banyak pengguna awal membagikan pengalaman bahwa waktu yang dihemat lewat vibe coding
      akhirnya habis kembali untuk refactoring dan pekerjaan perapian
    • Critical algorithms / Optimizations (algoritma kritis atau pekerjaan optimisasi)
      → contoh: manajemen memori kustom, algoritma pengurutan super cepat, dan sebagainya
      → AI mungkin baik untuk input skala kecil, tetapi kurang mempertimbangkan skala besar
      → hasilnya bisa melambat atau berperilaku salah tanpa peringatan
      → area seperti ini tetap membutuhkan kreativitas dan pemahaman mendalam dari manusia
    • Explainability and clarity (kejelasan dan kemudahan penjelasan)
      → ketika kode harus dapat dibaca dengan jelas oleh developer lain atau auditor
      → jika AI melakukan abstraksi berlebihan atau mengambil pendekatan yang terlalu rumit, keterbacaan dan maintainability bisa turun drastis
      → AI saat ini tidak selalu mengarah pada “kode yang singkat dan ringkas” → kadang justru terlalu verbose atau diabstraksikan secara tidak perlu
      → dalam kasus seperti ini, refactoring dan penulisan kode yang jelas oleh manusia tetap diperlukan
  • Singkatnya, vibe coding adalah alat akselerasi yang kuat, tetapi bukan solusi serba bisa
  • Sangat efektif untuk pekerjaan yang mengutamakan kecepatan dan hasilnya masih boleh diperbaiki beberapa kali
  • Sebaliknya, menyerahkan software mission-critical kepada AI sekaligus dalam sekali jalan adalah langkah yang berisiko
  • Analogi sederhananya: seperti meminta pembalap mobil mengemudikan bus sekolah — alat yang bagus, tetapi untuk penggunaan yang salah
  • Mungkin suatu hari AI akan menjadi alat dasar untuk seluruh pengembangan, tetapi hari itu belum sekarang
  • Yang perlu kita lakukan hari ini adalah menggunakan AI pada masalah yang tepat, dengan cara yang tepat, dan di bawah tanggung jawab yang tepat

Kesimpulan: lakukan vibe dengan hati-hati – nikmati kecepatannya, tapi jangan kehilangan craftsmanship

  • vibe coding dan pengembangan perangkat lunak berbasis AI menandai lompatan besar dalam evolusi alat
  • arus ini bukan tren sesaat, melainkan realitas yang kini sudah mapan, dan ke depan akan semakin canggih
  • tim engineering yang berpandangan ke depan tidak boleh mengabaikannya
  • seperti alat otomasi sebelumnya atau framework tingkat tinggi yang melampaui cara pengembangan lama,
    tim yang memanfaatkan AI dengan baik kemungkinan besar akan mengungguli tim yang tidak
  • pesan tulisan ini bukanlah untuk menolak vibe coding —
    melainkan untuk mendekatinya dengan mata terbuka sambil tetap menjaga dasar-dasar engineering
  • Pelajaran terpenting: kecepatan tidak berarti apa-apa tanpa kualitas
  • Merilis cepat kode yang penuh bug dan tidak bisa dirawat hanya berarti melaju kencang menuju jurang
  • developer terbaik adalah mereka yang memakai AI untuk menambah kecepatan tanpa meruntuhkan sistem
  • AI mengangkat bebannya, dan manusia memastikan semuanya tetap berdiri dengan benar
  • Menemukan titik keseimbangan (sweet spot) itulah kuncinya
  • Poin praktik untuk tech leader dan manajer:
    → budaya bahwa AI adalah alat yang harus digunakan secara bertanggung jawab perlu ditanamkan di tim
    • dorong vibe coding, tetapi sekaligus tetapkan ekspektasi dan aturan yang jelas untuk menjaga codebase
    • kode hasil AI juga harus selalu menjadi target code review,
      • dan bangun budaya di mana pertanyaan “Apakah kamu paham kode ini?” terasa alami
    • investasikan penguatan kemampuan agar seluruh tim bisa berkolaborasi secara efektif dengan AI
      • termasuk skill set baru seperti cara menulis prompt yang baik dan cara mengevaluasi usulan AI
    • ini adalah perubahan paradigma, seperti saat dulu beralih ke bahasa tingkat tinggi atau mengadopsi Git
      tim yang beradaptasi lebih cepat akan diuntungkan
  • Hal yang benar-benar harus tetap kita anggap penting dalam software engineering tetaplah sebagai berikut:
    • menyelesaikan masalah pengguna
    • membangun sistem yang dapat dipercaya
    • terus belajar
  • vibe coding adalah sarana, bukan tujuan
  • jika ia membantu memberikan nilai yang lebih cepat dan lebih baik kepada pengguna, maka itu alat yang hebat
  • tetapi jika dalam prosesnya ia membuat kita mengorbankan kualitas dan keamanan yang seharusnya kita jaga, maka penggunaannya perlu ditahan
  • Esensinya tetap sama:
    berpikir dengan jelas, memahami kebutuhan, merancang untuk menghadapi perubahan, dan melakukan pengujian secara menyeluruh
  • Terakhir, mari pegang semangat ini:
    “Bergerak cepat, tapi jangan merusak — dan kalau pun rusak, pastikan itu bisa diperbaiki.”
  • Tulis kode dengan cepat, tetapi fondasinya harus tetap berupa dasar engineering yang kokoh
  • AI bisa menjadi pahat yang sangat kuat di tangan seorang perajin
    → tetapi yang tetap mengendalikan pahat itu adalah tangan manusia
  • Jadi para developer, lakukan vibe — tetapi lakukan dengan hati-hati
  • Sambut masa depan, tetapi jangan lepaskan prinsip-prinsip dasar yang membawa kita sampai ke sini
  • vibe coding bukan alasan untuk membenarkan kualitas yang rendah,
    → melainkan kesempatan untuk menunjukkan seberapa jauh hal yang lebih besar bisa kita bangun ketika penilaian manusia dan kemampuan generatif mesin digabungkan
  • Tim yang menginternalisasi prinsip ini tidak hanya akan menjadi lebih cepat,
    → tetapi juga akan membangun software yang layak bertahan dalam jangka panjang

> Happy coding — dan biarkan vibe tetap tinggi, sementara kualitas lebih tinggi lagi.

3 komentar

 
tested 2025-04-23

+1
Saya setuju.

 
iolothebard 2025-04-21

Peringatan: postingan sangat panjang

 
GN⁺ 2025-04-21
Komentar Hacker News
  • Makna "vibe coding" telah didefinisikan ulang

    • Cuitan aslinya membahas menerima kode yang dihasilkan AI tanpa memedulikan kualitasnya, lalu mencoba lagi secara acak jika hasil yang diinginkan tidak keluar
    • Bertanya-tanya apakah orang sekarang memakai istilah ini untuk berarti "memberikan tugas yang luas kepada agen AI"
  • Hype AI coding terasa terlalu besar sehingga secara realistis tidak bisa dipenuhi

    • Pernah menyerahkan unit test untuk codebase yang kompleks ke aplikasi AI coding, tetapi 80% gagal
    • Developer manusia yang berpengalaman tetap bisa memakainya sebagai titik awal, dan itu mengurangi pekerjaan berulang
    • Saat ini AI berguna untuk mempercepat pekerjaan berulang, tetapi tidak bisa menggantikan developer manusia
  • Mengingatkan pada masa di awal 2000-an ketika perusahaan besar mencoba mengalihdayakan pekerjaan pengembangan ke negara berpendapatan rendah

    • Developer hasil outsourcing tidak memahami ide inti sistem, dan hanya mengembangkan sesuai spesifikasi yang tertulis
    • Akibatnya, butuh banyak waktu agar spesifikasi dan implementasi mencapai tingkat kualitas yang diinginkan
    • AI coding juga mirip seperti ini; berguna untuk prototipe atau solusi cepat, tetapi tidak bisa menggantikan pemahaman dan kreativitas manusia
  • Memperlakukan AI sebagai developer junior dalam tim justru bisa memakan lebih banyak waktu

    • Kode yang dihasilkan AI terlihat meyakinkan, tetapi sebenarnya bisa bermasalah sehingga perlu kehati-hatian
  • Tergantung pada use case

    • Sebagai konsultan, terutama mengerjakan otomatisasi proses bisnis dan integrasi sistem cloud
    • Kolaborasi dengan agen AI menjadi game changer, sehingga bisa fokus menulis kebutuhan teknis dan code review
    • Menjadi bisa mencapai lebih banyak hal dalam anggaran terbatas, sehingga kualitas output meningkat signifikan
  • Ada beragam sudut pandang tentang kualitas software

    • Kualitas dari sudut pandang pengguna: bug lebih sedikit, memodelkan masalah dengan akurat, dan tidak rumit tanpa perlu
    • Kualitas dari sudut pandang developer: kode rapi dan jelas, serta mudah diperluas atau diubah
    • Jika AI berfokus memenuhi spesifikasi formal dan metode pengujian, jenis kualitas yang kedua bisa menjadi tidak penting
  • Ada pertanyaan apakah AI-assisted coding akan berdampak negatif pada pertumbuhan developer

    • Penasaran apakah dalam jangka panjang permintaan developer akan meningkat, atau justru menurun dalam jangka pendek
  • Kesulitan sebuah tugas bisa dipahami melalui vibe coding

    • Membuat prototipe dan menguji library untuk memastikan apakah masalah bisa diselesaikan
    • Kadang LLM mengusulkan parameter atau fungsi yang salah, tetapi tetap bisa menghemat waktu
  • Orang cenderung ingin menghemat energi, dan vibe coding memungkinkan pengembangan dengan usaha minim

    • Tidak cocok untuk proyek penting, tetapi bisa berguna untuk proyek pribadi
  • Seluruh artikelnya terlihat seperti membesar-besarkan kalimat "vibe code harus ditinjau manusia sebelum dideploy ke production"