Kimsenin Yazmadığı Kodun Sahibi Kim?

Üretimde bir hata çıktığında olay sonrası analizde 'bu kodu AI üretti' cümlesi hiçbir şeyi açıklamaz. Müşteri, denetçi ya da sözleşme karşı tarafı için yazılımı işleten şirket sorumludur; model sağlayıcısının kullanım koşulları da genellikle çıktının doğruluğu için garanti vermez. Pratikte sorumluluk zinciri şöyle işler: kodu merge eden kişi ve onu onaylayan reviewer, değişikliğin sahibidir; servisi işleten ekip, davranışının sahibidir.

Bu bir suçlama kültürü önerisi değil. Suçlamasız (blameless) olay analizinde de soru 'kim yazdı' değil, 'hangi kontrol bunu yakalamalıydı' olmalı. AI'ın ürettiği kodda bu soru daha da önemli hale geliyor: test kapsamı, review derinliği ve izleme yeterli miydi? Somut kural önerisi: ajanın açtığı PR'larda da en az bir insan, kodu açıklayabilecek düzeyde anladığını belirterek onay verir. 'LGTM' ile geçen 600 satırlık bir AI PR'ı, sahipsiz kodun en tipik doğum anıdır.

Son 12 ayda sahiplik tartışmasının hem hukuki hem teknik zemini değişti. ABD'de Yüksek Mahkeme 2 Mart 2026'da Thaler v. Perlmutter davasında temyiz başvurusunu kabul etmedi; böylece bir makinenin yazar olamayacağı yönündeki karar kesinleşti. 16 Eylül 2026'da Dokuzuncu Daire, Doe v. GitHub davasında Copilot çıktısının mevcut bir kodun kopyası değil yeni bir eser olduğunu, bu yüzden telif yönetim bilgisinin (CMI) kaldırılmasından söz edilemeyeceğini söyledi. Mahkeme çıktının telif ihlali oluşturup oluşturmadığına girmedi ve sözleşme iddiaları alt mahkemede sürüyor.

Teknik tarafta 'anlama borcu' (comprehension debt) kavramı 2026'da yaygın bir tartışma başlığına dönüştü. Anthropic'in Ocak 2026'daki deneyinde yeni bir kütüphaneyi AI yardımıyla öğrenen geliştiriciler, anlama testinde elle kodlayanlardan belirgin biçimde düşük puan aldı (yüzde 50'ye karşı 67). Stack Overflow 2026 anketinde geliştiricilerin yüzde 48'i AI çıktısına ancak kolayca doğrulayabildiğinde güveniyor, önemli kararlarda güvenenler yalnızca yüzde 7. Bu tablo, onay veren insanın kodu gerçekten anlamasını her zamankinden kritik kılıyor. Hukukçu değilim; bu özet hukuki görüş değildir.

Bu bölüm hukuki görüş değil; ben hukukçu değilim ve kesin bir hüküm vermiyorum. Okuyabildiğim kadarıyla ABD'de tablo şöyle: ABD Telif Hakkı Ofisi, Ocak 2025'te yayımladığı raporun ikinci bölümünde, tamamen AI tarafından üretilen ifadenin telif korumasından yararlanmadığını, insanın yaratıcı seçim, düzenleme ya da değişiklik yaptığı kısımların ise korunabileceğini belirtti. Thaler v. Perlmutter davasında D.C. Temyiz Mahkemesi Mart 2025'te bir makinenin yazar olamayacağına hükmetti; Yüksek Mahkeme 2 Mart 2026'da temyiz başvurusunu kabul etmedi.

Yazılım için bunun pratik anlamı, insan katkısının hem nitelik hem de belge olarak önem kazanması. Mimari kararı veren, modülleri düzenleyen, üretilen kodu anlamlı biçimde değiştiren ekip, eserin insan kaynaklı kısmını oluşturuyor. Türkiye ve AB'de durum farklı değerlendirilebilir; FSEK'in (Fikir ve Sanat Eserleri Kanunu) AI çıktısına uygulanması tartışmalı. Ticari açıdan kritik bir kod tabanı için bu sorunun cevabı bir fikri mülkiyet avukatından alınmalı.

İkinci hukuki soru, üretilen kodun eğitim verisindeki lisanslı bir kodla birebir ya da çok yakın eşleşmesi. Özellikle GPL gibi copyleft (türev eserin de aynı lisansla dağıtılmasını şart koşan) lisanslı bir kod parçası kapalı kaynak bir ürüne girerse, lisans yükümlülüğü doğabilir. Burada da kesin hüküm vermiyorum; risk değerlendirmesi kullanım şekline ve yargı alanına göre değişir.

ABD'de bu riskin bir boyutu Eylül 2026'da netleşti: Dokuzuncu Daire, Doe v. GitHub davasında Copilot'un ürettiği kodu yeni bir eser saydı ve DMCA'nın telif yönetim bilgisini kaldırmayı yasaklayan hükmüne dayanan iddianın reddini onadı. Mahkeme, birebir ya da çok yakın bir kopyada bildirimin silinmesinin hâlâ dava konusu olabileceğini kabul etti ve çıktının telif ihlali olup olmadığını açık bıraktı.

Araç tarafında önlemler mevcut. GitHub Copilot'un code referencing özelliği, 150 karakter ve üzerindeki öneriler kamuya açık kodla eşleştiğinde, eşleşen kaynağı ve tespit edilen lisansı gösteriyor; organizasyonlar kamu koduyla eşleşen önerileri tamamen engellemeyi de seçebiliyor. Kurumsal müşterilere bazı sağlayıcılar telif iddialarına karşı tazminat taahhütleri de sunuyor, ama bu taahhütler genellikle filtrelerin açık olması gibi koşullara bağlı. Pratik adım: CI'a bir yazılım bileşimi analizi (SCA) ve lisans tarayıcı eklemek, filtre ayarlarını organizasyon düzeyinde sabitlemek.

Bir kod satırının kimden ya da neden geldiğini bilmek, hem hukuki hem de teknik sahiplik için temel. Geleneksel yazılımda git blame bir isim gösterir ve o kişiye sorarsınız. AI ile üretilen kodda blame bir insanı gösterir, ama o insan kodu belki hiç okumamıştır. Provenance (köken bilgisi) bu boşluğu kapatmaya çalışır.

Uygulanabilir pratikler: ajan ya da asistanla yazılan commit'lerde bir trailer kullanmak (ör. 'Co-Authored-By' satırı ya da ekibin belirlediği bir etiket); PR açıklamasında kullanılan aracı, verilen talimatı ve insanın değiştirdiği kısımları kısaca yazmak; büyük üretimlerde prompt'u ya da ajanın çalışma özetini PR'a eklemek. Eşik önerisi: 50 satırdan büyük ve çoğunlukla AI tarafından üretilmiş değişikliklerde bu not zorunlu olsun. Bu kayıt, bir yıl sonra 'bu modül neden böyle' sorusuna verilecek cevabın kendisi. Ayrıca telif açısından insan katkısını belgelemenin de en pratik yolu.

Kimsenin tam olarak anlamadığı bir modül, kim yazmış olursa olsun teknik borçtur. AI bu borcu hızlandırabilir: bir ajan bir öğleden sonra 2000 satırlık bir entegrasyon katmanı yazar, testler geçer, PR merge edilir. Altı ay sonra bir hata çıktığında ekipte o kodun akışını açıklayabilecek kimse yoktur. Bu duruma 2026'da yaygınlaşan adıyla 'anlama borcu' (comprehension debt) deniyor: sistemdeki kod miktarı ile ekibin gerçekten anladığı kod arasındaki açık. Teknik borcun aksine sürtünme yaratmaz; temiz kod ve yeşil testler onu gizleyebilir.

Buna karşı somut önlemler var. Her modülün CODEOWNERS dosyasında bir sahibi olsun ve bu sahip o kodu açıklayabilsin. Büyük AI üretimlerinden sonra 30 dakikalık bir 'kodu yürüt' toplantısı yapılsın: sahibi, akışı ekibe anlatsın. Bus factor (ekipten kaç kişi ayrılırsa bir bileşenin anlaşılmaz hale geleceği sayısı) bir olan modüller izlensin. Bir de basit ama etkili bir kural: anlamadığın kodu merge etme; AI'dan önce açıklama, sonra küçük parçalar halinde değişiklik iste.

AI çağında code review'un hem önemi hem de yükü arttı. DORA'nın Mart 2026 analizi de review'u AI ile gelen yeni darboğaz olarak tanımlıyor. İnsan bir PR'ı yazarken yaptığı seçimleri bilir; ajan PR'ında reviewer bu seçimleri ilk kez görür. Üstelik AI kodu genellikle düzgün görünür: tutarlı isimlendirme, yorum satırları, temiz biçim. Yüzeydeki bu düzen, mantıksal hataları ve gereksiz karmaşıklığı gizleyebilir.

İşe yarayan pratikler: PR boyutuna üst sınır koymak (ör. 400 satır; üstü bölünür); ajan PR'larında önce testleri okumak, sonra uygulamayı; 'bu kod neden var' sorusunu her yeni bağımlılık ve soyutlama için sormak; kimlik doğrulama, ödeme ve veri silme gibi kritik yollarda iki insan onayı istemek. AI'ı reviewer olarak kullanmak da mümkün ve faydalı, ama insan onayının yerine değil, önüne konan bir filtre olarak. Anti-pattern: aynı modelin yazdığı kodu yine aynı modele review ettirip insan onayını atlamak; aynı kör noktalar iki kez geçer.

Yukarıdaki kuralların hepsi, yazılı ve kısa bir ekip politikasında toplandığında işe yarar. İki sayfayı geçmeyen bir 'AI ile kod yazma sözleşmesi' şu soruları cevaplamalı: hangi araçlar onaylı ve hangi ayarlarla (kamu kodu filtresi açık mı); hangi veri ve kod modele gönderilebilir; AI kaynaklı değişiklik nasıl işaretlenir; review kuralları neler; lisans taraması nerede çalışır.

Müşteri sözleşmeleri de bu politikayla uyumlu olmalı. Ajans ve yazılım evleri için özellikle önemli: müşteriye teslim edilen kodun fikri haklarının devri ve garanti maddeleri, AI kullanımı düşünülerek yazılmamış olabilir. Bazı müşteriler sözleşmeye AI kullanımını bildirme ya da sınırlama maddesi koymaya başladı. Burada da hukuki metin bir avukatla yazılmalı. Yazılımcının işi, politikanın teknik olarak uygulanabilir olmasını sağlamak: kural CI'da otomatik kontrol edilemiyorsa, büyük ihtimalle uygulanmayacaktır.