Yapay Zeka Kod Yazmayı Ucuzlattı, Doğrulamayı Değil

💡 Özet: Ana Çıkarımlar

• Yapay zeka kod üretimini hızlandırır. Mimari kararlar, güvenlik ve hata senaryoları hâlâ doğrulanmalıdır.
• Yazarın açıklayamadığı kod, inceleyen kişiye ek iş çıkarır. Üretim hızı arttıkça bu iş bir kuyruğa dönüşebilir.
• Daha fazla kod, kalite ve bakım kolaylığı korunuyorsa kapasite artışını gösterebilir. Ekibin sistemi anlama kapasitesi de buna yetişmelidir.

Bugün bir geliştirici, küçük bir uygulamayla yanıma geldi. Kodun önemli bir kısmını yapay zekaya yazdırmış, bariz hataları bulmak için yine yapay zekaya inceletmişti. Canlıya çıkmadan önce son bir kez benim bakmamı istiyordu.

Bunu tembellik olarak görmüyorum. Onun hesabına göre pahalı iş bitmişti: Kod yazılmış, ilk kontrol yapılmıştı. Benden beklediği kısa bir son kontroldü.

Oysa onay verebilmem için uygulamanın hangi problemi çözdüğünü, hangi varsayımlara dayandığını ve hata durumlarında ne yapacağını anlamam gerekiyordu. “Son kontrol” dediğimiz iş, bazen mühendislik işinin neredeyse tamamını içeriyor.

Kodun arkasındaki kararlar hâlâ gerekli

Net bir problem tanımıyla çalışan deneyimli bir geliştirici, yapay zekayla çok daha hızlı ilerleyebilir. Eskiden bir hafta sürebilecek bir iş bazen iki günlük odaklı çalışmayla tamamlanabilir. Kendi işimde de bu hızdan yararlanıyorum.

Bu kazanımın bir kısmı, geliştiricinin sistemi zaten tanımasından gelir. Hangi mevcut çözümün kullanılacağını, hangi iş kuralının korunacağını ve canlı ortamın neyi kaldıracağını bilir. Yapay zeka bu kararları koda dönüştürmeyi hızlandırır.

Kararlar verilmeden üretilen kod da derlenebilir, testleri geçebilir ve düzenli görünebilir. Fakat onu onaylamadan önce şu sorulara cevap bulmak gerekir:

• Değişiklik doğru serviste mi? Mevcut bir çözümü yeniden mi kuruyor?
• İş kuralları korunuyor mu? Yetkilendirme, önbellek veya girdi doğrulama adımlarından biri atlanmış mı?
• Aynı istek tekrar geldiğinde, veri eskidiğinde ya da işlemin bir kısmı başarısız olduğunda ne oluyor?
• Canlıdaki davranışı kayıtlardan izleyebilir, hata halinde sistemi toparlayabilir veya değişikliği geri alabilir miyiz?

Kodun çalışması, bu cevapların hazır olduğu anlamına gelmiyor.

İncelemede yalnızca kodu okumuyoruz

Kod incelemesinde, değişikliğin arkasındaki düşünceyi de değerlendiririz. Neden bu yol seçildi? Hangi alternatiflerden vazgeçildi? Testler hangi davranışı doğruluyor, hangi riskler açıkta kalıyor?

Yazar bu kararları açıklayabiliyorsa inceleyen kişi eksik bağlamı tamamlar veya gözden kaçan bir hata senaryosunu bulur. Yazar açıklayamıyorsa inceleyen kişi önce veri akışlarını takip edip iş kurallarını eski koddan çıkarmak zorunda kalır. Kararların gerekçelerini yeniden kurduktan sonra değerlendirmeye başlayabilir.

Bu yüzden iki günde üretilen kodu anlayıp düzeltmek, doğru çözümü baştan yazmaktan daha uzun sürebilir. Deneyim riskleri görmeyi kolaylaştırır. Eksik düşünme işini ortadan kaldırmaz.

Bir kod inceleme isteğinde, yani pull request'te, yazardan her şeyi bilmesini beklemeyiz. Ama yaklaşımını, yaptığı testleri ve emin olmadığı yerleri anlatabilmelidir. Açıkça söylenen “buradan henüz emin değilim”, inceleyen kişinin dikkatini doğru yere yöneltir.

Daha önce anlama borcu derken, ürettiğimiz kodla gerçekten anladığımız kısım arasındaki açığı anlatmıştım. İnceleme sürecinde bu açık, onay verecek kişinin işine dönüşür. Borç kapanmadan el değiştirir ve planlanmamış bir ekip maliyeti yaratır.

Bunu deneyimli bir mühendis de yapabilir. Yeterince anlamadığı büyük bir yapay zeka çıktısını incelemeye göndermesi aynı yükü oluşturur. Bir kararı birlikte düşünüp nedenini öğretmek ekibin kapasitesini geliştirir. Üretilmiş kodu sessizce çözümleyip düzeltmek ise yazarın anlama açığını olduğu yerde bırakabilir.

Daha fazla kodu kim anlayacak?

Simon Willison'ın kavramsal bütünlük üzerine değerlendirmesi bu tartışmaya iki nüans katıyor. Kalite, testler ve bakım kolaylığı korunuyorsa daha fazla kod üretebilmek anlamlı bir kazanım olabilir. Fakat geliştiricinin üretebildiği kod miktarıyla anlayabildiği miktar aynı hızda artmaz. Bu, ölçülmüş bir ekip performansı sonucu değil, bir geliştiricinin deneyimine dayalı değerlendirmesi.

Kavramsal bütünlük, sistemin parçalarının tutarlı bir tasarıma uymasıdır. Örneğin aynı iş kuralının farklı yerlerde farklı biçimlerde uygulanması, her parça tek başına çalışsa bile sistemi anlamayı zorlaştırabilir. Yeni bir özellik eklemenin kolaylaşması, bu bütünlüğü korumak için ayırmamız gereken dikkati azaltmaz.

Bu nedenle satır sayısını tamamen anlamsız saymak da tek başına başarı ölçüsü yapmak da yetersizdir. Ekip, büyüyen kod tabanını açıklayabiliyor, doğrulayabiliyor ve bakımını yapabiliyorsa üretim artışı değerlidir. Bu koşulların sağlanıp sağlanmadığını ayrıca kontrol etmek gerekir.

Üretim hızlanırken inceleme kuyruğu büyüyebilir

Kod üretimini modeller, araçlar ve paralel görevlerle hızlandırmak mümkün. Sistemi tanıyan geliştiricilerin sayısını ve incelemeye ayırabilecekleri dikkati aynı hızda artırmak kolay değil. Daha çok iş tamamlanmış görünebilirken teslimat onay bekleyen kod yüzünden yavaşlayabilir.

2026'da yayımlanan, şirket destekli iki anket bu baskıya işaret ediyor. GitLab'in Harris Poll'a yaptırdığı ankete altı ülkeden 1.528 geliştirici ve teknoloji satın alma yetkilisi katıldı. Yüzde 85'i darboğazın kod yazmaktan inceleyip doğrulamaya kaydığını düşünüyor. Yüzde 79'u, bireysel üretkenlik artışına rağmen toplam teslim sürecinin aynı ölçüde hızlanmadığını söylüyor.

Sonar'ın 1.100'den fazla profesyonel geliştiriciyle yaptığı ankette yüzde 38, yapay zeka kodunu incelemenin insan yazımı koddan daha fazla çaba gerektirdiğini belirtiyor. Yalnızca yüzde 48, bu kodu commit etmeden önce her zaman doğruladığını söylüyor.

Bunlar katılımcıların beyanları. Anketler ekip performansını doğrudan ölçmüyor ve her şirkette asıl darboğazın kod incelemesi olduğunu göstermiyor. Bazı ekiplerde dağıtım ya da değişiklikleri toplu yayımlama biçimi daha belirleyici olabilir. Buradaki iddia daha sınırlı: Kod üretimi, ekibin inceleme kapasitesini ve paylaştığı sistem bilgisini aştığında doğrulanmayı bekleyen iş birikir.

İncelemeye hazır olmak ne gerektirir?

Yapay zeka, daha az deneyimli geliştiricilere de hızlı geri bildirim verebilir. Tanımadıkları kodu açıklayabilir, alternatifler önerebilir ve test hazırlamaya yardımcı olabilir. Ürettiği sonuç, yazarın doğrulama işinin başlangıcı olmalıdır.

Bunu yalnızca bireysel dikkate bırakmak yerine ekipçe birkaç beklentiyi açıkça belirlemek gerekir:

• Geniş bir değişiklikten önce sınırlar ve kısıtlar üzerinde anlaşın. Kısa bir tasarım konuşması, kararları sonradan koddan çıkarmaktan daha ucuzdur.
• İnceleme isteğinde önemli kararları, varsayımları, hata senaryolarını, testlerin gösterdiklerini ve belirsizlikleri anlatın.
• Değişikliği, yazarın ve inceleyenin bütünüyle anlayabileceği kadar küçük tutun.
• Yazar açıklayamıyorsa değişikliği geri gönderebilin. Bu, cezalandırma değil, hazırlık eksiğini görünür kılmaktır.

Benim pratik kuralım şu: Başka bir mühendise güvenle anlatamayacağınız yapay zeka kodunu incelemeye göndermeyin. Her satırı ezberlemek gerekmiyor. Kararları ve sonuçlarını sahiplenmek gerekiyor.

İnceleyen kişi, yazarın gözden kaçırdığını bulmasına yardım etmeli. Yazarın hiç anlamaya çalışmadığı çözümü baştan keşfetmek zorunda kalmamalı. Yapay zeka taslağı hazırlayabilir, hatta eleştirebilir. Ekibin karşısına geçip gerekçeleriyle “bunu canlıya almalıyız” deme sorumluluğu yazarda başlar.