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ıyla düzelten bir dil modeli sistemidir. Çekirdekteki model bir sonraki parçayı tahmin eder; aracı işe yarar kılan şey, 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 setinde tek denemede problemlerin %28,8'ini çözüyor, aynı problem için 100 örnek üretildiğinde oran %70,2'ye çıkıyordu. 41,4 puanlık bu fark, tek atışta doğru kod beklentisinin neden bırakıldığını gösteriyor.
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 derlemeyi durdurur. 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, sekme karakterinin ise soldan sağa 8'in katına tamamlandığını tarif eder. 4 boşluk yerine 3 boşluk yazan model çalışan bir program değil, bir IndentationError üretir. TypeScript tarafında tsconfig belgesindeki strict bayrağı, 2.3 sürümünden beri 9 ayrı denetimi birden açıyor; strictNullChecks etkinken atlanan tek bir null kontrolü kod çalışmadan önce derleyicide düşer.
Aynı katılık kod üretiminde işe yarıyor, çünkü doğruluk sorusunun cevabını insandan almak zorunda kalmıyorsunuz: derleyici 0 ya da 1 döner, test takımı "412 testin 408'i geçti" gibi ölçülebilir bir sayı verir. Modelin kendi hatasını görüp düzeltmesini mümkün kılan şey, bedeli sıfıra yakın 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
Orta ölçekli bir kurumsal depoyu 300.000 satır ve satır başına ortalama 35 karakter kabul edelim; 10,5 milyon karakter eder. Token başına ortalama 3,5 karakter saydığımızda yaklaşık 3 milyon token çıkar. 200.000 token'lık bir bağlam penceresine deponun ancak %6,7'si sığar, 1 milyon token'lık bir pencereye üçte biri. Modele "projenin tamamını oku, sonra yaz" demek bu ölçekte fiziksel olarak 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 3 milyon token'ın içinden 20-40 dosyalı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 üretiyor: doğru ama alakasız kod. Depoda iki yıldır duran, 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 80 satırlık ikinci bir istemci yazar. Kod derlenir, testler yeşil yanar, gözden geçiren kişi beş dakikada onaylar. Altı ay sonra ekip, farklı zaman aşımı değerleri taşıyan iki ayrı ağ katmanıyla yaşamaya başlar ve hangisinin hangi servise gittiğini kimse hatırlamaz. Kurduğumuz sistemlerdeki gözlemimiz şu yönde: tek bir servis 5.000 satırın altındayken model neredeyse hiç kopya üretmiyor, 50.000 satırı aşan depolarda mevcut yardımcıyı bulup kullanma oranı düşüyor.
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, tek 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, çalışma ortamı aracı işletir, sonucu yeni bir mesaj olarak konuşmaya geri koyar, 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 tablosunda, 300 örnekten oluşan sette bir ajan örnek başına ortalama 52,5 araç çağrısı harcayarak %72,7 çözüm oranına ulaşıyor; aynı tabloda başka bir yapılandırma 28,9 çağrı ile %72,0'ye çıkıyor. Neredeyse aynı sonuç 1,8 kat daha az adımda alınıyor ve fark doğrudan süreye, oradan da faturaya yansıyor. Tablo çağrı sayısını veriyor, geçen süreyi vermiyor; süre, araçların ne kadar hızlı koştuğuna göre her kurulumda değişir.
Döngü her iş için kârlı değil. Kendi kurduğumuz akışlarda gördüğümüz şu: tek satırlık bir yapılandırma değişikliği ajana verildiğinde dosyayı bulma, okuma, yazma ve testi çalıştırma adımlarıyla 8-12 araç çağrısına çıkıyor — aynı değişiklik insan elinde dosyayı açıp kaydetmekten ibaret. Bizim ayrım çizgimiz şu: birden fazla dosyaya dokunan ve en az bir test koşusu gerektiren işler ajana gider, altındaki işler gitmez.
Döngü, geri bildirim üreten bir yüzey olmadığı anda kapanmaz. Testi olmayan bir modülde model "düzelttim" der ve kanıt gösteremez. Ekrana hata basmayan mantık hataları — üretimde üç hafta sonra fark edilen yuvarlama sapmaları, kuyruk mesajlarının iki kez işlenmesi — döngünün göremediği sınıfa girer; derleyici de test takımı da sessiz kaldığı için ajan bunları hata saymaz ve düzeltmeye hiç girişmez.
Kıyaslama sonuçları ne söylüyor, ne söylemiyor
SWE-bench, ölçüm tarafındaki referans nokta. Özgün makalede kıyaslama, 12 popüler Python deposundan derlenen 2.294 gerçek GitHub sorunundan oluşuyor ve o dönemin en iyi modeli sorunların yalnızca %1,96'sını çözüyordu. Bugün aynı projenin liderlik tablosunda, 500 örneklik Verified setinde üst sıradaki gönderimler %79,2 seviyesinde. 1,96'dan 79,2'ye uzanan eğri 40 kata yakın bir sıçramaya karşılık geliyor.
Aynı tablo sınırları da gösteriyor. Multimodal setinde en iyi sonuç %35,98'de, Lite setinde %60,33'te kalıyor; görsel kanıt gerektiren ya da farklı biçimde derlenmiş sorunlarda oran yarı yarıya düşüyor. Daha önemlisi, kıyaslamadaki her sorun kapalı uçlu: hata metni var, deponun tamamı elde, doğruluğu ölçen test takımı hazır. Kurumsal bir işin gelme biçimi ise "ödeme sağlayıcının sözleşmesi değişti, iade akışını buna göre güncelleyin" cümlesidir. Ortada ne hata metni vardır ne de başarıyı tanımlayan bir test. %79,2'lik skoru olduğu gibi kendi deponuza taşımak, bu nedenle hatalı bir çıkarım olur.
Kod yazan yapay zeka nerede kırılıyor
Yedi kişilik bir ekibin dört yılda geliştirdiği, README'si 12 satır olan bir iç kütüphaneyi modele verin: eğitim verisinde on binlerce kez geçen açık kaynak bir paketi kusursuz kullanan model, burada var olmayan bir metot adı uydurur ve uydurduğu ada uygun bir çağrı zinciri kurar. Az belgelenmiş iç kütüphaneler, başarısızlığın ilk başlığı. Başarısızlık rastgele dağılmıyor, dört başlıkta toplanıyor; dördünün ortak paydası da modelin zayıf olduğu yerin eğitim verisinde bulunmayan, yalnızca sizin kurumunuzda var olan bilgi olması.
İkinci başlık iş kuralı bilgisi. İskontonun KDV'den önce mi sonra mı uygulandığı, iade penceresinin 14 gün mü 30 gün mü olduğu kodda yazmaz; sözleşmede, mevzuatta ya da beş yıllık kurum hafızasında durur. Model, kural yerine sektörde yaygın kalıbı yazar ve yazdığı kalıp sizin sözleşmenizle uyuşmaz. Üçü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, dolayısıyla "çalıştır ve gör" mantığı bu dört işlem sınıfında doğrudan zarara döner.
Dördüncü başlık güvenlik. Model, örnek kodda gördüğü kalıbı kopyalar; MITRE'nin CWE-798 olarak katalogladığı gömülü kimlik bilgisi kusuru tam olarak bu refleksle koda girer. API anahtarı kaynak dosyada sabit metne dönüşür, tek bir commit ile deponun geçmişine yerleşir ve fark edildiğinde yapılacak iş dosyayı düzeltmek değil, anahtarı baştan döndürmek olur.
İnsanın rolü kod yazmaktan şartname ve doğrulamaya kayıyor
Yazma maliyeti bu kadar 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ğı. Üç satırlık bir istem yerine 20 satırlık bir kabul ölçütü yazmak, düzeltme turlarını bizde gözle görülür biçimde azalttı. İ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. 400 satırlık bir değişiklik seti, 40 satırlık 10 ayrı adım hâlinde geldiğinde okunabilir kalıyor; tek parça geldiğinde onay mekanik bir tıklamaya dönüşüyor. Kendi işleyişimizde bir görevi 3-5 tur hâlinde ilerletiyoruz: şartname, ilk uygulama, test, düzeltme, gözden geçirme. Model kod satırlarının büyük bölümünü yazıyor; neyin doğru olduğu kararı hâlâ insanda.
Sıkça Sorulan Sorular
Kod yazan yapay zeka yazılımcının yerini alır mı?
Mevcut ölçümler bu yönde bir sonuç vermiyor. SWE-bench Verified setinde üst sıradaki sonuç %79,2 seviyesinde ve kalan %20,8, hata metni ile test takımı hazır gelen kapalı uçlu sorunlardan oluşuyor. Gerçek işlerde şartname, iş kuralı ve geri alınamaz işlemlerin denetimi insanda kalıyor. Satır yazmaya ayrılan pay düşerken şartname yazmaya ve doğrulamaya ayrılan pay artıyor.
Büyük bir kod tabanında neden alakasız kod üretiyor?
300.000 satırlık bir depo yaklaşık 3 milyon token tutar ve 200.000 token'lık bir bağlam penceresine bunun %6,7'si sığar. Model her istekte deponun küçük bir kesitini görür. Kesitin dışında kalan mevcut yardımcı sınıfı fark etmediği için 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?
En az dört kapı öneriyoruz: derleyici ve tip denetimi (TypeScript için strict altındaki 9 denetim 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ı. 40-60 satırlık parçalar hâlinde ilerlemek, bu dört kapının işlemesini kolaylaştırır.
