Yapay zekanın ürettiği kod için code review kontrol listesi ve merge kriterleri

Yapay zeka asistanları bir fonksiyonu saniyeler içinde yazıyor, ama yazılan kodun doğru, güvenli ve bakımı yapılabilir olup olmadığına karar vermek hâlâ insana düşüyor. Bu yazı, yapay zekanın ürettiği kodu merge etmeden önce kullanabileceğiniz pratik bir code review kontrol listesidir. Amaç kodu geri çevirmek değil, ekibin anlayıp sahiplenebileceği hale getirmektir.

Listenin arkasındaki sorunu knowledge debt yazısında anlattık: kod var, ama kimse neden öyle çalıştığını bilmiyor. Bu yazı o yazıyı tamamlar. Teşhis yerine, her pull request'te uygulayabileceğiniz somut kontrol adımlarını verir.

PR'ı küçült ve kodu açıklayabildiğini kanıtla

Yapay zeka tek bir istekte onlarca dosyayı değiştirebilir. Gözden geçirilemeyecek kadar büyük bir PR, pratikte gözden geçirilmemiş bir PR'dır. Önce değişikliğin boyutunu kontrol edin.

• Tek PR, tek amaç. Özellik, yeniden düzenleme ve bağımlılık güncellemesi aynı PR'da olmasın.
• Yeniden adlandırma ve biçimlendirme değişikliklerini mantık değişikliğinden ayırın. Reviewer asıl davranış farkını görebilmeli.
• İstemediğiniz kodu silin. Yapay zeka sık sık kullanılmayan yardımcı fonksiyonlar, fazladan soyutlamalar ve tekrar eden bloklar ekler.

Açıklama testi: PR'ı açan kişi kodu yapay zekaya sormadan bir meslektaşına anlatabilmelidir. Şu soruları cevaplayamıyorsa kod merge edilmez: Bu kod hangi girdide nasıl davranır? Neden bu yaklaşım seçildi, alternatif neydi? Şu satır silinirse ne bozulur? Kodu anlatamayan kişi, üretimde hata çıktığında onu düzeltemez.

Testi koddan değil gereksinimden türet

Yapay zeka çoğu zaman hem kodu hem testi yazar. Bu testler genellikle kodun yaptığını doğrular, gereksinimin istediğini değil. Aynı hatayı iki kez yazmış olursunuz. Testleri koddan değil gereksinimden türetin.

1. Gereksinimi kabul kriterlerine çevirin: "şu girdi verildiğinde şu sonuç dönmeli".
2. Test senaryolarını kodu okumadan, kabul kriterlerinden çıkarın.
3. Sınır durumlarını ekleyin: boş girdi, null, çok büyük değer, aynı anda gelen iki istek, yetkisiz kullanıcı.
4. Testin gerçekten başarısız olabildiğini kanıtlayın. Kodu kasıtlı bozun ve testin kırıldığını görün.

Yeşil testler tek başına yeterli değildir. Hiçbir şeyi doğrulamayan assertion'lar ve aşırı mock'lanmış testler yeşil görünür ama güven vermez. Her testin neyi ölçtüğünü sorun.

Bağımlılık, gizli anahtar ve güvenlik kontrolü

Yapay zeka kod önerirken paket de ekler. Her yeni bağımlılık, ekibin üstlendiği yeni bir risktir.

• Paket gerçekten var mı ve doğru paket mi? Yapay zeka olmayan ya da adı benzeyen paketler önerebilir. Paket adını resmi kaynaktan doğrulayın, yazım benzerliğiyle kötü amaçlı paket kurma riskini göz ardı etmeyin.
• Lisansı, bakım durumunu ve son sürüm tarihini kontrol edin. Küçük bir iş için ağır bir bağımlılık eklenmiş mi?
• Lock dosyası değişikliği PR'da görünüyor mu ve beklenenle uyuşuyor mu? Bilinen açıklar için bağımlılık tarayıcısını çalıştırın.
• Kodda, test dosyalarında veya örnek yapılandırmada API anahtarı, token ya da parola var mı? Prompt'a yapıştırdığınız gerçek değerler koda geçmiş olabilir.
• Gizli anahtar taraması (secret scanning) pre-commit ve CI aşamasında çalışsın. Sızdığından şüphelendiğiniz anahtarı silmek yetmez, döndürün (rotate). Git geçmişinde kalır.
• Kullanıcıdan gelen her veri doğrulanıyor mu? Yetki kontrolü sunucu tarafında mı yapılıyor? SQL ve komut enjeksiyonuna açık birleştirilmiş sorgu var mı?

Daha kapsamlı bir liste için vibe code production güvenlik kontrol listesi yazımıza bakabilirsiniz.

Hata yönetimi, loglama, performans ve veri bütünlüğü

Yapay zekanın ürettiği kod mutlu yolda iyi çalışır. Sorunlar hata yolunda, yük altında ve eşzamanlılıkta ortaya çıkar. Review sırasında bu dört alana ayrı ayrı bakın.

• Hata yönetimi: Hataları sessizce yutan boş catch blokları ve her şeye aynı cevabı veren genel hata mesajları kabul edilmez. Hata ya yönetilmeli ya yukarı iletilmeli. Dış servis çağrılarında timeout, sınırlı yeniden deneme ve net bir başarısızlık yolu bulunmalı.
• Loglama: Hatayı ayıklamaya yetecek bağlam (istek kimliği, işlem adı) loglanıyor mu? Parola, token ve kişisel veri loglara yazılmıyor olmalı.
• Performans: Döngü içinde veritabanı sorgusu (N+1), sayfalama olmayan listeler, indeksi olmayan filtreler ve gereksiz tekrar hesaplamalara bakın. Yerelde 10 kayıtla çalışan kod, üretimde milyonlarca kayıtla çalışacak.
• Veri bütünlüğü: Birden fazla yazma işlemi tek transaction içinde mi? Aynı istek iki kez gelirse çift kayıt oluşuyor mu (idempotency)? Migration geri alınabilir mi? Silme işlemi veriyi kalıcı olarak yok ediyor mu?

Mimari karar kaydı ve merge öncesi karar kriterleri

Yapay zeka sessizce mimari kararlar verir: yeni bir katman, farklı bir state yönetimi yaklaşımı, başka bir kütüphane. Bunları görünür kılmak için kısa bir mimari karar kaydı (ADR) tutun: bağlam, verilen karar, reddedilen alternatifler ve sonuçları. Birkaç cümle yeterlidir ve repoda kalıcı olarak durur. Altı ay sonra "bunu neden böyle yaptık" sorusunun cevabı orada olur ve yeni ekip üyeleri kararın gerekçesini birine sormadan öğrenebilir. Bu kayıt, yapay zekayla üretilen kodun en çok eksik kalan parçasını, yani gerekçeyi, kalıcı hale getirir.

Merge kararı için şu kriterleri kullanın:

1. PR tek amaçlı ve gözden geçirilebilir boyutta.
2. Yazan kişi kodu yapay zekaya sormadan anlatabiliyor.
3. Testler gereksinimden türetilmiş ve sınır durumlarını içeriyor.
4. Yeni bağımlılıklar doğrulanmış, kodda ve geçmişte gizli anahtar yok.
5. Hata yönetimi, loglama, performans ve veri bütünlüğü soruları cevaplanmış.
6. Mimariyi etkileyen karar kayıt altına alınmış.

Maddelerden biri karşılanmıyorsa üç seçenek vardır: düzelt, böl ya da reddet. "Sonra bakarız" diyerek merge etmek borcu üretime taşımaktır. Ödeme, kimlik doğrulama ve kişisel veri gibi yüksek riskli alanlarda ikinci bir insan reviewer zorunlu olsun.

Sıkça Sorulan Sorular

Yapay zekanın yazdığı kod için ayrı bir code review süreci gerekir mi? Ayrı süreç gerekmez, ama aynı süreç daha sıkı uygulanmalıdır. Kodu yazan kişi kodun mantığını kendisi kurmadığı için açıklama testi ve gereksinimden test türetme adımları ek önem kazanır.

Testler geçiyorsa kodu merge edebilir miyim? Hayır. Testlerin kendisi de yapay zeka tarafından yazıldıysa kodun yaptığını doğruluyor olabilir. Testin gereksinimden türetildiğinden ve kodu bozunca gerçekten kırıldığından emin olun.

Yapay zekayı code review için kullanabilir miyim? İlk geçiş olarak evet, bariz hataları ve eksik kontrolleri yakalamakta yardımcı olur. Ancak merge kararı sorumluluk taşıyan bir insana aittir.

Bir gizli anahtarı yanlışlıkla commit ettiysem ne yapmalıyım? Anahtarı hemen iptal edip yenisini üretin (rotate). Dosyadan silmek yetmez, çünkü anahtar git geçmişinde ve olası klonlarda kalır. Ardından sızıntının nasıl oluştuğunu inceleyip secret scanning ekleyin.

Yapay zeka ile üretilmiş bir kod tabanını üretime hazırlamak ya da ekibinizde bu review disiplinini kurmak istiyorsanız vibe-code-to-production hizmetimize göz atabilir, durumunuzu hızlı teklif formu ile iletebilirsiniz.