Yapay Zekâ Yazdığı Kodu Üretime Almadan Önce 9 Kontrol

Yapay zekâ yazdığı kod bugün çoğu ekipte günlük rutinin parçası. Asistan fonksiyonu üç saniyede yazıyor, kod ilk denemede çalışıyor, testler yeşil. Sorun tam da burada başlıyor: çalışan kod ile doğru kod aynı şey değil. Aşağıdaki dokuz kontrol, son bir yılda sahada gerçekten karşılaştığımız hata türlerinden çıkarıldı; hepsi birkaç dakikada uygulanabiliyor.

1. Kod, istenen problemi mi çözüyor?

Asistanlar isteği yorumlarken en yakın kalıba oturtur. "Kullanıcının son siparişini getir" dediğinizde çoğu zaman tarihe göre en yeni sipariş gelir. Oysa sizin işinizde "son sipariş" iptal edilmemiş, ödemesi tamamlanmış olanı ifade ediyor olabilir. Kod hatasız çalışır, sonuç yanlıştır ve bu yanlışlık ancak müşteri şikâyetiyle ortaya çıkar.

Kontrol basit: değişikliği okumadan önce, kodun ne yapması gerektiğini kendi cümlelerinizle yazın. Sonra koda bakın. İki cümle uyuşmuyorsa sorun koddadır, sizde değil.

2. Sınır durumları denendi mi?

Üretilen kod "mutlu yol" için neredeyse her zaman doğrudur. Boş liste, tek elemanlı liste, negatif sayı, çok uzun metin, null gelen ilişki — bunlar üretim ortamında ilk haftada gelir. Asistan bunları sormadıkça düşünmez.

// Asistanın ürettiği hâli
$ortalama = array_sum($puanlar) / count($puanlar);

// Boş dizide: Division by zero → 500
$ortalama = $puanlar ? array_sum($puanlar) / count($puanlar) : 0.0;

Bu satırın üretim ortamında patlaması için tek bir yeni kullanıcının henüz puan almamış olması yeterli.

3. Hata yolunda veri yarım kalıyor mu?

Üç tabloya yazan bir işlemde ikinci yazma başarısız olursa ne oluyor? Üretilen kodda transaction genellikle yoktur, çünkü istemediniz. Sipariş kaydı oluşur, stok düşer, ödeme kaydı oluşmaz; ertesi gün stok sayımı tutmaz. Veri bütünlüğünün nerede korunduğunu bilmek için transaction izolasyon seviyelerinin pratikte ne anlama geldiğine bakmakta fayda var.

4. Yetki kontrolü gerçekten var mı?

En sık ve en pahalı eksik bu. Asistan, kendisine verilen bağlamda yetki katmanını görmediyse onu yazmaz. Sonuç: kaydı id ile getiren bir uç, o kaydın isteği yapan kullanıcıya ait olup olmadığını sormaz. Bu, klasik IDOR açığıdır ve dışarıdan tek bir sayı değiştirerek sömürülür. Sahada en sık görülen açıklar listesinde neden hep üst sıralarda olduğu buradan anlaşılıyor.

5. Döngü içinde sorgu var mı?

Üretilen kod okunaklı olduğu için performans sorunları göze batmaz. Elli kullanıcının her biri için ayrı sorgu atan bir döngü gayet temiz görünür; 50 satırda fark edilmez, 5.000 satırda sayfa açılmaz. Değişikliği birleştirmeden önce sorgu sayacını açıp isteği bir kez çalıştırmak, bu sınıftaki hataların neredeyse tamamını yakalar. Konunun detayı için indeks mantığı ve yavaş sorgular yazısına bakabilirsiniz.

6. Bağımlılık gerçek mi?

Modeller zaman zaman var olmayan paket adı önerir; daha kötüsü, adı gerçek ama amacı farklı bir paketi çağırır. Bir de saldırganların bu davranışı bilerek o isimde zararlı paket yayınladığı durum var. Kurulum komutunu çalıştırmadan önce paketin deposuna, son yayın tarihine ve indirilme sayısına bakmak otuz saniye sürer.

7. Kopyalanmış lisanslı kod var mı?

Uzun ve alışılmadık biçimde "hazır" görünen blokları bir arama motorunda aratın. Nadiren de olsa, lisansı projenizle uyumsuz bir kaynaktan gelmiş olabilir. Kurumsal projelerde bu, sonradan çözülmesi çok pahalı bir konudur.

8. Yorum satırları kodla uyumlu mu?

Asistan kodu değiştirdiğinde üstündeki yorumu her zaman güncellemez. Yanlış yorum, yorumsuz koddan daha tehlikelidir: bir sonraki geliştirici koda değil yoruma güvenir. Değişen her bloğun yorumunu okuyun; artık doğru değilse silmek bile güncellemekten iyidir.

9. Kodu gönderen kişi anlatabiliyor mu?

Son ve en belirleyici kontrol teknik değil, sosyal. Ekip kuralı şu olsun: değişikliği açan kişi, sorulduğunda her satırın neden orada olduğunu anlatabilmeli. Anlatamıyorsa değişiklik beklemeye alınır. Bu tek kural, yukarıdaki sekiz maddenin çoğunu kendiliğinden devreye sokar — çünkü insan, savunmak zorunda olduğu kodu önce kendisi okur.

Asıl değişen ne?

Kod üretmek ucuzladı, kodun doğruluğunu güvence altına almak ucuzlamadı. Ekiplerin bir kısmı bu yüzden inceleme süresini kısaltmak yerine uzatıyor; makul olan da bu. Kod incelemesinde neyi nasıl eleştirmeli sorusunun cevabı da bu yüzden değişti: biçim tartışmasını araçlara bırakıp insan dikkatini niyet ve sınır durumlarına ayırmak, bugün her zamankinden değerli.

Sonuç

Yapay zekâ yazdığı kod, iyi bir stajyerin kodu gibi düşünülürse yerli yerine oturuyor: hızlı, istekli, çoğu zaman doğru, ama sorumluluğu üstlenmiyor. Sorumluluk hâlâ değişikliği gönderende. Yukarıdaki dokuz kontrolü şablona çevirin, ilk ay bulgularınızı sayın, işe yaramayan maddeleri atın. Kalanı, ekibinizin kendi listesi olur — ve asıl değerli olan da odur.

Konunun ekip pratikleri tarafını derinleştirmek isteyenler için: Martin Fowler — Yazılım mimarisi ve pratikler.