# Uzun soluklu işler için harness

Saatlerce çalışan bir loop oturumlar arasında her şeyi unutur, bu yüzden hafızası dosyalarda durmalı. İlerleme kayıtları, ajanın yalnızca çevirebildiği bir özellik listesi, bir başlangıç rutini ve model değiştikçe her parçayı yeniden test etme alışkanlığı.

## Her oturum hafızasız başlar

Saatlerce çalışan bir loop aslında art arda gelen birçok oturum ve her biri bir öncekini hatırlamadan başlıyor. Justin Young'ın uzun soluklu ajanlar yazısı bu gerçekten yola çıkıyor. Sonraki oturumun bilmesi gereken her şey, okuyabileceği bir yerde durmak zorunda.

Bağlam mühendisliği rehberi aynı şeyi öbür taraftan söylüyor: yapılandırılmış not almak dış hafızadır. Addy Osmani'nin tarifi bunu bir hafıza deposu olarak içeriyor: yapılanı ve sıradakini kaydeden, diskte duran bir markdown dosyası ya da pano. Ralph'ın plan dosyası da aynı fikrin en yalın hâli.

Young'ın yazısı dört hata üzerine kurulu ve her çözüm birine denk geliyor: erken zafer ilanı, belgelenmemiş durum, erken "bitti" ve boşa giden kurulum.

## İlk oturum sahneyi hazırlar

Young işi bir başlatıcı (initializer) oturuma ve birçok kodlama oturumuna bölüyor. Başlatıcı tek seferlik kurulumu yapıyor.

- Projeyi ayağa kaldıran `init.sh` script'ini yazıyor, böylece sonraki oturumlar bunu çözmeye vakit harcamıyor.
- Bir ilerleme kaydı başlatıyor.
- İlk git commit'ini atıyor.
- Prompt'u, her özelliği başarısız işaretlenmiş bir JSON özellik listesine genişletiyor.

Sonraki her oturum tek bir özellik yapıyor. O özelliğin yalnızca `passes` alanını değiştirebiliyor. Young bu dosya için Markdown yerine JSON seçti, çünkü modeller JSON'u daha az eziyor. Ajanın yeniden yazabildiği bir özellik listesi, iş bitmiş görünene kadar sessizce küçülen bir listedir.

```json
{
  "feature": "User can reset a password by email",
  "steps": ["open reset page", "submit email", "follow link", "set new password"],
  "passes": false
}
```

**Question:** Özellik listesi neden her özellik başarısız işaretli başlıyor ve sonraki oturumlar neden yalnızca passes alanını değiştirebiliyor?

- Dosya kısa olsun diye
- Ajan erken zafer ilan edemesin ya da hedefi yeniden yazamasın, yalnızca bir özelliği geçti olarak çevirebilsin diye
- JSON daha fazla alan tutamadığı için
- Git kullanmamak için

**Answer:** Ajan erken zafer ilan edemesin ya da hedefi yeniden yazamasın, yalnızca bir özelliği geçti olarak çevirebilsin diye. Erken zafer adı konmuş bir hata. Ajanın biçimini değiştiremediği bir liste, iş ilerlerken hedefi sabit tutuyor.


## Başlangıç rutini

Her kodlama oturumu aynı kısa rutinle başlıyor.

```flow
İlerleme kaydını ve git log'u okur
Özellik listesini okur
init.sh çalıştırır
Temel bir uçtan uca kontrol yapar
Başarısız bir özellik seçer
```

Özellik seçmeden önceki son kontrol gerisini koruyor. Önceki oturum uygulamayı bozuk bıraktıysa yeni oturum, bozuğun üstüne inşa etmeden önce bunu öğreniyor. Young ayrıca tarayıcı otomasyonunun, kendi kurulumunda bir Puppeteer MCP'nin, kodu okuyarak kaçan hataları yakaladığını aktarıyor.

Oturum sonunda ajan açıklayıcı bir mesajla commit atıyor ve ilerleme kaydını güncelliyor, böylece sonraki temiz başlıyor.

## Derleyici koşusunun öğrettikleri

Nicholas Carlini'nin C derleyicisi farklı bir şekil kullandı: ortak tek bir git deposunda, ayrı Docker konteynerlerinde 16 ajan, hiç orkestratör yok. Koordinasyon dosyalar ve git'ti.

- **Kilit dosyaları.** Bir ajan, `current_tasks/` içine kilit dosyası yazarak görevi sahipleniyor. Aynı görevi deneyen ikinci ajanı git başka birini seçmeye zorluyor.
- **Küçücük test çıktısı.** Birkaç satırda tutun, ayrıntıları dosyalara loglayın. Bağlamı çıktıyla boğan bir koşu ajanı kör ediyor.
- **Zaman körlüğü.** Claude geçen süreyi yargılayamıyor, o da hızlı bir örnekleme modu ekledi ve ilerleme çıktısını seyrek tuttu.
- **CI.** Yeni özellikler eskileri bozmaya devam etti, bu yüzden testler ve CI harness'ın parçası oldu.

## Oyun harness'ının öğrettikleri

Prithvi Rajasekaran'ın retro oyun yapıcı harness'ı üç rol kullandı: tek cümleyi 16 özellikli, 10 sprintlik bir spec'e çeviren planlayıcı, bir üretici ve ayrı bir değerlendirici. Üretici ile değerlendirici, her sprint için "bitti"nin ne demek olduğu üzerinde dosyalar üzerinden anlaştı.

En faydalı kısım sonradan geldi. Sonnet 4.5 ile harness'ın bağlam sıfırlamalarına, yani taze bir ajan ve yapılandırılmış bir devre ihtiyacı vardı; yazının "context anxiety" dediği şey yüzünden. Opus 4.5 ile bu sıfırlamalar bırakıldı. Opus 4.6 ile sprint yapısı kaldırıldı, değerlendirici tek bir son geçişe taşındı, planlayıcı kaldı.

> **Her parça bir varsayım**
Yazarın çıkardığı ders: harness'ın her parçası, modelin neyi yapamadığına dair bir varsayım taşıyor. Varsayımların ömrü var. Her yeni model sürümünde her parçayı yeniden test edin, maliyetini çıkarmayanları atın.


> **Loop'u değil dosyaları tasarlayın**
Loop'a alabileceğiniz bir proje için hafızasının yaşayacağı dosyaları sıralayın: bir ilerleme kaydı, passes alanlı bir özellik listesi, projeyi başlatan bir script. Taze bir oturumun izleyeceği beş satırlık başlangıç rutinini yazın. Yeni bir oturum yalnızca bu dosyalardan devam edemiyorsa loop kendini tekrar eder.


**Question:** Yeni bir model çıktı. Uzun soluklu harness araştırması harness'ınızla ne yapmanızı öneriyor?

- Eskiden çalıştığı için olduğu gibi bırakın
- Hangi parçalara hâlâ ihtiyaç olduğunu yeniden test edin, çünkü her biri eski modelin yapamadığına dair bir varsayım taşıyor
- Garanti olsun diye daha fazla parça ekleyin
- Her durumda değerlendiriciyi kaldırın

**Answer:** Hangi parçalara hâlâ ihtiyaç olduğunu yeniden test edin, çünkü her biri eski modelin yapamadığına dair bir varsayım taşıyor. Oyun harness'ında bağlam sıfırlamaları ve sprint'ler bir model için gerekliydi, sonrakilerde bırakıldı. Her modelde yeniden test edin.