# Kontrol edemeyeceğiniz loop'u başlatmayın

Loop, kontrolünün ölçtüğü şeyi optimize eder, bu yüzden zayıf kontrol kendinden emin yanlış iş üretir. Önce kontrolü kurun, yapanı ve kontrol edeni ayırın, kontrolcüyü kendi muhakemenize göre kalibre edin.

## Asıl prompt kontroldür

Loop, bir şey dur diyene kadar tekrar eder. O şey zayıfsa loop gürültüyle başarısız olmaz. Yanlış şeyde başarılı olur.

Nicholas Carlini paralel Claude'larla bir C derleyicisi yazarken nedenini tek cümleyle söyledi: doğrulayıcı neredeyse kusursuz olmalı, çünkü ajan kendisine verilen her şeyi çözer. Delikli bir test seti verirseniz delikleri doldurur, derleyiciyi değil.

Yani herhangi bir loop için ilk soru ne isteyeceğiniz değil. İşe yaradığını nasıl anlayacağınız. Cevabınız yoksa başlamayın.

## İyi bir kontrol neye benzer

Araştırma, en ucuzdan en güçlüye doğru birkaç tür gösteriyor.

- **Testler ya da bir skor.** Claude Code ekibinin Lighthouse skoru en az 90 örneği. Hızlı, ama testlerin kapsadığı kadar iyi.
- **Doğruluğu bilinen bir referans.** Derleyici koşusunda GCC referanstı. Ajanlar onunla karşılaştırdı, böylece çekirdek hatalarını tahmin etmek yerine paralel olarak ayırabildiler.
- **Gerçek bir uçtan uca çalıştırma.** Justin Young'ın uzun soluklu harness'ında tarayıcı otomasyonu, kodu okuyunca kaçan hataları yakaladı. Claude Code ekibinin tavsiyesi de aynı ruhta: Claude'a nasıl doğrulayacağını anlatan SKILL.md dosyaları yazın; uygulamayı çalıştırmak, kontrole tıklamak, konsolu okumak gibi.
- **Taze bağlamlı ayrı bir doğrulayıcı ajan.** Sonucu hiçbir programın yargılayamadığı durumlarda işe yarıyor.

Yolu değil sonucu değerlendirin. Eval yazısının örneği: ajanın hayal ettiğiniz adımları izleyip izlemediğine değil, rezervasyonun veritabanında olup olmadığına bakın.

**Question:** Derleyici projesinde yazar neden doğrulayıcının neredeyse kusursuz olması gerektiğini söyledi?

- Çünkü doğrulayıcılar pahalı
- Çünkü ajan kendisine verilen her şeyi çözer, kontroldeki boşluklar sonuçtaki boşluklara dönüşür
- Çünkü derleyicinin testi yoktu
- Çünkü GCC kullanılamadı

**Answer:** Çünkü ajan kendisine verilen her şeyi çözer, kontroldeki boşluklar sonuçtaki boşluklara dönüşür. Ajan kontrolü optimize eder. Kontrol bir şeyi kaçırırsa ajanın onu doğru yapmak için sebebi kalmaz.


## Yapan ve kontrol eden

Ajanlar kendi işlerini över. Uzun soluklu uygulama harness'ı yazısı, bağımsız bir değerlendiriciyi şüpheci olacak şekilde ayarlamanın, bir üreticiyi kendine eleştirel yapmaktan daha kolay olduğunu buldu. Bu yüzden iki iş iki ajana gidiyor: biri yapıyor, biri kontrol ediyor.

Addy Osmani aynı ayrımı ayrı bir doğrulayıcı alt ajanla öneriyor. Claude Code ekibi önemli bir ayrıntıyı ekliyor: ikinci ajanın bağlamı taze, yani yapanın varsayımlarına ikna edilmemiş.

```flow
Yapan ajan kodu değiştirir
Kontrol eden ajan sonucu çalıştırıp inceler
Kontrol eden, görüş değil kanıt raporlar
Loop sürer ya da kanıta göre durur
```

## Kontrolcünün de kontrolü gerekiyor

Kontrolcü bedava değil ve varsayılan olarak doğru da değil. Uygulama harness'ında, hazır hâlindeki değerlendirici kendi bulduğu hataları onayladı. Onu şüpheci yapmak, insan muhakemesine karşı birkaç tur ayar gerektirdi.

Kendinizinkini de aynı yolla kalibre edin. Zaten iyi ve kötü olduğunu bildiğiniz çıktıları alın, kontrolcüyü onlarda çalıştırın, sonuçları karşılaştırın. Sizin reddedeceğinizi geçiriyorsa, başıboş çalıştırmadan önce kontrolcüyü düzeltin.

Diğer yönde de dikkatli olun. Eval yazısı, çok denemede yüzde 0 başarı oranının genellikle zayıf ajanı değil bozuk görevi gösterdiğini, Opus 4.5'in de grader ve iskele hataları düzeltildikten sonra CORE-Bench'te yüzde 42'den yüzde 95'e çıktığını belirtiyor. Bozuk bir kontrol, kötü işi iyi gösterebildiği kadar iyi işi de kötü gösterebilir.

> **Bitti hâlâ bir iddia**
İyi bir kontrolcü olsa bile Osmani net: bitti diyen loop bir iddia ortaya koyuyor ve onu bir insan onaylıyor. Muhakeme isteyen özellik işlerinde loop'tan sessiz bir merge değil, bir taslak ve kanıt isteyin.


## Sonucu değil sistemi düzeltin

Bir loop hayal kırıklığı yarattığında Claude Code ekibi yalnızca o tek sonucu değil sistemi düzeltmeyi söylüyor. Loop kötü bir değişiklik üretmişse o değişikliği yamalamak bir sonraki koşuya hiçbir şey öğretmez. Hangi kontrolün bunu yakalayacağını sorun, o kontrolü ekleyin, loop'u yeniden çalıştırın.

Kod tabanını temiz tutmak da aynı şekilde yardım ediyor, çünkü temiz bir kod tabanını doğrulamak daha kolay.

> **Görevden önce kontrolü adlandırın**
Loop'a almak istediğiniz bir görev seçin. Başlamadan önce şu cümleyi yazılı olarak tamamlayın: "İşe yaradığını ___ ile anlarım ve yanlış bir cevap ___ yüzünden bunu geçemez." İkinci boşluk zorsa kontrolünüz fazla zayıf.


**Question:** Bir loop'un kontrolcüsü sizin reddedeceğiniz işleri onaylıyor. Doğru düzeltme nedir?

- Loop'u çalıştırın, bir insan sonra fark eder
- Başıboş çalıştırmadan önce kontrolcüyü kendi muhakemenize göre düzeltip kalibre edin
- Yapan için daha büyük bir modele geçin
- Kontrolcüyü kaldırıp yapana güvenin

**Answer:** Başıboş çalıştırmadan önce kontrolcüyü kendi muhakemenize göre düzeltip kalibre edin. Kalibre edilmemiş kontrolcü hataları onaylar. Kendi değerlendirdiğiniz örneklerle ayarlayın ve yapan ile kontrol edeni ayrı ajanlar olarak tutun.