Claude, rsync'in hata sayısını artırdı mı?

 (alexispurslane.github.io)
2 puan yazan GN⁺ 2026-06-06 | 2 yorum | WhatsApp'ta paylaş
  • Claude destekli sürümler yalnızca rsync v3.4.2 ve v3.4.3 olmak üzere iki tane ve şiddet ağırlıklı hata/10 commit ölçütüne göre geçmiş sürümlere kıyasla alışılmadık derecede fazla hataya sahip olduklarını gösteren bir kanıt yok
  • sev/10c, hata şiddeti puanlarını 0~1 aralığına normalize edip sürüm bazında toplayan, commit sayısına bölen ve ardından 10 commit başına değere çeviren temel metriktir
  • v3.4.2, 50 commit·9 Claude commit'i·0 hata·0.00 sev/10c; v3.4.3 ise 34 commit·28 Claude commit'i·17 hata·3.29 sev/10c değerine sahip ve her ikisi de IQR'nin iki yanına yerleşiyor; hiçbiri aykırı değer değil
  • Kesin permütasyon testi p-değeri %46, Fisher'ın kesin testi p-değeri %74 ve odds ratio 1.06; yani Claude sürümlerinin rastgele seçilmiş 2 sürümden daha kötü olduğu ya da medyanı aşma olasılığının daha yüksek olduğuna dair neredeyse hiçbir sinyal yok
  • v3.4.1, Claude kullanılmadan önceki bir sürüm olmasına rağmen 59 hata·9 commit·39.39 sev/10c ile tüm veri kümesindeki en kötü değerdi; rsync tartışmasının özü, tarihsel dağılım olmadan tek bir regresyonu Claude ile ilişkilendirmekti

Arka plan ve soru

  • Mayıs 2026'nın sonlarında rsync tartışması, v3.4.3 regresyonunu ve bu sürümdeki Claude commit'lerini ilişkilendiren bir Mastodon gönderisiyle başladı; ardından Hacker News'e ve GitHub'daki "Please Do Not Vibe Fuck Up This Software" başlıklı issue'ya yayıldı ve bu issue'da 300'den fazla yorum birikti
  • Tekrarlanan temel iddia, Claude destekli geliştirmenin daha önce istikrarlı olan bir araca hata soktuğu yönündeydi; veri açısından soru ise Claude destekli sürümlerin tarihsel sürümlere göre anormal derecede fazla hataya sahip olup olmadığıydı
  • Lobsters'ta sürüm bazında regresyon sayılarının zaman grafiğiyle gösterilmesi istendi ve analiz tek bir soruya odaklandı: “Claude destekli sürümler alışılmadık derecede fazla hata mı içeriyor?”

Veri kapsamı ve yeniden üretilebilirlik

  • Veri, RsyncProject/rsync'in v2.4.6'dan v3.4.3'e kadar hata verisi bulunan 36 sürümünü kapsıyor; Claude commit'i içeren sürümler ise yalnızca v3.4.2 ve v3.4.3
  • Metrik, metodoloji ve veri kaynağı seçimleri doğrudan insan tarafından yapıldı ve istatistik yüksek lisans derecesine sahip eşin tavsiyeleri yansıtıldı
  • Veri toplama, DuckDB'ye yükleme, view oluşturma ve istatistik analiz betikleri GLM 5.1 tarafından yazıldı; ancak tüm sayılar, istatistikler, kartlar ve grafikler, istatistik analizini çalıştıran Python betiği tarafından otomatik şablonlarla eklendi
  • Yeniden üretim için alexispurslane/rsync-analysis deposu, tüm pipeline'ı baştan sona çalıştırabiliyor

Metrikler ve hata atama yöntemi

  • Temel metrik, şiddet ağırlıklı hata/10 commit anlamına gelen sev/10c olup hesaplama formülü sev/10c = (Σ severity/100 ÷ total_commits) × 10 şeklindedir
  • Commit'ler ana dalda committer date sırasına göre dizildi; her sürüm aralığı bir önceki tag'den ilgili tag'e kadar olan commit'ler olarak alındı ve pre·rc tag'leri sınırdan hariç tutularak nihai sürüme dahil edildi
  • Hata kaynakları üç taneydi: GitHub issue'ları, rsync Bugzilla ve rsync e-posta listesi; GitHub issue'ları ve e-posta listesi hataları, raporlama anından hemen önce dağıtılmış en son sürüme atandı
  • Bugzilla kayıtlarında “Version” alanı hatanın raporlandığı sürümü açıkça belirttiği için hata o sürüme atandı
  • Sürüm bazlı analizin seçilme nedeni, eleştirinin bizzat “Claude commit'i içeren sürümlerin tamamı daha hatalı hale geldi” biçiminde olması ve çoğu hatanın tam olarak hangi commit'ten kaynaklandığının belirtilmemesiydi

Şiddet değerlendirme yöntemi

  • Tüm hata raporları, Qwen 3 35B tarafından 0~100 arası bir şiddet puanıyla değerlendirildi; prompt, gerçek kullanıcı etkisi perspektifinden kıdemli bir güvenilirlik mühendisi rolü veriyordu
  • 90~100 puan sessiz veri bozulması·veri kaybı·uzaktan kod çalıştırma veya yetkisiz erişim güvenlik açıkları; 70~89 puan çökme·takılma·yedekleme başarısızlığı·build başarısızlığı; 50~69 puan ise aşılabilir işlev gerilemeleri olarak sınıflandırıldı
  • Bugzilla ve e-posta listesi kayıtlarında gövde metni yerine yalnızca başlık bulunduğundan model sadece başlığa bakarak değerlendirme yaptı; bilgi yetersizse 40~60 puanlık orta aralığa eğilim göstermesi istendi
  • Çıktı, structured output için JSON schema kullanılarak yalnızca tam sayı şiddet puanlarına izin verecek şekilde sınırlandı ve aynı girdinin aynı puanı üretmesi için temperature 0'a sabitlendi
  • Özellik isteği, spam, AI ile ilgili teknik olmayan şikayetler ve boş gönderimler gibi 0 puan alan issue'lar temel hata sayısından çıkarıldı

Claude sürümlerinin istatistiksel sonuçları

  • v3.4.2, 50 commit'in 9'unda Claude commit'i içeriyordu; gerçek hata sayısı 0, sev/10c değeri 0.00 ve yüzdelik konumu 0 idi
  • v3.4.3, 34 commit'in 28'inde Claude commit'i içeriyordu; 17 hata, 3.29 sev/10c ve 77. yüzdelik dilimdeydi
  • Tarihsel IQR 0.29~2.59 sev/10c aralığındaydı; v3.4.2 IQR'nin hemen altında, v3.4.3 ise hemen üstünde yer alıyor; yani iki sürüm orta dağılımı karşıt uçlardan çevreliyor
  • Kesin permütasyon testi, mümkün olan 595 adet 2 sürümlük kombinasyonun 272'sinin Claude grubunun ortalaması olan 1.65 sev/10c veya üzerinde olduğunu gösterdi ve p-değerini %46 olarak verdi
  • Fisher'ın kesin testi, medyan 0.74 sev/10c eşiğine göre Claude sürümlerinin medyanı daha sık aşıp aşmadığına baktı ve p-değeri %74, odds ratio ise 1.06 çıktı

Commit sayısı ve değişiklik boyutu

  • Claude sürümleri ortalama 42 commit içeriyordu; Claude içermeyen sürümler ise ortalama 185 commit ve rastgele seçilen 2 sürümün en az bu kadar ya da daha fazla commit'e sahip olma olasılığı %88'di
  • GitHub compare API'ye göre değişen satır sayısı, Claude sürümlerinde ortalama 3.756 satır; Claude içermeyen sürümlerde ise ortalama 696 satırdı ve rastgele 2 sürümün en az bu kadar ya da daha fazla değişen satıra sahip olma olasılığı %5'ti
  • Şiddet ağırlıklı hata sayısı, Claude sürümlerinde ortalama 5.6; Claude içermeyen sürümlerde ise ortalama 14.9'du ve rastgele 2 sürümün en az bu kadar ya da daha fazla şiddet ağırlıklı hataya sahip olma olasılığı %77'ydi
  • Sonuç olarak Claude sürümleri çok daha fazla değişen satır içeriyordu, ancak ne commit sayısı ne de şiddet ağırlıklı hata sayısı daha yüksekti

Sürüm düzeni ve önceden var olan aykırı değerler

  • v2.x sürümlerinin ortalaması 1.11 sev/10c, v3.x sürümlerinin ortalaması ise 4.23 sev/10c idi; yani v3.x tarafında daha yüksek bir hata oranı görülüyordu
  • Yalnızca v3.x karşılaştırıldığında bile Claude sürümleri orta sıralarda veya daha iyi konumdaydı; Claude'u aykırı değer gibi göstermek için daha sakin bir geçmiş dönemle kıyaslamak ve aslında Claude'dan önce gerçekleşmiş değişimi Claude'a yüklemek gerekiyor
  • Wald–Wolfowitz runs test, Claude içermeyen 35 sürümde gözlenen 13 run, rastgele beklenen 18.5 run, z=-1.88 ve p=0.060 sonucunu verdi; bu da 0.05 eşiğinde rastgeleliği reddedecek kadar güçlü değil
  • v3.4.1, Claude kullanılmadan önceki bir sürüm olmasına rağmen 59 hata·9 commit·39.39 sev/10c ile tüm veri kümesindeki en yüksek hata oranına sahip sürümdü
  • v3.4.1, v3.4.0'dan sonraki gün çıkan bir hotfix sürümüydü; diğer tüm sürümleri tek haneli farkların çok ötesinde geride bırakan en yüksek hata oranına sahipti, ancak o dönemde suçu AI'ya atacak bir hedef yoktu

Yorum ve sınırlamalar

  • Verilerle uyumlu yorum, “şu anki iki Claude sürümü tarihsel sürümlerden istatistiksel olarak ayırt edilemiyor” yönündedir
  • v3.4.3, 3.29 sev/10c ile 77. yüzdelik dilimde olduğu için yüksek sayılabilir, ancak uç bir değer değildir; tarihsel olarak bundan daha yüksek puan alan 8 sürüm vardır
  • “Claude kesin olarak daha kötü hale getirdi” iddiası; ne sürüm dağılımı, ne permütasyon testi, ne de Fisher testi tarafından destekleniyor
  • Tersine, “Claude commit'leri genel olarak gelecekte de daha kötü hale getirmez” sonucu da bu veriden çıkmıyor; mevcut bulgu yalnızca bu iki sürümün sıradan aralıkta kaldığıdır
  • Bu metrik, commit karmaşıklığını veya güvenlik çalışmalarının yoğunluğunu kontrol edemeyen kaba bir araç olma sınırlamasına sahip

Tartışılan karıştırıcı etkenler

  • Hacker News'teki bir kullanıcı, CVE yanıtı kapsamında yapılan güvenlik düzeltmelerinin 2007'den beri kodda bulunan programlama hatalarını görünür hale getirmiş olabileceğini düşündü
  • Lobsters'taki bir kullanıcı, “LLM → bilinen güvenlik sorunlarında artış → normalden fazla değişiklik ihtiyacı → normalden fazla regresyon” şeklinde bir nedensellik zinciri önerdi
  • Andrew Tridgell, AI tarafından üretilen CVE raporu selinin rsync'in saldırı yüzeyinde hızlı ve kapsamlı değişiklikler gerektirdiğini açıkladı
  • Bu karıştırıcı etkenler de hesaba katıldığında, sorun Claude'un kendisinden ziyade daha fazla güvenlik çalışması ve buna bağlı artan değişiklik hacmi gibi görünüyor

İlgili okumalar

2 yorum

 
GN⁺ 29 일 전
Hacker News görüşleri

  • Commit geçmişine bakarken asıl commit ile geri alma commit’ini fark ettim: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
    malloc olması gereken yolların bile calloc olarak değiştirilmesi, tüm tahsisleri sanki calloc, mallocun katı bir üst uyumlu sürümüymüş gibi zorlamış. Büyük tahsislerde ya da özyinelemeli tahsislerde bunun maliyeti epey yüksek olabilir. Bu, Claude ile yazılan kodda böyle şeylerin gözden kaçmasına iyi bir örnek gibi görünüyor. Geri alma işlemi https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721... burada; geri alma açıklaması da yarısına kadar okununca bile LLM tarafından yazılmış hissi veriyor. Asıl gönderiyi açan kişinin ne hissettiğini anlıyorum

    • Commit sayısının kendisi de şüpheli. Son iki ayda rsync’e giren commit sayısı, ondan önceki iki yılın toplamına yakın ve çoğu da Claude ile yazılmış commit’ler. Böyle değişikliklerin de içeri girmesi, AI kullanımı konusunda heyecanlanıp giderek dikkatsizleşmenin tipik bir örneği gibi görünüyor
    • “Claude ile yazıldı” demek doğru değil. Geri alma commit’i https://github.com/RsyncProject/rsync/issues/959 konusuna atıf yapıyor ve o konuda yazar doğrudan “belleği 0’lama değişikliği benim fikrimdi ve benim yaptığım değişiklikti” diye açıklıyor
      Güvenlik raporunda dizinin sonunu aşan öğe kullanımından bahsedilmişti; tahsisleri 0 ile başlatmanın, benzer bir hata ileride tekrar olursa geçerli bir pointer yerine null pointer dereference ile sonuçlanma ihtimalini artıracağını düşündüğünü söylüyor. Claude’u sadece commit grubunu düzenlemek için kullanmış; en ufak düzenlemede bile co-authored etiketi eklendiği için bu, değişikliği Claude’un yazdığı anlamına gelmiyor. Asıl kodu kendisinin yazdığını açıkça belirtiyor
    • Bu kararı Claude’un verdiğini kesin olarak söylemezdim. Büyük bir commit’in arasına gizlice sıkıştırılmış yan bir değişiklik de değil; commit mesajı daha en başta “yeni tahsis edilen belleğin tamamını 0 ile başlat” diye başlıyor ve gerçekten de bunu yapıyor. Başlangıçta nasıl bir prompt verildiğini hayal ettiklerini bilmiyorum
      Bir insanın önce bunu iyileştirme sanıp sonra RSS gerilemesini görünce fikrini değiştirmiş olması gayet mümkün. Ayrıca bu değişikliğin mutlaka RSS’yi artırması gerektiğine dair bir doğa yasası da yok. calloc, işletim sisteminden yeni alınan bellek eşlemelerinin zaten 0 ile başlatıldığını bilip özel durum uygulayabilir. Burada AI’yı suçlayacaksak, bu daha çok AI’nın güvenlik açığı raporlarında patlama yaratması, bunun da acele düzeltmelerde patlamaya yol açması ve acele düzeltmelerin bazen başka sorunlar üretmesi anlamında olur
    • AI’nın üstüne bir de Linux overcommit çağı, harika. Bana kalırsa 10.8GB artık o kadar da büyük bir şey değil; sprintf buffer’ı belki daha bile büyüktür. Değilse öyle olmalı, yoksa snprintf kullanmaya başlamaları gerekir

  • Yorum yapmadan önce rsync yazarının bağladığı yazıyı okumanızı tavsiye ederim: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
    Açık olmak gerekirse Tridge ile birkaç yıldır iletişimde değilim ama uzun yıllar meslektaşım ve akıl hocamdı. Haçlı seferine katılmadan önce onun bakış açısını değerlendirmekte fayda var

    • Bu en üstteki yorum olmalı. Böyle bir yazı yazmak zorunda kalmış olması oldukça üzücü. Faturasını bile ödemeyen insanlar gereğinden fazla hüküm veriyor
    • “Yeni test paketinin temel yapısını önce master üzerinde açık şekilde oluşturmanın iyi olacağını düşündüm” kısmını tam anlayamadım. Sadece testleri güncellemiş ya da yalnızca master’a push etmiş olsaydı insanlar bu kadar öfkelenmezdi
      Ama o, release branch’e de kırıcı değişiklikler push etti. Yıllardır çalışan bir iş akışını bozmak, insanları kızdırmanın en garanti yoludur; bir de commit’te “Claude” görünüyorsa bu ateşe benzin dökmek olur
    • Onun yanıtının gerçekten iyi yazılmış bir karşılık olduğunu düşünüyorum

  • Bu tartışmada doğrudan bir çıkarım yok ama şüpheli görünen birkaç nokta var. En çok hatanın atfedildiği sürüm, Claude ortak yazarlı commit'lerinin ilk kez girdiği sürümden hemen önceki Ocak sürümü; bu sürüme atıf etiketi olmayan LLM tarafından yazılmış commit'ler girmiş olamaz mı diye merak ediyorum.
    Sürüme atfetme metodolojisi de pek iyi değil. Bir minor sürüm güncellemesinde giren hatalar, o minor sürüm içinde en uzun süre kalmış patch sürümüne atfedilme eğiliminde. 3.4.1'in gerçekten çok sayıda hata getirdiğini düşünmek zor; 3.4.0'dan bir gün sonra çıktığı için o sürümde oluşan hataların 3.4.1'e yazılmış olması daha olası. Ayrıca son sürümlerin hata raporlanması için daha az zamanı olduğundan, yeni sürümler olduğundan daha az hatalıymış gibi değerlendirilmesine yol açan bir yanlılık da olabilir

    • Katılıyorum. Yazıdaki “rsync tarihindeki en kötü sürüm Claude kullanılmadan önceydi ve bunu kimse fark etmedi” ifadesi, yazarın bu tartışmada çıkarı olmadığı hissini vermekten çok gösterişli istatistik terimleriyle görüşünü süslüyor hissi veriyor.
      “Göz kamaştıracak kadar açık”? Bir grafik çizmek yeterli. Ayrıca v3.4.1 tarihi 2025-01-16, yani teknik olarak AI destekli kodlama çağının içinde ve atıf etiketlerinin standart uygulama haline gelmesinden öncesine denk geliyor
    • Sürümlerin oldukça seyrek çıkmasını dikkate alınca aynı kısma bakmaya başladım. Atıf etiketi olmayan LLM yazımı commit sorunundan kaçınmak için, analizin v3.3.0 öncesi ve sonrası hata ciddiyeti karşılaştırmasını içermesi gerektiğini düşünüyorum. Tarih 6 Nisan 2024
    • LLM'ler birçok şekilde kullanılabilir. İnsanın çok doğrudan devreye girip yalnızca yerel değişiklik yaptırdığı kullanımdan tamamen ona bıraktığı kullanıma kadar geniş bir yelpaze var.
      LLM üretmiş olmasına rağmen commit mesajında ortak yazar etiketi olmayan çok kod gördüm. Genelde ancak kod tabanıyla etkileşim Claude/Codex gibi araçlar üzerinden tamamen yürütüldüğünde böyle bir etiket ekleniyor gibi görünüyor ve o commit'ler çoğunlukla en uzun anlatımlı olanlar ama neden değişiklik yapıldığını neredeyse hiç söylemeyip sadece kod değişikliğini özetliyor. Tersine, Claude'u araç olarak kullanan geliştiriciler de gördüm. VSCode ile Claude terminali arasında gidip gelerek doğru kodu bizzat kontrol ediyor, angarya işleri ise Claude'a bırakıyorlar. Muhtemelen yazar da küçük başlayıp zamanla kapsamı büyütmüş olabilir
    • Birinci ve ikinci noktalar birbiriyle çelişiyor gibi görünüyor. Eğer 3.4.1'deki tüm hatalar 3.4.0'a atfedilmeliyse, atfedilmemiş LLM commit'lerinin projeye girmiş olması gereken zaman daha da geriye gider ve bu da hipotezi daha da akıl dışı hale getirir.
      Daha büyük sorun şu: Önceki sürümlere gizlice LLM commit'leri girdiği ve hata oranının bu yüzden arttığı hipotezini destekleyen hiçbir kanıt yok. Hata sayısı yüksekse bunun otomatik olarak AI müdahalesi anlamına geldiğini varsaymadığınız sürece ortada dayanak yok; bu da döngüsel akıl yürütme olur. Üçüncü nokta geçerli. Genelde hata bulmanın ne kadar sürdüğünü ve her sürümün yayın döngüsünde kabaca nerede durduğunu analiz etmiştim; istenirse paylaşabilirim
    • En bariz şekilde şaşırtıcı hatadan başlayalım: Claude istatistikleri toplam 2 veri noktasından çıkarılmış

  • Burada önemli bir meta düzeyde ironi var. Asıl yazı AI kullanımını savunuyor ama verileri analiz ederken ve sonuçları sunarken de açıkça AI kullanılmış gibi görünüyor.
    Bu süreçte yazar, iyi anlamadığı bir şekilde istatistik kullanmış ve birçok yanlış sonuca varmış. İlgili tartışma https://news.ycombinator.com/item?id=48417626 adresinde görülebilir. Özetle, bu çalışmanın yeterli istatistiksel gücü yok ve haklı çıkarılmamış bir “fark yok” iddiasında bulunuyor. Sonuçta LLM ile verileri yorumlarken, bu çalışmanın araştırmaya çalıştığı şeyle aynı türden bir hata, yani yanlışları kendinden emin biçimde ileri sürme hatası yapılmış oluyor

    • AI fazla din gibi. İnanan birine ne söylersen söyle, inancını sorgulamasını sağlayamıyorsun. Daha genel söylersek, birinin inanmak istediği bir şeyden rasyonel argümanlarla vazgeçmesini sağlayamazsın

  • Bu işe kızan insanların rsync bakımcısına baskı yaparak elde edeceği tek şeyin, başkalarının AI kullanımını sorumlu biçimde açıklamamasına yol açmak olacağını düşünüyorum. Tartışmadan kaçınmak için commit'lerdeki Claude atıf etiketini kapatmalarına neden olacak

    • AI kullanımının açıklanmasını pek umursamıyorum. Bizzat tanıdığım biri değilse, insan yazımı kodun AI yazımı koda mutlaka daha iyi olduğunu düşünmüyorum.
      Sonuçta commit edilip pushlanan kodun sorumluluğu insana aittir. Bu hiç değişmedi. Elle yazılmış olsun, klavyenin üstünde yürüyen bir kedinin eseri olsun ya da AI üretmiş olsun, benim için fark etmez. Projenin kod kalitesi pek çok nedenle düşebilir ve sadece AI üretip üretmediğine takılmak verimli değil. Birileri AI'ı eleştirmek için bahane arıyor, bir başkası AI'ı savunmak istiyorsa bunu yapabilir ama bu, proje kod kalitesini değerlendirmenin doğru yolu değil
    • Tartışmadan bağımsız olarak bu tür etiketleri kapatmak doğru olur. Trilyon dolarlık şirketlere ücretsiz reklam yapmanın anlamı yok. Generated-by gibi trailer'lar ancak üçüncü taraf projelere katkı verirken anlamlı; o durumda da açıklamak nezakettir
    • “Etik dışı ya da ahlaksız bir şey yaptığın için öfkelenme, yoksa daha da etik dışı ya da ahlaksız bir şey yaparım!” gibi geliyor.
      LLM tarafından üretilmiş kodun atıf etiketini kapatmak sahtekarlıktır. Çünkü kodu kendin yazmışsın gibi söylemek olur. Gerçi bu, zaten en başta LLM ile kod üretme pratiğiyle de uyumlu. Nihayetinde yapılan şey, lisans ve telif hakkı bildirimleri kaldırılmış girdiyi papağan gibi geri kusmak
    • Bunun kötü bir şey olduğundan emin değilim. Anthropic'in pazarlama departmanı açısından öyle olabilir ama eğer ajan sadece geliştiricinin alet çantasındaki başka bir araçsa, atıf etiketi biraz tuhaf hissettiriyor. Sonuçta commit'in sorumluluğu geliştiricide
    • Bu mantık her seferinde ortaya atılıyor ama ikna edici değil. Sorunu kamuya açık şekilde dile getirmenin onu gizleme teşviki yarattığı doğru, ama bunun sonucu olarak ne yapmamız gerektiğini bilmiyorum.
      AI'ın kötü olup olmadığı tartışmasını bir kenara bırakırsak, benzetme olarak vergi kaçırmak kötüdür, etik dışıdır ve görüldüğünde dile getirilmelidir. Ama bunun gizleme teşviki yaratması, o halde kimsenin bunu söylememesi ve sessiz kalması gerektiği sonucuna götürmez

  • Andrew'un rsync'i yaratıp yıllardır bakımını üstlenmiş olmasına minnettarım ama ev ağımda makineler arası dosya yedeklemede rsync'e ciddi biçimde bağımlı olduğum için, Homebrew'deki rsync sürümünü 3.4.1'e sabitlemenin yolunu bulmak için zaman harcadım.
    Sonraki iki sürümdeki hatalar gerçekten korkutucu, bu olanları tetikleyen ilk rapor da öyle. Beklediğimden çok daha karmaşık çıkan adımları burada özetledim: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

  • Bu yazı yanıtlardan çok soru bırakıyor, bu yüzden bir yargıya varmak zor. Claude commit’inden hemen önceki v3.4.1’in neden en fazla hataya sahip olduğunu ve neden “kimsenin bunu fark etmediğini” anlamıyorum. Bunu sadece insan hatası deyip geçmek için fazla tuhaf
    Ayrıca v3.4.2’de neden 0 hata ya da hata puanı 0 olduğu da soru işareti. Diğer commit’lerde görünmeyen bu tür aykırı değerlerin toplu istatistiklere karışıp “Claude hata üretiyor mu?” puanını düşürmesine izin verilmesi de garip. Açıkçası bunun yazarın analizinde bir alarm işareti olmamasını anlayamıyorum. İleri istatistikler çalıştırılıyor diye yarım yamalak bir analizin çok karmaşık, tamamlanmış bir ürün gibi sunulduğu hissini veriyor

    • v3.4.1’in insan hatası olmadığını düşünmek için, bunun olamayacağına dair peşin bir varsayım dışında ne sebep var, bilmiyorum
      v3.4.2 de aslında ilk metrikte, özellik istekleriyle sorular ayıklanmadan önce 4 hataydı; ondan önce daha da yüksekti ama genel analizde büyük bir fark yaratmıyordu. Çeyrekler arası aralığın içindeydi, hem de alt tarafa rahatça giriyordu. Claude sürümü sadece iki tane varken tek bir aykırı değeri sırf komik görünüyor diye çıkarmanın daha kötü ve daha keyfi olduğunu düşünüyorum

  • “Commit karmaşıklığını, güvenlik odağını, hata ciddiyetini kontrol etmiyor. Tek satırlık yazım hatası düzeltmesiyle CVE yamasını ayırt etmeyen kaba bir araç. Ama eleştirmenlerin ‘Claude durumu daha kötü hale getiriyor’ suçlaması da kaba bir araç olduğu için, en adil cevap yine kaba bir araçtır” deniyorsa, buna katılmak zor
    Kullanıcı açısından hataların niteliğinin daha kötüye gidip gitmediğini anlamamız gerekiyor. Oran aynı kalsa bile hissedilen yazılım kalitesi düştüyse, özellikle de proje bakımcısıysanız, bunu daha kötüye gidiş sayarsınız. Bu analizi tamamen yok saymak istemiyorum ama böyle soruların yalnızca nicel analizle yeterince cevaplanmasının zor olduğunu düşünüyorum

    • Yine de adil olduğunu düşünüyorum. Şimdiye kadar birinin kodu analiz edip hangi ciddiyette kaç gerileme olduğunu söylediğini görmedim. Sadece “LLM yüzünden hatalar arttı” deniyor
      Bu analiz istenirse doğrudan doğrulanabilir ve “LLM olsa bile hata sayısı oldukça ortalama” diyor. Yani o iddiaya doğrudan cevap veriyor. Daha incelikli bir analiz isteniyorsa, isteyen kendisi yapıp sonucu paylaşabilir
    • Kanıt olmadan öne sürülen bir iddia, kanıt olmadan reddedilebilir. Bu analiz, ilk iddiada kullanılandan daha fazla kanıt ve daha yüksek titizlik içeriyor. Bana göre yeterli. Biri çıkıp ilk iddiayı daha iyi kanıtlarla gerçekten desteklerse güzel olur, görmek isterim. O zamana kadar bu konuyu dert etmeyeceğim
    • İspat yükü iddiada bulunan tarafta değil mi?

  • 20 yılı aşkın süredir kod yazıyorum, yazmayı sevdim ve büyük olasılıkla sevmeye devam edeceğim. Birkaç ay öncesine kadar yapay zeka konusunda şüpheciydim ama Claude ve Codex, geliştirme biçimimi ve hızımı hayal bile etmediğim şekilde değiştirdi
    Sonuç olarak daha fazla kod üretiyor ve daha fazla hata da buluyorum. Bu yüzden HN yorumlarında AI ile üretilen şeylere yönelik aşırı nefreti görünce epey şaşırıyorum. AI yardım etti ya da her şeyi üretti diye bir proje bir anda vibe coding olmuyor; bu ifadenin LLM kullanıcılarına yöneltilmiş bir hakaret olması da gerekmiyor. Bu bana 90’ların ortasından sonra yurtdışı outsourcing artarken “Hintli geliştirici”lere yöneltilen küçümseyici sözleri çok hatırlatıyor. 2020’lerin ortasında şimdi benzer söylemler AI’a yöneliyor. Bunu anlamıyorum. Kesin olan şu ki, karşı çıkanlardan bağımsız olarak giderek daha fazla kod AI ile üretilecek

    • Ben de 3 yıl önce benzer şekilde yapay zeka şüphecisiydim. GPT-4 en ileri modelken bağlam boyutu sınırları yüzünden yakında tıkanacağını düşünüyordum. 32K bağlam kullanmak için saçma paralar ödenen günleri hatırlıyorum
      Geçen yıl ilk kez bir AI ajanının önemsiz olmayan bir hatayı tatmin edici şekilde debug edip düzelttiğini gördüm. O zaman bile büyük işlerde kullanıldığında tüm issue tracker’ı baştan sona geçebilecek seviyede olmadığı açıktı. Şimdiyse son birkaç aydır Codex ile önemsiz olmayan bir proje üzerinde çalışıyorum. Kütüphane nedenleriyle prototipi C++ ile yaptım, ilk sürümü Haskell ile yazdım, yakın zamanda da mobil bellek kullanımını sınırlamak için Rust’a taşıdım. Kusursuz bir araç değil ama son 1 yıldaki ilerleme hızı şaşırtıcı. Şüphecilik iyidir ama sağlıklı şüphecilik, somut kanıt karşısında geri çekilmeyi bilmelidir
    • Araçların dahil olduğu her konuda, aracın kendisini sevenlerle o araçla başka bir şey yapmayı sevenler vardır. Programlamada ben ikinci gruptaydım. Programlama, aslında sevdiğim şey olan problem çözmeyi, sistem düzeyinde düşünmeyi ve yazılımla harika çözümler sunmayı mümkün kılan bir araç
      Bu yüzden AI’ın sıkıcı kısımlarda yardım etmesi benim için gerçekten keyifli; programcı olmayan iş arkadaşlarımın da kendi vibe coded fikirlerinin gerçeğe dönüşmesini heyecanla izlemesi çok eğlenceli. Yazılım sektöründe çalışan AI karşıtı tutumun bakış açısını gerçekten merak ediyorum. Sebep mesleğin yakında biteceği korkusu mu, yoksa teknolojik dönüşüm mü?
    • 90’ların ortasında yurtdışı outsourcing artarken “Hintli geliştirici”lere yönelik küçümseyici söylemler ortaya çıktıysa, bunun tetikleyicisi neydi?
    • Sürekli outsource edilmiş kodla uğraşıyorum ve istisnasız şekilde tam bir çöplük yangını gibi oluyor. Daha az önce, bir geliştiricinin yerel çalışma ortamını kurmayı bilmediği için kimlik doğrulama denetimlerini atlayan bir bayrağı varsayılan açık halde commit ettiği bir kod tabanını bir hafta boyunca temizledim
      AI vibe coding’de de aynı “kestirme yol” sorununun raporlandığını görüyorum ve ben de en ileri modelleri düşünme seviyesi 11’e çıkararak kullansam bile AI’ın ürettiği neredeyse bütün kodu yeniden yazmak zorunda kaldım. Buna rağmen AI, PR incelemesi, güvenlik açığı analizi, yazım hatası bulma, tersine mühendislik gibi başka işlerde çok faydalı. Muhtemelen aboneliğimi bir üst seviyeye çıkarmam gerekecek ama aynı anda AI’ın ürettiği kod hâlâ kullanılamaz durumda. Tek bir kişinin içinde bile “o kadar faydalı ki daha fazla para vermeliyim” ile “üretilen kodun kalitesi işe yaramaz” görüşleri aynı anda bulunabiliyorsa, genel kullanıcı kitlesinde farklı görüşlerin çıkması gayet doğal
    • LLM’ler bağlam arama ve şablon çıktısı üretmede iyi. Ama garanti edilen şey, en düşük ortak paydada öne çıkan cevap, telif koruması olmayan çıktı ve telif sızıntısından kaynaklanan potansiyel hukuki riskler
      Şu an izomorfik intihalin Napster altın çağı yaşanıyor

  • Bunun ne olduğuna anlam veremiyorum. Gerçekten önemli olan tek şey, AI tarafından yazılmış kodun kod tabanına girmesine izin verildikten sonra hataların artıp artmadığı. Cevabı herkes biliyor. Yine de bunun “veri” gerektiren bir sonuca ulaşmak için kullanılabildiğini görmek her zaman ilginç
 
GN⁺ 2026-06-06
Lobste.rs görüşleri

  • Bundan sonra vibe coding ile yürütülecek FOSS projelerini kullanmaya devam edip etmeyeceğine herkesin kendisinin karar verebileceğini düşünüyorum. Ancak bakımcının vibe coding araçlarına geçmesinden sonra topluluğun gösterdiği öfke oldukça şaşırtıcıydı ve yazıdaki ampirik veriler en azından bu pratik değişikliğinin etkisini daha iyi bağlama oturtuyor
    Bakımcı bu kodlama yaklaşımını benimsedikten sonra güvenin korunup korunmayacağını ya da daha da aşınıp aşınmayacağını zaman gösterecek

    • Bu geçişe öfkelenenler arasında gerçekten rsync’e anlamlı katkı yapmış ya da para vermiş kaç kişi olduğunu merak ediyorum

  • Bu analiz tam da görmek istediğim şeydi, hatta daha fazlasıydı. Özellikle “tüm metrikleri, metodolojiyi ve veri kaynaklarını Penn State University’de istatistik yüksek lisansı yapmış eşimle görüşerek bizzat seçtim” kısmını beğendim; gerçek bir istatistik uzmanını sürece dahil etmiş olmaları ve bunu okunması kolay bir yazıya dönüştürmeleri harika
    “10 commit başına hata sayısı” gibi tek bir metrik kullandıklarını söylüyorlar ama SI öneki kullanıp buna commit başına desihata (decibugs) deme fırsatını kaçırmış gibiler

    • Katılıyorum. Yazı benim değil ama birinin hararetli lehte/aleyhte tartışmaların ötesine geçip kod kalitesine etkisini verilerle göstermesi hoşuma gitti

  • Açık kaynak projelerin başarısı algıya fazlasıyla bağlı; öyle ki insanlar GitHub yıldızlarını para verip satın alıyor. Ne yazık ki bu algı sorunu artık kontrolden çıkıp başlı başına bir talking point hâline geldi ve bunu herhangi bir verinin değiştirmesi zor
    Bundan sonra “rsync bakımcısı LLM kullandı ve her şeyi bozdu” sözü, “veri merkezleri günde 500 bin galon temiz suyu israf ediyor”, “METR araştırması LLM’lerin üretkenliği düşürdüğünü söyledi” gibi başlıklarla birlikte AI şüphecilerinin öne süreceği bir nokta olacak
    AI şüphecisi olup olmadığımı söylemeye çalışmıyorum; sadece bu konudaki tartışmaların genelde böyle aktığını söylüyorum

    • Bu neden bir “talking point” olsun ki, düpedüz gerçek değil mi?
    • Yazarın verilerle birilerini ikna etmeye çalışıp çalışmadığından emin değilim. Bence bu yazı, rsync’in araç benimsemesi etrafındaki hararetli tartışmaya veri bağlamı ekliyor
      Ama yazıda nicel olmayan diğer unsurların tamamen dışarıda bırakıldığı da doğru; muhtemelen hem evangelistlerin hem de şüphecilerin gürültüsü zaten yeterince fazla olduğu için bunu bilerek yaptı

  • rsync tarihindeki en kötü sürümün Claude devreye girmeden önce çıkmış olması ve 10 commit başına 39,39 hata düşmesi çok önemli ve beklenen bir sonuç
    Kullanıcı ile geliştirici arasında test, kalite güvencesi gibi süreçler yazılımın doğruluğunu garanti etmiyorsa, ortada LLM olsun ya da olmasın, hatalı yazılım yayımlanır. LLM bu süreçte zararlı da olabilir, faydalı da

    • Katılıyorum. cURL’ün yakın tarihli yazısı karşı taraftan bir örnek gösteriyor gibi
      Zaten yıllardır yerleşmiş güçlü yazılım mühendisliği pratikleri sayesinde, benzer AI araçlarıyla hata bulmanın değeri genel olarak daha düşük kalmış
    • rsync’in geleceğiyle ilgili bazı endişelerim var. En büyük sorun, rsync’in aslında yıllardır fiilen tamamlanmış bir proje olması ama AI kullanılmaya başlanınca mevcut test kodunun sökülüp yerine Python test paketi getirilmesi ve uzun bir süre eski testlerin paralel çalıştırılarak doğruluğun doğrulanmaması
      Bana göre bu sorumsuzluk. Özellikle de rsync’in temel amacının değerli verileri taşımak olduğu ve bu verilerin bütünlüğünün mutlak önem taşıdığı düşünülürse

  • “AI karşıtı kullanıcılarda tipik olduğu gibi sonunda şiddet fantezisine kadar tırmandı” gibi ifadelerden kaçınılmasını isterdim. Bu, yazarın aynı fikirde olmadığı bazı insanları genelleştirmekle kalmıyor, baştan zaten katılmayan okurları da itiyor ve tam da yazıyı en çok okuması gereken kişilerin uzak durmasına yol açıyor
    Ayrı olarak, önceki sürümden daha fazla ya da daha az hata olması umurumda değil. Benim için önemli olan, yazılımın benim doğru bulduğum yazılım geliştirme anlayışıyla uyuşmayan bir şekilde geliştiriliyor olması. Verimlilik dışında da sorunlar olabileceğine dair temel bir kavrayış yoksa bu tutumun makul olduğunu insanlara anlatmayı beklemiyorum
    Neyse ki istemezsem rsync’in bu sürümünü kullanmak zorunda değilim ve LLM kullanılmadan önce çatallanmış bir alternatifi tercih edeceğim

    • Bu yazı o kadar öfke doluydu ki uzun süre okuyamadım, bırakmak zorunda kaldım. Adil olmaya çalışsa ya da en azından öyle görünse daha iyi olurdu
      Ayrıca, ilk hata raporunun insanların akın ettiği issue olduğu gibi çoktan çürütülmüş bir meme’i tekrarlaması da yardımcı olmadı. Gerçekte ilk hata raporu farklıydı

  • Bence yazı şu an dürüst olmak gerekirse daha iyi. Yine de “bu metrik commit karmaşıklığını, güvenlik hassasiyetini ve hata ciddiyetini kontrol edemiyor. Tek satırlık yazım hatası düzeltmesiyle CVE yamasını ayırt edemeyen kaba bir araç” kısmı, LLM'ler kötüdür tarafındaki benim konumumdan bakınca asıl eleştiriyi kaçırıyor.
    Benim ve başkalarının dile getirdiği eleştiri, yapay zekanın daha büyük, anlaşılması daha zor ve karmaşıklığı artıran commit'ler üretmeye yöneltmesi. LLM savunucuları da benzer şeyler söyleyip sonra, onlarca yıldır doğrulanmış “PR okuma” pratiğinden çıkıp kaleyi “LLM her şeyi test edebilmeli” noktasına taşıyor. Ama kod karmaşıklığının teknik borç olduğu gerçeği ortadan kalkmıyor.
    Bu vakada hatanın ciddiyeti çok yüksek. Çünkü yedekleme iş akışı gerçekten bozuldu. rsync yedeklemede yaygın biçimde kullanılıyor ve insanlar bunu o kadar “sahada kanıtlanmış” bir araç olarak gördü ki, bir yama güncellemesinin yedekleme betiklerini bozabileceğini hayal bile etmedi.
    LLM'in hatalı yazılım üretmesinin tesadüf olduğunu ya da bakımcının LLM iş akışını değiştirip test kapsamını artırması gerektiğini söyleyebilirsiniz. Nitekim bakımcı da bunu söyledi. Ama öfkenin özü, bu aracın o güveni kırmış olması.
    Gerçekten de bugünlerde “kodu hiç okumuyorum” diyen yeni bir LLM programcısı türü var. Sebebi, okumanın çok uzun sürmesi ve sıradan programcı koduna göre kavramasının daha karmaşık olması. Kod okumak, başkasının zihinsel modelini öğrenmektir; LLM araçları ise tek ve tutarlı bir zihinsel model sunamıyor.
    Ayrı olarak sitenin erişilebilirliği de kontrol edilmeli. Görüşüm oldukça iyi ve 20'li yaşlarımın sonundayım ama krem/sarı arka plan üstündeki açık gri yazıyı okumak gerçekten çok acı verici.

    • Alıntılanan kısım kafamı karıştırdı. Yazıdaki metrik, her 10 commit başına düşen hata sayısına ciddiyet ağırlığı vermiş gibi görünüyor; yazar kendi kendisiyle çelişiyor mu? Ben mi yanlış okudum?
    • İş akışının bozulduğunu söyleyenler için bunun, açık kaynak yazılımın ve GPL lisansının ne olduğunu ve ne tür güvenceler verdiğini öğrenmek adına iyi bir fırsat olduğunu düşünüyorum.
      İnsanların bu hatayı doğrudan kendilerinin keşfetmiş olduğunu sanmıyorum. rsync kullanıcılarının %90'ından fazlasının bu hatayı içermeyen eski bir sürümü kullandığını tahmin ediyorum. Ben de onlardan biriyim. 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      İlgi çekmesinin nedeni buysa, şu anda topluluğun önemli bir kısmının kafa karışıklığı yaşadığını görmek için Steven Pinker olmaya gerek yok. LLM'lerin programlamada insanlardan daha iyi olduğu gerçeğini kabullenmek kolay değil.
      Kimliğini ve özsaygısını programlama becerisine ya da mesleğine dayandıran insanlar, gelecekteki geçim/ piyasa değeri konusundaki belirsizlik ve kimlik krizi olmak üzere iki krizle karşı karşıya.
      Korku, belirsizlik ve şüpheyle başa çıkmak zor; LLM şirketleri de hisse fiyatlarını yükseltmek için bunun etkisini büyütmek adına ellerinden geleni yapıyor. Ekim'den sonra piyasa sert biçimde düzeltirse bu büyütme mekanizmasının da zayıflayabileceğini düşünüyorum.
      Dünya çapındaki programcıların çok küçük bir yüzdesi, yani kodu bir sanat biçimi olarak görenler, muhtemelen LLM'leri eğitim ve beceri geliştirme için kullanacaktır.

  • Bu yazı regresyondan bahseden yorumlardan çokça alıntı yapıyor ama analiz aslında regresyon değil, yalnızca hata raporlarını ölçüyor. Hataları, hatanın eklendiği sürüme değil bildirildiği sürüme bağlıyor ve sürümün ciddiyetini commit sayısıyla ölçerken sürüm süresi ya da dağıtım benimsenmesi gibi bariz etkenleri dışarıda bırakıyor.
    Bunun nasıl anlamlı olabildiğini anlayamıyorum.

  • Kişisel olarak LLM kullanan projelerden kaçınıyorum. Bunun somut bir nedeni olduğundan değil; sadece bana çok itici geliyor. Birinin “kek” ya da “fren” gibi şeyler söylemesini, ortada özel bir neden olmasa bile artık o kişiyle etkileşmek istemediğime dair bir işaret saymama benziyor.
    Şu anda LLM kullanımını sevmemek için öne sürülen açıklamalar bana sonradan eklenmiş rasyonalizasyonlar gibi geliyor. Etik, kalite gibi mevcut kaygılar doğru olabilir ama bu sorunlar çözüldü diye benim gibi AI karşıtı eğilimdeki insanların bir anda bunu sorun etmemeye başlayacağını sanmıyorum.
    Bu yüzden “AGENTS.md”, Claude ortak yazarlı commit'ler vb. olan projelerden somut bir gerekçe olmadan uzak duruyorum. Sadece hoşuma gitmiyor, zevkime uymuyor; hata olsun ya da olmasın fark etmiyor. Başkalarının da benzer hissettiğini düşünüyorum.

  • Yazara şunu söylemek isterim: Birincisi, fantezi sözdür. Fiiliyatta bunun sözde kaldığını iddia etmiş oluyor ya da en azından sözün sözel olmayan bir tırmanışa dönüştüğünü iddia etmiyor.
    İkincisi, böyle bir iddiada bulunacaksanız, yakındaki bir istatistik uzmanına bunun nasıl desteklenebileceğini sormanız gerekir. Birkaç kişinin böyle gönderiler paylaşmış olması, bunun “tipik” olduğu iddiasını anlamlı biçimde desteklemez.
    Benim istatistikle desteklenmemiş anekdotsal gözlemime göre “AI karşıtı” kullanıcılar, LLM'lerin işe yaramadığı yerlere sokulmasını çoğunlukla şiddetli bir şey olarak değil, daha çok üzücü bir şey olarak görüyor.

    • Bazen LLM karşıtlarının bir kısmına, genelde LLM'lere duygusal ve toplumsal tepki veren kesime karşı çok uzun ve ayrıntılı yazılar görüyorum. Nedenini net açıklamak zor ama bunlar bana çok kötü niyetli geliyor; sanki zayıfa vuruyor gibi.
      O kadar ayrıntılı oluyorlar ki duygusal açıdan karşı çıkmak zorlaşıyor ve sonuçta “Sorun LLM değil, doğru kullanılırsa bir yükselteçtir. AI karşıtları ne konuştuklarını bilmiyor, sadece geri kalmaktan korkuyor” noktasına varıyor gibi görünüyor.
      rsync bakımcılarının çalışmalarını tartışmaya indirgemek de istemediğim için, buna nasıl ikna edici bir karşı argüman kurabileceğimi bilmiyorum.
      Buradaki istatistikler açık kaynak bakım perspektifinden ilginç olabilir ama sonuç garip biçimde tek tarafa eğilmiş görünüyor ve GitHub tarzı açık kaynağın benim katkı vermek istediğim biçim olmadığı hissi kalıyor.
      Yine de rsync deposunda bakımcıya topluca yüklenilmesi hiç iyi değildi diye düşünüyorum.
    • Kamusal şiddet fantezisini kabul edilemez diye nitelemek doğru. Bu, uygarlık olarak hedeflememiz gereken bir şey değil. Ama yazarın bunu “tipik” diye adlandırdığı kısım, bir genelleme olduğu için rahatsız edici.
      Anekdotsal gözlem konusunda ise şu çizgi romanın haklı olduğunu düşünüyorum. Belirli ve ölçülebilir iddialar görmeyi seviyorum; biraz sayıları sevdiğim için, biraz da çevrimiçi tartışmaları son karenin ideal dünyasına biraz daha yaklaştırdığı için.

  • Analiz için teşekkürler ama metodoloji konusunda ikna olmuş değilim. Her commit için çekirdek kodda, yani test veya dokümantasyon dışındaki kodda değişen satır sayısıyla çarpılmış fark birimi başına hata sayısı gibi bir metrik ve belirli bir hata sayısına ulaşmanın sürümden sonra ne kadar zaman aldığının analizi ilgimi çekiyor
    Yine de bu sürümün diğer sürümlere kıyasla çok daha fazla ilgi görmüş olması ve bu yüzden daha fazla hata bildirilmiş olma ihtimali yüksek; dolayısıyla gerçekten ikna edici bir metrik oluşturmak zor görünüyor. “Sürümden sonraki ilk birkaç hafta açısından tipik mi?” gibi sorular da pek faydalı olmayabilir