Görünüm
Metin boyutu
Yazı tipi
Satır aralığı
4
Bölüm 4 · 3 dk

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.

Kendinizi deneyin

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

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ş.

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.

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.

Kendinizi deneyin

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

Devamını okuyun