Loop engineering - Aracıya prompt veren sistemi tasarlamak

• Kodlama aracısına her tur doğrudan prompt verme yöntemini bırakıp, aracının yerine prompt veren bir sistemi tasarlayan çalışma biçimine geçiş
• Loop, amaç tanımlandığında yapay zekanın tamamlayana kadar yinelediği özyinelemeli bir hedeftir ve yaklaşık beş bileşenden oluşur
• Bu beş unsur Automations, Worktrees, Skills, Plugins·connectors, Sub-agents olup hem Claude Code hem de Codex şu anda beşinin de tamamına sahip
• Altıncı unsur olan bellek, tek bir konuşmanın dışında durumu saklayan bir markdown dosyası ya da Linear panosudur; her çalıştırmada unutan modeli tamamlar
• Hâlâ erken aşamada ve token maliyetine dikkat etmek şart; doğrulama ve anlama ise hâlâ insanın işi (build the loop, stay the engineer)

---

Loop engineering'in tanımı ve ortaya çıkış arka planı

• Loop engineering, aracıya prompt veren kişinin yerini kendiniz yerine sistemle değiştirmek ve bunu yapan sistemi bizzat tasarlamaktır
  • Loop, amaç tanımlandığında yapay zekanın tamamlayana kadar yinelediği özyinelemeli bir hedeftir (recursive goal)
  • Kodlama aracılarıyla çalışmanın gelecekteki biçimi olabilir, ancak henüz erken aşamadadır ve token maliyetine dikkat etmek şarttır (token açısından zengin/fakir olmaya göre kullanım kalıbı ciddi biçimde değişir)
• Alıntı
  • Peter Steinberger: "Artık kodlama aracısına prompt vermeyin; aracıya prompt veren loop'u tasarlayın"
  • Boris Cherny (Anthropic'te Claude Code lideri): "Artık Claude'a prompt vermiyorum; Claude'a prompt verip ne yapacağına karar veren bir loop çalıştırıyorum. Benim işim loop yazmak"
• Son yaklaşık 2 yıldır yöntem, iyi prompt ve yeterli bağlam verip tur tur ilerleyerek aracıyı doğrudan bir araç gibi elde tutmaktı; ancak bu yöntem sona yaklaşıyor
• Artık işi bulup dağıtan, doğrulayan, tamamlananı kaydeden ve sıradaki işi belirleyen küçük bir sistem kurup bu sistemin aracıyı dürtmesini sağlıyoruz
  • Bu yaklaşım, önceki yazılardaki agent harness engineering (tek bir aracının çalıştığı ortam) ve factory model'in (yazılım üreten sistem) üst katmanında yer alıyor
  • Zamanlayıcıyla çalışan, küçük yardımcılar üreten ve kendini besleyen bir harness
• Bu artık araç meselesi değil — 1 yıl önce loop istiyorsanız bash betiklerini kendiniz yazıp sürdürmeniz gerekiyordu; şimdi bu bileşenler ürünün içine yerleşik geliyor
  • Steinberger'in listesi Codex uygulamasıyla neredeyse birebir örtüşüyor ve Claude Code ile de neredeyse aynı; bu yüzden hangi aracın daha iyi olduğunu tartışmak yerine iki tarafta da çalışan loop'lar tasarlamak gerekiyor

Loop'un beş bileşeni ve bellek

• Bir loop için beş şey gerekir; buna bir de durumu hatırlayacak tek bir yer eklenir
  • Automations — takvime göre tetiklenir, kendi kendine keşif ve triage yapar
  • Worktrees — paralel çalışan iki aracının birbirine çarpmasını önler
  • Skills — aracının tahminle dolduracağı proje bilgisini kaydeder
  • Plugins·connectors — aracıyı zaten kullandığınız araçlara bağlar
  • Sub-agents — biri fikir üretirken diğeri doğrular
• Altıncı unsur bellektir; markdown dosyası veya Linear panosu gibi tek bir konuşmanın dışında yaşar, tamamlanan işleri ve sıradakileri saklar
  • Fazla basit görünebilir ama uzun süre çalışan tüm aracıların dayandığı aynı numaradır (önceki yazı: long-running agents)
  • Model çalıştırmalar arasında her şeyi unuttuğu için bellek bağlamda değil diskte olmalıdır — aracı unutabilir ama repo unutmaz
• İki ürün de şu anda bu beş unsurun tamamına sahip; sadece isimleri biraz farklı, yetenekleri aynı

Automations — loop'un kalp atışı

• Automations, loop'u tek seferlik bir çalıştırma değil gerçek bir loop yapan unsurdur
  • Codex uygulamasında Automations sekmesinden oluşturulur; proje, çalıştırılacak prompt, periyot ve yerel checkout mu yoksa arka planda bir worktree mi olduğu seçilir
  • Bir şey bulan çalıştırmalar Triage inbox'a gider, hiçbir şey bulamayanlar ise kendini arşivler
  • OpenAI bunu içeride günlük issue triage, CI başarısızlık özeti, commit brifingi yazımı ve geçen hafta eklenen bug'ları avlama gibi sıkıcı işler için kullanıyor
  • Otomasyonlar skill çağırabildiği için dev bir talimat duvarı yapıştırmak yerine $skill-name tetiklenerek tekrarlayan işler bakımı kolay hâle getirilebilir
• Claude Code, zamanlama ve hooks ile aynı noktaya ulaşıyor
  • /loop ile belirli aralıklarla prompt veya komut çalıştırılabilir, cron işleri zamanlanabilir, aracının yaşam döngüsünün belirli anlarında hooks ile shell komutları ateşlenebilir
  • Dizüstü bilgisayarı kapattıktan sonra da sürmesini istiyorsanız her şeyi GitHub Actions'a devredebilirsiniz
• Oturum içindeki ikinci primitive olarak, bu yazının özüne daha yakın bir işlev daha var
  • /loop, belirlenmiş aralıklarla yeniden çalıştırır
  • /goal, yazdığınız koşullar gerçekten doğru olana kadar sürer ve her turun ardından ayrı küçük bir model tamamlanıp tamamlanmadığını kontrol eder; böylece kodu yazan aracı kendi kendini değerlendirmez
    • Örnek: "test/auth içindeki tüm testler geçsin, lint temiz olsun" gibi koşullar verip masadan kalkabilirsiniz
  • Codex de aynı şekilde /goal sunar; doğrulanabilir durma koşulu sağlanana kadar turları sürdürür ve pause·resume·clear destekler

Worktrees — paralelliğin kaosa dönüşmemesi için

• Birden fazla aracı çalıştırdığınız anda dosyalar çakışmaya başlar; kırılma noktası da burasıdır
  • İki aracının aynı dosyaya yazması, birbirine haber vermeden aynı satıra commit atan iki mühendisin yarattığı baş ağrısıyla aynıdır
  • git worktree bunu çözer — aynı repo geçmişini paylaşırken her biri kendi dalında ayrı çalışma dizinine sahip olur, böylece bir aracının düzenlemeleri diğerinin checkout'una dokunamaz
• Codex, worktree desteğini yerleşik sunar; birden fazla thread aynı repo üzerinde aynı anda çalışsa da çarpışmaz
• Claude Code ise git worktree, oturumu kendi checkout'u ile açan --worktree bayrağı ve subagent'lara eklenen isolation: worktree ayarıyla aynı izolasyonu sağlar (her yardımcı işini bitirdiğinde kendini temizleyen yeni bir checkout alır)
• Worktree mekanik çakışmaları ortadan kaldırır ama üst sınır hâlâ sizsiniz — gerçekte kaç tanesini çalıştırabileceğinizi araç değil, sizin review bant genişliğiniz belirler (önceki yazı: the orchestration tax)

Skills — projeyi her seferinde yeniden anlatmamak için

• Skill, her oturumda aynı proje bağlamını bir japon balığına anlatır gibi tekrar tekrar açıklamayı bırakmanın yoludur
  • Her iki araç da aynı biçimi kullanır — içinde talimat ve metadata bulunan SKILL.md dosyası olan bir klasör ile isteğe bağlı script'ler, referanslar ve varlıklar
  • Codex'te $ veya /skills ile çağrılabilir ya da iş skill açıklamasıyla eşleşiyorsa kendiliğinden çalışır; bu yüzden zekice açıklamalardan çok kısa ve sıkıcı açıklamalar daha iyidir
  • Claude Code da aynı şekilde çalışır (önceki yazı: agent skills)
• Skill, niyetin tekrar maliyetine dönüşmesini engelleyen yerdir
  • Aracı her oturuma soğuk başlar ve niyetteki boşlukları kendinden emin tahminlerle doldurur (önceki yazı: the intent debt)
  • Skill, bu niyetin dışsallaştırılmış hâlidir — teamüller, build adımları, "şu olay yüzünden bunu böyle yapmıyoruz" gibi şeyleri bir kez yazarsınız, aracı her çalıştırmada okur
  • Skill yoksa loop her çevrimde tüm projeyi sıfırdan yeniden türetir; varsa bilgi birikerek bileşik etki yaratır
• Skill bir yazım biçimidir ve plugin dağıtım yöntemidir — birden fazla repo arasında paylaşmak veya paketlemek istediğinizde plugin olarak sunarsınız (Codex ve Claude Code için aynı)

Plugins·connectors — loop'un gerçek araçlara dokunması için

• Yalnızca dosya sistemini görebilen loop, küçük bir loop'tur
  • MCP tabanlı connector sayesinde aracı issue tracker okuyabilir, veritabanı sorgulayabilir, staging API'lerini çağırabilir, Slack mesajı gönderebilir
  • Hem Codex hem Claude Code MCP konuştuğu için, biri için yazılmış connector çoğu zaman diğerinde de aynen çalışır
  • Plugin, connector ile skill'i paketler; böylece ekip arkadaşı her şeyi hafızadan yeniden kurmak yerine tek seferde kurabilir
• Fark, "işte bir düzeltme önerisi" diyen aracıyla, PR açan, Linear ticket'ını bağlayan ve CI green olduğunda kanala ping atan bir loop arasındadır
  • Connector sayesinde loop yalnızca olasılıklardan söz etmez, gerçek ortam içinde eyleme geçer

Sub-agents — yapanla kontrol edeni ayırmak

• Loop'taki en faydalı yapı açık ara kodu yazan tarafla kontrol eden tarafın ayrılmasıdır
  • Kodu yazan model, kendi ödevini notlandırırken fazla cömert davranır
  • Farklı talimatlara ve bazen farklı bir modele sahip ikinci bir aracı, ilkinin kendini ikna ettiği şeyleri yakalar
• Codex, yalnızca istendiğinde subagent oluşturur; bunları eşzamanlı çalıştırır ve sonuçları tek bir yanıtta birleştirir
  • .codex/agents/ altında TOML dosyalarıyla kendi aracı tanımlarınızı yaparsınız (name·description·instructions, isteğe bağlı model·reasoning effort)
  • Örnek: güvenlik inceleyicisi için yüksek effort'lu güçlü bir model, explorer için hızlı read-only model
• Claude Code ise .claude/agents/ altındaki subagents ve aralarında iş paylaştırılan agent teams ile aynı şeyi yapar
  • Her iki araçta da tipik iş bölümü şöyledir: bir aracı keşfeder, biri uygular, biri de spesifikasyona ve testlere göre doğrular (önceki yazılar: the code agent orchestra, adversarial code review)
• Loop siz bakmıyorken çalıştığı için, kalkıp gidebilmeniz adına güvenilir bir verifier gerekir
  • Subagent'lar kendi model ve araç çağrılarını yaptıkları için daha fazla token tüketir; bu yüzden ikinci görüşü gerçekten değer kattığı yerlerde kullanmak gerekir
  • Claude Code'daki /goal de içten içe bunu yapar — yeni bir model, işi yapan taraf yerine tamamlanma durumunu değerlendirir; yani durma koşulunun kendisine de maker·checker ayrımı uygular

Tek bir loop nasıl görünür

• Hepsi bir araya geldiğinde tek bir thread küçük bir kontrol paneline dönüşür; tekrar tekrar kullanılan bir örnek biçim şöyledir
  • Bir automation, her sabah repo'da çalışır; prompt'u triage skill'ini çağırır, dünkü CI başarısızlıklarını, açık issue'ları ve son commit'leri okuyup sonucu bir markdown dosyasına ya da Linear panosuna yazar
  • Değerli görülen her madde için thread, izole bir worktree açar; bir sub-agent'a ilk düzeltme taslağını verir, ikinci bir sub-agent da bu taslağı proje skill'i ve mevcut testlere göre inceler
  • Connector, loop'un PR açmasını ve ticket'ı güncellemesini sağlar; loop'un çözemediği her şey triage inbox'a düşer
  • State file, tüm yapının omurgasıdır — neyin denendiğini, neyin geçtiğini ve neyin hâlâ açık olduğunu hatırlar; böylece ertesi sabahki çalıştırma bugün durduğu yerden devam eder
• Asıl nokta, bu adımların hiçbirini tek tek prompt'lamıyor olmanız; bir kez tasarlıyorsunuz — Codex ya da Claude Code fark etmeksizin bileşenler aynı olduğu için loop da aynı

Loop'un hâlâ sizin yerinize yapmadıkları

• Loop işi dönüştürür ama insanı ortadan kaldırmaz; hatta loop ne kadar iyi olursa o kadar keskinleşen üç sorun vardır
• Doğrulama hâlâ sizin işinizdir
  • Gözetimsiz çalışan bir loop, gözetimsiz hata yapan bir loop da olabilir
  • Verifier sub-agent'ın maker'dan ayrılma nedeni, loop'un "bitti" demesine anlam kazandırmaktır; ama yine de "done", ispat değil iddiadır (önceki yazı: code review in the age of AI — iş, çalıştığı doğrulanmış kodu sevk etmektir)
• Anlayış ilgisiz bırakılırsa çürür
  • Loop sizin yazmadığınız kodu ne kadar hızlı üretirse, ortada olan şey ile sizin gerçekten anladığınız şey arasındaki fark o kadar büyür
  • Buna comprehension debt denir; akıcı bir loop, loop'un ürettiğini okumazsanız bu farkı daha da hızlı büyütür
• Rahat duruş tehlikeli duruştur
  • Loop kendi kendine çalıştığında fikir sahibi olmayı bırakıp size dönen şeyi olduğu gibi kabul etmek kolaylaşır (cognitive surrender)
  • Loop tasarımı, yargıyla yapıldığında çaredir; düşünmekten kaçmak için yapıldığında ise hızlandırıcıdır — aynı eylem, tam zıt sonuç

Loop'u kur ama mühendis olarak kal

• Bu, işin nasıl evrileceğine dair bir ön izleme gibi görünüyor; ancak kodu bizzat review etmez veya yalnızca otomatik loop'lara güvenirsiniz ürün kalitesi düşebilir ve giderek derinleşen bir çukura giren aşağı yönlü bir sarmala hapsolabilirsiniz
• Loop kurmak ama gerektiğinde aracıya doğrudan prompt vermeye devam etmek de hâlâ etkilidir; önemli olan doğru dengeyi bulmaktır
• Loop, kişiye göre tam zıt sonuçlar doğurabilir — aynı loop'u kuran iki kişiden biri derinlemesine anladığı işi daha hızlı yapar, diğeri ise işi anlamamak için kullanır
  • Loop bu farkı bilmez, ama siz bilirsiniz
• Loop tasarımını prompt engineering'den daha kolay değil daha zor yapan neden de budur — Cherny'nin vurguladığı şey işin kolaylaşması değil, kaldıraç noktasının yer değiştirmesidir
• Sonuç: loop'u kurun, ama yalnızca start düğmesine basan biri değil, mühendis olarak kalacak biri gibi kurun

[shakespeares]

Doğrulama hâlâ kişinin kendi sorumluluğunda

Anlayış, kendi hâline bırakılırsa çürür

Rahat duruş, tehlikeli duruştur

=> Sonuçta, doğrudan kendiniz kontrol etmeli ve tekrarlayan işleri en aza indirmek için prompting yapmalısınız.