Birkaç yıl öncesine kadar "bu kodu kim yazdı?" sorusunun yanıtı oldukça basitti. Belirli bir modülden sorumlu olan programcıyı, ekibi ya da yazılım evini göstermek mümkündü.
Bugün durum tamamen farklı.
Kodun bir kısmı elle oluşturulabilir. Bir kısmını Copilot üretebilir. Başka bir parça bir programlama ajanı tarafından oluşturulur. Bir diğeri açık kaynak bir kütüphaneden alınır. Bir başkası ise dış bir paketin bağımlılığı olur. Buna API'ler, bulut hizmetleri, hazır bileşenler, framework'ler ve diğer şirketler tarafından sunulan araçlar da ekleniyor.
Sistem çalışıyor. Ama gerçekten neyden inşa edildiğini biliyor musun?
Yapay zeka tarafından üretilen kod boşlukta ortaya çıkmaz
Yapay zeka programlama araçlarının gelişimi yalnızca yazılım yazma biçimini değiştirmiyor. Kod üzerindeki sorumluluk yapısını da değiştiriyor.
Bir programcı bugün bir ajana görev tanımlayabilir ve ardından hazır bir fonksiyon, modül, testler, yapılandırma ya da hatta mimari değişiklik önerisi alabilir. Bu, işte büyük bir hızlanma demek.
Sorun, üretilen kodu "hiçbir yerden gelmiş kod" gibi görmeye başladığımızda ortaya çıkıyor.
Çünkü yapay zeka kodu programlama ekosisteminden kopuk biçimde üretmez. Modeller büyük veri kümeleri üzerinde eğitilir ve üretilen parça mevcut çözümlere, desenlere ya da kamuya açık koda benzeyebilir. Tam da bu nedenle kodun kaynağı, lisanslar ve sorumluluk meselesi giderek daha önemli hale geliyor.
Bu, yapay zeka tarafından üretilen her kod parçasının otomatik olarak birinin lisansını ihlal ettiği anlamına gelmez. Ancak, yazılım geliştirme sürecinde yapay zekayı kullanan kuruluşların kodun kökenini ve doğrulamasını hukuki bir merak konusu olarak değil, mühendislik sürecinin bir unsuru olarak ele alması gerektiği anlamına gelir.
Bu artık yalnızca teori değil
16 Eylül 2026'da 9. Bölge Temyiz Mahkemesi, Doe v. GitHub davasının bir kısmına ilişkin karar verdi; davada programcılar GitHub, Microsoft ve OpenAI kuruluşlarını, Copilot ve Codex gibi araçları oluştururken ve eğitirken GitHub'da kamuya açık olan kodu kullanmakla suçluyordu.
Taleplerden biri DMCA ve telif hakkı bilgileriyle ilgiliydi. Mahkeme bu özel iddianın reddedilmesini onadı. Aynı zamanda dava, telif hakkı ve açık kaynak lisanslarıyla ilgili başka konuları da kapsıyor.
Bu önemli, çünkü tek bir karar "Yapay zekadan gelen kod kullanılabilir mi?" sorusuna basit bir yanıt vermez.
Vermez.
Daha önemlisi, bu uyuşmazlık daha geniş bir sorunu gösteriyor: Yapay zeka dünyasında insan tarafından yazılmış kod, model tarafından üretilmiş kod ve mevcut yazılım ekosisteminden gelen kod arasındaki sınırı izlemek giderek daha zor hale geliyor.
Yazılım geliştiren şirketler için bu, süreci daha iyi yönetme zorunluluğu anlamına geliyor.
Yazılım tedarik zinciri, yani sisteminin çok daha fazla "yazarı" var
Yazılım güvenliğinde uzun zamandır software supply chain - yazılım tedarik zinciri - kavramı kullanılıyor.
Bunlar, nihai ürünün ortaya çıkmasına katkıda bulunan tüm bileşenler, araçlar, kütüphaneler, bağımlılıklar ve süreçlerdir.
NIST bu bağlamda özellikle bileşenlerin kökeninin yönetilmesi, açık kaynak bağımlılıklarının kontrol edilmesi, güvenlik açıklarının izlenmesi ve SBOM yani Software Bill of Materials kullanımının önemine dikkat çeker.
SBOM'u çok basit bir şekilde ürünün içerik listesi ile karşılaştırabiliriz.
Sadece "bir uygulamamız var" demez. İçinde hangi bileşenlerin bulunduğunu gösterir.
Örneğin:
- uygulama framework'ü,
- dış kütüphaneler,
- tek tek paketlerin sürümleri,
- açık kaynak bileşenler,
- dolaylı bağımlılıklar,
- dış sağlayıcılar tarafından sunulan öğeler.
Bunun sayesinde belirli bir kütüphanede bir güvenlik açığı ortaya çıktığında, hangi sistemlerin onu kullandığı daha hızlı kontrol edilebilir.
NIST ayrıca provenance, yani yazılım öğelerinin kökeninin izlenebilmesi konusuna da dikkat çeker.
Ve işte yapay zeka tam burada yeni bir karmaşıklık katmanı ekler.
Çünkü mevcut zincire kodun ortaya çıkmasının bir yöntemi daha eklenir.
Tipik bir iş sistemini hayal et
Kodun %40'ını ekip yazdı.
%20'si yapay zeka desteğiyle oluşturuldu.
Diğer parçaları bir ajan üretti.
Birkaç kütüphane açık kaynaktan geliyor.
Bağımlılıkların bir kısmı framework tarafından eklendi.
Sistem, dış bir sağlayıcının API'sini kullanıyor.
Bileşenlerden biri, iki yıldır kimsenin güncellemediği bir paketten geliyor.
Peki bağımlılık dokümantasyonu?
Bir yerde depoda duruyor.
Ya da hiç yok.
Sistem çalışıyor...
Ve işte bu yüzden sorun görünmez. Ta ki bir şey olana kadar.
Sonra bir güvenlik açığı ortaya çıkıyor
Varsayalım ki kütüphanelerden birinde ciddi bir güvenlik açığı tespit edildi.
Soru şu: Sisteminin onu kullanıp kullanmadığını biliyor musun?
Düzenli bir bağımlılık kaydın varsa, yanıt dakikalar içinde alınabilir.
Yoksa, depoların elle taranması, programcılarla iletişim kurulması, ortamların, paket sürümlerinin ve dolaylı bağımlılıkların kontrol edilmesi gerekir.
Şimdi buna yapay zeka tarafından üretilen kodu da ekleyelim.
Hangi parçanın hangi araçla üretildiği biliniyor mu?
Code review yapıldı mı?
Kod testlerle kapsandı mı?
Bağımlılıklar kontrol edildi mi?
Birisi bileşenin lisansını doğruladı mı?
Belirli bir parçanın ortaya çıkmasına yol açan süreç yeniden oluşturulabilir mi?
Bunlar artık yalnızca programcıya yönelik sorular değil.
Bunlar, şirketin teknolojik risk yönetimi ile ilgili sorular.
En büyük sorun yapay zeka değil. Sorun süreç eksikliği
Bu makaleden kolayca yapay zekaya karşı bir uyarı çıkarmak mümkün olurdu.
Ancak bu fazla basit bir sonuç olurdu.
Yapay zeka, programlama ekibinin üretkenliğini çok güçlü biçimde artırabilir.
Sorun, şirket kod üretim hızını artırıp aynı anda bu kod üzerindeki kontrolü artırmadığında ortaya çıkar.
Bu, fabrikanın bir anda on kat daha fazla parça üretmesi ama kalite kontrolünü, malzeme kayıtlarını ve tedarikçi denetimini artırmaması gibi bir şeydir.
Bir yazılım evinde böyle bir kontrol sisteminin karşılıkları arasında şunlar vardır:
- code review
- otomatik testler
- bağımlılık taraması
- SBOM
- güvenlik açığı izleme
- açık kaynak lisans kontrolü
- güvenlik kontrolleriyle CI/CD
- depo yönetimi
- mimari dokümantasyon
- bileşenlerin kökenini izleme
- AI'nin geliştirmede kullanımına dair net kurallar
NIST ayrıca tedarik zinciri güvenliği mekanizmalarının doğrudan CI/CD pipeline'larına entegre edilebileceğine de işaret ediyor.
Bu, düşünme biçiminde önemli bir değişim.
Güvenlik, yalnızca yayından hemen önce yapılan bir kontrol olmamalı.
Yazılımın oluşum sürecinin bir parçası olmalı.
"Bu kodu kim yazdı?" artık doğru soru olmaktan çıkıyor
Geleneksel development dünyasında yazarını sormak mümkündü.
AI-assisted development dünyasında çok daha önemli sorular öne çıkıyor:
- Bu bileşen nereden geliyor?
- Hangi lisansa sahip?
- Bunu kim doğruladı?
- Hangi sürümü kullanıyoruz?
- Hangi bağımlılıklara sahip?
- Hâlâ bakımı yapılıyor mu?
- Güvenlik açıklarını biliyor muyuz?
- Değişiklik geçmişini yeniden oluşturabilir miyiz?
- AI'nin onun oluşumunda nerede yer aldığını biliyor muyuz?
Ve en önemlisi:
- Şirket tüm bunları kontrol altında tuttuğunu kanıtlayabiliyor mu?
Çünkü müşteri sonuçta "AI'dan kod" satın almıyor. Çalışan bir sistem satın alıyor. Ve bu sistemin sorumluluğu hâlâ onu teslim eden ve sürdüren kuruluşa ait.
Kod otomatik olabilir. Sorumluluk değil
Bu, muhtemelen AI'nin software house'lara getirdiği en önemli değişimlerden biri.
Programcı ortadan kaybolmuyor. Rolü değişiyor.
Giderek mesele yalnızca belirli sayıda kod satırı yazmak olmaktan çıkıyor. Çözümü tasarlamak, üretilen bileşenleri kontrol etmek, riski değerlendirmek, test etmek, entegrasyon, güvenlik ve tüm sistemin bakımını yapmak söz konusu oluyor.
Benzer şekilde şirket de kendini, programcılarının AI kullanıp kullanmadığını sormakla sınırlayamaz.
Nasıl kullandıklarını, hangi süreçte, hangi kontrollerle ve bunun yazılımın tüm yaşam döngüsünü nasıl etkilediğini bilmelidir.
Çünkü birkaç yıl sonra soru belki de şunu olmayacak: "Bu sistemi kim yazdı?"
ama: "Nelerden ve nasıl inşa edildiğini yeniden oluşturabiliyor musun?"
Eğer cevap "tam olarak değil" ise, sorun yeni bir AI aracının eksikliği değildir.
Sorun, software supply chain üzerinde kontrol eksikliğidir.
