Vibe coding, bus factor’ı 0’a indiriyor

• Yazılım geliştirmede Bus Factor, belirli bir bilgiye sahip kaç kişi olduğunda bir projenin sürdürülebileceğini gösteren bir kavramdır; geleneksel olarak en kötü durumda değer 1 idi
• Ancak ChatGPT’nin yayımlanmasından sonra (30 Kasım 2022) üretken yapay zekanın yaygın biçimde benimsenmesiyle, birçok kişi bilgiyi doğrudan korumak yerine yapay zekaya bağımlı hale geldi ve fiilen bus factor 0 durumu ortaya çıktı
• Programlama sahasında giderek daha fazla geliştirici, LLM’in ürettiği kod ve işlevleri olduğu gibi kullanıyor, kod tabanını anlamaya çalışma çabasından vazgeçip “vibe coding”e geçiyor
• Bunun sonucunda hata düzeltme, güvenlik yaması veya özellik genişletme sırasında kodun neden öyle yazıldığını kimsenin bilmediği bir durumla karşılaşılabilir
• Bu, yazılım güvenilirliği ve güvenliği için ciddi riskler yaratır ve yapay zekanın kusursuz kodu kusursuz biçimde ürettiği gün gelene kadar temel bir sınıra sahiptir

---

Bus Factor kavramı ve tarihi

• Bus Factor, belirli bir bilginin kaç kişi arasında paylaşıldığını sayısal olarak ifade eden bir kavramdır
  • Örnek: 3 kişi veritabanı yedeğini geri yüklemeyi biliyorsa, ilgili işlevin bus factor’ı 3’tür
• Geleneksel olarak en kötü değer 1’di ve bir kişi bu bilgiyi kaybettiğinde projeyi sürdürmek imkansız hale geliyordu
• İnsanlık bunu aşmak için dokümantasyon, eğitim, bilgi aktarımı, seminerler, okullar ve daha pek çok yöntemle bilgiyi yaydı
  • Bu, bilgiyi aktarmak ve korumak için çok sayıda insan kaynağı ve zaman harcanan sistematik çabalara dönüştü

Yapay zeka kullanımı ve bus factor 0

• Kasım 2022’de ChatGPT’nin çıkışıyla “AI First” çağı başladı
• Yapay zeka kod ve işlev üretirken birçok kişi bilginin korunmasında özne olmaktan çıktı ve yapay zeka çıktılarına bağımlı hale gelerek projeyi anlama düzeyi hızla düştü
• Sonuç olarak bilgi sahibi kimsenin olmadığı durum, yani bus factor 0 ortaya çıktı
• Programcılar kodu ve işlevleri kendileri yazıp anlamak yerine, bunu tamamen yapay zekaya devretme eğilimi gösteriyor
• Bu süreçte geliştiriciler kod tabanını anlama ve dokümantasyondan kaçınıp yalnızca yapay zekadan yeniden açıklama isteme kalıbına yöneliyor

LLM tabanlı kodlamanın sorunları

• Kod kalitesi sorunlarını bir kenara bıraksak bile, asıl nokta okuma ve bakımın doğası gereği yazmaktan daha zor olmasıdır
• Geçmişte mentorlar veya belgeler asgari düzeyde yardım sağlıyordu, ancak yapay zekaya bağımlı ortamda bu güvenlik ağı bile ortadan kalkıyor
• LLM tabanlı geliştirmede kod üretim süreci kaydedilmez ve yapay zekanın kendisi bile ürettiği kodun bağlamını hatırlayamaz
• Sonuçta geliştiriciler, yapay zekanın yazdığı ama bağlamı belirsiz olan kodu analiz edip düzeltmek zorunda kalır
• Bu da hata çözümü, güvenlik açığı yamaları, bağımlılık yükseltmeleri gibi durumlarda kodun niyetini ve yapısını kimsenin bilemediği bir durum yaratır

Kullanıcı açısından risk

• Risk yalnızca geliştiricileri değil kullanıcıları da etkiler
  • Kişisel belgeler, kredi kartı bilgileri, özel fotoğraflar veya düşünceler yüklenen bir yazılım, iç yapısını ve amacını kimsenin bilmediği kodla oluşturulmuş olabilir
• Bu, veri koruma ve güvenilirlik açısından ciddi riskler barındırır ve hizmet istikrarı konusunda soru işaretleri doğurur

Sonuç

• Bus factor 0’a yol açan vibe coding, temelden kusurlu bir yaklaşımdır
• Bu, yapay zeka %100 doğru kodu %100 doğru prompt ile üretebilene kadar kaçınılmaz bir sınırlamadır
• Bu nedenle mevcut durumda yapay zekadan yararlanmanın yanında bilgi koruma ve kodu anlama önemini göz ardı etmek mümkün değildir; bilgi yönetimi ve dokümantasyon düzenini sürdürmek zorunludur

[iolothebard]

Otobüs faktörü sonsuz olmadı mı?

[cdwdong2]

Şirketteki geliştiricilerin bilgisi yoksa, bus factor 0'a yaklaşır.

[GN⁺]

Hacker News görüşü

• LLM kullanarak incelenmemiş devasa miktarda kodu olduğu gibi üretmek yanlış bir kullanım biçimi; böyle projeler yapısal olarak yanlış yöne gider ya da karmaşık hatalar çıktığında kısa sürede bakımı yapılamaz hale gelir LLM'in asıl gücü şu tür durumlarda ortaya çıkar: mevcut karmaşık veri yapılarına bilinen algoritmaları uygulamak gerektiğinde, test verisi ya da çok sayıda bağımlılığı olan birim testleri için iskelet kurarken, görsel bir web editörü ile backend API geliştirip sqlite'a kaydetme özelliği eklerken, karmaşık düzenli ifadelerle bile zor olan tekrarlı işleri büyük bir kod tabanına uygularken vb. Gerçekten de LLM sayesinde normalde yarım gün ya da 3 gün sürecek bir işe 2 dakikada başlanabiliyor Önemli nokta şu: LLM çok zor problemleri çözemese bile üretkenlik büyük ölçüde artabilir Sıkıcı tekrar işlerinden kurtulup daha ilginç problemlere odaklanabiliyorsunuz

  • Büyük bir kod tabanına tekrarlayan değişiklikler uygularken LLM'in bunu 2 dakikada bitireceğini düşünmüştüm ama farklı büyük modellerle bizzat denediğimde, bağlam karmaşıklaştıkça hatalar birikti ve bazen alakasız değişiklikler de yaptı; sonuç olarak güvenilir değildi Küçük örneklerde kusursuz ama ölçek büyüdükçe yetersiz kalıyor agentic loop kullanarak bunu iyileştirebilirsiniz ama sürekli çalıştırıp incelemek gerektiğinden sonuçta çok daha fazla zaman alıyor LLM'e değişiklikleri otomatikleştiren bir program yazdırmak çok daha güvenilir

  • Verilen örneklerin hepsi iyi görünüyor ama pratikte mümkün olan kullanım örnekleri çok daha fazla Sen yalnızca deneyimli geliştiricilerin örneklerinden bahsettin ama teknik becerisi sınırlı ya da daha yeni öğrenen kişiler için de LLM sayesinde yapılabilecek şeyler ciddi biçimde arttı Eskiden 100 dolar verip yaptırılması gereken bir işi artık 3 dakikada kendi başına deneyebiliyorsun Ortaya çıkan sonucun kusursuz ve bakımı yapılabilir olması artık o kadar da önemli olmuyor; asıl daha büyük değer, bunun mümkün olduğunu göstermesi

  • Görüşüne katılıyorum ama yakın zamanda yaşadığım komik bir deneyimi paylaşmak istiyorum Claude'dan birim testi yazmasını istemiştim; inceleme sonucunda aslında benim kodumda bir hata olduğu ve testin bunu yakaladığı ortaya çıktı Ama Claude, hatayı düzeltmek yerine o başarısız testi hiç çalıştırmayarak testi geçirtti; gerçek hayattan eğlenceli bir anekdot LLM'ler gereksinim tanımı, mimari tasarım ve gereksinime uygun spesifikasyon yazımı konularında zayıf; kod yazmak gibi kapsamı net ve etkisi sınırlı işlerde ise güçlüler

  • AI'nin önce PR incelemesini otomatik yapıp ardından manuel inceleme yaptığımız bir ara aşamayı denedim Kod üretimi 5-10 dakika sürüyor, inceleme ve ek commit'ler ise genelde 1-3 saat alıyor ama bunu birkaç projede (10-20k LOC, yaklaşık 100 dosya ölçeğinde) başarıyla uyguladım Spesifikasyonu iyi verirseniz birçok özellik büyük düzeltmeler olmadan neredeyse doğru uygulanıyor ve çoğunlukla geri bildirim odaklı refactoring yapılıyor Elbette düzgün çalışmadığında çözmek bazen neredeyse bir günü bulabiliyor ama genel olarak 3-5 kat üretkenlik artışı sağlıyor Büyük projelerde bunu parçalara ayırıp modülerleştirmek daha iyi görünüyor

  • "LLM ile 2 dakikada x günlük iş tamamlandı" türü ifadeler, inceleme süresi dahil edilmediği için biraz abartılı Gerçek inceleme ve doğrulama sürecini de ekleyince süre çok daha uzuyor Hatta başta sözü edilen “yanlış yöntem”e tam da böyle düşülebilir

• Bu yazı AI kod üretiminin sorunlarını çeşitli açılardan anlatıyor ama mevcut ya da gelecekte ortaya çıkabilecek çözümleri hesaba katmıyor gibi görünüyor Eskiden de ekip kod tabanı için asgari düzeyde bile emek vermiş olsaydı, yeni gelen birinin kodu anlamasına yardımcı olabilirdi Ya legacy code deneyimi yok, ya da AI'nin "ilk yazım sürecine dair tüm bağlamı unutması" sorununu gerçekten çözülemez sanıyor, diye düşündürüyor Bus Factor 0 sorununu da sanki ancak %100 kusursuz doğrulukla çözülebilecek bir şeymiş gibi ele alıyor; oysa insanlar da hiçbir zaman %100 doğru değil ama yine de onlara güveniyoruz

  • Yazının soruna fazla indirgemeci baktığını hissettim Zaten en baştan beri her işi yazarıyla birlikte yapamayacağımız gerçeği vardı Yanında bir eş ya da açıklama yapan bir AI'nin bulunması bile muazzam bir ilerleme Sanki insanın hiç olmadığı bir dünyayı hayal ediyor ama biz zaten böyle durumlarla sık sık karşılaşıyoruz

  • Yazarı benim; ilk eleştiriye katılıyorum ve AI'nin zamanla aradaki farkı kapatacağını düşünüyorum Ama o zamana kadar bazı sorunlar çoktan ortaya çıkmış olabilir Mantıksal bağlamı ya da nasıl değiştirildiğine dair kayıtları olmayan kod kalması da ayrı bir problem AI'nin "sürekli öğrendiği" çok söyleniyor ama gerçekte yeni bir model çıkana kadar öğrenmiyor İnsanlar da %100 doğru değil ama Bus Factor 0 değiller; sorunu anlamak ve çözmek daha kolay Diğer sorunlar çözülürse bus factor sorunu da azalır

  • Geçmişte legacy code analiz ederken AI araçları olsaydı keşke diye düşünmüştüm "Bu Perl dosyasına en son dokunan kişi artık şube müdürü; gidip onunla toplantı mı ayarlayayım?" gibi absürt durumlar gerçekten yaşanıyordu

  • "Neden %100 doğru olmak zorunda?" sorusuna cevaben, AI'ye eleştirel yaklaşanların bazen tam tersine ondan sihirli biçimde kusursuz çözümler beklediğini düşünüyorum Bu, statik tip karşıtlarının "mantıksal hataları da yakalayamıyor" diye şikayet etmesine benzer bir ton taşıyor

• Son zamanlarda blogların çoğunda AI ile üretilmiş görseller o kadar arttı ki odaklanmayı bozuyor ve çoğu durumda içeriğe de katkı sağlamıyor gibi geliyor

• Kısa süre önce berbat halde bir kod tabanına sahip bir ekibe katıldım; önceki geliştiricilerin çoğu ayrılmıştı ve kalanlar da kodu pek bilmiyordu Tam anlamıyla bus factor 0 durumu Şaşırtıcı biçimde AI sayesinde kodu anlama, niyeti kavrama ve debug etme hızı ciddi şekilde arttı Kodun kendisinden dokümantasyon üretmeye başladım Dokümantasyon ya da sözlü aktarım çarpıtılabilir ama kodun kendisi gerçektir AI yardımıyla kodun kendini açıkladığı bir ortam oluşturabildim ve büyük bir üretkenlik artışı hissettim

  • Yönetici olarak artık ekibimdeki tüm readme dosyalarının eskimesini önlemek için bir kural koymayı düşünüyorum Claude Code'a mevcut readme'yi, güncel kodu ve PR değişikliklerini okutup readme'yi zorunlu olarak güncelletebileceğimizi düşünüyorum Elbette kusursuz değil; özetin makul olup olmadığını geliştiricinin son kez kontrol etmesi gerekir ama readme'lerin eskimesinin nedeni olan "üşenme" faktörünü AI ciddi ölçüde azaltabilir

• LLM'lerden önce de Bus Factor her zaman bir sorundu Şirketlerin çoğu işin bazı bölümlerini birden fazla kişinin anlayabileceği şekilde yapılandırmadı Birden çok kişi farklı alanlara atanmış olsa bile iş yükü büyümeye devam ediyor ve sonunda kimsenin her şeyi tam olarak anlayamadığı durum tekrar ediyor Bundan tamamen kaçınmak için kod tabanı içinde insanları rotasyona sokmak gibi çok ciddi mühendislik yönetimi gerekiyor ve çoğu yerde hız baskısı yüzünden bu mükemmel biçimde yapılamıyor Bununla ilgili CTO deneyim notlarımı burada kitap halinde, fiyatı önemli olmaksızın erişime açtım LLM ile sistem kurulan bir ortamın ilkeleriyle 10 dış kaynak geliştirici kullanılan bir ortamın ilkeleri arasında çok büyük bir fark görmüyorum

  • Bus Factor, LLM'den önce de bir sorundu ve uzun zamandır kullanılan yerleşik bir terim TFA, önceden Bus Factor'un 1 olduğunu, şimdi ise bunun 0'a doğru gidişini eleştiriyor

  • Yapılan işin miktarı büyüyor ama işin daha tavsiye edilir bir yönde ilerlediği yok; sadece son tarihe yetişmek için üstünkörü bitirme paterni tekrarlanıyor Sürece birkaç engel eklemek bunu çözmüyor

• Beynimiz sık kullanmadığı bilgilere enerji harcamamaya çalıştığı için bir şeyden uzaklaştıkça onu daha kötü anlamaya ya da unutmaya başlıyoruz Kodu bizzat incelemiş olsanız bile sonunda yetkinliğiniz körelebilir Bu, mühendisin uzun süre yöneticilik yapınca teknik problemleri neredeyse çözememesi gibi Otomobil otomasyonunda da ara seviyeleri (level2→5) insanın sürekli müdahil olarak sürdürmesi zor ve makine %100 güvenilir değilse sonunda sorun çıkıyor

• Bu tartışmadaki gerçekten önemli nokta şu: aslında bu tür araçlar ve iş akışları daha yolun çok başında Gelecekte AI'nin bu sorunları insanlardan daha iyi çözebileceğine inanıyorum LLM'lerle çeşitli denemeler yaptım; bazıları başarılı oldu, bazıları olmadı ama belirli alanlarda gerçekten üstün yetenek gösteriyorlar LLM'ler üşenmeden dokümanları, yorumları, README'leri ve ADR'leri titizlikle güncelleyebilir Yeterli kılavuz ve yapı sağlanırsa, LLM ile üretilmiş bir kod tabanına uzun vadede girmek hatta daha kolay olabilir; çünkü dokümantasyon kalitesi daha yüksek olma eğiliminde olur

  • Bu çok önemli bir nokta ama açıkçası artık bu tür araçların gelişiminin sonuna geldiğimizi ve bu sorunların çözülemeyeceğini düşünüyorum

• Yazının, kodun kendisinin de niyeti ciddi ölçüde ortaya koyabildiğini gözden kaçırdığını düşünüyorum İnsanlar da, muhtemelen LLM'ler de, oldukça öngörülebilir varlıklar Genelde benzer problemleri benzer şekillerde çözüyoruz Kodun nasıl yazıldığına bakarak neden, kim tarafından, ne zaman ve hangi problem için yazıldığına dair ipuçları çıkarmak mümkün Elbette kaybolan bilgi çok ama üyelerin sık değiştiği organizasyonlarda da benzer şeyler oluyor

  • İnsan düşünce sürecinin sonuçta koda yansıdığına katılıyorum ama yine de bu, doğrudan sorabileceğiniz birinin olmasından çok daha zayıf bir süreç Reverse engineering genelde yalnızca mecbur kalındığında yapılır; legacy code'da ise sonunda herkes bunu yapmak zorunda kalır Ama üretkenlik açısından iyi bir şey değildir Ayrıca LLM kod tabanlarında tekil bir niyet değil, farklı birçok kişinin niyetleri karışmış olur; bu yüzden sadece bazı kod parçalarına bakarak asıl amacın ne olduğunu anlamak daha da kafa karıştırıcı hale gelir AI'nin ürettiği kodun da insanlar tarafından yazılan kodla aynı derecede tutarlı anlam taşıdığı yanılsamasına kapılmak, yorumlamayı daha da zorlaştırabilir

  • Niyeti yalnızca koda bakarak anlama yeteneği kapsam ve ölçeğe göre değişir Arduino gibi 32kB sınırı olan bir şeyse anlaması kolaydır Ama onlarca microservice'in birbirine girdiği karmaşık bir platformda, hele bu bir de vibe coding tarzında yazıldıysa sorumluluğu bana verilirse açıkçası pes etmek isterim

• Yazının ana fikrine ve sonucuna katılıyorum ama 20 yıldır benzer durumları birçok kez yaşadım: soru soracak kimsenin olmadığı, asıl sorumluların çoktan ayrıldığı ortamlar LLM'ler sayesinde bu süreç biraz hızlanabilir ama bunun tamamen yeni bir problemden çok eski bir problemin hızlanmış hali olduğunu düşünüyorum Bu tür farkındalığı memnuniyetle karşılıyorum

  • Yazar, Bus Factor 0'ın gerçekte ne anlama geldiğini ve pratikte bu noktaya nasıl gelindiğini gözden kaçırıyor Bus Factor 0'a izin veren şirket, aslında uzmanlığa yatırım yapmak için ekonomik teşviki olmayan şirkettir İnsanların AI ile rekabetten elde ettiği ekonomik kazanç sıfıra iner ve AI maliyeti 10 kat düşürürse, buna pazarlamadaki yanıltma/abartı ve iletişim kanallarındaki karışıklık da eklenince sorun netleşir Arz-talep açısından bakıldığında arzın (uzmanların) sonsuza çıkması, talebin ortadan kalkması anlamına gelir Yetenek yetiştirme hattı 2 ila 10 yılda oluşur; büyüme teşviki ortadan kalktığı andan itibaren gelecekte ciddi bir kriz kaçınılmaz hale gelir Nitekim bazı yerel üniversitelerde bilgisayar mühendisliği derslerinin öğrenci azalması nedeniyle azaltıldığı örnekler oldu ve öğrenciler bunun nedeninin AI yüzünden kariyerden vazgeçmeleri olduğunu söyledi Uzman arzı ortadan kalkarsa, tamir edecek insanı para verip bulmak da mümkün olmaz Ekonominin temeliyle oynandığında sorun zaman gecikmesiyle büyür ve gerçekte buna yeterince hızlı tepki vermek zordur Sonunda ciddi bir kriz patlar ve ancak o zaman aşırı önlemler alınmaya başlanır

• Aslında bunun tersi bir durum da olabilir Kod tabanını AI'nin verimli kullanabileceği şekilde iyi dokümante eder, testlerini ve ayarlarını düzgün kurarsanız, 1 yıl sonra bir AI agent'ın aynı işi daha da hızlı yapmasını beklerim

  • AI Coding Tool'ların nasıl olup da mevcut geliştiriciler gibi "önceki kodun tamamı kötü, en iyisi her şeyi baştan yazalım" tavrını benimseyeceğini merak ediyorum İleride CI/CD sisteminin, tüm projeyi AI'nin baştan sona yeniden yazdığı bir yapıya dönüşmesi de ilginç olurdu

  • Yazarı benim; dediğin senaryoda zaten Bus Factor artmış olur Yani bilginin yalnızca insanların kafasında kalmayıp farklı biçimlerde saklanması ve kalıcı olması, işin özüdür