Döngü Mühendisliği - İstemden Döngüye

Bu makaleyi, sizin için işi yapacak kendi programlanabilir ajanınızı nasıl oluşturacağınıza ayırmaya karar verdim. Böylece her sabah bilgisayarınızı açıp ona tekrar tekrar komut vermek zorunda kalmazsınız.

Kendi kendine uyanacak, kendi başına görevler bulacak, sorunları kendi başına tespit edecek ve sonuçları incelemeniz için masanıza kaydedip sunacak.

Önsöz

Loop fikri birdenbire ortaya çıkmadı - Haziran 2026'daki tek bir hafta içinde, üç sektör uzmanı neredeyse aynı anda aynı düşünceyi dile getirdi: bu seviyeyi geliştirmeye başlamanın zamanı gelmişti.

Bir hafta sonra Andrew Ng, bu konuşmayı "Ürünleri 0'dan 1'e İnşa Etmek" bağlamına oturtarak daha kapsamlı bir resim sundu.

Bu makale, bu hikayeden başlıyor ve ardından sıfırdan minimal ama eksiksiz bir loop oluşturma sürecinde size adım adım rehberlik ediyor: 5 hamle, 6 parça, "hayır" diyen bir kapı ve bir insan kapısı - tamamı kendi makinenizde çalışan ve herhangi bir yazılım projesinde tekrar kullanılabilir.

Kaynak: HuaShu Turuncu Kitap, Loop Mühendisliği: Bana Ne Olduğunu Sormayı Bırakın (v260615, Haziran 2026)

Fitili Ateşleyen 3 Kişinin Olduğu Hafta

Haziran 2026: Birbiriyle koordinasyon halinde olmayan üç kişi, günler arayla neredeyse aynı şeyi söyledi.

Peter Steinberger, OpenClaw'un yaratıcısı, X'te 8,9 milyon görüntülenmeye ulaşan iki cümle yayınladı:

https://x.com/steipete/status/2063697162748260627

Tartışma aslında bu gönderiyle başladı. Bir manifesto ya da uzun bir makale değildi, sadece insanların sessizce zaten yapmakta olduğu bir şeyi adlandıran iki satırdı.

Boris Cherny: Artık Claude'a komut vermiyorum, çalışan loop'larım var. Claude'a komut veren ve ne yapacağını belirleyen onlar.

Addy Osmani: Loop mühendisliği, ajanı yönlendiren kişi olarak kendinizin yerine geçmektir. Bunu yapan sistemi siz tasarlarsınız.

Uygulama, isimden aylar önce geldi; herkes zaten loop'lar yazıyordu, ama henüz kimse buna bir isim vermemişti.

Bu nedenle loop'lar, AI ajanlarının yazılım oluşturmak için uzun vadede yinelemeli olarak çalışmasını sağlamanın temel bir parçası haline geldi.

Andrew Ng, üç loop'u zaman ölçeklerine göre içten dışa doğru sıraladı: en içteki loop en hızlı, en dıştaki loop ise en yavaş olandır. Ayrıca, en dıştaki loop'un girdisi, en içteki loop'un çıktısından gelir:

Loop

Kim çalıştırır

Döngü uzunluğu

Dış katmana ne çıktı verir

Ajan kodlama loop'u

ajanın kendisi

saniye - dakika

çalışan bir sürüm

Geliştirici geri bildirim loop'u

insan + ajan

onlarca dakika - saat

daha net bir ürün vizyonu ve şartname

Harici geri bildirim loop'u

kullanıcılar + ekip

saat - hafta

vizyonu geliştiren gerçek veri

Andrew Ng bize zamana göre haritayı verdi: farklı hızlarda çalışan üç loop. Addy Osmani ise soyutlamaya göre ikinci bir harita çizdi: komut -> bağlam -> koşum takımı -> loop.

Loop mühendisliği en üstte yer alır ve koşum takımının sahip olmadığı üç fiil ekler. Bir zamanlayıcıda çalışır, yardımcılar oluşturur ve kendini besler - bugünün çıktısı yarının girdisi olur. Bu sonuncusu, onu aynı görevin N kez çalıştırılmasından farklı olarak bir loop yapan şeydir.

En önemli sezgi: Aynı hata, her katmanda farklı bir maliyete sahiptir:

Katman

Neyi önemser

Temel soru

Prompt mühendisliği

bir prompt yaz

modele ne söyleneceği

Bağlam mühendisliği

pencerede ne yüklü

neyin çekileceği, özetleneceği, temizleneceği

Koşum takımı mühendisliği

tek bir çalıştırmayı donatmak banka

hangi araçlar, hangi eylemler, neyin bittiği sayılır

Loop mühendisliği

koşum takımının üzerinde zamanlama

tur üstüne tur kendi kendine nasıl çalıştırılır

Bir loop, tasarım gereği "dönüş sayısını" büyük yapan bir makinedir. Buradan itibaren alınan her karar - değerlendirici, insan kapısı, token sınırı, durum dosyası - "hatanın olması" ile "birinin onu görmesi" arasındaki mesafeyi kısaltmak için vardır.

Bir turun içinde ne olur:

"Loop" çoğu zaman "yerinde dönmek" olarak yanlış anlaşılır. Öyle değildir, her turun 5 somut hamlesi vardır. Bunlardan birini keserseniz loop ya çalışmaz - ya da hiçbir yere varamadan çalışır.

1. Doğrulama, "hayır" diyen harekettir.
2. Zamanlama, bu turu bir sonrakine besleyen harekettir.

İşte onu bir loop yapan kısım tam olarak budur.

Oluşturmak üzere olduğumuz projeyle eşleştirilmiş: küçük bir ekip için sabah triyaj loop'u:

Eylem

Ne yapar

TRİYAJ LOOP'UNDA

Keşif

bu turun ne yapması gerektiğini belirle

bir beceri CI / sorunlar / son commit'leri okur

Devir teslim

görevi dağıt ve izole et

her bulgu kendi çalışma ağacını alır

Doğrulama

"hayır" demesi için başka bir ajanı devreye sok

testleri ve becerileri yoklayan ikinci bir alt ajan incelemeci olarak

Kalıcılık

durumu konuşmanın dışına yaz

PR + Linear ticket + ./state/triage.md

Zamanlama

tur üstüne tur çalışmasına izin ver

GitHub Actions cron tetikleyicileri 06:00'da

Aşağıdaki 5 dersin her biri tam olarak bir hamleyi geliştirir.

Beş ders = Eksiksiz bir Loop.

Ve ilkiyle başlıyoruz: Keşif, çünkü Loop bugün ne yapmaya değer olduğuna karar veremiyorsa, ondan sonraki hiçbir şeyin önemi kalmaz.

Ders 1 Keşif: bir sabah-triyaj SKILL.md dosyası yazın

Beceriler, bir prompt duvarı değil.

Hayal edin, Pazartesi sabahı saat 6. Dizüstü bilgisayarınız kapalı ve GitHub Action uyanıp claude --skill morning-triage'ı ateşliyor: ne okuduğu, neyin eyleme geçirilebilir olduğuna karar verdiği, sonuçları nereye yazdığı - tüm bunlar yazmak üzere olduğunuz SKILL.md dosyasının içinde yaşıyor.

Osmani'nin kilit cümlesi: Otomasyon bir beceriyi tetiklemelidir - yazılı, güncellenebilir proje bilgisi, bir cron işine yapıştırılmış bir prompt duvarı değil. Yapıştırılan prompt orada çürür, çünkü hiç kimse bir zamanlamanın içine gömülü bir şeyi güncellemek için geri dönmez.

Bu ders için göreviniz: .claude/skills/morning-triage/SKILL.md konumunda, üç kaynağı (CI / sorunlar / commit'ler) kendi başına okuyan, neyin yapmaya değer olduğuna kendi başına karar veren, sonuçları ./state/triage.md dosyasına yazan - ve loop'un NE yapmasına İZİN OLMADIĞINI açıkça belirten bir Durdur bölümü olan bir beceri yazın.

İşte başlangıç ​​şablonu - üç şeyi değiştirin ve sizin olsun:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: günlük otomasyon tarafından çağrılır
5---
6
7## Oku   (keşif girdileri — SİZİN deponuzda GERÇEKTEN olan kaynaklarla değiştirin)
8- son çalıştırmadan bu yana başarısız olan CI çalıştırmaları      # gh run list --status failure
9- son 24 saatte açılan sorunlar               # gh issue list --search "created:>=…"
10- dünden bu yana birleştirilen commit'ler              # git log --since=yesterday
11- önceki ./state/triage.md              # "dün → bugün" devir teslimi
12
13## Yargıla  (tavan — loop'un seçmesine izin verin, ona bir liste vermeyin)
14Her aday için karar ver:
15- ŞİMDİ eyleme geçirilebilir mi, yoksa gürültü mü?
16- Bir sürümü engelliyor mu? → öncelik = P0
17- Zaten takip ediliyor mu? → atla
18Yalnızca BUGÜN bir çalışma ağacına değecek olanları tut.
19
20## Yaz  (kalıcılık — sohbette değil, işaretlemede sonlandır)
21./state/triage.md dosyasına ekle:
22| bulgu | kaynak | öncelik | durum |
23Dosyayı commit et ki yarın okuyabilsin.
24
25## Devret  (Ders 2'ye hazırlık)
26Tutulan her bulgu için bir görev satırı yayınla:
27  worktree=fix/<slug>
28  goal=<durma-koşulu>
29
30## Durdur   (standart olmayan TEK bölüm — burada iyi düşünün)
31Asla birleştirme. Asla silme.
32Emin olmadığınız herhangi bir şey → bir insan için ./inbox/ klasörüne.
33PR DEĞİL.

Burada asıl işi yapan üç bölüm var:

Oku: Keşif'in girdisidir - somut kaynakları, gerçek komuta kadar listeleyin. Unutmayın, "bağlamı oku" bir kaynak değildir, ancak gh run list --status failure bir kaynaktır.

Yargıla: Tüm loop'unuzun tavanıdır. Loop, "eyleme geçirilebilir vs gürültü"ye kendisi karar verir - sizden bir liste almaz, çünkü her sabah ona hâlâ bir liste veriyorsanız, yapmayı değil, seçmeyi otomatikleştirmişsinizdir. Ve seçmek genellikle daha pahalı olan adımdır. Kaynaklarınız ne kadar iyi olursa olsun, bu bölüm çöp seçerse, diğer dört hamle değersiz işlerde dönüp durur.

Durdur: Bu dosyanın standart olmayan tek bölümü. Loop, becerinin söylediği her şeyi ve yalnızca becerinin söylediğini yapacaktır. "Asla birleştirme" yazmazsanız - bir gün sizin için birleştirir.

Kırmızı çizgileri açıkça belirtin: asla birleştirme, asla silme, asla main'e push'lama, emin olunmayan her şey bir PR'a değil, bir insan için ./inbox/ klasörüne gider.

Bilmeye değer bir şey daha: Aynı beceri yapısı sabah triyajının ötesinde de çalışır: Oku bölümünü "dünün erişim günlükleri + yeni sorunlar + mevcut dağıtım sürümü" ile değiştirin ve bir akşam site-sağlığı loop'una dönüşür. Yargıla'ya bir satır ekleyin - "bu dünden bir gerileme mi?" - ve günler arası karşılaştırma yeteneği kazanır.

Bu dersin önlediği hastalık - Kör Loop:

En yaygın "loop'a benziyor ama değil" durumu: loop çalışır, ancak işi hâlâ her sabah siz atarsınız ("hey, şu üç hataya bak"). Bu, keşfin değil, yürütmenin otomasyonudur.

Belirti: Loop sizi asla şaşırtmaz, çünkü yalnızca zaten yapılması gerektiğini bildiğiniz şeyleri yapar.

Çözüm: Yargıla'yı becerinin içine koyun ve bugünün işini kendisinin seçmesine izin verin.

Devam etmeden önce şu üç soruyu yanıtlayın:

1/ Durdur bölümünüz kaç satırdan oluşuyor?

Sadece "asla birleştirme" ise - bir tane daha ekleyin: bu loop sizin için başka neyi asla yapmamalı? (sorunları asla kapatma / main'e asla push'lama / aynı anda 3'ten fazla bulgu alma..)

2/ Oku'nun ilk satırını, SİZİN projenizde GERÇEKTEN çalışan bir komut olarak yeniden yazın

**3/ Bu beceri bir yıl boyunca değişmeden kalırsa - ne olur?

**şimdi karşılaştırın: bir cron işine yapıştırılmış bir prompt duvarına bir yıl boyunca ne olur?

Ders 2 Devir Teslim: işi dağıtın ve izole edin

Ders 1'deki beceri az önce çalışmayı bitirdi. ./state/triage.md dosyasında artık 5 eyleme geçirilebilir bulgu var. En doğal sonraki düşünce - aynı anda 5 ajan ateşleyin, hızlı gidin. İşte bu tam adım, bir Dolaşık Loop oluşturmanın yoludur: birkaç ajan aynı dizindeki aynı dosyaları düzenler ve birleştirme günü arkeolojiye dönüşür.

Panzehir tek bir satırdır: her bulgu kendi çalışma ağacını alır.

git worktree, yerleşik bir git mekanizmasıdır: tek bir depo, her biri kendi dalına checkout edilmiş birden çok bağımsız çalışma dizini. git worktree add ../fix-auth fix/auth, ../fix-auth konumunda tamamen izole bir çalışma alanı açar. derlemeler, düzenlemeler, testler - hiçbir şey başka birine dokunmaz. bulgu başına bir çalışma ağacı = fiziksel olarak ayrılmış ajanlar.

Bu ders için göreviniz: ./state/triage.md dosyasındaki her bulguyu okuyan, bulgu başına izole bir çalışma ağacı açan (fix/<slug> adında), içine bir düzeltme taslağı hazırlaması için bir ajan gönderen - ve sonsuza kadar çoğalmaması için bir paralellik sınırı koyan bir betik yazın.

1# state/triage.md'yi oku, bulgu başına bir çalışma ağacı
2# değiştir: MAX_PARALLEL, makinenizin / faturanızın kaldırabileceği değere
3MAX_PARALLEL=3
4
5# değiştir: ayrıştırmayı gerçek triage.md sütunlarınıza göre ayarlayın
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # kilit satır: ajan başına fiziksel izolasyon
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # değiştir: goal, Ders 3'teki değerlendiricinin okuyacağı durma koşuludur
16  claude --worktree ../wt-$slug \
17    --goal "tests/$slug klasöründeki testler geçiyor ve lint temiz" \
18    "şunun için bir düzeltme taslağı hazırla: $finding" &
19done
20
21wait   # tüm paralel ajanların bitmesini bekle
22
23# kapanış kuralı: ajanlar asla otomatik birleştirme yapmaz — çalışma ağaçları
24# Ders 5'teki insan kapısını bekler
25echo "İnceleme için tüm çalışma ağaçları hazır:"
26git worktree list

Burada önemli olan kurallar: main üzerinde asla çalışmayın.

Main, insan incelemesi için iniş pistidir - ajanların masası değil. Tüm ajanlar fix/* çalışma ağaçlarında yaşar.

Paralelliği sınırlayın: Sınırsız çoğalma, token patlamasının ön kapısıdır (Ders 5 buna geri dönecek). MAX_PARALLEL'i dürüst bir soruya göre seçin: "makinem kaç tane çalıştırabilir" değil, "gerçekten kaç PR'ı inceleyebilirim."

Birleştirme insan kararıdır: Stripe, bu tür loop'lar aracılığıyla haftada 1.000'den fazla PR çalıştırır ve insanlar yine de her birini inceler. İnsan süreçten ayrılmadı - masası değişti: kod yazmaktan kod incelemeye geçti.

Ve Stripe örneğinden çalmaya değer bir detay: beklenmedik bir şekilde, mevcut en büyük model yerine katı deterministik geçitlere sahip daha küçük bir model kullandılar.

Ders: Loop çalışması için sıkı bir doğrulama geçidi, ham model gücünden daha iyidir.

Bu dersin önlediği hastalık - Dolaşık Loop:

Tek ajanlı bir loop mükemmel sağlıklı görünür. Sorun yalnızca paralel çalıştığınız gün ortaya çıkar - beş ajan çalışır, beş fark aynı dosyada çakışır, birleştirme kaostur.

Çözüm: Her görev kendi çalışma ağacını alır, ajanlar arasında asla bir çalışma dizini paylaşmayın.

Devam etmeden önce şu üç soruyu yanıtlayın:

**1/ MAX_PARALLEL'i hangi sayıya ayarladınız ve neden?

**(para? makine? yoksa "dürüstçe kaç PR'ı inceleyebilirim"?)

**2/ Bir çalışma ağacı çökerse - ajan hiçbir şeye dokunmadan çıkarsa

**yarının durum dosyası bununla ilgili ne kaydetmeli?

**3/ Stripe, en büyük model yerine daha küçük bir model + katı deterministik geçitler kullandı

**Bu seçim SİZİN loop'unuz için ne anlama geliyor?

Ders 3 Doğrulama: "hayır" diyen bir kapı takın (en ağır ders)

Loop mühendisliğindeki en zor harekettir ve diğer tüm derslerden daha fazla çabayı hak eder.

Anthropic mühendisi Prithvi Rajasekaran, uzun süreli ajan uygulamaları üzerinde çalışırken bir şey fark etti: az önce yazdığı kodu notlandırmasını isteyin, neredeyse her zaman kendini övecektir - bir insanın ilk bakışta vasat olduğunu görebilmesine rağmen.

Bu, modelin aptal olması değil: kendi ödevinizi notlandırmak yapısal olarak bozuktur. Kod bittiğinde, ajanın bağlamı, şeyleri neden bu şekilde yazdığına dair kendi kendini haklı çıkarma zinciriyle doludur. Kendi çıktısına baktığında sonucu değil, sonucun gerekçesini görür.

Bunu bir loop'un içine koyun ve bir felakete dönüşür: Her turdaki "bu yeterince iyi mi?" sorusu, onu az önce yazan ajan tarafından yanıtlanır. Her tur kendine onay verir. Ne kadar uzun çalışırsa, gerçek kaliteden o kadar uzaklaşır. İşte bu Onaylayan Loop'tur - ve listedeki en pahalı hastalıktır.

Rajasekaran'ın çözümü, kendi sözleriyle:

"Bağımsız bir değerlendiriciyi şüpheci olacak şekilde ayarlamak, bir üreteci kendi işine karşı eleştirel yapmaktan çok daha kolaydır."

Bu yapısal bir sorundur, bir ifade sorunu değil. Bir yazardan kendi kafasının dışına çıkmasını isteyemezsiniz, ancak *tamamen farklı talimatlarla, koda sıfırdan bakan - eklenmiş hiçbir kendini haklı çıkarma zinciri olmayan - farklı bir ajan getirebilirsiniz.

Analoji GAN'lardan gelir: bir ağ inşa eder, diğeri saldırır: yapıcı ve denetçi. Aynı eski bankacılık kuralı: parayı havaleyen kişi ile onu onaylayan kişi farklı kişiler olmalıdır.

Bu ders için göreviniz - iki şey yazın:

1) .claude/agents/reviewer.md konumunda beş bölümden oluşan bir değerlendirici sistem prompt'u: ROL + VARSAY + KONTROL ET + KULLAN + KARAR.

2) Bu loop'un durma koşulunu bildiren bir /goal komutu - üretici tarafından değil, ayrı bir temiz model tarafından değerlendirilir.

1# .claude/agents/reviewer.md  (3 şeyi değiştirin)
2ROL: Çekişmeli kod incelemecisi.
3VARSAY: aksini kanıtlanana kadar bu kod BOZUKTUR.
4ÖVGÜ YAPMA. Başarısız olanı bul.
5
6# değiştirin: KONTROL ET'i projenizin gerçek başarısızlık modlarına göre sıralayın,
7# önce çalıştırılabilir kontroller
8KONTROL ET, sırayla:
9  1. Çalışıyor mu?  (oku değil, çalıştır)
10  2. Testler: çalıştırın, gerçek çıktıyı yapıştırın.
11  3. Yazarın atladığı uç durumlar.
12  4. Davranış ticket ile eşleşiyor mu?
13
14# değiştirin: hangi MCP'nin kullanılacağı neyi test ettiğinize bağlıdır —
15# frontend → Playwright, API → curl/httpie
16Playwright MCP'yi KULLAN: sayfayı aç, tıkla,
17ekran görüntüsü al, DOM'u incele.
18Niyeti değil, davranışı yargıla.
19
20KARAR: Yalnızca her kontrol sağlanıyorsa GEÇTİ.
21         Aksi takdirde REDDET + her nedeni listele.

1# durma koşulu — ÜRETİCİ tarafından değil, temiz küçük bir model tarafından değerlendirilir
2# değiştirin: bulgunuzun gerçek doğrulanabilir koşuluyla değiştirin
3/goal test/auth klasöründeki tüm testler geçiyor ve lint adımı temiz
4
5# dikkat: /goal ve /loop AYNI ŞEY DEĞİLDİR
6#   /loop = aralıkta yeniden çalıştır (durma yargısı yok — tehlikeli)
7#   /goal = temiz bir model koşulun doğru olduğuna karar verene kadar çalıştır

İki ajan, ideal olarak iki model: "Aynı model, farklı prompt" genellikle aynı kör noktaları korur. Mümkünse modeli de değiştirin.

Varsayılan şüphecilik: Değerlendiricinin temel varsayımı BOZUK OLDUĞUNU VARSAY'dır - güven, kontrolleri geçerek kazanılmalıdır, varsayılan olarak verilmemelidir.

Niyeti değil, davranışı yargılayın: "Bu JSX iyi görünüyor" ile "Düğmeye tıkladım, sayfa yönlendirildi, işte ekran görüntüsü" iki farklı evrendir. Değerlendirici harekete geçmelidir - testleri çalıştırmalı, sayfaya tıklamalı, kodu okuyup hissetmemelidir.

Nedenlerle reddedin: Nedenleri listelenmemiş bir REDDET, bir ret değildir - üreticinin neyi düzelteceği hakkında hiçbir fikri yoktur.

Ve turnusol testi: Değerlendiriciniz son 5+ turda gerçekten bir şeyi reddetti mi? Yüzlerce tur boyunca hiç "hayır" dememiş bir loop, herhangi bir gerçek iş yükünde istatistiksel olarak imkansızdır. Bu, değerlendiricinin çalışmadığını kanıtlar.

Bu dersin önlediği hastalık - Onaylayan Loop:

Loop çalışır, ajan kod yazar, aynı ajan "iyi görünüyor" der. Her tur kendini onaylar, makine hızında makul görünen hataları biriktirir. Çözüm: bu dersin tamamı: yapısal ayrım + varsayılan şüphecilik + eylemle yargılama + üçüncü taraf durma koşulu.

Devam etmeden önce şu üç soruyu yanıtlayın:

1/ Değerlendiriciniz farklı bir prompt'a sahip aynı model mi, yoksa farklı bir model mi? neden?

2/ "Niyeti değil, davranışı yargıla"yı projeniz için

somut bir cümleye çevirin: "değerlendiricim kodu okumaz, _____ çalıştırır ve yalnızca _____ gördüğünde GEÇTİ verir"

3/ "Yeterince yakın" bir temiz modelin /goal koşulunuzu yanlışlıkla GEÇTİ verme olasılığı nedir?

en korkutucu başarısızlık modunuz X ise - hemen şimdi durma koşuluna X için bir kontrol ekleyin

Ders 4 Kalıcılık: bugünün işinin yarına ulaşmasını sağlayın

Ders 3 bitti. Değerlendiriciniz üç bulguyu değerlendirdi - ikisi GEÇTİ, biri REDDETTİ. Soru: Bu üç karar şu anda nerede yaşıyor?

Cevap "bağlam penceresinde" ise - yarın sabah 6'da loop, temizlenmiş bir bağlamla uyanır ve hiçbir şey hatırlamaz. Sıfırdan yeniden triyaj yapar, dünün düzeltilmemiş REDDETTİ'sine takılır, belki onu düzeltmesi için başka bir ajan atar, belki tamamen kaçırır, belki aynı çukura düşer.

İşte bu Hafızasız Loop'tur - her gün aynı kareden başlar.

Tek satırda panzehir: Bellek, bağlam değil, diske yazılan durumdur. Bir işaretleme dosyası, bir Linear panosu, bir veritabanı - bir kez yazıldı mı, ajanın ne kadar iyi unuttuğunun bir önemi kalmaz.

Bunlar sürekli karıştırılır, bu yüzden farkı netleştirelim:

BAĞLAM = ajanın BU turda gördüğü pencere -> her yenilemede temizlenir.

BELLEK = turlar ve günler boyunca yaşayan durum -> diske yazılır (işaretleme / DB / pano).

Bir loop, bugünü -> yarına yalnızca BELLEK aracılığıyla bağlar.

Bu ders için göreviniz:

1. En az 4 sütunlu (bulgu / kaynak / öncelik / durum) ./state/triage.md dosyası oluşturun - Ders 1'deki beceri onu yazar, Ders 2'deki çalışma ağaçları onu okur.
2. Bir bağlayıcı (MCP) bağlayın: GEÇTİ kararı otomatik olarak bir PR açar, REDDETTİ kararı ticket'ı otomatik olarak günceller.
3. Yarının loop'unun bugünün durumunu gerçekten geri okuyabildiğini doğrulayın.

1# ./state/triage.md  (loop'un belleği — gerektiği gibi değiştirin)
2
3| bulgu           | kaynak       | öncelik | durum      |
4|-----------------|--------------|---------|------------|
5| auth testi tutarsız | CI #4821     | P0      | düzeltiliyor |
6| null referans   | sorun 92     | P1      | PR açık    |
7| güncel olmayan bağımlılık | commit a3f9c | P2      | gelen kutusu |
8
9# gerektiğinde sütunları genişletin: son_görülme, deneme_sayısı, atanan_kişi
10# bu dosya depoya commit EDİLMELİDİR —
11# aksi takdirde yarının bulut çalıştırıcısı onu göremez

1// .mcp/connectors.json — loop'u dış dünyaya bağlayın
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← KESİNLİKLE false olmalı. insan kapısı = Ders 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Engellendi", "reason": "${verdict.reasons}" }
15  }
16}

Her sütun neden önemlidir: kaynak yok -> bir bulgunun nereden geldiğini denetleyemezsiniz. öncelik yok -> işi sıralayamazsınız. durum yok -> yarın bayrağı devralamaz.

Ve bu ders için doğrulama, taklit edemeyeceğiniz tek doğrulamadır: yarına kadar bekleyin. Uyanın, kontrol edin - gelen kutusu hâlâ orada mı? Bitmemiş bulgular durumlarını koruyor mu? Sabah 6'daki çalıştırma, sıfırdan başlamak yerine dünün kaldığı yerden devam etti mi? Bunu, üzerinde akıl yürüterek değil, çalıştırarak öğrenirsiniz.

Kalıcılıkla birlikte gelen sessiz bir disiplin - her zaman bir örneği okuyun.

Kalıcılık çalıştığında bir tuzak açılır: loop hızla PR'lar gönderir, kendinizi üretken hissedersiniz - ve kod tabanına dair zihinsel haritanız sessizce güncelliğini yitirir. Kural: her şeyi okumayın (bu loop'un amacını bozar), ancak günde bir örnek PR okuyun ve kendinizi loop'un neyi ve neden değiştirdiğini açıklamaya zorlayın.

Açıklayamadığınız an - haritanız geride kalmış demektir. Bunu sakin bir sabahta düzeltmek on dakika sürer. Bir üretim olayı sırasında düzeltmek çok daha pahalıya mal olur.

Bu dersin önlediği hastalık - Hafızasız Loop:

Loop iyi iş bulur, yapar, sonra yaptığını unutur - çünkü sonuç yalnızca temizlenmiş bir bağlamda yaşamıştır. Sonraki tur aynı işi yeniden keşfeder veya daha kötüsü - yeniden yapar ve ilk denemeyi ezer.

Belirti: birikmiş ilerleme yok, her gün aynı yerden başlar. Çözüm: diskte durum dosyası.

Devam etmeden önce şu üç soruyu yanıtlayın:

1/ "Bellek ≠ bağlam"ı kendi projenizden

somut bir cümleye çevirin: "benim _____ belleğimdir, benim _____ bağlamımdır"

2/ Yarının loop'u uyanıyor - ilk hamlesine karar vermek için

**state.md dosyasının hangi SÜTUNUNU okur? o sütunu doğru adlandırdınız mı, yoksa sadece onun için bir mayın mı gömdünüz?

3/ Disiplin: Tek örnek PR'ınızı günün hangi saatinde okuyacaksınız?

takvim hatırlatıcısını hemen şimdi ayarlayın - bu kendinizle yaptığınız bir sözleşmedir.

Ders 5 Zamanlama: gerçek yapın, güvenli yapın, bir kapıyı açık tutun

Ders 1-4 kuruldu, ancak loop, düğmeye basmayı bıraktığınız anda hâlâ duruyor. Son hamle tek bir fiildir: onu bir tetikleyiciye asın.

Ancak bu dersin en tehlikeli kısmı cron'u yanlış yapmak değil. Cron'u doğru yapmaktır - çünkü o zaman loop gerçekten yalnız çalışır ve tek bir hata, yardımcılar yardımcıları doğururken bütün gece dönmesine neden olabilir, ta ki tanımadığınız bir faturayla uyanana kadar.

Bu nedenle bu ders aslında üç şey yapar: tetikleyiciyi asın, sınırları belirleyin, bir insan kapısını açık tutun.

İlk olarak - zamanlayıcınızı seçin:

1Bulut (GH Actions)   Masaüstü zamanlanmış   /loop (CC'de)
2nerede çalışır          bulut                sizin makineniz        sizin makineniz
3makine açık mı?         gerekli değil        gerekli                gerekli
4oturum açık mı?         gerekli değil        gerekli değil          gerekli
5min aralık              1 saat               1 dakika               1 dakika
6yerel dosyaları görür mü?   hayır                evet                   evet

Belirleyici soru: bu iş dizüstü bilgisayarınızdan ayrılabilir mi?

1"yerel geliştirme sunucumu her dakika kontrol et"
2   → yerel + /loop olmalı (bulutun 1 saatlik aralığı ona ulaşamaz)
3
4"GitHub sorunlarını sabah 3'te tara ve PR'ları aç"
5   → bulut olmalı (dizüstü bilgisayarınız kapalı — loop onu bekleyemez)

Ve tüm uygulamadaki en sinsi kendini kandırma: yerel bir zamanlayıcıya "siz uyurken çalışıyor" muamelesi yapmak. Öyle değildir. "Ben hâlâ etraftayken birkaç tur daha çalıştırmak"tır.

Bu dersteki göreviniz:

1. .github/workflows/triage.yml dosyasını, sabah triyaj becerisini tetikleyen bir cron zamanlayıcı ile yazın.
2. Üç sınır belirleyin: çalıştırma başına bütçe, günlük bütçe, maksimum yeniden deneme sayısı.
3. İş akışını şu kuralla sonlandırın: PR'lar asla otomatik birleşmez, belirsiz olan her şey ./inbox/ klasörüne gider.

1# .github/workflows/triage.yml  (3 şeyi değiştirin)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # değiştirin: saat diliminizin 06:00'sı UTC cinsinden
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← çalıştırma başına sınır · değiştirin
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: sabah triyajı
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← günlük sınır · değiştirin
22          MAX_RETRIES: '3'          # ← yeniden deneme sınırı · değiştirin
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: PR'ları aç (ASLA otomatik birleştirme)
29        run: |
30          # PR'lar otomatik olarak açılır. Birleştirme insana kalır.
31          gh pr create --draft --base main \
32            --title "[döngü] $(date +%F) triyaj" \
33            --body-file ./state/triage.md
34          # burada `gh pr merge` komutu yok — bilerek
35
36      - name: belirsizleri gelen kutusuna yönlendir
37        run: |
38          ls ./inbox/ && echo "insan incelemesini bekleyen öğeler"

Altıncı ayda hala canlı kalmasını sağlayan üç kural:

Göndermeden önce sınırlayın: üç seviye - çalıştırma zaman aşımı, günlük bütçe, maksimum yeniden deneme - ilk otonom çalıştırmadan önce belirlenmeli, ilk korkunç faturadan sonra değil. Bir token sınırı tasarruf etmekle ilgili değildir. Bu, açık uçlu riski sınırlı riske dönüştüren bir devre kesicidir. Sınırları olmayan bir döngü, harcama yetkisini kendi hatalarına devretmiştir.

Ölçek açısından: Uber, AI bütçesini dört ayda tükettikten sonra mühendisleri kişi başına araç başına aylık 1.500 dolar ile sınırladı. Sizin döngü başına sınırınız, bu dersin ayrıntılı versiyonudur.

Bir kapıyı açık tutun: PR'lar otomatik birleşmez. Belirsiz öğeler gelen kutusuna düşer. Günde bir örnek okursunuz. Kapı, bir insanın her zaman içinden geçeceği için orada değildir; kapının var olması, sizi geçebilecek bir konumda tuttuğu için oradadır. Her kapıyı kaynakla kapatırsanız, içeri girmeniz gereken gün anahtarı kaybetmiş olursunuz.

Gerçekten uyandığından emin olun. En az 3 tur çalıştırın (kuru çalıştırmalar sayılır). En yaygın başarısızlık: demo gününde göz kamaştırır, Perşembe günü ölür. "Son çalıştırma, demonun yapıldığı gündü" ifadesi, bir Manuel Döngü'nün teşhis işaretidir.

Claude Code dışında da aynı şekilde çalışır - yetenekler satıcıya kilitli değildir, sadece yeniden adlandırılmıştır:

1YETENEK              Claude Code          Codex
2zamanlama            /loop · worker       Otomasyonlar sekmesi
3koşula kadar çalıştır /goal                otomasyonu yeniden çalıştır + değerlendir
4paralel izolasyon    --worktree           arka plan worktree
5alt temsilciler      .claude/agents/      .codex/agents/
6harici bağlantı      MCP + eklentiler     MCP bağlayıcısı
7açık beceri          SKILL.md             $beceri-adı
8makine kapalıyken çalışır Cloud Routines   bulut (planlanan)

Soru asla "hangi satıcı" olmadı. Soru "altı yeteneğin tamamı kurulu mu."

Bu dersin önlediği hastalık - Manuel Döngü:

Dört hamle güzelce inşa edildi, cron yok. Bu bir döngü değil - bir kere çalıştırdığınız ve unuttuğunuz bir betik.

Düzeltme: size bağlı olmayan herhangi bir tetikleyiciyi takın.

Göndermeden önce şu üç soruyu cevaplayın:

1/ Üç sınırınızın tam sayıları nedir?

Bir hata bütün gece dönerse - hangi sınır ilk önce düşüşü durdurur? Hiçbiri durdurmazsa... Bu size ne söylüyor?

2/ İnsan kapınız neye benziyor?

(PR incelemesi / gelen kutusu / günlük örnek / haftalık mutabakat?) Bunu yazın = kendinizle bir sözleşme imzalayın

3/ Kapanış sorusu: altı ay sonra, bu döngü sizi daha güçlü kılmış mı olacak (anlayış, muhakeme, sistem hissi) - yoksa okuyamadığınız bir makinenin bakıcısına mı dönüştürecek? İkincisinden kaçınmak için planınız nedir?

4 borç ve mühendis olarak kalmak

Döngünüz inşa edildi: uyanır, iş bulur, kendini eleştirir, hatırlar ve kendi yarınını planlar.

Bir döngü çalışırken, dört şey sessizce birikir - ve ortak özellikleri hiçbirinin alarm vermemesidir.

1DOĞRULAMA BORCU       reddedilmemiş çıktının birikmesi
2ANLAMA ÇÜRÜMESİ       kod tabanı büyür, zihinsel haritanız büyümez
3BİLİŞSEL TESLİMİYET   "Artık incelemek istemiyorum"
4TOKEN PATLAMASI        bir hata bütün gece döner → fatura olarak görürsünüz

Birbirlerini beslerler: doğrulanmamış çıktı anlayışınızı aşındırır -> aşınmış anlayış teslimiyeti davet eder -> teslimiyet döngünün daha uzun çalışmasına ve daha fazla harcamasına izin verir -> bu da daha fazla doğrulanmamış çıktı üretir.

Yeni döngünüzü ilk solo çalıştırmasından önce dördüne karşı denetleyin:

• Değerlendiricim gerçekten reddediyor - dekorasyon değil.
• Günde bir örnek PR okuyorum ve neyin değiştiğini açıklayabiliyorum.
• "Bu yanlış" deme alışkanlığını korudum.
• Sınırlarım İLK çalıştırmadan ÖNCE belirlendi, ilk faturadan sonra değil.

Ve işte her şeyi belirleyen kısım:

Aynı döngü, iki kişi tarafından inşa edildiğinde, zıt yerlerde sonuçlanabilir. Biri, kodu okumaya ve yönü korumaya devam ederken daha hızlı hareket etmek için kullanır - döngü, zaten sahip oldukları muhakemeyi güçlendirir.

Diğeri, aynı döngüyü özellikle hiçbir şeyi asla anlamamak için kullanır - altı ay sonra, birincisi daha keskindir ve ikincisi okuyamadığı bir makinenin bakıcısıdır.

Addy Osmani: "döngüyü inşa edin, ancak onu mühendis olarak kalmayı amaçlayan biri gibi inşa edin - sadece 'başlat' düğmesine basan kişi değil."

Döngüler üretmeyi neredeyse ücretsiz kılar, nadir bulunan şey muhakeme olarak kalır: hangi plan doğru, hangi satırda durmalı, hangi şey çalışıyor ama temelde yanlış. Döngü muhakemenin değerini düşürmez - muhakeme olmayan her şeyi soyup atar ve geriye sadece onu bırakır.

Bir döngü sadık bir çarpandır:

Anlayış getirin - anlayışı güçlendirir.

Tembellik getirin - tembelliği güçlendirir.

Ne güçlendirmek istediğinize karar verin - onu inşa etmeden önce.

Bizi izlemeye devam edin!

İyi şanslar :)