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.
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ş.
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.
Bir loop'un kontrolcüsü sizin reddedeceğiniz işleri onaylıyor. Doğru düzeltme nedir?
- Building a C compiler with a team of parallel Claudes (Nicholas Carlini)
- Harness design for long-running application development (Prithvi Rajasekaran)
- Loop engineering: Getting started with loops (Delba de Oliveira, Michael Segner)
- Demystifying evals for AI agents (Grace, Hadfield, Olivares, De Jonghe)
- Effective harnesses for long-running agents (Justin Young)
Bölüm tamamlandı
Loop engineering kursunun 6 bölümünden 4. bölümü bitirdiniz.
Bir loop'un üç çıkışı olmalı: kanıt olarak yazılmış bir durma koşulu, kanıt hiç gelmezse sert bir sınır ve tekrarlayan başarısızlık için bir kural. Gerçek koşuların maliyet rakamları sınırların neden şart olduğunu gösteriyor.
Sonraki bölüm