Yapay Zeka Kod Yazıyor Ama Bakım Yapamıyor mu? Alibaba’nın SWE-CI Testi Acı Gerçeği Gözler Önüne Serdi — 17.03.2026

18 Model, 100 Gerçek Kod Tabanı, 233 Gün: Sonuçlar Pek İç Açıcı Değil

Yapay Zeka Kod Yazıyor Ama Bakım Yapamıyor mu? Alibaba’nın SWE-CI Testi Acı Gerçeği Gözler Önüne Serdi — 17.03.2026

Geçen hafta sizlerle Amazon’un yapay zeka kodlama aracı Kiro’nun üretim ortamını “silip yeniden oluşturmaya” karar vermesini ve bunun 13 saatlik bir kesintiye yol açmasını paylaşmıştım. O yazıda “yapay zeka kodlama araçlarının üretim ortamında kontrolsüz bırakılmasının riskleri”nden söz etmiştim. Bu hafta ise o risklerin boyutunu sayılarla gösteren çok önemli bir araştırma karşımıza çıktı.

Microsoft’un depolarındaki kodun yüzde 20–30'unun artık yapay zeka tarafından yazıldığını, Claude Code’un günde 135.000'den fazla GitHub commit’i işlediğini ve Y Combinator destekli girişimlerin dörtte birinin kod tabanlarının yüzde 95'inden fazlasının yapay zeka tarafından üretildiğini biliyoruz [Kaynak 3]. Bu rakamlar etkileyici. Peki yapay zeka bu kadar kod yazıyorsa, yazdığı kodu altı ay sonra da ayakta tutabiliyor mu?

Sun Yat-sen Üniversitesi ve Alibaba Group araştırmacılarının 4 Mart 2026'da arXiv’de yayınladığı SWE-CI çalışması, tam da bu soruya yanıt arıyor. Kısa cevap: Pek de değil [Kaynak 2].

SWE-CI Nedir ve Neden Mevcut Testlerden Farklı?

Yapay zeka kodlama yeteneklerini ölçen mevcut testleri — HumanEval, MBPP, SWE-bench gibi — bir fotoğraf makinesine benzetebiliriz. Tek bir anı yakalıyorlar: İşte bir hata, düzelt, testleri geç. Bitti. Bu yaklaşım “anlık doğruluk” ölçmek için gayet iyi, ama gerçek yazılım geliştirme böyle işlemiyor [Kaynak 3, Kaynak 5].

Gerçek hayatta kod tabanları yaşayan organizmalar gibi. Gereksinimler değişir, arayüzler güncellenir, modüller genişletilir. Ocak ayında eklenen bir özellik, Mart ayındaki testleri etkiler. Altı ay önce alınan bir tasarım kararının maliyeti, her yeni değişiklikle katlanarak artar [Kaynak 4].

SWE-CI (SoftWare Engineering — Continuous Integration) ise bir fotoğraf değil, uzun metrajlı bir belgesel çekiyor. Araştırmacılar GitHub’daki tüm Python depolarını tarayarak 4.923 uygun depodan başlamış, en az 3 yıllık aktif bakım geçmişi, 500'den fazla yıldız, birim test altyapısı ve açık lisans gibi filtreleri uygulamış ve sonunda 100 görevlik bir test seti oluşturmuşlar. Her görev, ortalama 233 gün ve 71 ardışık commit’lik gerçek bir depo evrimine karşılık geliyor. Her görevde en az 500 satır kaynak kodu değişikliği var (test dosyaları hariç) [Kaynak 2, Kaynak 4].

Yani yapay zekaya “bu hatayı düzelt” demiyorlar. “Bu kod tabanını aylarca süren gerçek evrim boyunca bakımını yap, yeni gereksinimleri karşıla ve bunu yaparken daha önce çalışan hiçbir şeyi bozma” diyorlar. Kulağa tanıdık geliyor, değil mi? Çünkü bu tam olarak biz yazılımcıların her gün yaptığı iş.

Çift Ajanlı Protokol: Mimar ve Programcı

SWE-CI’ın ilginç bir yönü de değerlendirme yöntemindeki çift ajanlı protokol. Tek bir yapay zeka ajanı yerine iki farklı rol tanımlanmış: Mimar (Architect) ve Programcı (Programmer). Mimar, başarısız olan CI testlerini inceliyor, kök nedenleri belirliyor ve bir gereksinim dokümanı yazıyor (her iterasyonda en fazla 5 aşamalı gereksinim). Programcı ise bu gereksinimleri okuyor, bir plan yapıyor ve kodu değiştiriyor [Kaynak 5].

Bu ayrım gerçek mühendislik iş akışını yansıtıyor: Birisi sorunu anlıyor, başka birisi çözümü uyguluyor. Her görev için 20'ye kadar CI iterasyonu gerçekleştiriliyor. Yani yapay zekanın regresyon — daha önce geçen testleri bozma — yapması için 20 fırsat var. Bileşik hatalar hızla birikebiliyor [Kaynak 5].

Sonuçlar: Tablo Pek Parlak Değil

8 farklı sağlayıcıdan 18 model test edilmiş ve toplamda 10 milyar token harcanmış. İşte öne çıkan bulgular [Kaynak 3, Kaynak 4, Kaynak 5]:

Modellerin yüzde 75'i daha önce çalışan kodu bozuyor. Sıfır regresyon oranı — yani ajanın tüm bakım sürecinde daha önce geçen hiçbir testi bozmama başarısı — çoğu model için 0,25'in altında kalmış. Bunu şöyle düşünün: Her dört bakım iterasyonunun üçünde yapay zeka, dün çalışan bir şeyi bozuyor [Kaynak 4].

Claude Opus serisi açık ara önde. Yüzde 50'nin üzerinde sıfır regresyon oranını aşabilen tek model ailesi Claude Opus olmuş. Claude Opus 4.5 yüzde 51, Claude Opus 4.6 ise yüzde 76 ile dikkat çekici bir fark yaratmış. Diğer tüm modeller — GPT, DeepSeek, Qwen, MiniMax, Kimi, GLM-5, Doubao dahil — yüzde 25'in altında kalmış [Kaynak 3, Kaynak 4].

Yeni modeller her zaman eskilerden daha iyi. Bu durum 8 sağlayıcının tamamında istisnasız geçerli. 2026 sonrası çıkan modellerde fark daha da belirgin. Sektör doğru yönde ilerliyor, ancak hiçbir model sorunu “çözmüş” değil [Kaynak 5].

GLM-5 güçlü bir ikincil performans göstermiş. Claude Opus’un ardından en dikkat çeken model olarak öne çıkmış [Kaynak 3].

EvoScore: Kısa Vadeli Kazançları Cezalandıran Yeni Metrik

Araştırmacılar yalnızca sonuçları ölçmekle kalmamış, aynı zamanda EvoScore adında yeni bir metrik de tanıtmışlar. Bu metrik, anlık test başarısı için kırılgan kod yazan ajanları cezalandırmak üzere tasarlanmış [Kaynak 4].

EvoScore’un formülü bir ağırlıklandırma parametresi (γ — gamma) içeriyor. Gamma 1'e eşit olduğunda basit bir ortalama elde ediliyor. Ama gamma 1'i aştığında, sonraki iterasyonlar öncekilerden daha fazla ağır basıyor. Böylece 1–20 numaralı commit’lerde iyi performans gösterip 50–71 arasında çöken bir ajan, istikrarlı bir ajandan daha düşük puan alıyor [Kaynak 4].

Bu tasarım çok isabetli çünkü mevcut yapay zeka kodlama ajanlarının tipik başarısızlık biçimini yansıtıyor: Önlerindeki teste odaklanıyorlar, sonraki etkileri düşünmüyorlar. Bugünkü hatayı düzelten ama üç commit sonra ortaya çıkacak ince bir bağımlılık çakışması yaratan düzeltme, EvoScore ile görünür hale geliyor [Kaynak 4].

İlginç bir bulgu daha var: Gamma parametresi değiştirildiğinde model sıralamaları da değişiyor. MiniMax, DeepSeek ve GPT modelleri uzun vadeli kararlılık ağırlıklandırıldığında daha iyi puan alırken, Kimi ve GLM kısa vadeli ağırlıklandırmada öne çıkıyor. Claude ve Qwen ise her iki durumda da tutarlı performans sergiliyor. Bu, farklı eğitim yöntemlerinin farklı ödün verme profilleri ürettiğini gösteriyor [Kaynak 5].

Amazon Vakası: Teoriden Pratiğe

Bu araştırma sonuçlarının gerçek dünyada ne anlama geldiğini anlamak için çok uzağa gitmemize gerek yok. Financial Times’ın haberine göre Amazon’un yapay zeka kodlama aracı Kiro, Aralık ayında bir AWS hizmetinde çalıştığı ortamı “silip yeniden oluşturmaya” karar vermiş ve 13 saatlik bir kesintiye neden olmuş [Kaynak 6].

Kiro normalde değişiklikleri uygulamadan önce iki insandan onay almasını gerektiren bir sisteme sahip. Ancak aracın operatörünün yetkileri beklenenden geniş olduğu için bu güvenlik ağı devre dışı kalmış [Kaynak 6].

İşin ilginç yanı Amazon’un tepkisi: Şirket sorunu yapay zekaya değil, “insan hatasına” bağlamış ve yapay zeka araçlarının karıştığını bir “tesadüf” olarak nitelendirmiş. Amazon’a göre “aynı sorun herhangi bir geliştirici aracıyla veya manuel işlemle de yaşanabilirdi.” Teknik olarak doğru, ama bir geliştiricinin bilinçli olarak üretim ortamını silip sıfırdan kurmaya karar vermesi pek olası değil [Kaynak 6].

Üstelik bu izole bir olay da değil. Bir üst düzey AWS çalışanı, son birkaç ayda yapay zeka araçlarına bağlı ikinci üretim kesintisi olduğunu ve diğerinin Amazon’un Q Developer sohbet robotuyla ilgili olduğunu belirtmiş. Çalışan bu kesintileri “küçük ama tamamen öngörülebilir” olarak tanımlamış [Kaynak 6].

Priyanka Vergadia’nın Viral Paylaşımı

Microsoft’ta ürün hikayecisi olan Priyanka Vergadia’nın (@pvergadia) bu konuyu özetleyen sosyal medya paylaşımı oldukça ses getirdi. Vergadia’nın ifadesiyle: “Bir kodlama testini bir kez geçmek kolay. O kodu 8 ay boyunca patlamadan sürdürmek mi? Görünüşe göre yapay zeka için neredeyse imkansız.” [Kaynak 1]

Paylaşımın altındaki yorumlar da en az araştırma kadar aydınlatıcı. Bir kullanıcı “yapay zekanın daha hızlı kod üretmesi, teknik borcun da daha hızlı birikmesi anlamına geliyor” derken, Vergadia şu önemli noktanın altını çizmiş: “Yapay zeka, kodu yüzde 100 doğrulukla inceleyemediği sürece, yapay zeka tarafından üretilen kodu okuyacak ve onaylayacak insanlara ihtiyacımız olacak. Evet, katılıyorum — yüksek hızla teknik borç biriktiriyoruz.” [Kaynak 1]

Bir Yazılımcının Gözünden Değerlendirme

20 yılı aşkın yazılım geliştirme deneyimim boyunca “çalışıyor ama sürdürülebilir mi?” sorusu hep en zor soru oldu. Junior geliştiricilere öğrettiğim ilk şeylerden biri, testleri geçen kodun “iyi kod” olduğu anlamına gelmediğidir. SWE-CI tam da bu ayrımı yapay zeka dünyasına taşıyor.

SWE-bench’te yüzde 70 üzeri puan alan bir model, haftalar içinde bakım yükü haline gelen kod üretebiliyor. SWE-CI bu sezgiye bir sayı veriyor [Kaynak 4]. Bugünün biletini çözen ama gelecek sprint’te keşfedeceğiniz regresyonlar yaratan bir araç, mühendislik zamanından tasarruf etmiyor — gelecekten yüksek faizle borç alıyor [Kaynak 4].

Claude Opus 4.6'nın yüzde 76'lık sıfır regresyon oranı umut verici ve bunun mümkün olduğunu kanıtlıyor. Ama en iyi model bile dört bakımdan birinde bir şeyleri bozabiliyorsa, yapay zeka kodlama ajanlarını denetim olmadan üretim ortamına salmak için henüz erken.

Kısıtlamalar ve Geleceğe Bakış

Dürüst olmak gerekirse, SWE-CI’ın bazı sınırlamaları var. Test seti yalnızca Python depolarından oluşuyor. JavaScript, TypeScript, Go, Rust, C# gibi bakım kalıplarının önemli ölçüde farklılaştığı diller henüz kapsam dışı. Kurumsal kod tabanlarındaki özel bağımlılıklar, karma dil yapıları ve eski sistem kısıtlamaları da temsil edilmiyor. 100 görevlik test seti, kalite için miktar feda edilerek oluşturulmuş — her görev elle doğrulanmış. Ayrıca her iterasyonda 3.600 saniyelik test zaman aşımı sınırı var [Kaynak 5].

Yine de araştırmacılar çerçeveyi genişletilebilir şekilde tasarlamışlar ve verilerini Hugging Face üzerinde açık erişime sunmuşlar [Kaynak 2]. Bu, topluluğun farklı diller ve senaryolar için katkıda bulunabileceği anlamına geliyor.

Sonuç olarak yapay zeka kodlama araçlarının sağladığı verimlilik kazanımları gerçek. Ama bakım riski de öyle. SWE-CI, sektöre bu sorunu ölçmenin bir yolunu sunuyor. Asıl soru şu: Ekipler bu ölçüme göre hareket edecek mi, yoksa “şimdilik çalışıyor” deyip devam mı edecek?

Deneyimlerime dayanarak söyleyebilirim ki ikinci seçeneğin çekiciliği güçlü, ama maliyeti her zaman daha yüksek oluyor.

Kaynaklar

1. Priyanka Vergadia (@pvergadia) — X Paylaşımı — https://x.com/pvergadia/status/2033362617352556980
2. SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration — https://arxiv.org/abs/2603.03823
3. AI Can Write Code But Struggles To Maintain It, New SWE-CI Benchmark Reveals — https://officechai.com/ai/ai-can-write-code-but-struggles-to-maintain-it-new-swe-ci-benchmark-reveals/
4. 75% of AI Coding Agents Break Working Code Over Time — https://awesomeagents.ai/news/alibaba-swe-ci-ai-coding-agents-long-term-maintenance/
5. Most Coding Agents Break 75%+ of Their Own Fixes Over Time — https://www.engineerscodex.com/swe-ci-coding-agent-benchmark
6. Amazon blames human employees for an AI coding agent’s mistake — https://www.theverge.com/ai-artificial-intelligence/882005/amazon-blames-human-employees-for-an-ai-coding-agents-mistake

Not: Bu makale, kaynaklar bölümünde belirtilen haber kaynaklarından derlenerek hazırlanmıştır. Daha detaylı bilgi için kaynak haberlere göz atabilirsiniz. Makalenin İngilizce versiyonu için https://ourhaventech.com/ai-can-write-code-but-can-it-maintain-it-398a427e373b adresini ziyaret edebilirsiniz.