Açık kaynak projelerinde yapay zeka kodu kullanımı

Yapay zeka destekli kodu upstream göndermeden önce yapılması gerekenler

Açık kaynak projeleri artık yapay zeka destekli kod kullanımıyla ilgili politikalar yayınlamaktadır ve bu politikalar birbirleriyle uyumlu değildir. Bu nedenle alışkanlık basittir: yamayı yazmadan önce politikayı bulun ve gönderim yaparken durumu doğru bir şekilde beyan edin. Her iki durumda da geçerli olan tek bir kural vardır: inceleme sırasında açıklayamayacağınız tek bir satırı bile göndermeyin.

Proje üretilmiş kodu yasaklıyorsa veya kodun kaynağını gizlediyseniz, doğru bir yama bile reddedilir. Bunun maliyeti sizin adınıza yansır ve orada kalır; çünkü eksikliği daha sonra fark eden bir maintainer, geçmişinizin geri kalanına güvenmek için hiçbir nedene sahip olmayacaktır. Politikalar bu terimleri kullandığı için öncelikle bazı tanımlar gereklidir. Bir LLM (large language model), kodlama aracınızın arkasındaki modeldir. GitHub üzerindeki bir PR (pull request), GitLab üzerinde bir MR (merge request) ile aynıdır ve aşağıdakilerin tümü her ikisi için de geçerlidir. DCO (developer certificate of origin), commit mesajının altındaki onay satırıdır ve tüm tartışmanın merkezinde yer aldığı ortaya çıkmıştır.

Açık kaynaklı yapay zeka kodu politikalarının ulaştığı nokta

Projeler dört farklı kategoride karara varmıştır. Aşağıdaki her örnek günceldir, ancak bu metinler zamanla değişebilmektedir.

Yasaklı. Gentoo konseyi, 14 Nisan 2024 tarihinde "Doğal Dil İşleme yapay zeka araçlarının yardımıyla oluşturulan herhangi bir içeriğin Gentoo'ya katkı olarak sunulmasının kesinlikle yasaklandığına" karar vermiştir. NetBSD'nin commit yönergeleri, LLM çıktısını "kusurlu kod" olarak tanımlamakta ve "çekirdek ekibin yazılı onayı olmadan commit edilmemesi gerektiğini" belirtmektedir. QEMU'nun kod kökeni belgesi, Ağustos 2026 itibarıyla, projenin "yapay zeka tarafından üretilen içerikleri içerdiği veya bunlardan türetildiği düşünülen tüm katkıları REDDEDECEĞİNİ" ifade etmektedir.

Sadece analiz. Çoğu yasak, manşetlerde göründüğünden daha dar kapsamlıdır. QEMU'nun belgesi, politikanın "çıktılarının katkılara dahil edilmemesi koşuluyla, API veya algoritmaların araştırılması, statik analiz veya hata ayıklama gibi yapay zekanın diğer kullanımları için geçerli olmadığını" belirtir. Aracı kodu okumak için kullanabilirsiniz. Ancak yazdığı kodu projeye dahil edemezsiniz. Bu ayrım, çoğu kısıtlayıcı projenin temel çalışma prensibidir ve insanların gözden kaçırdığı nokta da budur.

Bildirim zorunlu. Fedora konseyi, Ekim 2025'te yapay zeka destekli katkılara ilişkin bir politikayı onaylamıştır. Bu politika araçların kullanımına izin verir ve sorumluluğu kişiye yükler: Katkıda bulunan kişi yazar kabul edilir, katkının tamamından tamamen sorumludur ve önemli bir kısmının araç tarafından değişiklik yapılmadan üretildiği durumlarda bunu bildirmek zorundadır. Linux çekirdeği, Aralık 2025'te süreç dokümantasyonuna bir kodlama asistanları sayfası eklemiş; burada aracın kaydedilmesine yönelik bir bölüm ve kimin onay verebileceğine dair kesin bir kural getirilmiştir.

Yazılı bir kural yok. Bu durum hala yaygın olan uygulamadır. Mayıs 2026 tarihli bir ön baskı çalışması, popüler 1.000 GitHub deposunu incelemiş ve bunlardan yalnızca 118'inin yazılı bir yapay zeka politikasına sahip olduğunu tespit etmiştir. Sessizlik, izin verildiği anlamına gelmez. Yamayı yazmadan önce sorun takip sisteminde (issue tracker) tek bir cümleyle soru sorun; alacağınız yanıt, daha sonra referans gösterebileceğiniz kamuya açık bir kayıt haline gelecektir.

Bakımcıların bu kuralları neden yazdığı

İlk neden inceleme yüküdür ve matematik tek bir yöne doğru işler. Bir yapay zeka aracı, bir dakika içinde 400 satırlık makul görünen bir birleştirme isteği (merge request) oluşturabilir. Bu isteği düzgün bir şekilde incelemek bir bakımcının öğleden sonrasına mal olur ve çoğu bakımcı gönüllüdür. Gönderim maliyeti sıfıra yaklaştı. İnceleme maliyeti ise hiç değişmedi.

curl, bu eğrinin uç noktasını göstermektedir. Daniel Stenberg, 2025 yılının ortalarında, proje üzerinden gelen güvenlik raporlarının yaklaşık beşte birinin kendi deyimiyle "AI slop" (yapay zeka çöpü) olduğunu bildirdi: gerçek fonksiyonları ve gerçek kod yollarını isimlendiren, makul bir saldırı senaryosu tanımlayan ancak içi boş olan raporlar. Proje, bu selin finansmanını sürdürmek yerine 2026 yılının başlarında ödül programını sonlandırdı. Bunlar yama değil rapor olsa da, bir bakımcının sizin PR'ınızı zaten yorgun bir şekilde açmasına neden olan mekanizma aynıdır.

GNOME Calendar bu sorunu bir etiket olarak tanımladı. Haziran 2026'da proje, "kod üretmek için yapay 'zekaya' büyük ölçüde veya tamamen güvenen" birleştirme istekleri için "Olasılıksal Olarak Otomatikleştirilmiş" (Probabilistically Automated) etiketini getirdi ve sorunun belirtisini tam olarak adlandırdı: "genellikle uygun testlerin eksikliği ve yamaların kodun doğruluğundan ziyade teorik olarak amaçlanan davranışa dayalı olarak tamamlanması". Bu son ifadeyi iki kez okuyun. Kod çalışması gerekiyormuş gibi görünür. Kimse gerçekten çalışıp çalışmadığını kontrol etmemiştir.

İkinci neden ise köken bilgisidir; yani kodun nereden geldiği ve hangi lisansa tabi olduğu. QEMU, bu çatışmayı açıkça belirtir: bir değişikliği onaylamak (sign-off), katkıda bulunduğunuz içeriğin "telif hakkı ve lisans durumunu tam olarak anladığınızı" beyan etmeniz anlamına gelir ve model çıktılarının telif hakkı durumu belirsizdir. Gentoo konseyi de kalite ve etik gerekçelerinin yanı sıra aynı nedeni öne sürdü. Hukuki yoruma katılmak zorunda değilsiniz. Ancak bu kararın size değil, bakımcıya ait olduğunu fark etmek zorundasınız.

Bir projenin yapay zeka politikasını nasıl bulabilirim?

Sırasıyla şu yerlere bakın.

• Depo kök dizinindeki CONTRIBUTING.md, ardından .github/CONTRIBUTING.md ve sonrasında yanındaki herhangi bir DCO dosyası.
• Geliştirici belgeleri. QEMU kurallarını docs/devel/code-provenance.rst içinde tutar. Çekirdek (kernel) ise kendi kurallarını Documentation/process/coding-assistants.rst içinde barındırır.
• Proje web sitesi veya wiki sayfası. Gentoo'nun politikası konseyin wiki sayfasında, NetBSD'ninki ise commit kılavuzlarında yer alır.
• Hata takip sistemi (issue tracker) ve e-posta listesi arşivi. Bir politika genellikle depoya yazılmadan aylar önce buralarda tartışılır.

Bir çalışma kopyasının (checkout) içinden, tek bir grep komutu çoğu durumu kapsar:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Ardından projenin kendi geçmişini inceleyin, çünkü commit edilmiş gelenekler her türlü özetin üzerindedir:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Bir trailer değerinin yanındaki sayı, projenin fiilen kullandığı biçimi gösterir. Boş bir sonuç, burada kimsenin bu biçimde beyanda bulunmadığı anlamına gelir ki bu da başlı başına bir bilgidir. Proje GitHub üzerinde barındırılıyorsa ve iş akışı size yeniyse, GitHub üzerinde pull request ve fork işlemleri nasıl çalışır bölümü, bu kısmın varsaydığı mekanizmaları açıklar.

Açıklamayı yorumda değil, commit trailer kısmında belirtin

Trailer, commit mesajının son paragrafındaki bir Key: value satırıdır. Git bu biçimi halihazırda Signed-off-by: ve Co-authored-by: için kullanmaktadır ve araçlar bunu ayrıştırabildiği için, kodla birlikte ağaca taşınan tek açıklama yöntemi budur.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Çekirdek belgeleri bu formatı Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] olarak tanımlar ve satırın sınırları konusunda nettir: "Yapay zeka aracıları Signed-off-by etiketleri eklememelidir. Yalnızca insanlar Geliştirici Köken Sertifikasını (DCO) yasal olarak onaylayabilir." Aracının adı Assisted-by kısmına yazılır. Sizin adınız ise Signed-off-by kısmına yazılmalıdır. Bir aracın ikinciyi yazmasına veya kimseye ait olmayan bir Co-authored-by adresi uydurmasına asla izin vermeyin.

İsimler değişkenlik gösterdiğinden, kendi isminizi uydurmak yerine yerel olanı kopyalayın. Mayıs 2026'da QEMU listesinde yayınlanan bir yama, mekanik değişiklikler, testler, dokümantasyon ve yirmi satır veya daha kısa hata düzeltmeleri için bu projenin yasağının esnetilmesini ve bunların AI-used-for: tests, docs gibi bir trailer ile kaydedilmesini önermiştir. Ağustos 2026 itibarıyla bu bir posta listesi önerisidir ve commit edilen belge hala üretilmiş içeriği reddetmektedir. Bir proje, 2023 ile 2026 yılları arasında tutumunu iki kez değiştirmiştir. Bir sonraki değişiklik sizi beklemeyecektir; bu yüzden yöntem, listeden daha önemlidir.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer, Git 2.32 veya daha yeni bir sürüm gerektirir. İkinci komut, değeri doğrudan size geri döndürmelidir. Boş bir satır, Git'in trailer kısmını ayrıştıramadığı anlamına gelir; bunun nedeni neredeyse her zaman mesajın altındaki trailer bloğunun içinde boş bir satır veya sıradan bir cümlenin bulunmasıdır. Halihazırda yazdığınız bir seri için git rebase --signoff origin/main her commite sign-off ekler, git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt ise bir mesaj dosyasını düzenler.

İki hata modu için plan yapmakta fayda vardır. Squash merge işlemi commit mesajını yeniden yazar; bu nedenle squash yapan bir projede, açıklamayı bakımcının okuduğu PR açıklamasında tekrarlayın. Bir inceleme yorumu ise kayıt niteliği taşımaz, çünkü yorumlar düzenlenebilir ve asla Git geçmişine girmez.

Doğruluk her iki tarafı da keser. Elle yazdığınız bir committe Assisted-by kullanmak gürültü kirliliğidir ve gerçek açıklamalarınızın değerini düşürür. Aracın yazdığı bir committe bunu belirtmemek ise ilişkiyi bitiren şeydir.

Signed-off-by ifadesi gerçekte neyi tasdik eder?

DCO, developercertificate.org adresinde yayımlanan ve çekirdek (kernel), QEMU ve daha pek çok proje tarafından kullanılan 1.1 sürümü numaralı kısa bir metindir. Signed-off-by: Your Name <you@example.com> eklemek, bu metni onayladığınızı beyan ettiğiniz anlamına gelir. Neyi onayladığınızı okuyun; çünkü çoğu kişi bunu hiç okumadan imzalar.

(a) maddesi, katkının "tamamının veya bir kısmının tarafımca oluşturulduğunu ve dosyada belirtilen açık kaynak lisansı altında sunma hakkına sahip olduğumu" belirtir. (b) maddesi, üzerinde değişiklik yapma hakkına sahip olduğunuz önceki açık kaynak kodlarına dayanan çalışmaları kapsar. (c) maddesi, aynı şeyi tasdik etmiş birinden size teslim edilen kodları kapsar. (d) maddesi ise katkının ve imzanızdaki kişisel bilgilerin herkese açık olduğunu ve süresiz olarak saklandığını anladığınızı ifade eder.

Neyin eksik olduğuna dikkat edin. DCO, her karakteri sizin yazdığınızı iddia etmez. Kodu bu lisans altında sunma hakkına sahip olduğunuzu söyler. Üretilmiş kodun (generated code) burada sorunlu durmasının nedeni budur: mesele yazarlık değil, kökeni açıklayıp açıklayamayacağınızdır. İmza gerektiren çoğu proje gerçek isim de talep eder, bu nedenle takma isimler kontrolü geçemez. Satırı git commit -s ile ekleyin; bu komut git yapılandırmanızdan user.name ve user.email değerlerini okur. Bir DCO botu PR isteğinizi reddettiğinde ve eksik satırın bulunduğu commit'i belirttiğinde, git rebase --signoff origin/main komutu ve ardından dalınıza yapacağınız bir force push sorunu çözecektir.

Commit imzalamak ile sign-off yapmak aynı şey değildir

git commit -s bir metin satırı ekler. git commit -S ise GPG veya SSH anahtarınızı kullanarak commit nesnesi üzerinde kriptografik bir imza oluşturur. Bu iki işlem farklı sorulara yanıt verir. İmza, commit'in ilgili anahtarın sahibi tarafından oluşturulduğunu ve o andan itibaren değiştirilmediğini doğrular. İçerikteki kodun kaynağı hakkında herhangi bir bilgi vermez; dolayısıyla, açıklanmamış üretilmiş kodlarla dolu imzalı bir commit, teknik olarak imzalı olsa da yine de bir politika ihlali teşkil edebilir. Sign-off, köken ile ilgili bir beyandır. İmza ise kimlik ile ilgili bir beyandır. Her ikisini de talep eden projeler, her iki işlemi de ayrı ayrı isteyecektir.

Açıklayamadığınız kodu incelemeye göndermeyin

Bu bir testtir ve konu dürüstlükten ziyade yetkinliktir. Her satır için şu soruları sorun: Bu ne işe yarıyor ve bu satır olmazsa ne bozulur? Bu sorulardan herhangi birinin cevabı eksikse yama hazır değildir; çünkü inceleme yorumu geldiğinde vereceğiniz cevap, sürecin bir tur daha uzamasına neden olacaktır. İncelemeyi yapanlar bunu anlar. İşte bir katkı sağlayıcının projeye yük olmaya başladığı an budur. Aynı soruları uç durumlar, boş girdi, hata yolu ve ikinci çağırıcı için de sorun.

Kodu çalıştırın. Derleyin, projenin test paketini çalıştırın ve düzeltmeyi iddia ettiğiniz hata için bir yeniden üretim (reproducer) senaryosu yazın. Çekirdek belgeleri, dürüst bir geri çekilme yöntemini açıkça belirtir: "Eğer düzeltme derlenemiyor veya test edilemiyorsa ya da bir yeniden üretim senaryosu oluşturulamıyorsa, bunu açıkça belirtin: sürdürücüler şu anda doğrulanmamış raporları ve test edilmemiş düzeltmeleri analiz ederek çok fazla zaman kaybediyor." "Bunu gerçek donanım üzerinde test edemedim" diye yazmanın size bir maliyeti yoktur. Test ettiğinizi ima etmek ise projeden dışlanmanıza neden olur.

İnceleme yorumlarını kendi kelimelerinizle ve kendi zamanınızda bizzat yanıtlayın. Yorumdan otuz saniye sonra gelen ve yorumu beş paragrafta tekrar eden bir yanıt, sürdürücüye tam olarak ne olduğunu anlatır. Ayrıca diff dosyasını küçük tutun. Tamamen anladığınız kırk satırlık bir kod, denetlediğiniz dört yüz satırlık bir yeniden düzenlemeden (refactor) bir proje için daha değerlidir. Eğer yapay zeka aracınız sizden istediğinizden fazlasını vermeye devam ediyorsa, onu çalışan en küçük değişikliğe zorlayan bir beceri, yamayı satır satır savunabileceğiniz bir seviyede tutmanın bir yoludur.

Ajan talimatlarını depoda tutun

Ajanınıza verdiğiniz talimatlar araç zincirinizin bir parçasıdır, bu nedenle onlara kod gibi davranın. Depo kök dizininde bulunan ve genellikle AGENTS.md olarak adlandırılan bir dosya; derleme komutunu, test komutunu, commit mesajı formatını, onay gereksinimini ve projenin halihazırda belgelediği stil kurallarını barındırır. Bu dosya sürümlenmiş ve incelenebilir durumdadır; bugün neyse yarın da aynı kalır. Her oturumda hafızadan yeniden yazılan talimatlar her seferinde farklı bir yama üretir ve reddedilen yamanın hangi oturumda oluşturulduğunu bilemezsiniz. Hem bir ajanın hem de bir insanın okuyabileceği bir AGENTS.md yazmak konusu bu dosyanın kendisini ele almaktadır.

Başkalarının depoları hakkında bir uyarı: İlk katkınızı, bakımını yapmadığınız bir projeye ajan talimat dosyası ekleyen bir PR (çekme isteği) olarak yapmayın. Bu, projenin araç politikasını dışarıdan belirleme girişimi olarak algılanır ve hesabınızın, bakımcıların zaten bıkkın olduğu bir konuyla ilişkilendirilmesinin hızlı bir yoludur. Birisi sizden isteyene kadar dosyayı kendi fork'unuzda tutun.

Ajanı nerede çalıştırdığınız da aynı nedenle önemlidir. Projeyi derleyebilen ve testlerini kontrolünüz altındaki bir sandbox içinde çalıştırabilen bir ajan, size gerçekten doğrulanmış bir yama sunar; bu, yardım aldığınızı açıklamak ile bir tahminde bulunduğunuzu açıklamak arasındaki farktır. Kendi VPS'nizde bir kodlama ajanı çalıştırmak bu kurulumu, Claude Code, Cursor, Codex ve Copilot arasındaki pratik farklar ise bu araçların günlük kullanımda nasıl farklılaştığını ele almaktadır.

Politika değişikliği sonrası izlenecek yöntem

1. Herhangi bir şey yazmadan önce belirtilen politikayı bulun: depo, geliştirici dokümanları, web sitesi veya takip sistemi.
2. Eğer bir politika yoksa, ilgili issue içerisinde tek bir cümleyle soru sorun ve gelen yanıtı saklayın.
3. Projenin kullandığı formata uygun şekilde açıklama yapın, bunu commit trailer kısmına ekleyin ve proje commitleri birleştiriyorsa (squash) PR gövdesinde tekrarlayın.
4. Kodun gönderilme hakkına sahip olduğunuzu beyan eden satırın sorumluluğunu alarak gerçek adınızla imzalayın (sign-off).
5. Kendi yamanızı, sanki onu bir yabancı yazmış gibi inceleyin; çünkü aslında öyle olmuştur.

Bu sayfada adı geçen her proje, siz okuduğunuz sırada yer değiştirmiş olacaktır. Ancak bu beş adım değişmez.

FAQ

AI kodlama aracı kullandığımı belirtmek zorunda mıyım?

Projenin kurallarını kontrol edin, çünkü yanıt yerel olarak belirlenmiştir. Fedora, katkının önemli bir kısmı üzerinde değişiklik yapılmadan bir araç tarafından oluşturulduğunda bildirim yapılmasını şart koşar. Linux kernel, bir Assisted-by trailer eklenmesini ister. Gentoo ve QEMU, Ağustos 2026 itibarıyla bu tür katkıları hiç kabul etmemektedir. Yazılı bir kuralın olmadığı durumlarda, yine de commit trailer kısmında belirtin. Durumu sonradan fark eden bir maintainer, araca değil, bu bilginin gizlenmiş olmasına tepki verecektir ve bu tepki gönderdiğiniz diğer tüm işlere yansıyacaktır.

Hangi açık kaynak projeleri yapay zeka tarafından oluşturulan kodu yasaklıyor?

Ağustos 2026 itibarıyla güncel durum şöyledir: Nisan 2024'ten beri Gentoo; LLM çıktısını çekirdek onayına tabi, kusurlu kod olarak gören NetBSD; oluşturulmuş içerikten türetilen katkıları reddeden QEMU ve Loupe ile Calendar dahil olmak üzere çeşitli GNOME uygulamaları. Bu liste zamanla eskiyeceğinden, her projenin kendi metnini okuyun. Çoğunun paylaştığı muafiyete dikkat edin: Bir modeli API araştırması yapmak, statik analiz çalıştırmak veya hata ayıklamaya yardımcı olması için kullanmak, çıktısı yamaya (patch) dahil edilmediği sürece genellikle sorun teşkil etmez.

Signed-off-by ile imzalı commit arasındaki fark nedir?

Signed-off-by, git commit -s tarafından eklenen düz bir metin satırıdır. Geliştirici menşe sertifikasını (DCO) onaylar; yani bu kodu projenin lisansı altında gönderme hakkına sahip olduğunuzu beyan eder. git commit -S ile oluşturulan imzalı bir commit ise, commit nesnesi üzerinde GPG veya SSH anahtarınızla yapılan kriptografik bir imzadır. Commit'in sizin anahtarınızdan geldiğini ve değiştirilmediğini kanıtlar. Menşe ve kimlik ayrı iddialardır, bu nedenle imzalı bir commit bile bir yapay zeka politikasını ihlal edebilir.

Bildirimi commit mesajı yerine pull request açıklamasında belirtebilir miyim?

Commit mesajına ekleyin; çünkü bu, git geçmişine işlenen ve depoyu daha sonra klonlayan herkesle birlikte taşınan kayıttır. Bir pull request açıklaması sonradan düzenlenebilir ve yalnızca barındırma platformunda kalır. Proje "squash merge" yapıyorsa, PR gövdesine de ekleyin; çünkü squash işlemi commit mesajınızı yeniden yazar ve trailer kısmını silebilir.

Pull request'im yapay zeka tarafından oluşturulduğu için kapatıldı. Şimdi ne yapmalıyım?

Başlık altında politikayı tartışmayın; çünkü kapatma işlemini yapan kişi kuralı tek başına yazmamıştır ve tartışma yeri burası değildir. Politika metnini okuyun ve buna uyum sağlayıp sağlayamayacağınıza karar verin. Proje oluşturulmuş yamaları yasaklıyorsa, yama içermeyen ancak yeniden üretilebilir bir hata raporu hala kabul görür ve genellikle daha faydalı bir katkıdır. Kodla geri dönecekseniz, satır satır savunabileceğiniz küçük bir değişiklikle gelin.