Vibecoding’i Açıklayınca Emacs Yaması Reddedildi

• macOS için Emacs performansını iyileştirmek amacıyla hazırlanan küçük bir yama emacs-devel’e gönderildi, ancak LLM destekli çalışmaları kabul etmeyen GNU politikası nedeniyle kabul edilmedi
• Çalışmayı yapan kişi, GLM 5.2’nin sorunu bulup taslağı oluşturduğunu açıkça belirtirken; doğruluk ve etki analizini, düzeltmeleri, manuel testleri ve kişisel sorumluluğu kendisinin üstlendiğini söyledi
• Reddedilen yama dar kapsamlı ve 92 satırlıktı; ayrıca LLM kullanıldığını gizlemek de mümkün olduğundan, politikanın kullanımdan çok dürüst açıklamayı dezavantajlı hale getirdiğini eleştirdi
• GNU tarafındaki kaygıların LLM çıktılarının açıklığı ve yasal olarak kullanılabilirliğine yakın olduğunu, ancak açık ağırlıklı modelleri ve sektördeki gerçek kullanım örneklerini gerekçe göstererek buna katılmadığını söyledi
• Artık Emacs üzerinde çalışmayacağını belirtti ve sabit diskinde bulunan yaklaşık 40 performans iyileştirme yamasından yalnızca yakın zamanda doğruladığı bazılarını yayımladı

---

macOS Emacs performansını iyileştirme çalışması

• Przemysław Alexander Kamiński, aylar boyunca macOS’ta Emacs performansını iyileştirmek için çalıştı; ölçüm bağlantıları ve benchmark’lar yazmaya zaman ayırdı
• Birden fazla LLM’e Emacs kod tabanını verip belirli sorunları bulmalarını istedi, ancak sonuçlar çoğunlukla iyi değildi
  • Yamalar analiz edildiğinde çoğu zaman etkilerinin küçük olduğu veya sorunu yanlış anladıkları görüldü
• O dönemde performans darboğazlarına ilişkin değerlendirmesi şöyleydi
  • macOS’ta ana sorun rendering problemleri ve hızlı ayırma/serbest bırakmadan kaynaklanan bellek thrashing’i
  • macOS’un sistem malloc yaklaşımı, bellek sıkıştırmanın olmaması nedeniyle sanal belleğin şişmesine ve önbellek yerelliğinin kaybına yol açıyor
  • Emacs çekirdeğinde de performans sorunları hâlâ mevcut
  • regexp işleme birçok yerde kullanıldığı için, iyileştirilmesi genel performansı etkileyebilir

GLM 5.2 ile bulunan yama ve gönderim süreci

• Bir arkadaşından z.ai Max planı aldığı için GLM 5.2 kullanabildi ve bu modelin kod optimizasyonunda oldukça yetenekli olduğunu değerlendirdi
• Daha önce biriktirdiği bilgiye dayanarak Emacs hakkında somut sorular sordu ve GLM 5.2’den sorunları araştırıp analiz etmesini istedi
• Yaklaşık 3 saat sonra birkaç rapor aldı; önerileri ve kodu inceledikten sonra her maddenin etkisini test etti ve benchmark’lar çalıştırdı
• Yama gönderimine uygun biçimde düzenlemek zaman aldığı için en umut verici maddelerden birini seçip üzerinde çalıştı ve yazıyı yazmadan iki gün önce emacs-devel e-posta listesine gönderdi
• Ertesi gün GNU’nun LLM destekli çalışmaları kabul etmeyen bir politikası olduğunu ve bu nedenle yamanın kabul edilmediğini öğrendi

Gönderi e-postasında açıklanan LLM kullanım kapsamı

• Yamayı e-posta listesine gönderirken LLM kullandığını ve kendi inceleme kapsamını birlikte açıkça belirtti
  • Sorunun bulunmasını ve yama taslağının hazırlanmasını GLM 5.2’nin yaptığını, GLM 5.2’nin Çin menşeli açık ağırlıklı bir model olduğunu söyledi
  • Sorun raporunun doğruluğunu ve etkisini bizzat analiz etti
  • Yamayı inceledi ve düzeltti
  • Yamayı manuel olarak test etti
  • Hukuki amaçlarla gönderinin yazarlığını beyan etti ve kendi katkısının LLM’inkinden daha büyük olduğunu savunmaya hazır olduğunu belirtti
  • Gönderi için tüm kişisel sorumluluğu üstleneceğini ilan etti
• Gönderinin uygulama kapsamı çok dar ve boyutu da küçüktü
  • Yayımladığı yama 92 satır ve varlık gerekçesini yorumların içinde içeriyor
• Bu yamayı “slop” olarak sınıflandırmanın mümkün olmadığını düşündüğünü, ancak herkesin kendi kararını verebileceğini ekledi

GNU politikasına itiraz

• GNU’nun politikasına saygı duyduğunu, ancak katılmadığını ve politikanın yeterli dayanağı olmadığını düşünüyor
• LLM kullandığını gizleyebilirdi, ancak bunu açıkça belirtti; sonuçta gönderisinin dezavantajlı hale geldiğini düşünüyor
  • Bu yüzden politikanın LLM kullanımının kendisinden çok dürüst açıklamayı cezalandırdığını eleştiriyor
  • LLM’lere hiç güvenmediği için LLM destekli çalışmalarda daha az değil, daha fazla inceleme ve göz gerektiğini düşünüyor
• Politikanın tam bağlamının GNU iç listelerinde tartışıldığı için bilinemeyeceğini; geçmiş konuşmalarda karşılaştığı soruların ise LLM katkılarının yeterince açık olup olmadığı ve yasal olarak kullanılıp kullanılamayacağına yakın olduğunu özetliyor
• Açık ağırlıklı modellerin açıklığını sorun eden mantığa katılmıyor
  • Örneğin yerel ortamda Qwen 3.6 kullanmanın kabul edilebilir, ancak OpenRouter üzerinden kullanmanın kabul edilemez sayılması gibi bir ayrımı absürt buluyor
  • GLM 5.2’nin açık ağırlıklı bir model olduğunu; 256 GB RAM ve 24 GB VRAM varsa yerelde çalıştırılarak “SaaS kapalıdır” argümanının bertaraf edilebileceğini söylüyor
  • İnternette özgür olmayan çok içerik olduğuna göre, aynı mantıkla bir gönderi hazırlarken internete erişimin de yasaklanması gerekip gerekmediğini soruyor
• Hukuki kaygılara da katılmıyor
  • Oyun şirketlerinin IP ve LLM konusunda daha hassas olmasına rağmen LLM kullanımının görüldüğünü; ChatGPT’nin 1 milyar aktif kullanıcısı olduğunu ve yüz binlerce ila milyonlarca kuruluşun her gün LLM çıktısı kullandığını söylüyor
  • ABD’li bir avukat olmadığını belirterek, telif hakkı tescili meselesinin telif hakkı bildirimi koyan tarafla ilgili olduğunu anladığını ifade ediyor
  • GNU’nun kendi avukatlarının ve görüşlerinin en büyük ağırlığa sahip olduğuna inanma tutumuna katılmıyor

Emacs çalışmasını bırakması ve yayımlanan yamalar

• GNU’nun kendi kararlarını verme özgürlüğü, kendisinin de eleştirme özgürlüğü olduğunu söylüyor
• Politikanın içeride tartışılıp kullanıcılara şeffaf olmamasını, Meta’nın Facebook’un yönünü içeride belirlemesi kadar açık olmakla eleştiriyor
• Sonuç olarak artık Emacs üzerinde çalışmayacağını açıkladı
  • Gönüllü olarak yaptığı bir işte “çubuğu yanlış tarafından tuttuğu” söylenen bir durumda bulunmaktan hoşlanmadığını belirtiyor
• Sabit diskinde yaklaşık 40 performans iyileştirme yaması var; bazıları birbiriyle örtüşüyor, bazılarının gerçek etkisi ise henüz kanıtlanmış değil
• Yakın zamanda doğrulayıp çalıştığını ve anlamlı etki gösterdiğini gördüğü bazı yamaları yayımladı; bu yamaların gerçekten fark yarattığını söylüyor

[GN⁺]

Lobste.rs yorumları

• Yazarın “open weight”teki openın ne anlama geldiğini yanlış anladığını düşünüyorum.
  Nihai matris yığını açıkta ve bir ölçüde ince ayar yapılabiliyor diye, onu üretmek için kullanılan eğitim materyallerinin de açık kaynak olduğu anlamına gelmez. OSI seems to agree de benzer düşünüyor gibi; öyleyse telif hakkı sorunu hiç çözülmüş değil.
  İyi niyetle, karşılık beklemeden katkı yapmak isteyen birine empati duyuyorum; ama GNU kuralları açıkça yazmış ve oraya gidip “birazcık ihlal ettim, işte yama” derseniz reddedilmeniz şaşırtıcı olmaz. Reddedilme nedeni dürüstlük değil, açıkça yapılmaması söylenen bir şeyi yapmış olması.

  • Gizlilik anlaşmasına tabi veri sayfalarına dayanarak yazılan sürücüler de tamamen özgür yazılım değil mi yani? Üretici çalışanının iç belgeleri ve uzman bilgisini kullanarak sürücü yazdığı durumları nasıl değerlendirmeliyiz?
  • Eğitim materyallerinin neden ilgili olduğunu pek anlamıyorum. Çıktıyı özgürce kullanabiliyor, yeniden dağıtabiliyor ve değiştirebiliyorsanız bu bence opena epey yakın.

• Yazarın bugün, milyarlarca insanın yanılabileceğini öğrenmesini umarım. Normalization of deviance sapmayı meşrulaştırmaz; yalnızca o sapmanın nasıl yayılmaya devam ettiğini açıklar.
  chatbot psychosis içinde görülen kalıplardan biri, karşı çıkan ya da farklı fikir belirten insanları düşman olarak algılamaktır. Chatbot’un öğrendiği narremes, kullanıcının başkahraman olduğu, omuz üstü kamera açısına ve okunması kolay kişisel bir anlatıya sahip olduğu bakış açısını içerir. Chatbot’un sonradan işlenmiş tercih anlatısı, kullanıcıda başkahramanlık duygusunu güçlendirerek doğrudan etki eder; kullanıcı yeterince iyonize olduğunda tarafsız bir konumu bile kabul edemez hâle gelir.
  Bu durumda yazarın link vermediği ya da alıntılamadığı the original discussion metnini okumanızı öneririm. Emacs topluluğu yazara karşı nazik, kabul edici, soru soran, ilgi gösteren ve açık fikirli bir tutum sergilemiş. Yamayı reddederken bile yazarı suçlamak yerine GNU politikasına odaklanarak yumuşak bir dille konuşmuşlar.

  • Asıl tartışmanın bağlantısını yazıya koymamış olması açıkçası büyük bir kırmızı bayrak. Bunu fark etmemiş olmasına inanmak zor.
  • narremes adlı Wikipedia maddesi yalnızca tek paragraftan oluşuyor ve üzerinde [incomprehensible] etiketi var.
    Yine de bağlamdan ne anlama geldiği anlaşılıyor ve burada yararlı, iyi oturan bir kavram gibi görünüyor.

• GNU Project yalnızca ABD telif hakkı sorunlarını değil, dünya genelindeki telif hakkı endişelerini de dikkate almak zorunda. ABD hukuku da tamamen netleşmiş değil.
  GNU, önemli katkılarda telif hakkının %100 kendilerinde olduğundan emin olmak istiyor. Burada yazarın hukuki yorumu önemli değil; GNU Project güvenli yolu seçiyor. LLM’ler hakkında muhtemelen sahip oldukları diğer endişeler ise henüz hesaba bile katılmamış durumda.

  • Açıkçası mevcut içtihatlara göre yazarın ABD hukuku anlayışı da yanlış[1]. Mevcut içtihat uyarınca LLM tarafından üretilen kod telif hakkı koruması alamaz; dolayısıyla lisanslanamaz da ve otomatik olarak kamu malı olur.
    Dahası bir depoda LLM tarafından üretilmiş kod varsa ve bu kod açıkça ayrılmamış/işaretlenmemişse, tüm deponun telif hakkı korumasına ve lisanslamaya uygun olmadığı kabul edilir.
    Başka bir deyişle, yazar yalan söyleyip kodun commit edilmesini sağlasaydı, tüm Emacs kod tabanının lisans geçerliliğini riske atabilirdi.
    Bunların hepsi, “IANAL ama avukatlar bariz şekilde yanılıyor” şeklindeki sanrıya yakın kibirli tutumdan ayrı. İlgili hukuk maddelerinin yalnızca bir kısmına bakarken aynı anda avukatları kibirli olmakla suçluyor.
    [1] Yaklaşık iki ay önce şirketin hukuk ekibiyle bu konuşmayı yaptığım zamana göre güncel.

• “Yalan söyleseydi kabul edilirdi”nin anlamlı bir argüman olup olmadığından emin değilim.

  • Aynı mantık lisans için de kullanılabilir. Kapalı kaynak bir kod tabanından bir şey kopyalayıp kendi yazdığınızı söyleyerek yalan söylerseniz yama kabul edilebilir. Ama gerçeği söylerseniz reddedilir. O hâlde sonuç, lisansların kötü olduğu mu?
  • Doğru. no-LLM politikaları hakkında “o zaman insanlar sadece yalan söyler” argümanını sık duyuyorum.
    Bu, o insanlar hakkında hiç de iyi bir şey söylemiyor, değil mi?
    Bakımcıları LLM yanlısı/karşıtı politikaları nedeniyle taciz etmenin iyi bir tarafı olduğunu sanmıyorum. İşi onlar yapıyor ve hangi katkıları değerlendireceklerine, kabul edeceklerine ya da reddedeceklerine karar verme hakları var.
    Elbette şikâyet etmekte sorun yok bence. Bu kişi blogunda kendi tutumunu ortaya koyuyor; tartışmalar da böyle şekilleniyor. Ama framing’e katılmıyorum. Buradaki mesele “dürüstlük” değil. no-LLM politikası duyurulmuşsa, böyle katkıları istemeyen bir projeye LLM kullanarak katkı yapmaya zaman harcamanın sorumluluğu kişinin kendisine ait.
    Bu, bir vegana içinde et ya da peynir bulunan yiyecek verip, malzemeleri “dürüstçe” söylediğiniz için yememesinden şikâyet etmekten farklı değil. “Söylemeseydim içinde süt ürünü olduğunu bilmezdi” iyi görünmüyor; “söylemeseydim LLM kullandığımı bilmezdi” de aynı şekilde.
  • Katılıyorum. Yeni başlık olarak Vibecoding gets Emacs patch rejected önerdim. Vibe coding yaptığını kabul etmedeki dürüstlük, telif hakkı ihlalini kabul etmedeki dürüstlüğe benziyor. Reddin temel nedeni dürüstlük değil.
  • LLM kullanıp bunu dürüstçe açıklamanın, yamanın reddedilmesi için neden olduğunu düşünüyorum. LLM kullanıp yalan söylemek ise yamanın reddedilmesine ek olarak sonraki katkı girişimlerinin de yasaklanması için nedendir.

• GNU ve FSF, profesyonel hukuki danışmanlık almak için epey yatırım yapıyor. Ama bu potansiyel katkıcı, internetteki birinin söylediklerine dayanarak o profesyonel danışmanlığı görmezden gelmelerini salık vermiş oluyor
  Profesyonel danışmanlığa para ödediyseniz o tavsiyeye uymak mantıklıdır; katılmıyorsanız başka bir uzmana gitmeniz gerekir. Rastgele bir internet yorumcusunun tavsiyesi yüzünden bunu görmezden gelmek “neredeyse hiciv gibi” değil, düpedüz aptallık

  • Bir projeye katkıda bulunmak, kendinizi ortaya koymak ve kırılgan bir konumda durmak demektir. Özellikle “kod çalışıyorsa” ve kişisel bir rahatsızlığı gideriyorsa reddedilmek daha da zor olabilir
    Reddedilmesinden bağımsız olarak, ileride epey ilginç dava örnekleri ortaya çıkabilir gibi görünüyor. Büyük model sağlayıcıları bir tür tazmin güvencesi sunup “oluşturulmasına yardım ettiğimiz kod bu, istediğiniz gibi telif hakkı iddia edebilirsiniz” diyebilir; ya da tam tersine meseleyi zorlayıp kodun kendilerine ait olduğunu ve belirli kullanımlar için lisans alınması gerektiğini ileri sürebilirler. Claude şu anda kodu kullanıcıya veriyor, ama nasıl bir tazmin güvencesi sunduğunu bilmiyorum. Diğer modeller için de pek bilmiyorum

• Suçun yalnızca yakalandığında yasa dışı olduğunu biliyor muydun

• GNU’nun ateşli bir hayranı hiç değilim ama LLM kodlama aracı, GNU felsefesinin tam karşı kutbunda yer almıyor mu? Kedi kafesine köpek getirip kovulunca öfkelenmek gibi bir şey

• Başlığı “Honesty gets Emacs patch rejected”dan Vibecoding gets Emacs patch rejecteda çevirmek bence son derece dürüst olmayan bir değişiklik
  Yazar gibi yapay zeka araçlarından yardım alınmış olsa bile, koda o kadar zaman ve anlayış yatırıldıysa bu açıkça vibe coding değildir. “Emacs’i daha hızlı yap” diye yapay zekaya atıp çıkan sonucu gözünüz kapalı göndermiş olsaydınız vibe coding olurdu; ama yazıyı okuyunca bunun kesinlikle böyle olmadığı görülüyor

  • “honesty” başlığı da dürüst değildi. Yamanın reddedilme nedeni dürüstlük değil, politika ihlaliydi
  • “vibe coding” terimine dair yorumuna katılıyorum, ama insanların bu terimi çok farklı şekillerde kullandığını görünce bunun o kadar da dürüstlükten uzak olduğunu düşünmüyorum
    Ben olsam muhtemelen “Breaking contribution policy gets Emacs patch rejected” gibi bir şey derdim. Hâlâ alaycı, ama itiraz etmesi daha zor

• Burada dikkat çeken şey, yazarın iki ay boyunca düzenli çalıştığını iddia ederken, sorunu bulup çözmek için kullandığını söylediği modelin 12 gün önce yayımlandığını belirtmesi
  Yazarın epey sinirlendiğini anlıyorum; ama sonuçta açık kaynak, birine hak vermekten çok, zaten oluşturulmuş kodu kullanabilme ayrıcalığına yakın bir şey bence. Eğer bir değer taşıyorsa—muhtemelen taşıyordur ve macOS hakkında yazdıkları genel olarak doğru—Emacs geliştiricileri zaman ayırıp bakabilir. Yine de macOS’un onların başlıca ilgi alanı olduğunu sanmıyorum

• Bu politikanın ne kadar aptalca olduğunu kanıtlayan kolay bir çözüm var. İkinci monitörde LLM destekli PR diff’ini açık tutup, ana monitörde değişiklikleri baştan elle yeniden yazarsınız. Değişken adlarını ve yorum içeriklerini de biraz değiştirirsiniz
  Artık insan tarafından yazılmış kod olduğuna göre birleştirilebilir

  • Dünyadaki çeşitli yargı bölgelerinde LLM çıktıları etrafındaki telif hakkı ve hukuki meseleler düşünüldüğünde bu çok safça bir bakış açısı