Zig projesinin anti-AI katkı politikasının gerekçesi
(simonwillison.net)- Zig; issue, Pull Request, hata takipçisi yorumları ve çevirilerde LLM kullanımını yasaklayan katı bir kural uyguluyor
- İngilizce kullanımı yalnızca bir tavsiye, zorunluluk değil; katkı sunanlar ana dillerinde yazabilir, diğerleri ise içeriği kendi seçtikleri çeviri araçlarıyla yorumlayabilir
- Bun, kendi Zig fork'unda LLVM backend'e parallel semantic analysis ve multiple codegen units ekleyerek Bun derlemelerinde 4 kat performans artışı elde etti, ancak LLM ile yazılmış katkılar yasak olduğu için şu anda upstream planı yok
- Zig'in inceleme yaklaşımı, eksik PR'leri reddetmektense yeni katkı sunanların merge edilebilir bir sonuca ulaşmasına yardımcı oluyor ve tekil katkılardan çok katkı sunanın gelişimine önem veriyor
- Büyük ölçüde LLM tarafından yazılmış PR'ler, inceleme süresinin güvenilir yeni katkı sunanları artırmak için kullanılmasını engelliyor; ayrıca maintainer'ın aynı sorunu çözmek için LLM'i bizzat çalıştırma seçeneği de doğuyor
Politika ile Bun fork'u arasındaki çatışma
- Zig, Code of Conduct içinde issue, Pull Request, hata takipçisi yorumları ve çevirilerde LLM kullanımını yasakladığını açıkça belirtiyor
- İngilizce kullanımı bir tavsiyedir; katkı sunanlar ana dillerinde yazabilir
- Diğerleri ise içeriği kendi seçtikleri çeviri araçlarıyla yorumlayabilir
- Zig ile yazılmış öne çıkan projelerden biri Bun JavaScript runtime'ı; Bun, 2025 Aralık ayında Anthropic tarafından satın alındı
- Bun, kendi Zig fork'unu sürdürüyor ve LLVM backend'e “parallel semantic analysis and multiple codegen units” ekleyerek Bun derlemelerinde 4 kat performans artışı sağladı
- İlgili kod, oven-sh/zig karşılaştırma bağlantısında yayımlandı
- Bun'un şu anda upstream planı yok; çünkü Zig, LLM tarafından yazılmış katkıları katı biçimde yasaklıyor
- Bir Zig core contributor değerlendirmesine göre bu yamanın kabul edilmesi, LLM meselesinden bağımsız olarak da zor
- parallel semantic analysis uzun süredir planlanan bir özellik, ancak Zig dilinin kendisini etkiliyor
Contributor Poker ve katkı sunan merkezli inceleme
- Contributor Poker and Zig's AI Ban içindeki contributor poker, Zig'in katı yasak politikasını anlamak için temel bir benzetme
- Başarılı açık kaynak projeleri, işleyebileceklerinden daha fazla PR aldıkları bir aşamaya ulaşıyor
- Zig, ROI'yi en üst düzeye çıkarmak için eksik PR'leri reddetmek yerine, yeni katkı sunanların çalışmalarını merge edilebilir hale getirmelerine yardımcı olmayı seçiyor
- Bu yaklaşım yalnızca “doğru olan” değil, aynı zamanda “akıllıca olan” olarak görülüyor
- Zig, tekil katkılardan çok katkı sunana önem veriyor
- PR inceleme ve kabulünün birincil amacı yeni kod eklemek değil; zamanla güvenilir ve üretken katkı sunanlara dönüşecek kişilere yardımcı olmak
- Her katkı sunan, Zig core team için bir yatırım hedefi haline geliyor
- LLM desteği bu yapıyı bozuyor
- LLM kusursuz bir PR yazımına yardımcı olsa bile, Zig ekibinin incelemeye harcadığı zaman yeni, özgüvenli ve güvenilir katkı sunanların sayısını artırmaya katkı sağlamıyor
- “contributor poker” ifadesi, oyunun kartlara değil insanlara bakılarak oynandığı benzetmesinden geliyor
- Anlamı, ilk PR'nin içeriğinden çok katkı sunana bahis yapmak gibi
- Eğer bir PR büyük ölçüde LLM tarafından yazılmışsa, proje maintainer'ı o PR'yi inceleyip tartışmak yerine aynı sorunu çözmek için LLM'i doğrudan kendisi çalıştırmayı seçebilir
2 yorum
İnsan darboğazı olduğu için böyle. Yağmur gibi yağan çöp PR'leri engellemeye çalışırken incelemek zorunda kalırlarsa Zig geliştirmesi yapılamayacağı için, önceden birinci aşama filtreleme politikası.
Hacker News yorumları
https://kristoff.it/blog/contributor-poker-and-ai/ yazısına göre, LLM tabanlı katkılar genel olarak olumsuz olmuş
Değersiz drive-by PR'ler halüsinasyon kod ile arka plan gürültüsünü artırmış, derlenmeyen ya da CI'dan geçmeyen katkılar gelmiş; hatta ilk kez katkı yapan birinin 10 bin satırlık PR gönderdiği bile olmuş
Görünüşte iyi duran ve LLM kullanılmadığını belirten PR'ler de varmış; ancak sonraki tartışmalarda yazarın gizlice LLM'e başvurduğu ve hatalarla dolu yanıtları tekrar ettiği hemen ortaya çıkmış
hooks için clone sırasında kurulumu zorunlu kılmanın temiz bir yolu yok ama GHA Workflows ya da başka forge'ların eşdeğer özellikleri olabilir
Belli bir ölçek ve popülerliğe ulaşmış projelerde bunların temel gereklilik olması gerektiğini düşünüyorum
“AI katkı yapamıyor” diye görülen sorunların önemli bir kısmı daha iyi otomatik kontroller ve koruyucu mekanizmalarla bir ölçüde azaltılabilir gibi duruyor
AI'nin bu yeni spam türünü mümkün kılması dışında özünde AI ile ilgili değil
AI olmasa bile insanlar ucuz offshore geliştirici orduları tutup orta kalite drive-by PR'leri seri şekilde ürettirse etki aynı olurdu
AI ile de iyi kod üretilebilir ama diğer araçlar gibi dikkatli kullanılmalı
Bu, projeyi ve hedefleri bilen birinin aracı iyi kullanarak özenle hazırladığı katkı değil; spam
AI politikasını çevreleyen gürültü, Bun geliştiricilerinin bu politika yüzünden performans PR'lerini upstream edemediklerini söylemesiyle ortaya çıkmış gibi görünüyor
Ama asıl nedenin PR kodunun kendi durumunun iyi olmaması ve sağlıksız bir karmaşıklık getirmesi olduğu anlaşılıyor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Alıntılanan açıklamaya göre paralel semantic analysis, Zig derleyicisi için çok uzun zamandır açık bir plandı ve self-hosted Zig compiler tasarımını da büyük ölçüde etkiledi; ancak doğru biçimde uygulanması için yalnızca derleyici implementasyonunda değil, Zig dilinin kendisinde de değişiklikler gerekiyor
Çünkü Zig'in daha iyi sonuçlara ulaşmak için oluşturduğu kendi yol haritasıyla çakışıyor ve dilin tamamını geliştirmeye yönelik yönelimi sekteye uğratıyor
Politika tüm LLM kodunu açıkça yasaklıyor; dolayısıyla doğal olarak “gerçek neden” de bu politika
Zig tarafı, ZeroMQ'nun yolunu izliyor gibi görünüyor https://zguide.zeromq.org/docs/chapter6
Yönelim, “projenin kolektif sahipliğini zorunlu kılarak katkı sağlayanların ekonomik teşviklerini artırmak ve düşmanca aktörlerin hijack riskini azaltmak” şeklinde
Sağlıklı bir katkıcı topluluğu, yalnızca kod performansı, özellik sayısı ya da satır sayısından daha önemli
Bugün zeromq “topluluğu” oldukça seyrek; hâlâ aktif olan birkaç harika insan var ama insan ölçeğinde süreçler ve iletişim kanalları iyi tanımlanmış değil ve yeterince de işletilmiyor
libzmq ve binding'lerin çoğu istikrarlı olduğu için, bu insan etkinliği ve etkileşim eksikliği bir ölçüde kabul edilebilir ya da meşru görülebilir; ancak Hintjens'in harika vizyonu zeromq'yu buraya kadar getirdi ve onu kaybettikten sonra proje sanki sürükleniyor
Topluluk odaklı vizyonla biraz ironik biçimde, bir topluluk kazanmak ve onu elde tutmak için karizmatik ve aktif bir lider gerekiyor gibi görünüyor; bu da yazılım geliştirmeden çok insan doğası hakkında bir şey söylüyor
Zig konusuna dönersek, Zig'in PR eksiği yok; dolayısıyla no-LLM katkıları önceden eleme lüksüne sahip
Onlar için bu iyi bir tercih ve “contributor poker” fikrini de anlıyorum
Ama yeni girişler azalmaya başlarsa oyunun kuralları değişir; o noktada Zig ekibi hâlâ yeni katkıcılar istiyorsa ağı genişletmeleri gerekebilir
Yine de o noktaya gelindiğinde LLM destekli katkıları açmak toparlanmak için fazla geç olabilir
AI üretimli OSS katkılarında merak ettiğim şey şu
Eğer AI geliştirici verimliliğini gerçekten bu kadar artırıyorsa, bir OSS maintainer neden kendisiyle LLM'in arasına tanımadığı bir katkıcıyı koymak istesin?
maintainer doğrudan Claude Code'a sorabilir
Bir meslektaşımın dediği gibi, “AI modeliyle konuşmak için bir aracıya ihtiyacımız yok ve darboğaz da kodlama değil”
AI ile ilk kötü sürümü oluşturur, prompt'u ayarlar, elle düzeltmeler yapar, başka kısımları düzelttirir, ilgili özellikleri keşfedip ekletir, benchmark çalıştırıp küçük bir özelliği kaldırır ya da benzer iki uygulama arasında seçim yapar
Oraya buraya manuel düzeltmeler daha ekler, genişletilmiş otomatik testleri çalıştırarak tuhaf ayarlardaki garip bug'ları bulur ve AI ile elle çalışarak düzeltir
Böylece 20 saatin sonunda son sürüm yalnızca 50 satır olabilir ve her satır 5 kez yeniden yazılmış olabilir
maintainer da yalnızca son sürümü yaklaşık 1 saat incelemekle yetinir
Bu, 5 dakika AI'ye patch yazdırıp derlenmeyen 1000 satırı hiç okumadan maintainer'a göndermekten tamamen farklı
“Bu o kadar kolay ki ben de yapabilirdim”
Doğru ama fiilen yapmadın
Ama bir insana verir gibi yalnızca üst düzey talimatlar vererek kullanılabilecek türden değil
AI'nin yalnızca üst düzey talimatlarla çalıştığını iddia edenlerin genelde “fazla düşünce gerektirmeyen” projeler yaptığı izlenimine kapılıyorum; yani ayrıntıya inen geliştiricinin çok kafa yormasını gerektirmeyen işler
Umarım bu, LLM'in tek faydasının elle yazması sıkıcı olan kodu üretmek olduğu anlamına da gelmiyordur
“Zig, katkıdan çok katkı sağlayanı önemser. PR'leri inceleyip kabul etmenin temel amacı yeni kod eklemek değil, zaman içinde güvenilir ve üretken katkıcılara dönüşmelerine yardımcı olmaktır. LLM desteği bunu tamamen bozar. LLM'in mükemmel bir PR göndermeye yardımcı olması durumunda bile” açıklaması şimdiye kadar gördüğüm en iyi gerekçe
Zig'in kararını tamamen destekliyorum ve hem topluluk hem de gerçek proje için uzun vadeli vizyonunu çok değerli buluyorum
Dürüst olmak gerekirse LLM'lerin daha işbirlikçi çalışmalara o kadar uygun olduğunu da düşünmüyorum
İleride nasıl değişeceğini göreceğiz ama AI üretimli PR kabul ettiğimde çoğu zaman sonunda işi yine benim yapmam gerekiyor; ironik biçimde bunu da LLM kullanarak yeniden yaptığım için giderek daha fazla çelişki hissediyorum
Yine de en azından önümüzdeki 5 yıl için Zig politikasının iyi bir fikir olduğunu düşünüyorum
Bence söyleyebilecekleri en az saldırgan ifade bu ve kendi projeleri için aldıkları karar olarak buna saygı duyuyorum
Yine de projenin gereksiz yere kendini bağladığı hissi de var
LLM bir araçtır; düşünmeye, araştırmaya ve kod yazmaya yardımcı olabilir
Aşırı kullanılabilir ama yararlı olduğu yerlerde kabul edilmeli
Bun'un PR'ini başka nedenlerle almamak gayet normal ama tüm LLM ile yazılmış PR'leri toptan yasaklamak gereksiz derecede kısıtlayıcı
Sadece işin kalitesine odaklanmak yeterli
maintainer aynı işi doğrudan kendi LLM'ini kullanarak muhtemelen daha iyi tasarım ve daha dikkatli bir yaklaşımla yapabilir
maintainer'ın zamanı, düşük emekli PR incelemeye değil geliştirmeye gitmeli
LLM kod seli dengeyi maintainer aleyhine çeviriyor; bu yüzden doğrudan yasaklamak istemelerini gayet iyi anlıyorum
Bir süredir LLM ve coding agent kullandıktan sonra genel izlenimim şu: bu bir elektrikli alet ya da vinç, karar verme aracı değil
Organizasyon içinde kavramsal anlayışı ve derin mühendislik bilgisi çok güçlü olanların üretkenliği patlayıcı biçimde artıyor
Buna karşılık anlayışı zayıf olanlar ya da yeni başlayanlar, çalışıyor olması yeterli sanarak cehennem gibi kod üretiyor
LLM'ler organizasyon içinde entelektüel bir uçurum oluşturuyor ve ne kadar çok kullanılırsa bu fark o kadar büyüyor
Sonunda üretilen kod yüzünden kurum içindeki çıktılara güvenemez hale gelebiliriz
AI genel olarak beceri setini büyütüyor; iyi tarafı da kötü tarafı da güçlendiriyor
Son dönemdeki harika bir kullanım örneği authentication daemon için concept hazırlamaktı
Codex ile konuşup önerileri seçtik, normal web aramasıyla çapraz doğrulama yaptık, son taslağı belirleyip ekip arkadaşlarıyla tartıştık
Böyle entegre web araması içeren etkileşimli planning, inanılmaz derecede faydalı; ayrıca zaten yazılmış kodu AI ile review etmek de bence net fayda sağlıyor
Ama AI'nin temel caveat'ı, sonuçta araçtan daha akıllı olman gerekmesi
Codex sana tech stack X'i öneriyorsa bunun neden gerçekten iyi olduğunu araştırmalı, tamamen anlamalı ve diğer çözümlerle karşılaştırmalısın
Pek çok insan bu adımı atladığı için sayısız sorun çıkıyor ve bu ölümcül
Sohbet bittiğinde AI'den daha akıllı hale gelmiş olmalı; AI'nin söylediklerini tamamen anlayıp eleştirebilmelisin
Mimari netleştikten sonra LLM implementasyonu oldukça iyi yapıyor
Genelde harika ve iyi test edilmiş kod ürettirmek mümkün; hatta aynı sürede tek başına yapmaktan çok daha iyi sonuç da alınabiliyor
Ama AI'nin ürettiği her şey hakkındaki bilgiyi sürekli güncel tutmak yine de zorlayıcı
“PR'nin çoğunu LLM yazdıysa, maintainer o PR'yi inceleyip tartışmaya harcayacağı zamanda kendi LLM'ini açıp aynı sorunu çözemez mi?” mantığı, aslında açık kaynak kavramının kendisine de uygulanabilir
Robot doğrudan yazabiliyorsa neden başkasının projesini kullanalım?
Özellikle o açık kaynak proje vibe coded ise daha da öyle
AI ve genel olarak teknoloji, kişiselleştirmeyi ucuz ve kolay hale getiriyor
Eskiden herkes için idare eder seri üretim ürünler kullanmak zorundaydık ama şimdi yalnızca bana mükemmel gelen bir şeyi elde etme umudu doğdu
Ayrıca insanlar her yerde LLM kullanarak açık kaynak projeleri yeniden ürettikçe emek ekonomisi de bundan etkileniyor
LLM bunları birkaç dakikada kusabilir
Benim en çok istediğim şey kullanım geçmişi
Benden önce başkalarının kullanmış olduğu yazılımı kullanmak istiyorum; bug'larla ve sivri köşelerle onların karşılaşıp törpülemiş olmasını tercih ederim
Evde model indirip bastıktan sonra sonsuza kadar özelleştirebiliyorsak niye ürün satın alalım deniyordu
Medeniyetin var olma nedeni, hayatın büyük kısmını başkasının problemi haline getirip kendinin tek bir işi iyi yapmaya odaklanabilmendir
Dişçiysen ya da bir muffler shop işletiyorsan günün zamanı sınırlıdır; muhtemelen vibecoding öğrenip tuhaf ve emek isteyen bir yardımcının başında durmak yerine bir SaaS vendor'una para ödemeyi tercih edersin
İstisnalar vardır ama sonuçta istisnadır
vendor makul ve yetkin bir ürün yapıyorsa seve seve para verirsin
Açık kaynakta da durum aynı
LLM sıfırdan yeni bir işletim sistemini güvenilir şekilde yapabiliyor olsa bile gerçekten bunu ister miyim?
Ben işletim sistemi bakımını yapmak istemem, işletim sistemi bakımını yapan birini yönetmek de istemem; zaten işletim sistemi hakkında tutarlı bir vizyonum olduğuna da inanmam
Belli bir karmaşıklık eşiğinden sonra robotun aklımı yeterince okuyup “yalnızca bana mükemmel” yüksek kaliteli bir sonuç vereceğini beklemek zor
Zig projesi kesinlikle bu yetenek aralığının çok ötesinde
Maliyeti karşılayamayanlar var; erişimi olanlarda bile Claude kesintileri ya da zamanla genel performansın düşmesi gibi sorunlar ara sıra ya da sürekli yaşanabiliyor
Birkaç ay önce Claude'u yeni kullanmaya başladığımda bir hafta içinde birden fazla projede kolayca ilerleme sağlayabiliyordum ama bugünlerde çoğu zaman yalnızca spinner görüyorum ve kod kalitesi de sanki keskin biçimde düşmüş; neredeyse hiçbir şey yapamıyorum
Yaklaşık 100 yıldıza sahip birkaç depom var; çok büyük şeyler değil ama geçen yıla kadar ara sıra PR gelirdi, bu yıl ise şu ana kadar neredeyse hiç yok
Benim hipotezim, LLM'lerin ana akım projelere bağlanmayı tercih etmesi
Pek çok geliştirici artık büyük ölçüde LLM'lere dayanıyor ve bunun sonucunda benim sunduğum şeylerin çoğunu görmezden gelmeye dönük bir bias oluşuyor
LLM'lerle tekerleği yeniden icat etmenin artmasının nedeni de yeni bir şey inşa etme maliyetinin düşmesi
Bu yüzden GitHub'daki niş şeyleri, örneğin benimkileri kullanmak yerine ihtiyaç duyulanı doğrudan üretmek daha kolay hale geliyor
dependency tercihlerimde de aynı olguyu görüyorum
Çok güçlü bir gerekçe yoksa LLM'in önerdiğini olduğu gibi seçme eğilimi oluşuyor
Kısmen katılıyorum ama tamamen değil
Katkı sağlayanları yetiştirmenin doğru öncelik olduğu doğru
Ama AI'yi bir yardımcı teknoloji olarak görüyorum
Bir screen reader ya da magnifying glass gibi, gerçi elbette farklı yönleri de var
Bir robot dış iskeleti gibi düşünülebilir
Kötü işler ve aptalca şeyler için kullanılacak ama esas olarak daha önce yapamayacak kişilerin iyi işler yapmasını ya da daha yetkin hale gelmesini de sağlayacak
Bazı insanlar için AI, daha önce yapamadıkları kodlamayı mümkün kılacak; pek çok kişi için AI'nin ne yaptığını izleyerek kod öğrenme aracı olacak; başkaları içinse çok daha hızlı ya da daha iyi kod yazmayı sağlayacak
Kimilerinde bazı beceriler körelebilirken başka beceriler gelişebilir
Piyasaya iyi bir dış iskelet ürünü çıksa aynı sorunlar onda da olurdu ama genel olarak olanak sağlayan bir araç olurdu
Yardımcı teknoloji kullanan katkıcıları yetiştirmenin, kullanmayanları yetiştirmekten neden daha kötü olduğunu bilmiyorum
Elbette daha zor olabilir
LLM vendor'larının iddia ettiği kadar LLM'ler zeki değil
Gerçekten öyle olsalardı tamamen otonom olurlardı ve bu konuşmayı yapmıyor olurduk
LLM üretimli kodu körü körüne gönderen ya da kullandığını açıklamayan insanların bunu gerçekten bırakması gerekiyor
Ama kalan sorun bunun hâlâ bir araç olması
Rastgele bir geliştiriciye “tek seferlik bir PR ile Zig'i hızlandır” dersen iyi sonuç çıkmaz
Geçmişte OSS projelerinde çalışan kod yazabilmek bir tür öz eleme mekanizmasıydı; o seviyeye gelenler birkaç yıl öğrenmiş oldukları için genelde doğru işleri yapıyor, özellik ya da gereklilik konusunda bir tür muhakemeye de sahip oluyordu
Bugün LLM kusursuz ve muhakemesi güçlü olsa bile sonunda prompter'ın talimatlarını yerine getiriyor
Yani artık bu öz eleme ortadan kalktı
Zig geliştiricilerinin gerçekte neyin LLM üretimi neyin insan üretimi olduğunu ayırt etmesi de zor olacaktır
Muhtemelen içeriye zaten LLM üretimli kod girmiştir ama en azından bu durumda insan gönderici yine de kodu epey iyi kullanabiliyor olmalı
Sonunda bunun “yalnızca trusted badge of honor sahibi insanlar commit atabilir” noktasına mı gideceğini, yoksa “LLM yeterince muhakeme edip ‘hayır, defol. Bu özellik/plan/fikir çöp, bunu üretmeyeceğim’ diyebilen” bir seviyeye mi varacağını merak ediyorum
Bunu yaptıklarında gerçekten canlarını yakacak bir yaptırım yoksa onları neyin durduracağını bilmiyorum