Orijinal Başlık: Loop Engineering.
Orijinal Yazar: Addy Osmani
Çeviri: Peggy, BlockBeats

Editör Notu: AI kodlama ajanlarının kullanım şekli, "insanın manuel olarak Prompt yazıp adım adım ilerlemesi"nden, "insanın bir döngü tasarlayıp sistemin ajanları sürekli yönetmesi"ne doğru evriliyor. Addy Osmani'nin bahsettiği Loop Engineering (Döngü Mühendisliği), özünde otomatik olarak görevleri keşfeden, görevleri dağıtan, sonuçları kontrol eden, ilerlemeyi kaydeden ve bir sonraki adıma karar veren bir iş akışı kurmayı hedefliyor.

Bu döngü kabaca beş modülden oluşuyor: Automations (zamanlanmış görev keşfi ve triyaj), Worktrees (birden fazla paralel geliştirme ortamını izole etme), Skills (proje bilgisi ve ekip alışkanlıklarını biriktirme), Plugins/Connectors (GitHub, Linear, Slack, veritabanı gibi gerçek araçlara bağlanma), Sub-agents (uygulayıcı ve denetleyiciyi ayırma) ve buna ek olarak durum ve ilerlemeyi kaydetmek için Markdown dosyaları veya Linear panosu gibi bir harici bellek katmanı.

Makale, Loop Engineering'in anlamının sadece "AI'nın birkaç tur daha koşmasını sağlamak" olmadığını, mühendisin muhakeme yeteneğini sistem tasarımının önüne koymak olduğunu hatırlatıyor. Döngü, geliştiricinin iş kaldıracını önemli ölçüde artırabilir, ancak doğrulama, anlama ve muhakemenin yerini almaz. Gerçek risk, döngüyü kullanmak değil, döngüyü kodu ve sistemi anlamaktan kaçmak için bir bahane olarak kullanmaktır. Gelecekte AI ile kodlama iş birliğinde kilit yetenek, belki de sadece iyi bir Prompt yazmak değil, güvenilir, doğrulanabilir ve sürdürülebilir şekilde çalışan ajan iş akışları tasarlamak olacaktır.

İşte orijinal metin:

Loop engineering (Döngü Mühendisliği), sizin "ajanlara Prompt yazan kişi" rolünüzün yerini alıyor. Siz, ajanlara Prompt yazması için bir sistem tasarlıyorsunuz. Buradaki loop (döngü), özyinelemeli bir hedef olarak anlaşılabilir: Bir amaç tanımlarsınız, AI görev tamamlanana kadar sürekli iterasyon yapar. Kabaca beş bileşenden oluşur ve Claude Code ile Codex şu anda bu beş bileşene de sahip.

İnanıyorum ki, bu gelecekte kodlama ajanlarıyla iş birliği yapma şeklimiz olabilir. Ancak, bu hala erken aşamalarda ve ben şüpheciyim. Token maliyetlerine kesinlikle dikkat etmelisiniz, çünkü farklı kullanım modellerinde maliyet farkı çok büyük olabilir, özellikle "token zengini" mi yoksa "token fakiri" mi olduğunuza bağlı olarak. Ayrıca, kalitenin düşmemesini sağlayacak bir mekanizmaya ihtiyacınız var. "AI çıktısı çöpü" (slop) endişeleri de haklı. Yine de, bakalım bu işin aslı neymiş.

@steipete geçenlerde şöyle dedi: "Artık kodlama ajanlarına prompt yazmamalısın. Ajanını yönlendirecek döngüler tasarlamalısın." Benzer şekilde, Anthropic'in Claude Code sorumlusu @bcherny de şunları söyledi: "Artık Claude'a prompt vermiyorum. Çalışan bir döngü kümem var; bunlar Claude'u yönlendiriyor ve bir sonraki adımda ne yapacağına kendisi karar veriyor. Benim işim döngüleri yazmak."

Peki, bu tam olarak ne anlama geliyor?

Son iki yıldır, bir kodlama ajanına bir şey yaptırmak istediğinizde temel yöntem, iyi bir prompt yazmak ve yeterli bağlam sağlamaktı. Bir cümle yazıp sonucu okur, ardından bir sonraki cümleyi yazardınız. Ajan bir araçtı ve siz bu aracı elinizde tutar, turdan tura ilerletirdiniz. Bu aşama bir şekilde sona erdi, en azından bazıları bunun sona ermek üzere olduğunu düşünüyor.

Şimdi inşa ettiğiniz şey küçük bir sistem: Kendi işini keşfeder, görevleri dağıtır, sonuçları kontrol eder, tamamlananları kaydeder ve ardından bir sonraki adımda ne yapacağına karar verir. Yani, sistemi ajanı yönlendirmesi için görevlendiriyorsunuz, sizin bizzat tekrar tekrar prompt vermeniz yerine. Daha önce bunun "yakın akrabası" olan agent harness engineering (ajan çalışma ortamı mühendisliği) – yani tek bir ajan için çalışma ortamı kurmak – ve factory model (fabrika modeli) – yani yazılım inşa eden sistemler – hakkında yazmıştım. Loop engineering ise harness'ın bir kat üstünde yer alır. Harness'a benzer, ancak zamanlayıcıyla çalışır, küçük asistanlar üretir ve kendini besler.

Beni şaşırtan şey, bunun artık sadece "araç seviyesi" bir mesele olmaması. Bir yıl önce, bir döngü istiyorsanız, bir sürü bash scripti yazmanız ve bu scriptleri sonsuza kadar bakımını yapmanız gerekiyordu. Bu sizin kendi işinizdi ve sadece size aitti. Şimdi, bu bileşenler doğrudan ürünlere entegre edilmiş durumda. Steinberger'in listelediği yetenekler neredeyse birebir Codex uygulamasına ve yine neredeyse aynı şekilde Claude Code'a karşılık geliyor. Formlarının aynı olduğunu fark ettiğinizde, hangi aracı kullanacağınız konusunda takılıp kalmazsınız; bunun yerine bir döngü tasarlarsınız: Hangi aracın içinde oturuyor olursanız olun, bu döngü çalışmaya devam eder.

Beş Bileşen ve Bazı Açıklamalar

Bir döngünün beş şeye ve bilgileri hatırlamak için bir yere ihtiyacı vardır. Önce listeleyip, ardından tek tek eşleştireceğim.

Birincisi, Automations (Otomasyon Görevleri): Planlı olarak tetiklenir, otomatik olarak keşif ve yönlendirme yapar.

İkinci olarak, Worktrees (Çalışma Ağaçları): Paralel çalışan iki ajanın birbirlerinin dosyalarına müdahale etmesini engeller.

Üçüncü olarak, Skills (Beceriler): Proje bilgisini yazılı hale getirerek ajanların her seferinde tahmin yürütmesini önler.

Dördüncü olarak, Plugins and connectors (Eklentiler ve Bağlayıcılar): Ajanların halihazırda kullandığınız araçlara erişmesini sağlar.

Beşinci olarak, Sub-agents (Alt Ajanlar): Biri çözüm önerisi sunarken diğeri bu çözümü kontrol eder.

Ve altıncı şey: memory (bellek). Bu bir Markdown dosyası olabilir, bir Linear panosu olabilir veya tek bir sohbetin dışında, "tamamlanan görevler" ve "sonraki adımlar"ı saklayan herhangi bir yer olabilir. Kulağa önemsiz gelecek kadar basit gelebilir, ancak uzun süre çalışan her ajanın dayandığı aynı tekniktir. Bunu long-running agents yazımda da detaylandırmıştım: Model her çalıştırma arasında her şeyi unutur, bu nedenle bellek bağlamda değil, diskte saklanmalıdır. Ajan unutur, ancak kod deposu unutmaz.

Şimdi, her iki ürün de bu beş bileşene sahip.

İsimlendirmeleri bazı yerlerde farklılık gösterse de, yetenekleri özünde aynı şeydir. Aşağıda tek tek açıklayacağım, çünkü açıkçası bir döngünün istikrarlı bir şekilde çalışması mı yoksa sessizce her yerden sızdırması mı, işin püf noktası detaylarda gizlidir.

Automations: Bu, döngünün kalbidir

Automations, bir döngüyü elle çalıştırdığınız tek seferlik bir görev olmaktan çıkarıp gerçek bir döngü haline getiren şeydir. Codex uygulamasında, Automations sekmesinde bir otomasyon görevi oluşturabilir, projeyi, çalıştıracağı prompt'u, çalışma sıklığını ve yerel checkout'unuzda mı yoksa arka planda bir worktree'de mi çalışacağını seçebilirsiniz. Sorun tespit eden çalıştırmalar Triage inbox'a (ön inceleme gelen kutusu) giderken, sorun bulamayanlar otomatik olarak arşivlenir, bu oldukça iyi bir özellik. OpenAI dahili olarak bunu günlük issue triage'ı, CI başarısızlıklarını özetleme, commit özetleri yazma ve geçen hafta birinin eklediği hatayı takip etme gibi sıkıcı ama gerekli işler için kullanıyor. Otomasyon görevleri ayrıca skill'leri çağırabilir, böylece tekrarlayan görevleri bakımı kolay tutabilirsiniz: Bir duvar dolusu talimatı, kimsenin güncellemeyeceği bir zamanlanmış göreve yapıştırmak yerine $skill-name'i tetikleyin.

Claude Code da aynı sonuca ulaşabiliyor, sadece farklı bir yol izliyor: bunu zamanlama ve hook'lar aracılığıyla yapıyor. Bir istemi veya komutu belirli aralıklarla çalıştırmak için /loop kullanabilir, bir cron görevi planlayabilir veya aracı yaşam döngüsünün belirli noktalarında shell komutlarını tetiklemek için hook'lar kullanabilirsiniz. Dizüstü bilgisayarınızı kapattıktan sonra da çalışmaya devam etmesini istiyorsanız, tüm yapıyı GitHub Actions'a da taşıyabilirsiniz. Mantık tamamen aynı: otonom bir görev tanımlıyor, ona bir ritim veriyor ve sonuçların size gelmesini sağlıyorsunuz, sizin her yeri kontrol etmeniz gerekmiyor.

Bir de oturum içi ilkeller var ki bunlar aslında bu yazının gerçek odağına daha yakın. /loop bir ritimle tekrar tekrar çalışır; /goal ise yazdığınız belirli bir koşul gerçekleşene kadar sürekli olarak yürütülür. Her turdan sonra, görevin tamamlanıp tamamlanmadığına ayrı bir küçük model karar verir, yani kodu yazan aracı kendine not vermez. Ona "test/auth içindeki tüm testler geçiyor ve lint temiz" gibi bir koşul verebilir ve arkanıza yaslanabilirsiniz. Codex de aynı yeteneğe sahiptir ve buna da /goal adını verir. Doğrulanabilir bir durma koşulu oluşana kadar turlar boyunca çalışmaya devam eder ve duraklatma, devam ettirme ve temizleme işlemlerini destekler. Aynı ilkel, her iki araçta da var. Bu, yazıda tekrar eden desenin ta kendisidir.

Yani, Automations işi yüzeye çıkarmaktan sorumludur. Loop'un geri kalanı ise bu işleri halleder.

Worktree'ler: Paralelliğin Kaosa Dönüşmesini Engellemek

Birden fazla aracı çalıştırmaya başladığınızda, dosya çakışmaları bir başarısızlık noktası haline gelir. İki aracının aynı dosyaya aynı anda yazması, özünde iki mühendisin haberleşmeden aynı kod satırını değiştirmesi kadar sorunludur. git worktree bu sorunu çözer. Bağımsız bir daldaki ayrı bir çalışma dizinidir, ancak aynı kod deposu geçmişini paylaşır, bu nedenle bir aracının yaptığı değişiklik fiziksel olarak diğer aracının checkout'una dokunamaz.

Codex, worktree desteğini doğrudan içinde barındırır, böylece birden çok iş parçacığı aynı depo üzerinde birbirine çarpmadan çalışabilir. Claude Code da aynı izolasyonu git worktree aracılığıyla sağlayabilir: Bağımsız bir checkout'ta oturum açmak için --worktree flag'ini kullanabilir veya her bir alt aracının yepyeni bir checkout almasını ve işi bittiğinde otomatik olarak temizlemesini sağlamak için subagent üzerinde isolation: worktree ayarını yapabilirsiniz. Bunun insani boyutunu "the orchestration tax" yazısında anlatmıştım: worktree'ler mekanik çatışmaları ortadan kaldırır, ancak siz hala sınırlayıcı faktörsünüz. Aynı anda kaç tane aracı çalıştırabileceğinizi belirleyen şey araçlar değil, sizin review bandwidth'inizdir (inceleme bant genişliğiniz).

Skills：Her seferinde projeyi yeniden açıklamak zorunda kalmamanı sağlar

Skill, her oturumda bir japon balığı gibi aynı proje bağlamını yeniden açıklamak zorunda kalmamanı sağlayan bir mekanizmadır. İki araç da aynı formatı kullanır: içinde talimatlar ve meta veriler bulunan bir SKILL.md dosyası olan bir klasör; ayrıca isteğe bağlı betikler, referanslar ve kaynak dosyaları da eklenebilir. Codex, bir skill'i $ veya /skills ile çağırdığında çalıştırır ve ayrıca görevin skill'in açıklamasıyla eşleşmesi durumunda otomatik olarak çalıştırır. Bu nedenle, kısa ve sade bir açıklama genellikle akıllı ve süslü bir açıklamadan daha iyidir. Claude Code da aynı şeyi yapar, bu modeli agent skills'te yazmıştım.

Skills aynı zamanda niyetin her seferinde tükenmediği yerdir. Intent debt'te de belirttiğim gibi, ajan her oturuma soğuk başlangıç yapar ve niyetinde boşluklar olduğu sürece, bu boşlukları kendinden emin tahminlerle doldurur. Skill, bu niyeti harici bir yere yazar: proje kuralları, yapı adımları, "bunu yapmıyoruz çünkü daha önce şu kaza oldu" gibi şeyler, ajanın her çalıştığında okuyacağı bir yere tek seferde yazılır. Skills olmadan, loop her turda tüm projeni sıfırdan yeniden çıkarmak zorunda kalır; skills ile bu, bileşik faiz gibi bir şeye dönüşür.

Bir ayrımı netleştirmek gerekir: skill bir yazma formatıdır, plugin ise dağıtım şeklidir. Bir skill'i birden fazla kod deposu arasında paylaşmak veya birkaç skill'i bir araya getirmek istediğinde, bunları bir plugin olarak paketlersin. Codex için de böyledir, Claude Code için de.

Plugins ve Connectors: Loop'un gerçek araçlarına erişmesini sağlar

Sadece dosya sistemini görebilen bir loop, çok küçük bir looptur. Connectors, MCP üzerine inşa edilmiştir ve ajanın issue tracker'ını okumasını, veritabanını sorgulamasını, staging API'sini çağırmasını veya Slack'te mesaj göndermesini sağlar. Codex ve Claude Code'un her ikisi de MCP'yi destekler, bu nedenle biri için yazdığın bir connector genellikle diğerinde de kullanılabilir. Plugins ise connectors ve skills'i bir araya getirerek takım arkadaşlarının tüm yapılandırmayı hafızadan yeniden oluşturmak yerine tek seferde kurmasını sağlar.

İşte "bir ajan sana 'işte düzeltme bu' der" ile "bir loop kendi kendine PR açar, Linear ticket'ı bağlar ve CI geçtikten sonra kanala bildirim gönderir" arasındaki fark budur. Connectors önemlidir çünkü loop'un gerçek ortamında hareket etmesini sağlar, sadece "yapabilseydim şöyle yapardım" demekle kalmaz.

Alt-Ajanlar: Üreticiyi Denetleyiciden Ayırmak

Bir döngü içinde en faydalı yapısal tasarım, "yazan" ile "kontrol eden" kişiyi ayırmaktır. Kod yazan bir modelin, kendi ödevini değerlendirirken çok hoşgörülü olması kolaydır. Farklı talimatlarla ve hatta bazen farklı bir modelle çalışan başka bir ajan, ilk ajanın kendini ikna ettikten sonra gözden kaçırdığı sorunları yakalayabilir.

Codex, yalnızca siz istediğinizde alt-ajanlar oluşturur; bunlar paralel olarak çalışır ve sonuçları tek bir cevapta birleştirir. Kendi ajanlarınızı .codex/agents/ dizininde TOML dosyalarıyla tanımlayabilirsiniz: her ajanın bir adı, açıklaması, talimatları ve isteğe bağlı olarak modeli ile akıl yürütme yoğunluğu bulunur. Bu sayede güvenlik denetçiniz yüksek yoğunluklu akıl yürüten güçlü bir model olabilirken, keşif ajanınız hızlı ve salt okunur hafif bir model olabilir. Claude Code da .claude/agents/ içindeki alt-ajanlar ve ajan ekipleri aracılığıyla benzer bir yetenek sunar ve birden fazla ajanın işi birbirine aktarmasını sağlar. Her iki tarafta da en yaygın iş bölümü şudur: bir ajan keşfeder, bir ajan uygular ve bir ajan da spesifikasyonlara göre doğrulama yapar.

Bu görüşü iki kez detaylandırdım: bir kez kod ajan orkestrasında, bir kez de çekişmeli kod incelemesinde. Bir döngü içinde bu özellikle önemlidir çünkü döngü siz izlemezken çalışır; bu nedenle gerçekten güvendiğiniz bir doğrulayıcı, uzaklaşmaya cesaret etmenizin tek sebebidir. Alt-ajanlar daha fazla token tüketir çünkü her ajan kendi model çağrısını ve araç çağrısını yapar; bu yüzden onları "ikinci bir görüşün ödemeye değer olduğu" yerlerde kullanmalısınız. Temelde Claude Code'un /goal komutunun arka planda yaptığı da budur: döngünün tamamlanıp tamamlanmadığına, işi yapan modelin değil, yeni bir modelin karar vermesi. Yani "üretici" ve "denetleyici" ayrımını durdurma koşulunun kendisine uygular.

Bir Döngü Nasıl Görünür

Tüm bunları bir araya getirdiğinizde, tek bir iş parçacığı küçük bir kontrol paneline dönüşür. İşte sık kullandığım bir yapı.

Her sabah, bir otomasyon kod deposunda çalışır. İstemci, bir triyaj becerisini çağırır, dünkü CI hatalarını, açık sorunları ve son commit'leri okur ve bulguları bir Markdown dosyasına veya Linear panosuna yazar. İşlenmeye değer her sorun için iş parçacığı izole bir çalışma ağacı açar, bir alt-ajanı düzeltme taslağı hazırlaması için gönderir ve ardından ikinci bir alt-ajanı proje becerilerine ve mevcut testlere göre bu taslağı incelemesi için gönderir.

Connector'lar, bu döngünün kendi kendine PR açmasını ve ticket'ı güncellemesini sağlar. Döngünün işleyemediği her şey triage inbox'a düşer ve ben hallederim. Durum dosyası tüm sistemin omurgasıdır: neyin denendiğini, neyin geçtiğini ve neyin hâlâ tamamlanmadığını hatırlar. Böylece ertesi sabahki çalıştırma, bugün kaldığı yerden devam eder.

Gerçekte ne yaptığına dikkat et. Sadece bir kez tasarladın. O adımları bizzat sen tek tek yönlendirmedin. Steinberger'in sözünün gerçek hayattaki karşılığı işte bu. Üstelik aynı döngü, hem Codex'te hem de Claude Code'da çalışabilir, çünkü yapı taşları aynı.

Döngü hâlâ senin yerine ne yapmaz?

Döngü çalışma şeklini değiştirir, ama seni işin içinden çıkarmaz. Aslında döngü güçlendikçe üç sorun daha da keskinleşir, kolaylaşmaz.

Doğrulama hâlâ sana bağlıdır. Gözetimsiz çalışan bir döngü, aynı şekilde gözetimsiz hata da yapabilir. Verifier alt-agent'ı ile maker'ı ayırmanın sebebi, döngünün "tamamlandı" demesine bir anlam kazandırmaktır. Yine de "tamamlandı" bir iddiadır, kanıt değil. Yapay zekâ çağında kod incelemesi yazımda hep aynı cümleyi tekrarlıyorum: Senin sorumluluğun, geçerli olduğunu onayladığın kodu teslim etmektir.

Eğer başıboş bırakırsan, kendi anlayışın yine de çürür. Döngü, senin bizzat yazmadığın kodu ne kadar hızlı teslim ederse, gerçekten anladığın şeyle sistemde gerçekten var olan şey arasındaki uçurum o kadar büyür. Buna comprehension debt (anlayış borcu) denir. Döngünün ürettiklerini okumazsan, pürüzsüz bir döngü bu borcu daha da hızlı büyütür.

Ve evet, en rahat pozisyon aynı zamanda en tehlikeli pozisyon olabilir. Döngü kendi kendine çalışabildiğinde, kendi muhakemeni oluşturmayı bırakıp döngünün döndürdüğü her şeyi kabul etmek kolaylaşır. Buna cognitive surrender (bilişsel teslimiyet) diyorum. Eğer döngüyü muhakemenle tasarlarsan, panzehirdir; eğer döngüyü sadece düşünmekten kaçmak için tasarlarsan, hızlandırıcıdır. Aynı hareket, tamamen zıt sonuçlar doğurur.

Döngüyü inşa et, ama yine de mühendis ol

Bence bu, gelecekteki çalışma şeklimizin evrimine işaret ediyor. Bununla birlikte, eğer kodu bizzat incelemezsem ya da kodu düzeltmek için tamamen otomatik döngülere güvenirsem, ürün kalitem zarar görür. Büyük olasılıkla kendimi aşağı doğru bir sarmalın içinde bulurum: sürekli kendimi daha derin çukurlara kazarken.

Yani, elbette kendi loop'unu kurabilirsin, ancak unutma ki aracını doğrudan yönlendirmek de hâlâ etkilidir. Önemli olan doğru dengeyi bulmaktır.

Loop'un sonuçları kişiden kişiye değişir. İki kişi aynı loop'u oluşturabilir ama tamamen zıt sonuçlar alabilir. Biri, derinlemesine anladığı bir işte hız kazanmak için kullanır; diğeri ise işi anlamaktan kaçmak için. Loop, bu ikisi arasındaki farkı bilmez. Ama sen bilirsin.

İşte bu yüzden loop design (döngü tasarımı), prompt engineering'den (istem mühendisliği) daha zordur, daha kolay değil. Cherny'nin kastettiği işin kolaylaşması değil, kaldıraç noktasının değişmesidir.

Loop'unu kur. Ama bunu, hâlâ bir mühendis gibi çalışmayı planlayan biri gibi yap; sadece "başlat" düğmesine basan biri gibi değil.

[Orijinal bağlantı]

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia