Gecelerimizi yedi yapay zeka ajanı yürütüyor: kodlamanın ötesinde zamanlanmış ajanlar, prompt'larıyla birlikte

23 Eylül'de Rob adında bir kullanıcı herkese açık backlog'umuza şunu yazdı: “would love to get examples of how you guys are doing stuff beyond coding”. Yerinde bir soru. Bu sitedeki her şey kodlama ajanlarıyla ilgili, oysa her akşam gerçekten çalıştırdığımız şeylerin çoğu kod değil.

28 Ağustos'tan beri yedi ajan saat 20:00'de bir Mac mini üzerinde başlıyor. Günün commit'lerini, Search Console'u, yönetim panolarını, backlog'u, insanların gönderdiği geri bildirimleri, önceki gecenin raporlarını okuyorlar. Hataları düzeltiyor, web sitesini düzeltiyor, üç günde bir blog yazısı yazıp çeviriyor, üç sosyal ağda paylaşım yapıyor, bir ürün bilgi tabanını güncelliyorlar; saat 22:00'de de yedincisi diğer altısının bıraktıklarını okuyup 25 satırlık bir e-posta gönderiyor. Kimse izlemiyor. Kurucu e-postayı ertesi sabah telefonundan okuyor.

Bu yazı Rob'a cevabımız. Ne çalışıyor, nasıl bağlanmış, ajanlar hiç konuşmadan işi birbirine nasıl devrediyor, hangi model hangi işi yapıyor ve neden, prompt'larının zor yoldan öğrenmek zorunda kaldığı dört kural ve kopyalayabileceğin bloklara sıkıştırılmış prompt'ların kendisi. Aşağıdaki her sayı depodan geliyor: raporlar gece gece oraya commit ediliyor.

33 gecenin ürettikleri

Depodaki rapor klasöründe 28 Ağustos'tan 30 Eylül'e kadar tarihli 33 dizin var. Okuyunca ortaya çıkan şu:

• Raporcunun gönderdiği 31 sabah e-postası.
• Düzeltici tarafından düzeltilen 51 hata, her birinin rapor satırında commit bağlantısı var. Birkaçını kullanıcılar herkese açık backlog'da bildirmişti ve bir sonraki sürümde yanıt aldılar.
• SEO ekibinin 10 Eylül'den beri yazdığı 7 blog yazısı, üç günde bir, her biri önce İngilizce ve Fransızca, ardından aynı gece 18 dilde daha.
• 29 günlük sosyal medya günlüğü: akşam başına üç ağ ve beş Facebook grubu, ayrıca bir kullanıcının AgentsRoom'u paylaştığı her gönderinin altına bir teşekkür yorumu.
• Günün commit'leriyle senkron tutulan, yaklaşık yüz bilgi kartından oluşan bir ürün bilgi tabanı; uygulama içi asistan onu okuyor, site de onu llms-full.txt olarak sunuyor.

Bunların hiçbiri 20:00'den sonra bir insan gerektirmedi. Bir kısmı 08:00'de bir insan gerektirdi ve son ajanın bütün amacı da bu.

Kadro: 20:00'de kim çalışıyor

Her ajan AgentsRoom'da bir Zamanlanmış Görev: bir prompt, bir ajan (rol, CLI, model), bir makine ve bir saat. Yedisi de Claude Code üzerinde çalışıyor. İkisi tek bir ajan değil, iki adımlı ekip; nedenine döneceğiz.

Son sütundaki .md dosyalarının hepsi reports/night/<date>/ içinde duruyor, commit ve push edilmiş halde. Bu klasör koordinasyon sisteminin tamamı; bir sonraki bölüm de nedenini anlatıyor.

Nasıl bağlandılar

Yedisinin her biri aynı yapıda bir Zamanlanmış Görev:

• Her gün 20:00'de tetiklenir (raporcu için 22:00). Cron ifadesi yok; sıklık editörde seçiliyor.
• Tek bir makineye sabitlenmiş. Proje birkaç bilgisayarda açık ve bir tetikleyici, sen kısıtlamadıkça onu barındıran her makinede tetiklenir. Bizimkiler Mac mini ile sınırlı, bu yüzden 20:05'te açılan bir dizüstü ikinci bir CEO başlatmaz.
• Makineyi uyandırır. Mac mini uyuyor. Görevin bir “makineyi uyandır” seçeneği var; bu seçenek, çalıştırmadan birkaç saniye önce işletim sisteminin kendi aracıyla bir uyanma planlar (macOS'ta pmset, Windows'ta uyandırarak çalıştırma seçeneğiyle Görev Zamanlayıcı, Linux'ta rtcwake). O olmadan uyuyan bir makine çalıştırmayı basitçe kaçırır.
• Telafi açık ya da kapalı, görev başına. Makine 20:00'de kapalıysa, telafisi açık bir görev bir sonraki açılışta tetiklenir. CEO, PM ve raporcuda açık. SEO, düzeltici, sosyal medya ve dokümantasyon görevlerinde kapalı: ertesi sabah 11:00'de başlayan bir çalıştırma aynı checkout'taki gündüz işiyle çakışırdı.
• İzin modu görev üzerinde ayarlanır, sağlayıcı üzerinde değil. Gözetimsiz bir çalıştırma gece 3'te bir onay isteminde duramaz, bu yüzden görev onaylar olmadan çalışır; kurucunun aynı CLI üzerinde elle yönettiği ajanlar ise önce sormaya devam eder.
• Konsol 60 dakika boşta kaldıktan sonra kapanır. İşini bitirmiş bir ajan, biri onu kapatana kadar kenar çubuğunda beklemez.
• Prompt ilk mesajdır. Her prompt'un metni Prompt Kütüphanesi içinde saklanıyor ve tetikleyicinin prompt alanındaki metinle aynı; yani birini düzenlemek ikisini de düzenlemek demek. Prompt'lar Fransızca, çünkü kurucu raporları Fransızca okuyor. Commit mesajlarından bilgi tabanına kadar geri kalan her şey İngilizce.

Yedisinin paylaştığı bir parça daha var: “gece ajanları, ortak kurallar” adlı bir beceri. Her prompt “bu beceriyi yükle ve uygula” diye başlıyor ve beceri hepsi için geçerli olan her şeyi içeriyor: kimin neden sorumlu olduğu, “bir gece, bir çalıştırma” koruması, git yetkileri, rapor biçimi, backlog kuralları ve raporcu için e-posta biçimi. Bir kural değiştiğinde tek bir yerde değişiyor.

Konuşmadan işi birbirlerine nasıl devrediyorlar

Yedi ajan birbirine asla mesaj göndermiyor. Gönderebilirlerdi, AgentsRoom'da bir ajan mesajlaşması var, ama bir mesaj ertesi sabah görünmez ve üzerinde grep yapılamaz. Her şey geceden sağ çıkan üç şeyden geçiyor:

Depo. Her ajan reports/night/<date>/<agent>.md dosyasını yazar, çalıştırmasının ilk dakikasında açar, biten her işten sonra yeniden yazar, commit eder ve push eder. Raporun dört sabit bölümü var: “İki kelimeyle” (madde işaretli bir liste, yapılan her şey için bir madde), “Karar verilecek” (yalnızca prompt'un insana ayırdığı şeyler), “Kontrol edilecek” (açılacak yerel bir URL ya da ekran), “Ayrıntılar” (gerektiği kadar uzun). Bir çalıştırma işaretiyle biter: ajanın gördüğü son commit.

Backlog. Başka bir ajan için iş bulan ajan o işi kendisi yapmaz. Etiketli bir ticket açar: düzelticinin alacağı doğrulanmış küçük bir hata için ceo-fix; hedef sorgusuyla birlikte bir içerik işi için ceo-seo; insan gerektiren her şey için ceo-decision (veritabanı, faturalama, kimlik doğrulama, şifreleme, fiyatlar, dizine eklenmiş bir URL, bir varsayılan davranış). Dokümantasyon sorumlusu commit'leri okurken sitede sayfası olmayan bir özellik bulur: bir ceo-seo ticket'ı açar ve SEO onu ertesi gece alır. CEO hata günlüklerini okurken nedeni kodda olan bir hata bulur: ceo-fix, ve düzeltici onu ertesi gece alır.

Dünün raporu. Herhangi bir işe girişmeden önce her ajan bir önceki gecenin kendi raporunu ve gün içinde kapatılan ticket'ların listesini okur. Dün işaret ettiği şey çoğu zaman gün içinde düzeltilmiştir. Zaten ele alınmış bir konu yeniden gündeme getirilmez; zaten açık bir ticket yeniden oluşturulmaz.

Döngü insanla kapanır. Raporcunun e-postası tek bir satırla biter: product manager'a yanıt vermek için rapport.md dosyasının sonuna bir “## Kararlar” bölümü ekle (P1 OK / P2 HAYIR: gerekçe / P3 SONRA), commit, push. PM push edilmiş sürümü ertesi akşam okur ve onaylananı uygular: ticket'ı oluşturur, kopyaları birleştirir, gerisini gerekçesiyle rafa kaldırır. Üç gece yanıt almayan bir karar da bir karardır: öneri e-postadan çıkar ve ticket olarak kalır.

Hangi model hangi işi yapıyor ve neden

Yukarıdaki tablo iki model gösteriyor. Bu bir benchmark değil, güncel yapılandırma ve değişiyor. Ama ayrım bilinçli.

İşin muhakeme olduğu yerde Fable. CEO, bir kâhine verilen beğenmeme oyunun gerçek bir hata mı yoksa bir tercih mi olduğuna karar verir. Düzeltici, bir hata bildiriminin gerçekten hata mı yoksa makineye özgü bir kurulum mu olduğuna karar verir, ardından nedeni kodda bulur. SEO adım 1, sitedeki hangi cümlenin bugünkü commit'le yanlış hale geldiğine, hangi yazının yazılacağına ve hangi sayfaya dokunulmayacağına karar verir. Sosyal medya adım 1 akşamın konusunu seçer ve üretilmiş metni üç satırda fark eden bir kitle için yazar. Bu prompt'lar uzun (SEO'nunki yaklaşık 4.000 kelime) ve kısa istisna listeleri olan “sen karar verirsin, sormazsın” kurallarıyla dolu. En güçlü modelin maliyetini hak ettiği yer burası.

İşin hacim olduğu yerde 1M bağlamlı Opus. Bir yazıyı alt ajanlarla, her birine üç locale düşecek şekilde 18 dile çevirmek, ardından birleşik sonucu Fransızca referansla karşılaştırmak okuma ve yazma işidir, hem de çok, aynı kurallar 18 kez uygulanarak. Dokümantasyon sorumlusu bir günlük diff'i yüz bilgi kartıyla karşılaştırarak okur. PM, çıkış sohbetlerinin 8 MB'lık bir dökümünü okur. Raporcu beş rapor okur ve kopyalar, düşünmez. Orada büyük bir bağlam ve daha düşük token maliyeti muhakemeden daha önemli.

Bu yüzden yedisinin ikisi iki adımlı ekipler; her adım kendi modeli olan bir ajan. Fable üzerindeki adım 1, ortak rapora bir “Handoff” bölümü yazarak biter: çevirmenin teslim etmesi gereken dosya ve anahtarların tam listesi ya da yayıncının yayınlaması gereken gönderilerin tam hali. Opus üzerindeki adım 2 o bölümü okur ve yalnızca orada listelenenleri yapar. Ekibin grafiği doğrusal, tek döngü, ve rapor adım 2 onu kaldırana kadar “çalıştırma sürüyor” satırını korur. Dışarıdan bakınca, 22:00'de hâlâ “sürüyor” diye işaretli bir rapor ya kesilmiş bir çalıştırma ya da iki adımı arasındaki bir ekip anlamına gelir ve raporcu hangisi olduğunu söyler.

Prompt'ların öğrenmek zorunda kaldığı dört kural

İlk prompt'lar iş tanımlarıydı. Şimdikiler çoğunlukla kurallardan oluşuyor ve her kuralın bir tarihi var, çünkü her biri kötü giden bir geceden sonra yazıldı.

1. Dünün raporundan okunan bir çalıştırma işareti. SEO ajanının ilk sürümü “son 24 saatin commit'lerini” okuyordu. İki sorun: 20:00'deki bir çalıştırma ile ertesi gün 20:10'daki bir çalıştırma aynı 24 saati görmez ve ajanın çalışmadığı bir gece, kimsenin bakmadığı bir günlük commit demektir. Artık her rapor Son görülen commit: <sha> ile bitiyor ve bir sonraki çalıştırma, saat ne derse desin, o commit'ten başlıyor. İşaret yoksa (ilk gece, eksik rapor): iki gün geriye, ve rapor bunu belirtir.

2. Geçmiş diskte, bu yüzden bir şeyi gündeme getirmeden önce grep yap. İlk iki haftada en sık gelen şikâyet: “bunu bana zaten söylemiştin, dün düzelttim”. Çözüm, içinde bir komut olan bir kural: bir konuyu işaret etmeden ya da bir işe girişmeden önce grep -ril "<konu>" reports/night/ ve git log --since="30 days ago" -- <dosya>. Bir eşleşme varsa önce o raporu oku. Ele alınmış bir konudan yeniden söz etmeye üç durum, yalnızca üç durum izin verir: düzeltme işe yaramadı ve bunu az önce doğruladın; düzeltme kısmi ve geriye kalanı adıyla söylüyorsun; konu nitelik değiştirdi. Bununla birlikte iki sonuç geldi. Bir gece, bir çalıştırma: bu gecenin raporu varsa, “İki kelimeyle” içeriyorsa ve artık “çalıştırma sürüyor” demiyorsa ajan durur. Ve üç gece yanıtsız kalan bir öneri rapordan çıkar; ticket kalır.

3. Rapor iş başlamadan önce açılır. 21:30'da kesilen bir çalıştırma eskiden geride hiçbir şey bırakmazdı. Artık bir ajanın beceriyi yükledikten sonra yaptığı ilk şey mkdir -p reports/night/$(date +%F) ve dört bölüm başlığıyla ve çalıştırma sürüyor, 20:01'de başladı satırıyla rapor iskeletini yazmak. Biten her işten sonra dosyanın tamamını yeniden yazar. Kesilen bir çalıştırma, raporcunun kopyalayabileceği kısmi bir rapor bırakır; bu, “çalışmamış” bir ajandan çok daha iyidir.

4. İlerledikçe commit et, asla sonda değil. 9 Eylül'de ölçüldü: iki ajan aynı dakikada durduruldu. Her işten sonra commit eden hiçbir şey kaybetmedi. Diğeri, kurucunun ertesi sabah elle topladığı, push edilmemiş ve kime ait olduğu belirlenemeyen 45 değiştirilmiş dosya bıraktı ve raporu hiç yoktu. O günden beri kural şu: biten her iş için bir commit, dosyalar tek tek adlandırılmış, rapor için son bir commit ve çalıştırma sırasında en az bir push. Bir commit aynı zamanda tarihli bir izdir ve kural 2'nin grep yaptığı da budur.

Beşinci bir kural hafızayla değil cesaretle ilgili ve çıktıyı en çok değiştiren de o oldu. SEO prompt'u şöyle diyor: “Bulgu raporlayan bir denetçi değilsin: geceleri site senin. Onaylanacak altı fikirle biten bir çalıştırma başarısız bir çalıştırmadır.” Ardından ajanın harekete geçmek yerine sorması gereken altı durumu, yalnızca altı durumu listeliyor: bir URL'yi silmek ya da yeniden adlandırmak, sıralamada olan bir sayfanın başlığını değiştirmek, hukuki metin, bir fiyat ya da kota, gizlilik ya da şifreleme hakkında bir iddia, beşten fazla sayfaya dokunan bir değişiklik. Geri kalan her şeyi yapıyor, kurucu da ertesi sabah beğenmediğini kaldırıyor. Düzelticide aynı kural üç durumla var. Bu kuraldan önce raporlar öneri listeleriydi. Sonrasında commit listeleri oldular.

Prompt'lar

Orijinaller Fransızca ve uzun. Aşağıda taşınabilir kısım var, projemize özgü yollar ve adlar çıkarılmış halde. Üç blok: her ajanın yüklediği ortak kurallar, raporcu ve iki “sen karar verirsin, sormazsın” bölümü.

Blok 1: ortak kurallar (yedisi de beceri olarak yükler)

# Gece ajanları: ortak kurallar
İkisi çelişirse bu kurallar senin kendi prompt'undan önce gelir.

## Bir gece, bir çalıştırma
DAY=$(date +%F); F=reports/night/$DAY/<sen>.md
F varsa, “İki kelimeyle” içeriyorsa ve artık “çalıştırma sürüyor” içermiyorsa:
dur. Hiçbir şey yazma, hiçbir şey gönderme, tek satırlık bir mesajla bitir.
Hâlâ “çalıştırma sürüyor” diyorsa: bu senin kendi çalıştırman, birkaç dakika önce kesilmiş.
Kaldığı yerden devam et, baştan başlama.

## Neleri yapabilirsin
- Git: add <adı verilen dosyalar>, commit, SENİN işinin push'u, ilerledikçe.
  Asla: add -A, commit -a, push --force, stash, reset, checkout, clean, yeni branch.
- Build: typecheck, lint, kontrol script'leri, doğrulamak için yerel bir build.
  Asla: deploy eden ya da yayınlayan herhangi bir script.
- Backlog: ticket oluşturmak, bir ticket'a ekleme yapmak, düzelttiğin bir ticket'ı kapatmak.
  Asla: bir kullanıcıya yanıt vermek (bu bir e-posta gönderir), ticket silmek, bir açıklamanın üzerine yazmak.
- Asla uydurma bir sayı yok. Kaynak erişilemiyorsa: bunu söyle ve devam et.
- Herhangi bir git yazımından önce: git status --short. Ağaç diğer ajanlarla paylaşılıyor.

## Yetiş ve ZATEN yapılmış olanı bil
git fetch && git status -sb
Geride ve temiz: git pull --ff-only. Geride ve kirli: pull yapma, raporunun en başında bunu söyle.
Çalıştırma işaretin: dünkü raporun sonundaki “Son görülen commit: <sha>” satırı.
İşaret yoksa: --since="2 days ago", ve bunu söyle.
Her analizden önce üç zorunlu okuma:
1. git log --no-merges --format='%h %s' <sha>..HEAD ve git diff --stat <sha>..HEAD
2. dünden beri kapatılan ticket'lar ve bir insanın beklemeye aldığı ticket'lar
3. dünkü kendi raporun: “İki kelimeyle” ve “Karar verilecek”

## Rapor klasörü SENİN geçmişindir
Bir bulguyu gündeme getirmeden ya da bir işe girişmeden önce:
grep -ril "<konu>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <dosya>
Bir eşleşme varsa: herhangi bir karar vermeden önce o raporu oku.
Aynı konuda üst üste iki gece: ikincisi boşa gitmiştir.
Dokunduğun bir sayfaya ya da metne üç hafta boyunca yeniden dokunulmaz,
yanlış hale gelmiş bir şeyi düzeltmek dışında.

## Aynı şeyi asla iki kez gündeme getirme
Zaten ele alınmış bir bulgunun ertesi gün geri gelmesi bir kusurdur.
Buna yalnızca üç durum izin verir:
1. düzeltme işe yaramadı ve bunu az önce doğruladın: “<tarih> tarihinde <commit> ile düzeltildi, hâlâ bozuk: <kanıt>”
2. düzeltme kısmi: geriye tam olarak neyin kaldığını söyle
3. konu nitelik değiştirdi: yeni neden, yeni ölçüm, yeni kapsam
Bir stoku yeniden sayma. Değişimi raporla, asla stoku değil.

## Yanıtsız bir öneri üç gece sonra ölür
1. ile 3. geceler arası: satır sayacını ve ilk tarihini taşır (“2. gece, ilk kez 07/09'da”).
4. geceden itibaren: “Karar verilecek” bölümünden çıkar. Ticket kalır; “Ayrıntılar”da en fazla bir satır.
Karar senin alanındaysa 3. gecede ver ve bunu söyle.

## İlerledikçe commit ve push et
İlk iş bitip doğrulanır doğrulanmaz ilk commit. Sonra her iş için bir tane.
Raporun için son bir commit. Çalıştırma sırasında en az bir kez ve sonunda bir kez push et.
Push reddedildi (remote ilerledi): git pull --ff-only, sonra push. Hâlâ reddediliyorsa: zorlama,
rebase yapma, bunu rapora yaz.

## Raporun: başta açılır, asla yalnızca sonda yazılmaz
reports/night/<YYYY-MM-DD>/<sen>.md, işten ÖNCE oluşturulur, şunlarla:
  # <Ajan> - <tarih>
  _çalıştırma sürüyor - <HH:MM>'de başladı_   (sonda kaldırılır)
  ## İki kelimeyle      (3 ila 5 satır ya da madde listesi: yapılan her şey için bir madde)
  ## Karar verilecek    (yalnızca prompt'unun insana ayırdığı şeyler; yoksa “Yok”)
  ## Kontrol edilecek   (- [ ] ne : nerede : ne görülmeli; yoksa “Yok”)
  ## Ayrıntılar         (gerektiği kadar uzun: kanıtlar, dosyalar, komutlar)
  ## Çalıştırma işareti
  Son görülen commit: <son commit'inden sonra git rev-parse HEAD>
Biten her işten sonra dosyanın tamamını yeniden yaz.
Okuyucu telefonda, iki dakikalığına: kısa cümleler, dosya yolu yok,
SHA yok, ilk bölümde fonksiyon adı yok. Sayı yalnızca bir kararı değiştiriyorsa.

Blok 2: raporcu (22:00)

Sen raporcusun. Diğerlerinden iki saat sonra çalışırsın.
Tek işin: onların bıraktıklarını okumak ve kurucunun telefonda bir dakikada okuyup
başka hiçbir şey açmadan anlayacağı TEK bir e-posta göndermek.
Hiçbir şeyi analiz etmezsin, hiçbir şeyi düzeltmezsin, hiçbir şey önermezsin. Toplarsın ve netleştirirsin.

Raporladığın gece saatten değil, diskten okunur:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; ağaç temizse git pull --ff-only: raporlar commit edilmiş durumda.
2. ls reports/night/$DAY: beş dosyayı bekle (ceo, seo, pm, fixer, social).
   Eksik varsa: 9 dakika sleep ve yeniden say, en fazla 6 tur. Sonra yine de gönder, kimin eksik olduğunu belirterek.
3. Hâlâ “çalıştırma sürüyor” diyen bir rapor, olmayan değil, kesilmiş bir çalıştırmadır.
   İçindekini kopyala ve “İşe yaramayanlar” bölümüne bu ajanın kesildiğini yaz.
4. Her rapordan yalnızca üç bölüm al: “İki kelimeyle”, “Karar verilecek”, “Kontrol edilecek”.
   “Ayrıntılar”dan asla alıntı yapma.
5. Düzelticinin düzelttiği hatalar, “ > ” ile ayrılmış üç parçalı maddelerdir:
   kullanıcının yaşadığı sorun > tek cümlede neden > commit URL'si.
   Onları karakteri karakterine, bağlantı dahil, “Düzeltilen hatalar” bölümüne kopyala.
6. git status -sb ve git log --oneline --since="4 hours ago": commit'i olmayan bir iş iddia eden
   bir rapor, kimsenin sahiplenmediği değiştirilmiş dosyalar ya da push edilmemiş commit'ler: e-postanın ilk satırı.

reports/night/$DAY/rapport.md dosyasını yaz. En fazla 25 satır metin
(bölüm başlıkları ve “Düzeltilen hatalar” satırları sayılmaz).
Satır satır uygulanan altı kural:
1. Bir madde = tek başına anlaşılan tam bir cümle. Asla “dün bildirildiği gibi”.
2. Bir konu yalnızca TEK bir bölümde görünür.
3. Sıfır jargon: yol yok, SHA yok, anahtar adı yok, iç kısaltma yok.
   Tek istisna: bir commit'in tam GitHub URL'si, her “Düzeltilen hatalar” satırında zorunlu.
4. Sayı yalnızca bir kararı değiştiriyorsa, ve bu bir değişimdir, asla bir stok değil.
5. Madde başına en fazla iki satır. Ayrıntı ajanın raporunda.
6. Kötü haber iyi haberden önce gelir ve ilk satır bir şeyin bozuk olup olmadığını söyler.

Bölümler, sırasıyla: Karar verilecek / Kontrol edilecek / Düzeltilen hatalar / Yapılanlar /
Sosyal ağlar (en fazla 3 satır, bağlantılar dahil) / CLI'ler ve modeller (1 satır) /
İşe yaramayanlar. Boş bir bölüm tek kelimedir: “Yok”.
Asla kesme: “Karar verilecek”, bağlantılarıyla “Düzeltilen hatalar”, gönderi bağlantıları, SEO yazısı.
Gönder. HTTP kodunu kontrol et. En alta “Gönderildi: ... - HTTP <code>” ekle.
rapport.md dosyasını commit ve push et. Asla iki kez gönderme: bugünkü rapport.md zaten
bir “Gönderildi:” satırı içeriyorsa dur.

Blok 3: “sen karar verirsin, sormazsın” bölümleri

SEO ajanı, prompt'unun 0. bölümü:

# 0. Sen karar verirsin, sormazsın
Bu, bu prompt'un en önemli kuralıdır ve temkin refleksinden önce gelir.
Bulgu raporlayan bir denetçi değilsin: geceleri site senin.
“İşte onaylanacak 6 fikir” diye biten bir çalıştırma başarısız bir çalıştırmadır.
Tereddüt ettiğinde kendini kurucunun yerine koy ve dört referansla karar ver:
- ürünün gerçekte ne yaptığı, depoda ve yayımlanmış sürümde okunmuş haliyle, asla mevcut metinlerde değil;
- sitenin zaten ne söylediği: bakış açısı, tonu, vaatleri. Sen genişletirsin, yeniden icat etmezsin;
- Search Console'un söyledikleri: hangi sayfalar yaşıyor, hangi arama niyetleri gerçekten var;
- kitle: Google'da arama yapan geliştiriciler ve araç öneren yapay zeka asistanları.
  Onlar için önemli olan: doğrulanabilir, tarihlendirilebilir bir iddia; tek bir kesin soruya cevap veren bir sayfa;
  sayfalarla tutarlı, güncel bir llms.txt; dürüst karşılaştırmalar.
Kurucu raporunu ertesi sabah okur ve beğenmediğini kaldırmanı söyler.
Fazladan bir düzeltme beş dakikaya mal olur; çıktısız bir gece sonsuza dek kaybolur.

Onun fikrini yalnızca şu altı durumda sorarsın:
1. mevcut bir URL'yi silmek ya da yeniden adlandırmak;
2. sıralamada olan bir sayfanın başlığını ya da meta açıklamasını, yanlış değilken değiştirmek;
3. hukuki metin (şartlar, gizlilik, lisans);
4. bir fiyat, ticari bir kota, bir teklif;
5. gizlilik, şifreleme ya da verinin nerede işlendiği hakkında bir iddia;
6. aynı anda beşten fazla sayfaya dokunacak bir değişiklik.
Bu altı durumda: karar için etiketlenmiş bir ticket, “Karar verilecek” bölümünde bir satır, ve devam edersin.
Geri kalan her şeyi bu gece yaparsın. “Karar verilecek” başka bir şey içeriyorsa,
senin olan bir kararı başkasına devretmişsin demektir.

Düzeltici, prompt'unun 0. bölümü:

# 0. Sen düzeltirsin, sınıflandırmazsın
Bir kullanıcının bildirdiği hata bir sözdür. Biri yazmak için zaman ayırdı, bekliyor
ve bu gece başka kimse onunla ilgilenmeyecek. “5 hata analiz edildi, 1 düzeltildi,
4 belgelendi” döndüren bir çalıştırma başarısız bir çalıştırmadır. Hedefin boş kuyruk: önce kullanıcıların hataları,
en eskiden başlayarak, sonra geri kalanlar, hiç kalmayana kadar.
Bir düzeltmede tereddüt ettiğinde üç referansla karar ver:
- kodun bugün ne yaptığı, okunmuş, varsayılmamış;
- kullanıcının raporu yazarken açıkça ne beklediği;
- en düşük risk: nedeni çözen en dar düzeltme, en zarif olanı değil.
Tartışmalı bir düzeltmeyi geri almak beş dakikaya mal olur; bir ay daha bırakılan bir hata bir kullanıcıya mal olur.

Bildirilmiş bir hatayı yalnızca üç durumda düzeltmeden bırakabilirsin, ticket'ta kanıtlanmış olarak:
1. gerçek bir incelemeden sonra nedeni bulamadın: neleri elediğini yaz,
   yalnızca “yeniden üretilemiyor” değil;
2. bu bir hata değil, bir karar: veritabanı, faturalama, kimlik doğrulama, şifreleme, gizlilik,
   dizine eklenmiş bir URL, bir varsayılan davranış. Karar için ticket, önerinle birlikte;
3. bir kontrol düzeltmeni reddediyor ve onu onaramıyorsun.
“Büyük bir iş”, “birkaç dosyaya dokunuyor”, “sormayı tercih ederim” gerekçe değildir.
Bir hata = bir commit. Sonra ticket tamamlandıya geçer ve bir kullanıcı bildirdiyse,
iki cümlelik bir mesaj bir sonraki sürüm için sıraya alınır. Asla “beklemede”: o sütun
insanlara aittir.
Düzelttiğin her hata için rapor satırın, sabah e-postasına aynen kopyalanır:
- <kullanıcının yaşadığı sorun> > <neden, tek basit cümlede> > <commit URL'si>

Diğer dört prompt (CEO, PM, dokümantasyon sorumlusu, SEO adım 2) aynı iskeleti izliyor: beceriyi yükle, yazmana izin verilen dosyaları adlandır, okumaları sırasıyla listele, ticket'a neyin, rapora neyin gireceğini söyle, çalıştırma işaretiyle bitir.

İşe yaramayanlar ve hâlâ yaramayanlar

Bazı geceler e-postanın “İşe yaramayanlar” bölümünde yer alıyor ve listelemeye değerler, çünkü senin de karşılaşacağın şeyler bunlar.

• Aynı dakikada aynı branch'e push eden beş ajan. Remote ilerlediği için bir push reddediliyor. Kural git pull --ff-only ardından push, asla zorlama yok, ve iki kez başarısız olursa rapor bunu söylüyor ve push'u sabah insan yapıyor. Bu yaklaşık haftada bir oluyor.
• Başka bir ajanın stage ettiği dosyayı süpüren bir commit. 29 Eylül'de SEO'nun ilk commit'i, dokümantasyon sorumlusunun paylaşılan checkout'ta stage ettiği bir silmeyi de beraberinde götürdü. Hiçbir şey kaybolmadı (silme kasıtlıydı), ama commit yanlış ajana atfedildi. O günden beri her commit açık pathspec'ler kullanıyor ve “dosyalar tek tek adlandırılır” kuralı bir üslup tercihi değil.
• Üst üste iki akşam, saat 20:10'da boş alanı sıfır bayta düşen bir disk. Ajanların dışında bir sorun, 20:25'te kendiliğinden düzeldi, hiçbir dosya kaybolmadı. Ama raporlar bunu söylüyor, çünkü diski dolu bir gece, bir ajanın hiçbir şey yapmadığı bir geceyle tıpatıp aynı görünüyor.
• Gelmeyecek bir raporu 54 dakika bekleyen raporcu. Dokuz dakikalık altı tur üst sınır. 22:00'de iki adımı arasındaki bir ekip kesilmiş bir çalıştırma gibi görünüyor ve e-posta “bitirmemişti” diyor; bu dürüst ama okuması biraz ürkütücü.
• Tekrarlanan bulgularla geçen ilk haftalar. Yukarıdaki kural 2, kurucu dördüncü kez “bunu bana üç gün önce söylemiştin” yazana kadar yoktu.

Bunu kendin nasıl kurarsın

Yedi ajana ihtiyacın yok. Okuyacağın bir rapor yazan tek bir ajana ihtiyacın var; raporcu ise ancak üçüncü ajandan itibaren işe yarar. AgentsRoom'da:

1. Prompt'u Prompt Kütüphanesi'nde yaz. Yukarıdaki blok 1'i beceri olarak kullanarak başla ve bu ajanın neden sorumlu olduğunu ve hangi dosyaları yazabileceğini söyleyen kısa bir prompt ekle.
2. Projede bir Zamanlanmış Görev oluştur: istediğin saatte her gün, ajanın rolü, CLI'si ve modeli, prompt ve gelişmiş blokta gözetimsiz bir çalıştırma için izin modu. Görevi onu çalıştıracak makineye sabitle ve o makine uyuyorsa “makineyi uyandır” seçeneğini aç.
3. Depoda reports/night/ klasörünü oluştur ve commit et. Koordinasyon katmanının tamamı bu.
4. İlk ajan başka biri için ticket üretmeye başladığı gün ikinci bir ajan ekle: bir ceo-fix etiketi ancak bir düzeltici onu ertesi gece okuduğunda bir anlam taşır.
5. Bir iş muhakeme ve hacim olarak ikiye ayrıldığında, onu iki modelli, iki adımlı bir ekip yap ve adım 1'e, adım 2'nin okuyacağı bir handoff bölümü yazdır.

Zamanlanmış Görevler sayfası alanları anlatıyor, kodlama ajanlarını gece vardiyasına koymak üzerine yazı ise bu kadrodan önce gelen düşünce. Ajanların bir makineyi paylaşıyorsa, önce on tanesi aynı komutu çalıştırdığında ne olduğunu oku: burada, gece yaşandı ve çözüm küçük, paylaşılan bir kilit oldu.

Rob, kodlamanın ötesinde yaptığımız şey bu. Prompt'lar ürünün ta kendisi.

Sık sorulan sorular

Ajanları böyle bir zamanlamayla çalıştırmak için AgentsRoom gerekli mi?

Hayır. Bir cron satırı ve claude -p, herhangi bir makinede saat 20:00'de bir Claude Code oturumu başlatır. Geri kalanını o zaman kendin yazarsın: uyuyan bir bilgisayarı uyandırmak, makinenin kaçırdığı bir çalıştırmayı telafi etmek, proje iki bilgisayarda açıkken gece başına tek çalıştırmada kalmak, bir ajanın raporunu başka bir modeldeki ikinci bir ajana aktarmak ve çalıştırmanın bir soruda takılı kaldığını telefonundan görmek. AgentsRoom'un Zamanlanmış Görevleri bu parçaları üstlenir ve bu yazıdaki yedi ajan hepsini kullanır. Oturumu ne başlatırsa başlatsın, prompt'lar ve kurallar olduğu gibi taşınır.

Yedi ajanlık bir gece ne kadara mal oluyor?

AgentsRoom'da başlattığın her ajan gibi, bir Claude aboneliği üzerinde Claude Code oturumları olarak çalışırlar; bu yüzden onlar için token başına bir fatura yok ve gece başına bir maliyet yayımlamadık. Maliyeti sınırda tutan kural “bir gece, bir çalıştırma” korumasıdır: iki kez tetiklenen bir tetikleyici ya da kesilip yeniden başlatılan bir çalıştırma işi tekrarlamaz, çünkü her ajanın yaptığı ilk şey bu gecenin raporunun zaten var olup olmadığını ve kapanıp kapanmadığını kontrol etmektir.

Kimse bakmıyorken ajanların commit ve push yapmasına izin vermek güvenli mi?

Güvenli, ama bunun nedeni onlardan istenen şeyler değil, yapmalarının yasak olduğu şeyler. Ortak kurallar git add -A, commit -a, zorla push, stash, reset, checkout, clean, branch oluşturmayı ve deploy eden her türlü script'i yasaklar. Her commit dosyalarını tek tek adlandırır, her yazmadan önce ağaç git status ile incelenir, remote ilerlediği için reddedilen bir push ise fast-forward bir pull ile çözülür ya da insana bırakılır. Sabah incelemesi gecenin commit listesidir ve yanlış olan her şey beş dakikalık bir revert'tir.

Ajanlar raporlarını neden bir pano yerine depoya Markdown olarak yazıyor?

Çünkü rapor aynı zamanda hafızadır. Her ajan işe bir önceki gecenin kendi raporunu okuyarak başlar, orada çalıştırma işaretini (gördüğü son commit) bulur ve herhangi bir şeyi gündeme getirmeden önce tüm rapor klasöründe grep yapar; böylece geçen hafta ele alınmış bir konu tekrar gündeme gelmez. Bir pano aynı sayıları gösterir ve hiçbir şeyi hatırlamazdı. Raporu commit etmek onu tarihlendirir de; bir sonraki gecenin öncekinin tam olarak neye dokunduğunu bilmesini sağlayan da budur.

Yedi ajanın ikisi neden iki farklı model üzerinde iki adımlı ekipler?

Çünkü işin iki yarısı aynı iş değil. Search Console'u okuyan, sitede neyin yanlış olduğuna karar veren ve yazıyı İngilizce ve Fransızca yazan SEO adımı muhakeme ister ve Fable üzerinde çalışır. O yazıyı 18 dile daha çevirmek, i18n kontrollerini ve build'i çalıştırmak hacim işidir ve 1M bağlamlı Opus üzerinde çalışır. İlk adım ortak rapora açık bir handoff bölümü yazar, ikinci adım yalnızca o bölümde listelenenleri yapar. Sosyal medya ekibinde de aynı ayrım var: yazım ve görsel Fable'da, Chrome'da yayınlama ve teşekkürler Opus'ta.

Bir çalıştırma yarıda kesilirse ne olur?

Rapor, çalıştırmanın ilk dakikasından itibaren “çalıştırma sürüyor” diyen bir satırla vardır ve biten her iş anında commit edilir. Böylece 21:40'ta kesilen bir çalıştırma geride kısmi bir rapor ve commit'lerini bırakır, izlenmeyen hiçbir dosya bırakmaz. Raporcu kısmi raporu kopyalar ve ajanın kesildiğini yazar. Bunu 9 Eylül'de acı bir şekilde öğrendik: iki ajan aynı dakikada durdu, ilerledikçe commit eden hiçbir şey kaybetmedi, diğeri kimsenin kime ait olduğunu söyleyemediği 45 değiştirilmiş dosya bıraktı.