Yazılım geliştirmede bazı şeyler sayılarla ölçülemez. Örneğin bir animasyonun 'doğru hissettirmesi' gibi. FPS gibi metrikler olsa da, 'bu bölge geçişi iyi hissettiriyor mu?' sorusunun assert karşılığı yoktur. İşte bu noktada devreye ikinci bir yapay zeka ajanı giriyor: birincisini yazılı bir rubriğe göre değerlendiren, salt okunur bir denetçi.
Bu yazı, 3 bölümlük serinin ikinci kısmı. İlk bölümde FPS gibi sayısal hedefler kovalayan bir döngü kurmuştum. Burada ise kaliteyi ölçmek için sayı olmayan bir yaklaşım kullanıyorum: bir ajan kod yazıyor, diğeri onu rubriğe göre puanlıyor. Denememde denetçi, yapıcıyı üç kez reddetti ve en ilginç hatayı kodda değil, test kanıtlarında buldu.
Çözdüğüm problem şu: tarayıcıda bölge değiştirirken (örneğin Tamilce'den Korece'ye) yüzlerce poster aynı anda değişiyor. Kötü yapılırsa grid boş kalıp sıçrıyor; iyi yapılırsa bir set diğerine soluyor, düzen korunuyor, yüklenme durumu gösteriliyor ve sayfa başına dönülüyor. 'İyi' öznel bir kavram, bu yüzden birim testi yapılamaz. Bunu rubrik olarak yazıp ikinci bir ajana uygulattım.
Sonuç ve Değerlendirme
Rubrik, yedi maddelik düz İngilizce kontrollerden oluşuyor. En önemli kural: 'Genel ONAY, her maddenin GEÇER olmasını gerektirir.' Bu dosyayı yalnızca insan değiştirebilir. Maddeler arasında çapraz solma, düzen kayması olmaması, görünür yüklenme durumu, posterlerin 2:3 oranını koruması ve geçiş sonrası sayfa başına dönülmesi gibi şeyler var. Karmaşık değil, sadece 'iyi'nin yazılı hali.
Uzmanların Görüşleri
Önemli karar: yapıcı ve denetçi iki ayrı Claude Code ajanı, farklı yetkilerle. Yapıcı kod yazabilir (Read, Edit, Write, Grep, Glob), denetçi salt okunur (Read, Grep, Glob). Her biri kendi bağlamında çalışıyor. Neden tek ajan her iki işi yapmıyor? Çünkü kod yazıp aynı kodu denetleyen ajan kendini onaylama eğiliminde. Denetçi, yapıcının mantığını veya özetini görmez; yalnızca kodu ve otomatik yakalanmış ekran görüntülerini (öncesi, sırası, sonrası) inceler.
Teknik Analiz
Gerçekte neler oldu? Denetçi yapıcıyı üç kez reddetti. Birinci turda yapıcı, gridin tamamını yüklenme iskeletiyle değiştirip 'sert kesmeyi ortadan kaldırdım' dedi. Denetçi ekran görüntülerine bakıp aynı fikirde olmadı: her posteri aynı iskelet kartla değiştirmek de bir sert kesmeydi. Karar: DEĞİŞİKLİK TALEP EDİLDİ. İkinci turda yapıcı gerçek bir çapraz solma ekledi, denetçi solmayı onayladı ama yüklenme durumunun hiç görünmediğini fark etti. Üçüncü turda yüklenme durumu eklendi ve altı madde geçti; yedinci madde ise 'ENGELLENDİ' olarak işaretlendi çünkü kanıt yetersizdi.
En ilginç hata kodda değildi. Özellik çalışıyordu, kod kaydırmayı sıfırlıyordu. Ancak ekran görüntüsü her zaman sayfanın en başından alındığı için kaydırma sıfırlaması görünmüyordu. Çözüm, uygulamada değil, yakalama betiğindeydi: geçiş yapmadan önce sayfayı biraz aşağı kaydırmak. Denetçi, yalnızca gördüğü kanıt kadar iyidir; iyi bir denetçi bile kör noktayı işaret eder ama göremez.
Detaylar ve Etkileri
Döngü dördüncü turda durdu, başarısızlıktan değil Claude kullanım limitine takıldığımdan. Son maddeleri elle kontrol edip birleştirdim. Bir dürüst detay: birleştirilen kodda birkaç lint hatası vardı çünkü döngü yalnızca UX rubriğini çalıştırmıştı. Bu yaklaşım, öznel kaliteyi otomatik denetlemenin gücünü ve sınırlarını gösteriyor. İyi bir rubrik ve bağımsız bir denetçi, insanın gözden kaçırabileceği hataları yakalayabiliyor.
Kaynak: dev.to
