Bağımlılıklarda LLM üretimi kod yasak

• git-annex’in LLM tarafından üretilmiş kod içeren bağımlılıklar olmadan derlenebilmesi için son bir ayda yaklaşık 100 saat harcanarak inceleme yapıldı
• Bu çalışma, tek tek kodlardan çok tüm bağımlılık ağacını sürekli takip etmek gerektiği gerçeğini ortaya koyuyor ve bakım yükünü ciddi biçimde artırıyor
• İnceleme sırasında, büyük ölçekli LLM üretimi değişikliklerin açıklama olmadan geri alınması, 26.000 LOC’luk bir kod tabanında 10.000 satırlık değişiklik, 1.489 satırlık tutarsız commit mesajı gibi örnekler tespit edildi
• Bağımlılıkların kalite bilgisi hakkında ek veri elde edilmiş olması olumlu görülse de, Software Freedom Conservancy veya FSF gibi kurumsal düzeyde bir yanıt konusunda kuşkucu bir bakış sürüyor
• LLM ile yapılandırma ekleme ya da biçimlendirme değişikliği yapmak kolay olsa da, bu tür commit’ler işbirliği güveni ve projeye katılım üzerinde doğrudan maliyet yaratabiliyor

---

git-annex bağımlılık incelemesi

• git-annex’in LLM üretimi kod içeren bağımlılıklar olmadan derlenebilmesi için yaklaşık bir ay boyunca yaklaşık 100 saatlik inceleme yapıldı
• Şu ana kadar hedefe ulaşıldığı görülüyor
• İlgili sayfa: git-annex no LLM code
• Sorunun özü, programın tüm bağımlılık ağacını sürekli gözden geçirme yükünde yatıyor

İnceleme sırasında ortaya çıkan örnekler ve etkileri

• Tespit edilen örnekler, basit bir tercih meselesinden çok bakım ve güven sorununa dönüşüyor
  • Büyük ölçekli LLM üretimi değişiklikler bir sonraki sürümde hiçbir açıklama olmadan geri alındı
  • 26.000 LOC’luk bir kod tabanına 10.000 satırlık değişiklik girdi ve commit mesajı 1.489 satırlık tutarsız bir içerikten oluşuyordu
  • Başka bir projeden kod kopyalamayı söyleyen bir LLM prompt’u vardı ve şans eseri telif hakkı ihlalinden kaçınılmış gibi görünüyor
• Bu çalışma sayesinde bağımlılıkların kalitesi hakkında ek bilgi elde edildi ve bu bilgiler gelecekteki seçimleri etkileyebilir
• Software Freedom Conservancy, LLM tabanlı üretken yapay zeka önerilerinde bu sorunu pas geçmiş gibi görünüyor; FSF’nin daha iyi yapıp yapamayacağı da belirsiz
• Bu değişimler karşısında ilgili topluluklara katılımı yeniden değerlendirse de, çalışmayı ve kullanıcılara desteği sürdürülüyor
• LLM’e Add fourmolu config and restyled, neat, format a module gibi prompt’lar verip sonucu commit etmek kolay görünebilir; ancak bu davranışın geniş kapsamlı etkileri dikkate alınmalı

[GN⁺]

Lobste.rs yorumları

• Bugün öğrendim: git-annex’in Haskell ile yazılmış olması harika

  Bugün eve dönerken metroda yanımdaki kişi YouTube Shorts’u son ses izliyordu; sessiz ve tıklım tıklım bir trende bu gürültü kirliliği sinir bozucuydu
  Daha da sinir bozucu olan, izlediği videonun tamamen yapay zekâ ile üretilmiş düşük kaliteli bir video olmasıydı

  Bu yazıda, bağımlılıkların yazarlarının LLM’lerle anlaşılması zor değişiklikler ürettiğine dair anekdot bana dokundu
  LLM’lerin kötüye kullanımında en bunaltıcı kısım, birbirimizle etkileşimimizi bozması
  Eskiden şirkette üstünkörü düşünülmüş bir öneriyi incelesem bile temel fikir açıkça ortada olurdu; onu yakalayıp yorum yapmak kolaydı. Artık herkes zayıf bir değişikliği LLM’e verip dışarıdan iyi kurgulanmış gibi görünen, ama incelendiğinde delik deşik olduğu ortaya çıkan bir çıktıya dönüştürebiliyor
  Aynı şekilde dışarıdan iyi görünen kötü kod da üretilebiliyor

  Yeni bir şikâyet değil ama giderek daha fazla sinirime dokunmaya başladı
  İşi ve hayatı keyifli ve dolu kılan insani bağın temel parçalarından birini kaybediyormuşuz gibi hissediyorum

  • Bir iş arkadaşımın “bunu 🤖 yaptı” diye dürüstçe söylemesi iyi oluyor; böylece nasıl bir inceleme düzeyi beklediğini baştan anlayabiliyorum
    Genelde bu, kod tabanını daha iyi öğrenmek için kullandığı sürecin belgesi oluyor; bu yüzden iş arkadaşımın LLM çıktısını okuduğuna ve gerçekten öğrenip öğrenmediğini doğrulatmak istediğine güvenebiliyorum

  • Bence LLM’in değiştirdiği şey kalitenin göreli fiyatı
    Ev benzetmesiyle, eskiden çatısı akan ve temeli kötü, berbat bir McMansion 1000X; gizli baş ağrıları olmayan iyi bir ev 2000X idi

    Şimdi LLM teknolojisiyle, yetkin biri mekanik ve doğrulaması kolay işlerin bir kısmını devrederek iyi evin fiyatını teorik olarak 1500X’e indirebilir
    Ama berbat McMansion 100X’e düştü

    Bu yüzden düşük kaliteli McMansion’ların, kaliteli işi çirkin bir şekilde piyasadan itmesi oldukça olası
    İyi evi 2000X’ten 1500X’e indiren zanaatkârları rahatsız etmek gibi bir niyetim yok; ama 100X’lik kaba saba evler daha iyilerini piyasadan kovup bir limon pazarı yaratırsa müşteriler genel olarak yazılımdan çok daha fazla şüphe duymaya başlayabilir
    Alıcının kaliteyle çöpü ayırt etmesinin bir yolu olmaması nedeniyle limon pazarı çirkin bir şey
    Yazılımdaki en ünlü örnek, devasa bir çöp oyun dalgasının çok sayıda müşteriyi yakıp satın almayı bırakmalarına neden olduğu 1983 video oyunu çöküşüdür

• Bu tutumun gayet makul olduğunu düşünüyorum
  Kişisel olarak zamanla çoğunun boşa uğraş olacağını sanıyorum ve kendi yazılım kullanımımda çok dert etmiyorum; ama öznel açıdan gayet geçerli ve ilginç, ayrıca bu kişinin böyle yapmasını da iyi buluyorum

  Yapay zekâ iyimserlerinin abarttığı gibi, yapay zekâ karşıtı taraf da olumsuz yönleri aşırı dramatize etme eğiliminde
  Bu yazının kendisi daha çok bir istisna, ama son paragraftaki acele genellemeyi çıkarsaydı genel niyeti ve mesajı çok daha güçlü olurdu

  Yine de böyle yazıları okuyup duyguların içindeki ilginç tarafları bulmayı seviyorum
  Proje bazında bilinen son %100 LLM’siz kod veritabanı olsa ilginç olurdu
  Etkili slop veritabanı da eğlenceli olurdu; burada “etkili”nin hem olumlu hem olumsuz anlamda, “slop”un ise incelenmemiş çıktı anlamında olması önemli

  Kabaca 2023 başındaki GitHub arşivini almak gibi bir hile yapılabilir; ama tek bir zaman noktasının anlık görüntüsü değil de proje bazında son commit anlık görüntüsü olursa daha ilginç olurdu
  Bu veri kümesinden çıkabilecek çok sayıda ilginç sonuç var gibi görünüyor; ayrıca bu yazıdaki gibi yalnızca LLM’siz yazılımlarla bir ekosistem kurmak isteyenlere de yardımcı olur

  Tahmin edebileceğiniz gibi ben bir LLM kullanıcısıyım
  Yine de makul tarafta olduğumu düşünüyorum
  Merak ederseniz web sitemdeki yazıları okuyabilirsiniz; blog yazılarının gövdesinin %100 insan tarafından yazıldığına söz veriyorum
  Karşı görüşleri okumanın öğrenmenin ve gelişmenin en iyi yollarından biri olduğunu düşündüğüm için böyle girişimlere katılmayı seviyorum

  • Proje bazında son LLM’siz sürümü izlemeye yakın bir proje var
    Hararetli yapay zekâ karşıtları tarafından yürütülen https://codeberg.org/ethical-foss/open-slopware
    Bazı projeler için “son kirlenmemiş sürüm veya commit ID’si” var, ama tüm projeleri kapsamıyor

• Bu yazıyı göndermemin nedeni, yazarın bağımlılıklarda LLM kullanıldığını düşündüren belirli commit’leri bizzat arayıp bulması ve bulgularını derleyen bir sayfa oluşturmasını beğenmemdi

  Kişisel olarak bu yazının vibe coding’den çok topluluk ve pratikler hakkında olduğunu düşündüğüm için vibecoding etiketini koymalı mıyım emin değildim

• “Bu noktada yükselen gelgiti durdurmaya çalışıyor olabileceğimi biliyorum” diye bir ifade var

  Projenin bağlı olduğu derleyici etkilenirse kazanamazsınız
  Ben de hasar kontrolü yapıyorum, ama sonunda alternatifte ısrar etmenin daha kötü olduğu ve taviz vermek zorunda kalınan bir an geliyor

• Zor bir mesele
  Ne kadar iyi analiz edilirse edilsin LLM kodundan kaçınmak muhtemelen zor olacak
  Örneğin kod otomatik tamamlama ile giren kodu yakalayamazsınız

• Güvenin kırıldığı anın, bu kütüphanelerin LLM kullanmaya başladığı zaman değil; devasa değişiklikleri kabul edip entegre ederken okunması zor ve işe yaramaz commit mesajları ekledikleri zaman olduğunu düşünüyorum

  Bu, LLM kullanılıp kullanılmamasından bağımsız bir yazılım mühendisliği başarısızlığı

  Bu arada Joey Hess’i ve yazılımlarını seviyorum; kod katkılarının hangi araçla üretildiğine bakılmaksızın ortaya çıkan ürünün değerine göre değerlendirilmesi gerektiği görüşündeyim

• Açıklama biçimi biraz hayal kırıklığı yaratıyor
  persistent commit’i LLM tarafından yazılmış gibi görünmüyor
  İnsanların “Co-authored-by” bulunan her commit’i LLM üretimi diye adlandırmamasını isterim

  İlk yesod bağlantısı bir CI değişikliği; bu yüzden bağımlı olunan kod sayılmasının zor olduğunu düşünüyorum
  “1489 satırlık commit mesajı olan LLM üretimi commit” denince commit’in kendisinin çılgın bir hâlde olacağını sanmıştım; ama gerçekte makul bir squash merge, sadece diff çok büyük

  cabal commit’inde LLM’in yalnızca testleri ürettiği belirtiliyor; bunun da bağımlı olduğum kod sayılıp sayılmaması gerektiğinden emin değilim
  git commit’i de sadece CI

  Bu bağımlılıkların bazılarının LLM kullandığından şüphe etmiyorum, ama sunulan kanıtların yeterince sağlam durduğunu söylemek zor
  Öte yandan beklediğimden çok daha fazla emek harcanmış bir çalışma ve belirli bir bağımlılığı kullanmamak için işaret edilebilecek somut nedenler olması iyi