Kod Yazan Yapay Zeka Nasıl Çalışır, Nerede Kırılır

Kod yazan yapay zeka, doğal dilde verilen bir isteği kaynak koda çeviren ve ürettiği kodu derleyici, test ve çalışma zamanı çıktısına bakarak düzelten bir dil modeli sistemidir. Çekirdekteki model bir sonraki parçayı tahmin eder; aracı işe yarar kılan, tahminin etrafına kurulan döngüdür: dosyaya yaz, çalıştır, hata çıktısını oku, düzelt, tekrar çalıştır. 2021'de yayımlanan Codex makalesinde model, HumanEval setindeki problemlerin %28,8'ini tek denemede çözüyordu; problem başına 100 örnek üretilip bunlardan birinin doğru olması yeterli sayıldığında oran %70,2'ye çıkıyordu. Bu fark, tek seferde doğru kod beklemek yerine çok deneyip sonucu sınamanın neden işe yaradığını gösteriyor; bugünkü araçlar bu sınamayı derleyici ve testlerle yapıyor.

Kod üretimi neden düz metin üretiminden farklı

Serbest metinde yaklaşık doğru bir cümle işini görür; kodda tek karakterlik sapma programı durdurabilir. Python'un sözcüksel çözümleme belgesi girintinin dilin dilbilgisine dahil olduğunu, çözümleyicinin INDENT ve DEDENT token'larını bir yığın üzerinden ürettiğini anlatır: geri çekilen bir satırın girintisi önceki seviyelerden biriyle eşleşmezse program çalışmaz, IndentationError verir. Python dört boşluğu şart koşmaz; tutarlı olduğu sürece üç boşluklu girinti de geçerlidir, hata tutarsızlıktan doğar. TypeScript tarafında tsconfig belgesindeki strict bayrağı, strictNullChecks ve noImplicitAny gibi bir grup denetimi birden açar ve TypeScript 6.0'dan bu yana varsayılan olarak açıktır. strictNullChecks etkinken atlanan bir null kontrolü, kod çalışmadan önce derleyicide yakalanır.

Aynı katılık kod üretiminde işe yarıyor, çünkü doğruluk sorusunun bir kısmının cevabını insandan almak gerekmiyor: derleyici başarılı ya da başarısız döner, test takımı kaç testin geçtiğini sayıyla verir. Modelin kendi hatasını görüp düzeltmesini mümkün kılan, bedeli düşük olan bu geri bildirim kanalı. Kanalın gördüğü alan ise dar: sözdizimi denetimi anlam denetimi değildir. Yanlış KDV oranıyla hesap yapan bir fonksiyon da sorunsuz derlenir, hiçbir uyarı vermez ve yanlış faturayı keser.

Bağlam penceresi ile depo büyüklüğü arasındaki gerilim

Kaba bir hesap yapalım: 300.000 satırlık bir depo, satır başına ortalama 35 karakterle 10,5 milyon karakter eder. Token başına ortalama 3,5 karakter varsayarsak yaklaşık 3 milyon token çıkar. 200.000 token'lık bir bağlam penceresine bu deponun yaklaşık %7'si, 1 milyon token'lık bir pencereye üçte biri sığar. Bu ölçekte modele "projenin tamamını oku, sonra yaz" demek mümkün değil. Araçlar bu yüzden seçici çalışır: dosya adı ve sembol araması, grep benzeri düz metin taraması, vektör araması ve içe aktarma zincirini izleme ile deponun içinden görevle ilgili küçük bir kesit çıkarılır; model yalnızca o kesiti görür.

Kesiti kaçıran model, sorunun en can sıkıcı biçimini üretir: doğru ama gereksiz kod. Depoda yeniden deneme ve zaman aşımı mantığı yerleşmiş bir HttpClient sarmalayıcısı varken, model onu görmediği için sıfırdan ikinci bir istemci yazabilir. Kod derlenir, testler geçer, gözden geçiren kişi onaylar. Zamanla ekip, farklı zaman aşımı değerleri taşıyan iki ayrı ağ katmanıyla yaşamaya başlar. Depo büyüdükçe ve modelin göremediği kısım arttıkça bu risk de büyür.

Ajan döngüsü: yaz, çalıştır, hatayı oku, düzelt

Ajan testi çalıştırır, AssertionError satırını okur, ilgili dosyayı açar, bir koşulu değiştirir ve testi yeniden çalıştırır. Yaygın kodlama araçlarında bu akış araç kullanımı üzerine kurulu. Anthropic'in araç kullanımı belgelerinde tarif edilen çevrim şöyle işler: model bir araç çağrısı üretir, uygulama aracı çalıştırır ve sonucu bir sonraki istekte modele geri verir, model buna göre sonraki adımı seçer. Kod bağlamında araçlar dosya okuma, dosya yazma, kabuk komutu ve test çalıştırmadır. Döngü, testler geçene ya da adım bütçesi bitene kadar döner.

swebench.com üzerindeki Multilingual liderlik tablosu (dokuz programlama dilinden 300 görev) bu döngünün maliyet tarafını iyi gösteriyor. Şubat 2026 tarihli gönderimlerde, aynı ajan iskeletiyle (mini-SWE-agent) çalışan Gemini 3 Flash görev başına ortalama 52,5 model çağrısıyla görevlerin %72,7'sini, Claude Opus 4.6 ise 28,9 çağrıyla %72,0'ını çözüyor. Daha az adım daha ucuz demek değil: aynı tabloda görev başına maliyet, çok adım atan yapılandırmada yaklaşık 0,35 dolar, az adım atanda yaklaşık 0,66 dolar. Adım sayısı süreyi, çağrı başına fiyat ise faturayı belirler; ikisini ayrı ayrı ölçmek gerekir.

Döngü her iş için kârlı değil. Tek satırlık bir yapılandırma değişikliğinde ajan dosyayı bulmak, okumak, yazmak ve testi çalıştırmak için birkaç araç çağrısı yapar; aynı değişiklik insan elinde dosyayı açıp kaydetmekten ibarettir. Pratik bir ayrım çizgisi şu olabilir: birden fazla dosyaya dokunan ve en az bir test koşusu gerektiren işler ajana, daha küçük işler doğrudan insana.

Döngü, geri bildirim üreten bir yüzey olmadığında işlemez. Testi olmayan bir modülde model "düzelttim" der ama kanıt gösteremez. Ekrana hata basmayan mantık hataları (üretimde haftalar sonra fark edilen yuvarlama sapmaları, kuyruk mesajlarının iki kez işlenmesi) döngünün göremediği sınıftadır; derleyici de test takımı da sessiz kaldığı için ajan bunları hata saymaz ve düzeltmeye girişmez.

Kıyaslama sonuçları ne söylüyor, ne söylemiyor

SWE-bench, ölçüm tarafındaki ana referans noktalarından biri. Özgün makalede kıyaslama, 12 popüler Python deposundan derlenen 2.294 gerçek GitHub sorunundan oluşuyordu ve o dönemin en iyi modeli (Claude 2) sorunların yalnızca %1,96'sını çözüyordu. Projenin liderlik tablosunda aynı tam sette en yüksek sonuç bugün %52,6; bu setten seçilen 500 görevlik, insanlarca elenmiş Verified alt kümesinde ise en üst gönderimler %79,2'de. İki rakam farklı setlere ait olduğu için "kaç kat arttı" diye doğrudan karşılaştırılmamalı; yine de iki yılda alınan yolun büyük olduğu açık.

Aynı tablo sınırları da gösteriyor. Görsel içerik barındıran sorunlardan oluşan Multimodal setinde en iyi sonuç %36 civarında kalıyor. Daha önemlisi, Verified setinin kendisi tartışmalı hâle geldi: OpenAI Şubat 2026'da bu setin artık en gelişmiş modellerin kodlama becerisini ölçmediğini açıkladı. İki gerekçe gösterdi: modellerin sık çözemediği görevlerden incelenen alt kümenin en az %59,4'ünde testlerin doğru çözümleri de reddetmesi ve test edilen tüm sınır modellerin bazı görevlerin insan yazımı çözümünü birebir üretebilmesi, yani bu görevleri eğitim sırasında görmüş olması. OpenAI bu nedenle Verified skorlarını raporlamayı bıraktı ve yerine SWE-bench Pro'yu önerdi.

Kıyaslamadaki her sorun ayrıca kapalı uçludur: hata metni vardır, depo eldedir, doğruluğu ölçen test takımı hazırdır. Kurumsal bir iş ise çoğu zaman "ödeme sağlayıcının sözleşmesi değişti, iade akışını buna göre güncelleyin" cümlesiyle gelir; ortada ne hata metni vardır ne de başarıyı tanımlayan bir test. Liderlik tablosundaki skoru olduğu gibi kendi deponuza taşımak bu yüzden hatalı bir çıkarım olur.

Kod yazan yapay zeka nerede kırılıyor

Küçük bir ekibin yıllar içinde geliştirdiği, belgesi birkaç satırdan ibaret bir iç kütüphaneyi modele verin: eğitim verisinde sık geçen açık kaynak bir paketi rahatça kullanan model, burada var olmayan bir metot adı uydurabilir ve uydurduğu ada uygun bir çağrı zinciri kurabilir. Az belgelenmiş iç kütüphaneler, başarısızlığın ilk başlığı. Bu yazıda başarısızlıkları dört başlıkta topluyoruz; dördünün ortak paydası, modelin eğitim verisinde bulunmayan, yalnızca sizin kurumunuzda var olan bilgiye dayanmasıdır.

İkinci başlık iş kuralı bilgisi. İskontonun KDV'den önce mi sonra mı uygulandığı, iade süresinin 14 gün mü 30 gün mü olduğu kodda yazmaz; sözleşmede, mevzuatta ya da kurum hafızasında durur. Model, kural yerine yaygın kalıbı yazar ve yazdığı kalıp sizin sözleşmenizle uyuşmayabilir. Üçüncü başlık yan etkisi olan işlemler: deneme yanılma döngüsü geri alınabilir işlemlerde ucuzdur; şema göçü, toplu güncelleme, ödeme çağrısı ve e-posta gönderimi ise geri alınamaz, bu yüzden "çalıştır ve gör" mantığı bu işlemlerde doğrudan zarara döner.

Dördüncü başlık güvenlik. Model, örnek kodda gördüğü kalıbı kopyalayabilir; MITRE'nin CWE-798 olarak katalogladığı gömülü kimlik bilgisi kusuru bu yolla koda girebilir. API anahtarı kaynak dosyada sabit metne dönüşür, bir commit ile deponun geçmişine yerleşir ve fark edildiğinde yapılacak iş dosyayı düzeltmek değil, anahtarı iptal edip yenilemek olur.

İnsanın rolü kod yazmaktan şartname ve doğrulamaya kayıyor

Yazma maliyeti düşünce darboğaz yer değiştirir: yeni darboğaz, üretilen kodun doğru işi yapıp yapmadığını belirlemektir ve bu iş iki girdiye dayanır. Birincisi şartname: hangi girdide hangi çıktının beklendiği, hangi sınır değerlerin geçerli olduğu, hangi durumda hata fırlatılacağı. Kısa bir istem yerine yazılı kabul ölçütleri vermek, modelin tahmin etmek zorunda kaldığı kısmı küçültür. İkincisi doğrulama, yani testin kendisi; testi insanın yazması, modelin hem kodu hem de onu doğrulayan ölçütü aynı yanlış varsayımla üretmesini engeller.

Gözden geçirme tarafında da alışkanlık değişiyor. Büyük bir değişiklik seti küçük ve ayrı adımlar hâlinde geldiğinde okunabilir kalır; tek parça geldiğinde onay mekanik bir tıklamaya dönüşme eğilimindedir. Görevi şartname, ilk uygulama, test, düzeltme ve gözden geçirme turlarına bölmek bu yüzden işe yarar. Model kod satırlarının büyük bölümünü yazabilir; neyin doğru olduğu kararı insanda kalır.

Sıkça Sorulan Sorular

Kod yazan yapay zeka yazılımcının yerini alır mı?

Bugünkü ölçümler bu yönde bir sonuç vermiyor. Kıyaslamalardaki yüksek skorlar, hata metni ve test takımı hazır gelen kapalı uçlu sorunlardan geliyor ve en çok kullanılan setlerden biri olan SWE-bench Verified'ın güvenilirliği de sorgulanıyor. Gerçek işlerde şartname yazmak, iş kuralını bilmek ve geri alınamaz işlemleri denetlemek insanın sorumluluğunda kalıyor. Değişen, zamanın nereye harcandığı: satır yazmaya ayrılan pay azalırken şartname ve doğrulamaya ayrılan payın artması bekleniyor.

Büyük bir kod tabanında neden gereksiz kod üretiyor?

Çünkü model her istekte deponun yalnızca küçük bir kesitini görür; büyük bir depo milyonlarca token tutabilir ve geniş bağlam pencerelerine bile tamamı sığmaz. Kesitin dışında kalan mevcut yardımcı sınıfı fark etmeyen model, işlevsel olarak doğru ama projede zaten var olan kodun ikinci bir kopyasını yazar. Çözüm, modele doğru dosyaları gösteren arama katmanını güçlendirmek ve istemde ilgili dosya yollarını açıkça vermektir.

Üretilen kodu üretime almadan önce hangi denetimler şart?

Dört kapı öneriyoruz: derleyici ve tip denetimi (TypeScript'te strict açık), insan tarafından yazılmış birim testleri, gizli bilgi taraması (CWE-798 türü gömülü anahtarlar için) ve veritabanı şemasını ya da ödeme akışını değiştiren her değişiklikte insan onayı. Değişiklikleri küçük parçalar hâlinde ilerletmek, bu dört kapının işlemesini kolaylaştırır.

Son güncelleme: 15 Ekim 2026