Debian, yapay zeka üretimi katkılar konusunda kararı erteledi

• Debian topluluğu, yapay zeka veya LLM tabanlı kod katkılarına izin verilip verilmeyeceğini tartıştı, ancak bir sonuca varmadan görüşmeyi kapattı
• Önerilen taslak, AI araçları kullanıldığında bunun açıkça belirtilmesi, sorumluluğun netleştirilmesi ve hassas bilgilerin kullanılmasının yasaklanması gibi koşullarla buna izin verilmesini öngörüyordu
• Geliştiriciler, “AI” teriminin muğlaklığı, LLM’lerin kullanım kapsamı ve kalite, telif hakkı, etik sorunları konusunda farklı görüşlere sahipti
• Bazıları, yeni katkıcıların projeye uyumunu zorlaştırması, etik dışı şirket uygulamaları ve hukuki belirsizlik gibi gerekçelerle karşı çıktı
• Debian, şimdilik mevcut politikalara göre vaka bazında değerlendirme yaklaşımını sürdürecek ve ileride tartışmayı devam ettirme olasılığını açık bırakacak

---

Debian’ın AI katkıları tartışmasına genel bakış

• Debian, yapay zeka tarafından üretilen kodun kabul edilip edilmeyeceği konusunda iç tartışma yürüttü, ancak genel karar (GR) önerisi sunulmadan süreç sona erdi
  • Tartışma, Lucas Nussbaum’un AI destekli katkılara ilişkin tutumu netleştirmeyi amaçlayan bir taslak sunmasıyla başladı
  • Geri bildirim topladıktan sonra bunu resmî olarak sunmayı değerlendirdi, ancak tartışma yatışınca karar teklifi gündeme gelmedi
• Taslakta, AI araçlarıyla üretilen kodun açıklanması zorunluluğu, katkıcının sorumluluğunun açıkça belirtilmesi, güvenlik ve lisans uyumunun garanti edilmesi ve gizli bilgilerin kullanılmasının yasaklanması gibi maddeler yer alıyordu

Terim tanımı ve teknik ayrım tartışması

• Birçok geliştirici, “AI” teriminin belirsizliğine dikkat çekerek LLM gibi somut teknolojilerin özellikle belirtilmesi gerektiğini vurguladı
  • Russ Allbery, “AI” ifadesinin politika oluşturmak için fazla geniş kapsamlı olduğunu söyledi
  • Sean Whitton, LLM kullanım amacına göre ayrım yapılmasını (kod inceleme, prototip, üretim kodu) önerdi
  • Andrea Pappacoda, Claude’s C Compiler gibi projelerin Debian’a dahil edilmemesi gerektiğini belirtti
• Buna karşılık Nussbaum, asıl önemli olanın araç türünden ziyade otomatik kod üretimi eylemi olduğunu savundu

Yeni katkıcıların uyumu ve maliyet sorunu

• Simon Richter, AI’nin yeni geliştiricilerin öğrenme fırsatlarının yerini alabileceği endişesini dile getirdi
  • AI’nin yönlendirme alsa bile öğrenmediğini ve proje kaynaklarının kalıcı bilgi aktarımına dönüşmediğini belirtti
  • AI kullanımının ücretli araçlara bağımlılık yaratıp katkıcıların erişimini zorlaştırabileceği de ifade edildi
• Nussbaum, şu anda ücretsiz erişimin mümkün olduğunu ancak ileride maliyet sorununun ortaya çıkabileceğini kabul etti
  • Buna karşılık AI’nin karmaşık görevlere erişimi artırabileceğini savundu
• Ted Ts’o, AI kullanıcılarını dışlamanın kendi içinde çelişkili olacağını ve katkıcı çeşitliliğini sınırlayabileceğini söyledi

Etik, telif hakkı ve kalite tartışması

• Matthew Vernon, AI şirketlerinin etik dışı veri toplaması ve çevresel zararları nedeniyle Debian’ın buna açıkça karşı çıkması gerektiğini savundu
  • Telif hakkı ihlali, rıza dışı görsel üretimi ve sahte güvenlik raporları gibi yan etkileri örnek gösterdi
• Jonathan Dowland, hukuki belirsizlik giderilene kadar AI üretimi içeriklerin kabulünün sınırlandırılmasını önerdi
• Thorsten Glaser, LLM tabanlı kod içeren projelerin non-free alanına taşınması gerektiğini savundu, ancak Linux çekirdeği, Python gibi büyük projelerin dışarıda kalma riski nedeniyle destek bulamadı
• Allbery, AI kodunun kalitesi etrafındaki tartışmanın anlamsız olduğunu, çünkü insanların da kötü kod yazabildiğini söyledi
• Bdale Garbee, AI’yi evrimin bir aşaması olarak gördüğünü ve uzun vadeli etkilerinin izlenmesi gerektiğini vurguladı

‘Tercih edilen değiştirme biçimi (Preferred form of modification)’ tartışması

• Nussbaum, LLM girdisinin (prompt) tercih edilen değiştirme biçimi olduğunu söylese de, belirlenimsizlik sorunu nedeniyle tartışma sürdü
  • Bazıları, LLM’lerin belirlenimci olmaması nedeniyle reproducible build için uygun olmadığını savundu
  • Diğerleri ise PRNG seed ve aynı ortam korunursa yeniden üretilebilirliğin mümkün olduğunu ileri sürdü
  • Tartışma, determinism, reproducibility, GPU işlemlerinin asenkronluğu gibi teknik ayrıntılara kadar genişledi

Sonuç: Kararı erteleyen Debian

• Debian içinde, AI üretimi katkıların tanımı konusunda bile henüz uzlaşı sağlanmış değil
• Birçok kişi, şu anda karar teklifi için oylama zamanı olmadığını ve tartışmanın e-posta listesi düzeyinde sürmesinin daha uygun olacağını düşünüyor
• Nussbaum, “AI’ye izin verip güvenlik önlemleri koyan bir orta yolun” gerçekçi olabileceğini belirtti
• Şimdilik mevcut politikalara göre vaka bazında değerlendirme yaklaşımı korunuyor ve AI modelleri, LLM kodu ve AI üretimi katkıların nasıl ele alınacağına dair ölçütler belirsizliğini koruyor
• Karmaşık teknolojik değişim ve farklı görüşler arasında, mevcut durumun korunması en pratik seçenek olarak değerlendiriliyor

[GN⁺]

Hacker News görüşleri

• Hayatım boyunca kod yazdım ama bilek sakatlığı yüzünden yazı yazmak neredeyse imkânsız hale geldikten sonra, LLM’ler, yapay zeka otomatik tamamlama ve ajan tabanlı geliştirme sayesinde yeniden yüksek kaliteli kod üretebilir oldum
  Yapay zekanın halüsinasyonları bile promptları iyileştirmeye ve niyeti daha net ifade etmeye yardımcı oluyor
  Erişilebilirlik açısından yapay zeka benim için vazgeçilmez bir araç ve bence mesele “iyinin kötüyü telafi edip etmediği”nden çok, ekosisteme bütüncül biçimde entegre etme yaklaşımı

  • Dediğin gibi yapay zekayı makul şekilde kullananlar var ama tüm kullanıcıların böyle olduğunu varsaymak tehlikeli
    Bazı projeler düşük kaliteli PR yağmuruna tutuluyor ve birçok katkıcı sadece GitHub profilini doldurmaya çalışıyor
    Sonuçta önemli olan iyi niyetle katkı yapılıp yapılmadığı; projelerin de bunun kabul sınırını netleştirmesi gerekiyor
  • Ben de benzer bir yaklaşım izliyorum. Zor problemleri yapay zekaya bırakmak yerine, zaten uygulamayı düşündüğüm teknik çözümü verip kod üretmesini istiyorum
    Böyle olunca inceleme yorgunluğu azalıyor ve sadece beklenenden farklı kısımlara odaklanabiliyorum
  • Bende de bilek ağrısı var; Whisper + LLM kombinasyonu ile sesli giriş ve düzenleme yapıyorum. E-posta, doküman yazımı, hatta fiş sınıflandırma bile otomatikleşti ve sağlığıma da iyi geldi
    Artık bu tür özellikleri engelleyen şirketlerde çalışmak istemeyecek kadar ileri gittim
  • Bende de RSI var ve yapay zeka otomatik tamamlama çok yardımcı oldu. Ama ajan tipi yapay zeka, gerçek zamanlı C++/Rust ortamlarında pek faydalı değil
    Erişilebilirlik boyutu çok önemli ama telif ve sorumluluk meseleleri hâlâ karmaşık
  • Kodu imzalayıp kendi uzmanlığını ve itibarını ortaya koyabiliyorsan, yapay zeka sadece gelişmiş bir otomatik tamamlama aracıdır; “no AI” kuralında istisna sayılmalı

• Bence PR incelemesi eninde sonunda güven meselesi. Gönderen kişinin elinden gelenin en iyisini yaptığına inanmak gerekiyor
  Mesele yapay zeka kullanılıp kullanılmadığı değil, onun sorumlulukla kullanılıp kullanılmadığı

  • Elbette kötü niyetli aktörler de var. XZ saldırısında olduğu gibi kalıcı tehditler (APT) açık kaynak için de gerçek
    Birden fazla sahte hesap aslında tek bir saldırgana ait olabilir ve LLM’in ürettiği kod, LLM’e bakınca iyi göründüğü için doğrulaması daha da zor olur
    Sonuçta PR değerlendirmek, onu üretmekten daha zor hale gelmiş durumda
  • Ama ben yine de tüm kodların potansiyel bir Truva atı gibi görülüp doğrulanması gerektiğini düşünüyorum
  • İnceleme süreci, ister insan ister yapay zeka kaynaklı olsun hataları yakalayabilecek kadar sağlam olmalı

• Yapay zeka katkılarının kalitesi etrafındaki tartışma tuhaf. Kalite her zaman gönderenin sorumluluğunda
  Yapay zeka kullanmış olmak sorumluluktan muafiyet sağlamaz; hatta yapay zeka kullanımını kısıtlayan politikalar iyi niyetli katkıcılara zarar verebilir

  • Sorun şu ki LLM kodu dışarıdan iyi görünebilir ama gerçekte anlaşılmadan yazılmış kod olabilir
  • Önemli olan araç değil, katkıcının inceleme sırasında kendi kodunu açıklayıp savunabilmesi
    Ben yapay zekayla 300 commit’lik bir fork sürdürüyorum ama her satırı inceleyip açıklayabilirim
    Sonuçta belirleyici olan katılımın niteliği, kullanılan aracın türü değil
  • Asıl değişmez ilke sorumluluk. Bir yama gönderdiysen, tasarımından bakımına kadar sorumluluğunu da üstlenmelisin
  • Ama yapay zeka insanları bu sorumluluktan kaçmaya teşvik etme riski taşıyor

• Uzun vadede yapay zeka gelişirse insan ve yapay zeka çıktısını ayırt etmek zorlaşacak gibi görünüyor
  Sonunda “yeterince iyi” seviyesine gelince insan yapımı gibi görünecek; o zaman ne olacağını merak ediyorum

  • Tamamen engellemek mümkün değil ama bir politika belirlemek, hiçbir şey yapmamaktan daha iyi bence
    Şu anda AI PR’larının çoğu düşük kaliteli ama kalite artsa bile hukuki ya da ideolojik nedenlerle reddedilebilirler
  • Yapay zeka katkılarını sonuçta bireyin bir uzantısı olarak görmek gerek. Hesap gerçek bir kişiye ait olmalı ve o kişinin itibarı işin içinde olmalı
  • Bir anda çok büyük miktarda kod gelirse yapay zeka kullanımı şüphesi doğabilir. Önemli olan yapay zeka kullanılıp kullanılmadığı değil, problemin anlaşılıp anlaşılmadığı
  • Yapay zeka hâlâ token düzeyinde tahmin yapıyor, bu yüzden insanın tasarladığı koddan ayrışıyor
    Aşırı derecede parçalanmış soyutlamalar ya da gereksiz refactor’lar sık görülüyor
    İnsanların yapay zekayı araç olarak kullanması sorun değil ama yapay zekanın insanın yerini alacağı düzey hâlâ uzak
    Yine de vibecoding’in aşırı kullanımı, inceleme ve bakım maliyetlerini hızla artırıyor
  • Sonuçta doğru kullanan birinin kodu insan kodundan ayırt edilemez. Sorun araçta değil, kullanım biçiminde

• Benim duruşum “çalışıyorsa yeterlidir”
  Kod işlevsellik, dokümantasyon, test ve doğruluk ölçütlerini karşılıyorsa, bunu yapay zekanın mı insanın mı yazdığı önemli değil
  Önemli olan “çalışıyor” tanımını netleştirmek ve yetkin bir inceleme sistemi kurmak

• Yapay zeka bir seferde binlerce satır kod üretip PR açabilir ama sonuçta bunu incelenebilir boyutla sınırlamak gerekir
  Yapay zeka testleri geçse bile, yazarı içeriği anlamıyorsa bu risklidir
  İş kapsamının sınırlandırılması ve önceden yapılmış manuel katkı geçmişi gerekli

• Debian’ın politikası basit: “Kimse incinmesin”. Güzel bir ilke

• Debian’ın, başkasının kodunu kendi koduymuş gibi göndermeyi yasaklayan bir kuralı olup olmadığı sorulmuştu
  Aslında bu, telif hakkı ihlali nedeniyle yasa dışı olduğu için açıkça yazılmasa da fiilen örtük biçimde mevcut
  LLM insan değil ama ürettiği kodun telif hakkı hâlâ belirsiz

• Web uygulaması ya da mobil uygulama vibecoding’i çok sorun olmayabilir ama çekirdek, derleyici, işletim sistemi gibi kritik altyapı yazılımlarında yapay zeka kullanmak riskli
  Bu alanlarda Ada/SPARK gibi biçimsel doğrulama dilleri gerekiyor
  Bir gün yapay zekanın yaptığı fren sistemine sahip bir arabaya binecek olmaktan korktuğunu söyleyenler var

  • Katılıyorum. Kritik sistemlerde çok dikkatli olunmalı; LLM’lerde hem dikkat eksikliği hem de telif riski var
  • Aslında otomotiv sektöründe yapay zekadan önce de otomatik üretilmiş kodun yaygın olduğunu duymuştum

• “YOLO tarzı kod gönderimi” yerine, “Yapay zeka kullandım ama olabildiğince doğruladım” denilen kod çok daha kabul edilebilir