LLM ile üretilen kodun kalitesi: 12 projede uygulamalı bir inceleme

Yapay zekâ ile üretilen kod hakkındaki tartışmaların çoğu, kodun çalışıp çalışmadığına odaklanır. Bu yanlış bir sorudur. Canlı sistemler açısından asıl soru; kodun güvenilir biçimde çalışıp çalışmadığı, onu yazmamış mühendislerin bakımını yapıp yapamayacağı ve sürekli teslimatı mümkün kılacak düzeyde düşük bir oranda hata üretip üretmediğidir.

Bu soruları kanaatlerle değil, verilerle yanıtlamayı amaçladık.

Metodoloji

Haziran 2025 ile Ocak 2026 arasında NOSOTA'nın yapay zekâ orkestrasyonlu geliştirme metodolojisiyle teslim edilmiş ve canlıya alınmış 12 projeyi analiz ettik. Her proje, orkestratör rolündeki bir ila üç kıdemli mühendis tarafından geliştirildi; üretim kodunun büyük bölümünü, yapılandırılmış görev tanımları ve insan incelemesi altında yapay zekâ ajanları yazdı.

Projeler kurumsal sunucu tarafı sistemlerini, platformlar arası mobil uygulamaları, web portallarını ve ML entegreli sistemleri kapsıyor. Toplamda 200.000'i aşkın kod satırını, 1.400'ü aşkın otomatik testi ve 350'yi aşkın REST API uç noktasını temsil ediyorlar. Her ölçüm Git geçmişine, CI/CD kayıtlarına ve hata takip sistemlerine kadar izlenebilir.

Üç boyutu ölçtük: test kapsamı (CI tarafından raporlanan satır ve dal kapsamı), hata yoğunluğu (dağıtım sonrasındaki ilk 90 günde bin kod satırı başına hata sayısı) ve bakım kolaylığı (kod tabanına yabancı bir mühendisin önemsiz olmayan bir değişikliği uygulaması için gereken süre).

Bulgu 1: Test kapsamı sektör ölçütlerinin üzerinde

12 projede medyan satır kapsamı %78 oldu; üç proje %85'i aştı. Daha katı bir ölçüt olan dal kapsamı ortalama %64'e ulaştı. Karşılaştırma için: Sektör anketleri, kurumsal kod tabanlarında ortalama satır kapsamının tutarlı biçimde %40 ile %60 arasında olduğunu gösteriyor.

Açıklama yapısaldır, kahramanlıkla ilgisi yoktur. Yapay zekâ ajanları, kapsamı doğru belirlenmiş bir görev tanımı aldıklarında testleri standart çıktılarının bir parçası olarak üretir. Ajan testi uygulamayla birlikte ürettiğinde test yazmanın maliyeti sıfıra yaklaşır. Geleneksel iş akışlarında pahalı olan kapsamlı test takımları, yapay zekâ orkestrasyonlu geliştirmenin varsayılan çıktısı hâline gelir.

Belirleyici etken, görev tanımının kalitesidir. Orkestratörün her ajan görev tanımında açık kabul kriterleri belirttiği projeler, test gereksinimlerinin örtük bırakıldığı projelere göre 15–20 yüzde puan daha yüksek kapsama ulaştı.

Bulgu 2: Hata yoğunluğu daha düşük, ancak bunun nedeni inceleme disiplini

12 projenin tamamında medyan hata yoğunluğu, ilk 90 günde bin kod satırı başına 0,8 hata oldu. Olgun ekipler için sektör ölçütü genellikle KLOC başına 1–5 hatadır. İki projede ölçüm döneminde canlı ortamda hiç hata görülmedi.

Bu sonucun nedeni, yapay zekânın kusursuz kod üretmesi değil. Üretmiyor da. Verilerimize göre yapay zekâ ile üretilen kodun yaklaşık %12'si, birleştirme öncesindeki insan incelemesinde değişiklik gerektirdi. Düşük hata oranı inceleme sürecinden kaynaklanıyor: Yapay zekâ çıktısının her satırı, kod tabanına girmeden önce kıdemli bir mühendisin değerlendirmesinden geçiyor. Yapay zekânın üretim hızı ile insan incelemesinin titizliği bir araya gelince hem hızlı yazılan hem de özenle denetlenen kod ortaya çıkıyor.

Orkestratörün incelemeyi atladığı ya da aceleye getirdiği projelerde — Git meta verilerindeki daha kısa inceleme sürelerinden anlaşılabiliyor — hata oranları 3–4 kat daha yüksekti. Metodoloji, süreçteki insan inceleme görevini ciddiye aldığında işe yarar.

Bulgu 3: Dokümantasyon, kodun bakımını başkaları için de mümkün kılıyor

Bakım kolaylığı, müşterilerin en az sorduğu ama bedelini en uzun süre ödediği boyuttur. Bir sistemi geliştirmemiş bir mühendis onu hızla anlayabiliyor ve güvenle değiştirebiliyorsa o sistemin bakımı kolaydır.

Yapay zekâ orkestrasyonlu teslimatta dokümantasyon sonradan akla gelen bir iş değil, yöntemin doğal bir yan ürünüdür. Örneklemdeki her proje; yapay zekâ ajanlarına yol gösteren spesifikasyonlar, mimari karar kayıtları, API dokümantasyonu ve sözdizimini değil amacı açıklayan yorumlar içeren kodla birlikte teslim edildi. Yapay zekâ çıktısını hatalara karşı denetleyen inceleme, kodun kendini açıklayıp açıklamadığını da denetliyor.

Bunun iki pratik sonucu var. Birincisi, müşteri bir tedarikçiye bağımlı kalmaz: Sisteme ilişkin bilgi, onu geliştirenlerin zihninde değil, kod deposunda yer alır. İkincisi, iş bir ekipten diğerine — şirket içi mühendislere, başka bir yükleniciye ya da yeni işe alınanlara — çok kısa bir öğrenme süresiyle devredilebilir; çünkü yeni ekip, ilk ekiple aynı spesifikasyonlardan ve kararlardan yola çıkar.