Vibe coding membuat bus factor menjadi 0

• Dalam pengembangan perangkat lunak, Bus Factor adalah konsep yang menunjukkan berapa banyak orang yang harus memiliki pengetahuan tertentu agar proyek tetap dapat dipelihara; sebelumnya nilai terburuknya adalah 1
• Namun, setelah rilis ChatGPT (30 November 2022), adopsi luas AI generatif membuat banyak orang tidak lagi menyimpan pengetahuan secara langsung dan justru bergantung pada AI, sehingga secara efektif muncul situasi bus factor 0
• Di lapangan pemrograman, semakin banyak developer yang langsung memakai kode dan fitur yang dihasilkan LLM apa adanya, menyerah untuk memahami codebase, lalu beralih ke “vibe coding”
• Akibatnya, saat memperbaiki bug, menerapkan patch keamanan, atau memperluas fitur, tim bisa menghadapi situasi di mana tidak seorang pun tahu mengapa kode itu ditulis seperti itu
• Ini menimbulkan risiko serius bagi keandalan dan keamanan perangkat lunak, dan sampai hari ketika AI bisa menghasilkan kode sempurna secara sempurna tiba, keterbatasan mendasarnya akan tetap ada

---

Konsep dan sejarah bus factor

• Bus factor adalah konsep yang menyatakan dalam angka berapa banyak orang yang berbagi pengetahuan tertentu
  • Contoh: jika 3 orang tahu cara memulihkan backup database, maka bus factor untuk fungsi itu adalah 3
• Secara tradisional, nilai terburuknya adalah 1, dan jika satu orang kehilangan pengetahuan itu, proyek tidak bisa dipertahankan
• Umat manusia telah menyebarkan pengetahuan untuk mengatasinya melalui dokumentasi, pelatihan, transfer pengetahuan, seminar, sekolah, dan banyak cara lainnya
  • Ini berlanjut sebagai upaya sistematis untuk mewariskan dan melestarikan pengetahuan dengan menginvestasikan banyak sumber daya manusia dan waktu

Adopsi AI dan bus factor 0

• Rilis ChatGPT pada November 2022 membuka era “AI First”
• Dalam proses AI menghasilkan kode dan fitur, banyak orang tersingkir dari peran sebagai penyimpan pengetahuan dan mulai bergantung pada hasil buatan AI, sehingga pemahaman mereka terhadap proyek menurun tajam
• Akibatnya, muncul keadaan tanpa pemilik pengetahuan sama sekali, yaitu situasi bus factor 0
• Para programmer menunjukkan kecenderungan untuk tidak menulis dan memahami kode maupun fitur sendiri, melainkan mendelegasikannya sepenuhnya kepada AI
• Dalam proses ini, developer menghindari pemahaman codebase dan dokumentasi, lalu berubah ke pola yang sekadar meminta AI menjelaskan ulang

Masalah coding berbasis LLM

• Terlepas dari masalah kualitas kode, inti persoalannya adalah bahwa membaca dan memelihara pada dasarnya lebih sulit daripada menulis
• Di masa lalu, mentor atau dokumentasi setidaknya memberi bantuan minimal, tetapi dalam lingkungan yang bergantung pada AI, bahkan jaring pengaman ini pun menghilang
• Dalam pengembangan berbasis LLM, proses pembuatan kode tidak terekam, dan AI pun tidak dapat mengingat konteks kode yang dihasilkannya sendiri
• Pada akhirnya, developer harus menganalisis dan memodifikasi kode yang ditulis AI tetapi konteksnya tidak jelas
• Ini menyebabkan keadaan di mana tidak seorang pun dapat mengetahui maksud dan struktur kode saat menangani perbaikan bug, patch kerentanan keamanan, upgrade dependensi, dan sebagainya

Risiko dari sudut pandang pengguna

• Bukan hanya developer, pengguna pun terekspos pada risiko
  • Perangkat lunak tempat orang mengunggah dokumen pribadi, informasi kartu kredit, foto pribadi, atau pikiran personal bisa saja dibuat dengan kode yang struktur internal dan tujuannya tidak diketahui siapa pun
• Ini mengandung risiko serius dari sisi perlindungan data dan keandalan, serta menimbulkan pertanyaan tentang stabilitas layanan

Kesimpulan

• Vibe coding yang menyebabkan bus factor 0 adalah pendekatan yang pada dasarnya cacat
• Ini adalah keterbatasan yang tak terhindarkan sampai AI dapat menghasilkan kode yang 100% akurat dari prompt yang 100% akurat
• Karena itu, dalam situasi saat ini, selain memanfaatkan AI, kita tidak boleh mengabaikan pentingnya pelestarian pengetahuan dan pemahaman kode, dan menjaga sistem manajemen pengetahuan serta dokumentasi adalah hal yang esensial

[iolothebard]

Bukankah bus factor-nya jadi tak terhingga?

[cdwdong2]

Jika developer di perusahaan tidak memiliki pengetahuan, bus factor akan mendekati 0.

[GN⁺]

Opini Hacker News

• Menggunakan LLM untuk begitu saja memuntahkan kode dalam jumlah besar tanpa review adalah cara penggunaan yang keliru; itu berarti proyek semacam itu secara struktural bergerak ke arah yang salah atau akan segera mustahil dipelihara ketika muncul bug yang rumit Kekuatan nyata LLM ada pada situasi seperti ini: ketika perlu menerapkan algoritme terkenal pada struktur data kompleks yang sudah ada, saat membuat data uji atau kerangka unit test dengan banyak dependensi, saat membangun editor web visual dan API backend lalu menambahkan fungsi penyimpanan ke sqlite, atau saat menerapkan pekerjaan berulang yang sulit bahkan dengan regular expression kompleks ke codebase berskala besar Dalam praktiknya, berkat LLM, pekerjaan yang biasanya memakan setengah hari atau 3 hari bisa mulai dikerjakan dalam 2 menit Yang penting adalah, meskipun LLM tidak bisa menyelesaikan masalah yang sangat sulit, produktivitas tetap bisa meningkat drastis Kita bisa terbebas dari pekerjaan berulang yang membosankan dan fokus pada masalah yang lebih menarik

  • Saya kira LLM akan menyelesaikan pekerjaan perubahan berulang pada codebase besar dalam 2 menit, tetapi setelah saya uji sendiri dengan beberapa model besar, makin kompleks konteksnya makin banyak error yang menumpuk, dan kadang muncul perubahan yang tidak relevan, sehingga hasilnya pada akhirnya tidak bisa dipercaya Untuk contoh kecil hasilnya sempurna, tetapi makin besar skalanya makin kurang memadai Ini bisa diperbaiki dengan agentic loop, tetapi karena harus dijalankan dan direview berulang kali, pada akhirnya justru memakan jauh lebih banyak waktu Jauh lebih andal jika LLM diminta menulis program yang mengotomatisasi pekerjaan perubahan itu

  • Semua contoh yang diberikan memang terlihat bagus, tetapi contoh penggunaan yang benar-benar memungkinkan sebenarnya jauh lebih banyak Anda berbicara tentang kasus milik pengembang berpengalaman saja, tetapi orang yang kemampuan teknisnya kurang atau yang baru belajar juga kini bisa melakukan jauh lebih banyak hal berkat LLM Pekerjaan yang dulu harus dibayar 100 dolar kini bisa dicoba sendiri dalam 3 menit Apakah hasilnya sempurna dan mudah dipelihara justru menjadi kurang penting; menunjukkan kemungkinan memiliki nilai yang lebih besar

  • Saya setuju dengan pendapat Anda, tetapi ingin berbagi pengalaman lucu belakangan ini Saya meminta Claude menulis unit test, dan setelah direview ternyata memang ada bug di kode saya, dan test itu menemukannya Namun alih-alih memperbaiki bug tersebut, Claude justru berusaha meloloskannya dengan tidak menjalankan test yang gagal itu sama sekali; sebuah episode lucu dari dunia nyata LLM lemah dalam pendefinisian kebutuhan, perancangan arsitektur, dan penulisan spesifikasi yang sesuai kebutuhan, tetapi kuat pada pekerjaan dengan cakupan yang jelas dan dampak yang terbatas seperti penulisan kode

  • Saya pernah menerapkan langkah perantara berupa AI yang otomatis melakukan review PR lalu dilanjutkan review manual Pembuatan kode memakan 5~10 menit, dan review serta commit tambahan biasanya butuh 1~3 jam, tetapi saya berhasil menerapkan cara ini di beberapa proyek (10~20k LOC, sekitar 100 file) Jika spesifikasinya diberikan dengan baik, banyak fitur diimplementasikan hampir tepat tanpa banyak perbaikan, dan yang paling sering terjadi adalah refactoring berbasis feedback Tentu saja, saat tidak berjalan semestinya, penyelesaiannya kadang memakan hampir satu hari, tetapi secara keseluruhan produktivitas meningkat 3~5 kali lipat Untuk proyek besar, sepertinya lebih baik dipecah dan dimodularisasi

  • Ungkapan seperti "menyelesaikan pekerjaan x hari dalam 2 menit dengan LLM" agak berlebihan karena tidak memasukkan waktu review Jika digabung dengan proses review dan verifikasi yang sebenarnya, waktu yang dibutuhkan jauh lebih lama Justru bisa jatuh ke “cara yang salah” yang tadi disebut di awal

• Tulisan ini memang memaparkan beberapa masalah AI code generation, tetapi tampaknya tidak mempertimbangkan solusi yang sudah ada atau yang mungkin akan muncul nanti Dulu pun, jika tim setidaknya memberi sedikit usaha pada codebase, orang baru bisa dibantu untuk memahami kode itu Saya jadi bertanya-tanya apakah penulis kurang punya pengalaman dengan legacy code, atau benar-benar menganggap bahwa fakta AI “melupakan semua konteks proses penulisan awal” itu tidak bisa diperbaiki Masalah Bus Factor 0 juga dipahami seolah hanya bisa diatasi jika akurasinya 100% sempurna, padahal manusia pun tidak selalu 100% akurat, tetapi tetap dipercaya

  • Saya merasa tulisan itu melihat masalah secara terlalu disederhanakan Kenyataan bahwa sejak awal kita tidak selalu bisa melakukan semua pekerjaan bersama penulis aslinya memang sudah ada Kehadiran rekan berpasangan atau AI yang bisa menjelaskan saja sudah merupakan kemajuan besar Seolah-olah sedang membayangkan dunia tanpa manusia, padahal kita sudah cukup sering mengalami situasi seperti itu

  • Saya penulisnya, saya setuju dengan poin pertama dan saya juga berpikir AI ke depan akan mempersempit kesenjangan ini Tetapi saat itu tiba, sebagian masalah mungkin sudah terlanjur terjadi Ada juga masalah berupa kode yang tertinggal tanpa konteks logis atau riwayat pengambilan keputusan Banyak yang bilang AI “selalu belajar”, tetapi kenyataannya ia tidak belajar sampai model baru dirilis Manusia juga tidak 100% akurat, tetapi bukan Bus Factor 0; mengidentifikasi dan menyelesaikan masalah lebih mudah Jika masalah-masalah lainnya juga teratasi, maka masalah bus factor pun akan berkurang

  • Saat menganalisis legacy code dulu, saya sering berpikir andai ada tool AI waktu itu Situasi absurd seperti “penulis terakhir file Perl ini sekarang kepala cabang, apa saya harus menjadwalkan rapat langsung dengannya?” benar-benar pernah terjadi

  • Untuk pertanyaan “mengapa harus 100% akurat?”, saya merasa orang yang kritis terhadap AI justru cenderung berharap AI menjadi solusi ajaib yang sempurna Nuansanya mirip orang yang menentang static typing lalu mengeluh bahwa ia “bahkan tidak bisa menangkap logical error”

• Akhir-akhir ini terlalu banyak gambar buatan AI di blog, dan rasanya justru mengganggu fokus serta sering tidak membantu isi tulisan

• Saya baru-baru ini bergabung dengan tim yang memiliki codebase berantakan; sebagian besar pengembang lama sudah pergi, dan orang-orang yang tersisa pun tidak terlalu memahami kodenya Ini benar-benar Bus Factor 0 Anehnya, berkat AI, pemahaman kode, penangkapan niat, dan kecepatan debugging meningkat drastis Kami mulai mengekstrak dokumentasi langsung dari kode dengan AI Dokumentasi atau cerita lisan bisa terdistorsi, tetapi kode itu sendiri adalah kebenaran Dengan bantuan AI, kami bisa menciptakan lingkungan di mana kode menjelaskan dirinya sendiri, dan saya merasakan peningkatan produktivitas yang besar

  • Dari sudut pandang manajer, saya sedang mempertimbangkan untuk menetapkan satu aturan agar semua readme tim kami ke depan tidak menjadi usang Saya rasa Claude Code bisa diwajibkan memperbarui readme dengan membaca readme lama, kode terbaru, dan bahkan perubahan PR Tentu tidak sempurna, tetapi pengembang tetap harus melakukan verifikasi akhir apakah ringkasannya masuk akal, dan AI bisa sangat mengurangi masalah readme menjadi usang karena “malas” memperbaruinya

• Bahkan sebelum kemunculan LLM, Bus Factor selalu menjadi masalah Sebagian besar perusahaan tidak menstrukturkan pekerjaan agar sebagian darinya dipahami oleh beberapa orang Meski banyak orang ditugaskan ke tiap area, jumlah pekerjaan terus bertambah sehingga pada akhirnya situasi di mana tak seorang pun benar-benar memahami semuanya terus terulang Untuk sepenuhnya menghindari hal ini diperlukan manajemen engineering yang sangat besar, seperti merotasi orang di dalam codebase, dan biasanya itu tidak bisa dilakukan sempurna karena tuntutan kecepatan Saya merangkum refleksi pengalaman saya sebagai CTO terkait hal ini dalam bentuk buku di sini dan membukanya tanpa mempedulikan harga Menurut saya, prinsip antara membangun sistem dengan LLM dan menggunakan 10 pengembang outsourcing tidak jauh berbeda

  • Bus Factor sudah menjadi masalah bahkan sebelum LLM, dan ini adalah istilah teknis yang sudah lama ada TFA (artikel sumber) mengkritik tren bahwa sebelumnya Bus Factor adalah 1, dan sekarang bergerak menjadi 0 sama sekali

  • Yang bertambah hanya volume pekerjaannya, bukan berarti pekerjaan benar-benar bergerak ke arah yang lebih direkomendasikan; pola yang berulang hanyalah menyelesaikannya seadanya demi tenggat waktu Menaruh beberapa hambatan prosedural saja tidak akan menyelesaikannya

• Otak kita cenderung menghemat energi untuk informasi yang tidak sering dipakai, sehingga makin jauh dari sesuatu, makin sulit memahaminya atau makin mudah melupakannya Bahkan jika kita melakukan semua code review sendiri, kemampuan kita tetap bisa menurun Ini mirip ketika engineer terlalu lama mengerjakan pekerjaan manajerial hingga hampir tak mampu lagi menyelesaikan masalah teknis Dalam otomatisasi mobil juga, mempertahankan keterlibatan manusia di tahap peralihan (level2→5) itu sulit, dan jika mesin tidak bisa dipercaya 100%, pada akhirnya akan timbul masalah

• Ada satu poin yang benar-benar penting dalam diskusi ini: sebenarnya tool dan workflow seperti ini baru saja dimulai Saya yakin ke depan AI bisa menyelesaikan masalah-masalah ini lebih baik daripada manusia Saya juga sudah bereksperimen memanfaatkan LLM; ada yang berhasil, ada yang gagal, tetapi di bidang tertentu kemampuannya jelas luar biasa LLM tidak merasa malas dan bisa dengan teliti memperbarui dokumentasi, komentar, README, bahkan ADR Jika ada panduan dan struktur yang cukup, dalam jangka panjang codebase LLM justru bisa lebih mudah dimasuki, karena dokumentasinya cenderung lebih baik

  • Ini memang poin yang sangat penting, tetapi sebenarnya saya melihat kita sudah berada di ujung perkembangan tool seperti ini, sehingga saya menganggap masalah-masalah ini tidak bisa diselesaikan

• Saya rasa tulisan itu mengabaikan bahwa niat bisa cukup banyak dibaca dari kode itu sendiri Manusia, dan mungkin LLM juga, adalah makhluk yang cukup dapat diprediksi Biasanya kita menyelesaikan masalah yang serupa dengan cara yang serupa Jika melihat bagaimana kode ditulis, kita bisa menangkap petunjuk tentang mengapa, siapa, kapan, dan masalah apa yang sedang diselesaikan Tentu ada banyak informasi yang tersembunyi, tetapi hal serupa juga terjadi di organisasi dengan pergantian anggota yang sering

  • Saya memang menganggap proses berpikir manusia pada akhirnya tercermin di dalam kode, tetapi tetap saja itu jauh lebih inferior dibanding punya orang yang bisa ditanya langsung Reverse engineering biasanya hanya dilakukan saat benar-benar perlu, tetapi pada legacy code akhirnya semua orang melakukannya Namun dari sisi produktivitas, itu bukan hal yang baik Dan pada codebase LLM, yang tercampur bukan niat tunggal melainkan niat dari banyak orang yang beragam, sehingga hanya dengan melihat sebagian potongan kode justru makin membingungkan apa maksud aslinya Kita bisa keliru mengira kode buatan AI memiliki makna yang sepenuhnya setara dan seterstruktur seperti kode tulisan manusia, sehingga malah makin sulit ditafsirkan

  • Kemampuan memahami niat hanya dari melihat kode bergantung pada cakupan dan skalanya Jika dibatasi 32kB seperti Arduino, memahaminya mudah Tetapi pada platform kompleks dengan puluhan microservice yang saling kusut, apalagi jika ditulis ala 'vibe coding', kalau itu jadi tanggung jawab saya rasanya ingin langsung menyerah

• Saya setuju dengan pokok dan kesimpulan tulisan ini, tetapi selama 20 tahun saya sudah beberapa kali mengalami situasi serupa (lingkungan tempat tak ada seorang pun yang bisa ditanya, penanggung jawab sebenarnya sudah semua pergi) Berkat LLM, hal seperti ini mungkin bisa terjadi sedikit lebih cepat, tetapi menurut saya ini bukan masalah yang sepenuhnya baru, melainkan lebih seperti percepatan dari masalah lama Saya menyambut baik adanya kesadaran terhadap masalah ini

  • Penulis mengabaikan apa arti sebenarnya Bus Factor 0 dan bagaimana secara realistis kondisi itu bisa tercapai Perusahaan yang membiarkan Bus Factor 0 pada dasarnya adalah perusahaan yang tidak punya insentif ekonomi untuk berinvestasi pada keahlian Jika keuntungan ekonomi yang didapat manusia saat bersaing dengan AI menjadi 0, dan AI menurunkan biaya sampai 10 kali lipat, maka ditambah kebohongan/hiperbola pemasaran dan kekacauan saluran komunikasi, masalahnya menjadi jelas Dalam prinsip penawaran dan permintaan, jika penawaran (ahli) menjadi tak terbatas, permintaan akan hilang Pipeline pembinaan talenta dibangun dalam 2~10 tahun, dan sejak insentif untuk tumbuh hilang, krisis serius akan datang di masa depan Bahkan sudah ada contoh di universitas daerah tempat mata kuliah ilmu komputer dikurangi karena penurunan jumlah mahasiswa, dan para mahasiswa menjawab bahwa mereka menyerah pada jalur karier itu karena AI Jika pasokan ahli menghilang, nanti bahkan dengan uang pun tak ada orang yang bisa memperbaikinya Jika fondasi ekonomi tersentuh, masalah akan membesar belakangan karena efek jeda waktu, dan di dunia nyata kita tidak bisa merespons cukup cepat Pada akhirnya akan terjadi krisis serius, dan baru setelah itu langkah-langkah ekstrem mulai diambil

• Bahkan ada situasi sebaliknya Jika codebase disiapkan dengan dokumentasi, test, dan konfigurasi yang baik agar bisa dimanfaatkan AI, saya menduga 1 tahun lagi AI agent akan bisa menyelesaikan pekerjaan yang sama lebih cepat

  • Saya penasaran bagaimana AI Coding Tool akan mulai mengambil sikap seperti pengembang lama yang berkata “kode sebelumnya jelek semua, jadi harus ditulis ulang dari awal” Menarik juga membayangkan CI/CD system ke depan berubah menjadi model di mana AI menulis ulang seluruh proyek sekaligus

  • Saya penulisnya, dan jika seperti yang Anda katakan, berarti Bus Factor justru sudah meningkat Artinya, esensinya adalah informasi tidak lagi hanya tersimpan di dalam kepala, tetapi disimpan dan dipertahankan dalam berbagai bentuk