Loop Mühendisliği.
Yazar: Addy Osmani
Peggy, BlockBeats

Editör Notu: AI kodlama Agent'larının kullanımı, «insanın manuel olarak Prompt yazıp görevleri adım adım ilerletmesi» yerine, «insanın döngüleri tasarlayıp sistemin Agent'ları sürekli olarak yönlendirmesi» yönünde değişiyor. Addy Osmani'nin belirttiği Loop Engineering (Döngü Mühendisliği), görevleri otomatik olarak keşfetme, görevleri atama, sonuçları kontrol etme, ilerlemeyi kaydetme ve bir sonraki adımı belirleme iş akışını kurmaya odaklanıyor.

Bu döngü yaklaşık beş modülden oluşur: Automations (zamanlanmış keşif ve triaj görevleri), Worktrees (birden fazla paralel geliştirme ortamını izole etme), Skills (projeye ait bilgileri ve ekip alışkanlıklarını biriktirme), Plugins/Connectors (GitHub, Linear, Slack, veritabanları gibi gerçek araçlara bağlanma), Sub-agents (yürütücü ve inceleyiciyi ayırma), ayrıca durum ve ilerlemeyi kaydetmek için Markdown dosyaları veya Linear panoları gibi dış bir bellek katmanı.

Makale uyarısı, Loop Engineering'in anlamı yalnızca "AI'yi birkaç döngü daha çalıştırmak" değil, mühendislerin yargılarını sistem tasarımına önceden dahil etmektir. Döngüler, geliştiricilerin çalışma verimliliğini önemli ölçüde artırabilir, ancak doğrulama, anlama ve yargılamayı yerine geçmez. Gerçek risk, döngüleri kullanmak değil, döngüleri kodu ve sistemi anlamaktan kaçınmanın bir gerekçesi olarak kullanmaktır. AI ile programlama yaparken geleceğin anahtarı, belki de iyi bir Prompt yazmak değil, güvenilir, doğrulanabilir ve sürdürülebilir Agent iş akışları tasarlamaktır.

Aşağıda orijinal metin yer almaktadır:

Döngü mühendisliği, sizin «bir ajan için ipucu yazma» rolünüzü yerine getiriyor. Bir sistemi tasarlamalısınız ki bu sistem, sizin yerinize ajanlara ipucu vermesini sağlasın. Buradaki döngü, rekürsif bir hedef olarak anlaşılabilir: bir amaç tanımlarsınız, AI ise görev tamamlanana kadar sürekli olarak yinelemeye devam eder. Bu sistem yaklaşık beş bileşenden oluşur ve Claude Code ile Codex şimdi bu beş bileşene sahiptir.

Bence bu, gelecekte kodlama ajantlarıyla nasıl iş birliği yapacağımızın bir örneği olabilir. Ancak bunların hepsi hâlâ erken aşamada ve ben şüpheci kalıyorum. Token maliyetlerine dikkat etmeniz kesinlikle gerekli, çünkü farklı kullanım modellerinde maliyetler çok büyük ölçüde değişebilir, özellikle "token zengini" mi yoksa "token sıkıntılı" mı olduğunuz bağlı olarak. Ayrıca kalitenin düşmemesini sağlayacak bir mekanizma da gerekiyor. "AI çöp üretimi" (slop) konusundaki endişeler de mantıklıdır. Bununla birlikte, bunun tam olarak ne olduğunu inceleyelim.

@steipete son zamanlarda şunu söylemişti: “Artık kodlama ajanlarına ipucu vermemelisiniz. Bu ajanlara ipucu vermek için bazı döngüler tasarlamalısınız.” Benzer şekilde, Anthropic’in Claude Code sorumlusu @bcherny de şunu söyledi: “Artık Claude’a ipucu vermiyorum. Çeşitli döngüler çalıştırıyorum ve bu döngüler Claude’a ipucu veriyor ve bir sonraki adımın ne olacağını kendileri kararlaştırıyor. Benim işim döngüleri yazmak.”

Peki, bu tam olarak ne anlama geliyor?

Son yaklaşık iki yıl boyunca, kodlama ajanlarına ne yaptırmak istediğiniz, iyi bir ipucu yazmak ve yeterli bağlam sağlamakti. Bir cümle girdiğinizde, dönen sonucu okuyup bir sonraki cümleyi giriyordunuz. Ajan bir araçtı ve siz bu aracı elinizde tutarak, tur tur itiyordunuz. Bu aşama bir ölçüde sona erdi, en azından bazıları bunun yakında biteceğini düşünüyor.

Şu anda oluşturduğunuz küçük bir sistem: kendisi işleri keşfediyor, görevleri atıyor, sonuçları kontrol ediyor, tamamlanmaları kaydediyor ve sonraki adımı belirliyor. Yani bu sistemi, sizin sürekli olarak yönlendirmenize gerek kalmadan ajanları yönlendirmeye bırakıyorsunuz. Daha önce bunun "yakın akrabasını" yazmıştım—agent harness engineering (ajan çalışma çerçevesi mühendisliği), yani tek bir ajan için çalışma ortamı kurmak; ve factory model (fabrika modeli), yani yazılım oluşturmak için bir sistem kurmak. Loop engineering ise harness’in üst katmanındadır. Harness gibi çalışır ama zamanlayıcıya göre çalışır, küçük asistanlar üretir ve kendi kendini besler.

Bunu artık sadece “araç düzeyinde” bir sorun olarak görmüyorum. Bir yıl önce, bir döngü oluşturmak istiyorsanız, bir dizi bash betiği yazıp bu betikleri sonsuza dek bakım altında tutmanız gerekirdi. Bu, sadece sizin kendi işinizdi ve sadece sizinle sınırlıydı. Şimdi ise bu bileşenler doğrudan ürüne entegre edildi. Steinberger’in listelediği yetenekler neredeyse tamamen Codex uygulamasına ve neredeyse aynı şekilde Claude Code’a da karşılık geliyor. Bunların biçiminin aynı olduğunu anladığınızda, hangi aracı kullanmanız gerektiğini düşünmek yerine, herhangi bir araçta oturduğunuzda çalışacak şekilde bir döngü tasarlamaya başlarsınız.

Beş bileşen ve bazı açıklamalar

Bir döngüye beş şey ve bilgiyi hatırlamak için bir yer gerekir. Önce listeliyorum, sonra her birini eşliyorum.

Birinci, Automations (Otomatik Görevler): Planlanan zamanda tetiklenir, otomatik olarak keşfedilir ve yönlendirilir.

İkinci olarak, Worktrees (Çalışma Ağaçları): İki paralel çalışan ajanın birbirinin dosyalarına zarar vermesini önler.

Üçüncü olarak, Beceriler (Yetenekler): Proje bilgilerini yazın, böylece akıllı sistem her seferinde tahmin etmek zorunda kalmaz.

Dördüncü, Eklentiler ve bağlayıcılar: Agentinizi zaten kullandığınız araçlara bağlayın.

Beşinci, Alt-akıllı ajanlar: Birisi çözüm önermekten, diğeri çözümü kontrol etmekten sorumludur.

Sonra altıncı şey: memory (hafıza). Bu, bir Markdown dosyası olabilir, bir Linear panosu olabilir veya tek bir diyalogun dışında tamamlanmış ve sonraki adımların kaydedildiği herhangi bir yer olabilir. Önemsiz gibi görünebilir, ancak her uzun süreli akıllı ajanın kullandığı aynı tekniktir. Uzun süreli ajanlar konusunda detaylı olarak yazdım: model her çalıştırma arasında unutur, bu yüzden hafıza bağlamda değil, diskte tutulmalıdır. Akıllı ajan unutur, ancak kod deposu unutmaz.

Şu anda, iki ürün de bu beş bileşene sahip.

Adlandırılmaları bazı noktalarda farklı olsa da, yetenekleri temelde aynı şeydir. Aşağıda bunları tek tek açıklıyorum, çünkü dürüst olmak gerekirse, bir döngünün nihayetinde kararlı bir şekilde çalışıp çalışmadığı yoksa her yerden sızıp sızmadığı, detaylarda yatıyor.

Otomasyonlar, loop'u sadece bir kez elle çalıştırdığınız bir görevden ziyade gerçekten loop yapan şeydir. Codex uygulamasında, Otomasyonlar sekmesinde bir otomasyon oluşturabilir, projeyi, çalıştırılacak talimatı, çalıştırma sıklığını ve yerel checkout'unuzda mı yoksa arka planda worktree'de mi çalıştıracağını seçebilirsiniz. Sorun tespit edilen sonuçlar Triage inbox'a (sınıflandırma posta kutusu) yönlendirilir, sorun tespit edilmeyen çalıştırmalar ise otomatik olarak arşivlenir; bu harikadır. OpenAI iç kullanımında da günlük issue sınıflandırma, CI hatalarının özeti, commit özetleri yazma ve geçen hafta kimin hangi hatayı eklediğini takip etme gibi sıkıcı ama gerekli işler için kullanılmaktadır. Otomasyon görevleri skill çağırabilir, bu sayede tekrarlanan görevleri sürdürülebilir tutabilirsiniz: Bir planlı göreve bir duvar kadar açıklama yapıştırmak yerine $skill-name tetikleyin.

Claude Code aynı sonucu verir, ancak yolu farklıdır: Bu, zamanlama ve hook'lar aracılığıyla gerçekleştirilir. /loop komutuyla sabit aralıklarla bir talimat veya komut çalıştırabilir, bir cron görevi ayarlayabilir veya ajan yaşam döngüsünün belirli noktalarında hook'larla shell komutlarını tetikleyebilirsiniz. Bilgisayarınızı kapatıktan sonra da çalışmaya devam etmesini istiyorsanız, tüm sistemi GitHub Actions'a taşıyabilirsiniz. Fikir tamamen aynıdır: Kendi kendine çalışan bir görev tanımlarsınız, ona bir ritim verirsiniz ve sonuçları sizin her yerde kontrol etmeniz yerine size doğru gelmesini sağlarsınız.

Konuşma içindeki, bu metnin gerçekten tartıştığı çekirdeğe daha yakın bir başka özgün ifade daha var. /loop, ritme göre tekrarlı olarak çalışır; /goal ise yazdığınız bir koşul gerçekleştikçe kadar sürekli çalışır. Her tur sonrası, görevin tamamlanıp tamamlanmadığına dair ayrı bir küçük model karar verir, bu nedenle kod yazan akıl birimi kendi performansını değerlendiren kişi değildir. Örneğin, “test/auth içindeki tüm testler başarılı olmalı ve lint temiz olmalı” gibi bir koşul verip ayrılabilirsiniz. Codex’in de aynı yeteneği vardır ve buna yine /goal denir. Bu, doğrulanabilir bir durma koşulu sağlanana kadar arka arkaya çalışır ve duraklatma, yeniden başlatma ve temizleme işlevlerini destekler. Aynı özgün ifade, iki araçta da mevcuttur. Bu temelde metinde tekrar tekrar ortaya çıkan kalıptır.

Dolayısıyla, Otomasyonlar işleri yüzeye çıkarır. Döngünün geri kalanı ise bu işleri yürütür.

Bir den fazla ajan çalıştırdığınızda, dosya çakışmaları başarısızlık noktalarına dönüşür. İki ajanın aynı dosyayı aynı anda yazması, iki mühendisin iletişim kurmadan aynı satır kodu değiştirmesi kadar sorunlu olur. Git worktree, bu sorunu çözer. Aynı kod deposu geçmişini paylaşan, ancak bağımsız dallarda bulunan ayrı bir çalışma dizinidir; bu nedenle bir ajanın değişiklikleri fiziksel olarak başka bir ajanın checkout'una dokunamaz.

Codex, worktree desteğini doğrudan dahil eder, bu nedenle birden fazla iş parçacığı aynı deposu aynı anda işleyebilir ve birbirleriyle çakışmaz. Claude Code, git worktree kullanarak aynı izolasyonu sağlayabilir: Bir oturumu bağımsız bir checkout ile açmak için --worktree bayrağını kullanabilir veya isolation: worktree ayarını alt ajanlara uygulayarak her bir yardımcı için yeni bir checkout oluşturup işlem sonunda otomatik olarak temizleyebilirsiniz. Bu konuyu orchestration tax yazısında insan yönünden ele aldım: worktrees, mekanik çakışmaları ortadan kaldırır, ancak hala siz sınırsınız. Aynı anda kaç ajan çalıştırabileceğinizi gerçekten belirleyen araçlar değil, review bandwidth’inizdir (inceleme bant genişliği).

Skill, her oturumda aynı projenin bağlamını balık gibi yeniden açıklamak zorunda kalmadan kullanabileceğiniz bir mekanizmadır. İki araç da aynı formatı kullanır: bir SKILL.md dosyasının bulunduğu bir klasör, bu dosyada açıklamalar ve meta veriler saklanır; ek olarak isteğe bağlı betikler, referanslar ve kaynak dosyalar da bulunabilir. Codex, $ veya /skills komutlarını kullandığınızda bir skill çalıştıracaktır ve göreviniz bu skill açıklamasıyla eşleştiğinde otomatik olarak çalıştırılacaktır. Bu nedenle, akıllıca ve süslü bir açıklama yerine, sade ve öz bir açıklama genellikle daha iyidir. Claude Code da aynı yaklaşımı izliyor, bu modeli agent skills bölümünde yazdım.

Beceriler, niyetlerinizi tekrar tekrar tüketmenizi engelleyen yerdir. Intent debt konusunda, ajanın her sohbet başlangıcında soğuk başlatıldığını ve niyetinizde boşluk varsa, bunu güvenle tahminlerle doldurduğunu söylemiştim. Beceri, bu niyetleri dışarıda yazmaktır: proje anlaşmaları, inşa adımları, “daha önce bu kazaya neden olduğu için bunu yapmıyoruz” gibi şeyler, ajanın her çalıştırıldığında okuyacağı bir yere tek seferlik yazılır. Beceriler olmadan, döngünün her turunda tüm projenizi sıfırdan yeniden çıkarmanız gerekir; becerilerle, bu tamamen bileşik faiz gibi çalışır.

Bir şeyi ayırt etmek gerekir: skill, biçimlendirme yazımıdır; plugin ise dağıtım yöntemidir. Bir skill'i birden fazla kod deposu arasında paylaşmak veya birkaç skill'i bir araya getirmek istediğinizde, bunları bir plugin olarak paketlersiniz. Codex böyle, Claude Code da böyle.

Sadece dosya sistemini gören bir döngü, çok küçük bir döngüdür. Connectors, MCP tabanlıdır ve akıllı varlıkların sorun takip sisteminizi okumasına, veritabanlarını sorgulamasına, staging API’lerini çağırmasına veya Slack’te mesaj göndermesine olanak tanır. Codex ve Claude Code, MCP’yi destekler; bu nedenle biri için yazdığınız bir connector, genellikle diğerinde de kullanılabilir. Plugins, connectors ve becerileri bir araya getirerek takım üyelerinizin tam yapılandırmayı hatırlamadan tek bir kurulumla kurmasını sağlar.

Bu, bir agentin size “bu tamir çözümü” dediği ile bir loop’un kendi kendine PR açması, Linear biletini ilişkilendirmesi ve CI geçtikten sonra kanala bildirme işlemi arasındaki farktır. Connectors’un önemli olmasının nedeni, loop’un sadece “Eğer yapabilseydim, bunu yapardım” demek yerine, gerçek ortamınızda harekete geçmesini sağlamasıdır.

Bir döngü içinde, en kullanışlı yapısal tasarım, "yazan" ile "kontrol eden" kişiyi ayırmaktır. Kod yazan model, kendi ödevini değerlendirdiğinde çok kolaylıkla aşırı hoşgörülü davranır. Farklı talimatlarla, hatta bazen farklı bir model kullanan başka bir akıllı sistem, ilk akıllı sistemin kendi kendini ikna ettikten sonra gözden kaçırdığı sorunları yakalayabilir.

Codex, yalnızca isteğinizi aldığında subagent'ler oluşturur, bunlar paralel olarak çalışır ve sonuçları tek bir cevapta birleştirir. Kendi agent'lerinizi .codex/agents/ dizinindeki TOML dosyalarıyla tanımlayabilirsiniz: her bir agent'ın adı, açıklaması, talimatları ve isteğe bağlı olarak modeli ve çıkarım şiddeti bulunur. Bu nedenle güvenlik denetmeniniz yüksek çıkarım şiddetiyle güçlü bir model olabilirken, keşif görevi için hızlı ve salt okunabilir hafif bir model kullanabilirsiniz. Claude Code, .claude/agents/ içindeki subagent'ler ve agent takımları aracılığıyla benzer bir yeteneğe sahiptir ve birden fazla agent'in birbirleri arasında iş paylaşmasını sağlar. Her iki sistemde de en yaygın görev dağılımı şudur: bir agent keşfeder, bir agent uygular, bir agent de spesifikasyona göre doğrular.

Bu fikri zaten iki kez açıkladım: biri code agent orchestra'da, diğeri adversarial code review'da. Özellikle döngü içinde önemlidir, çünkü döngü siz gözlemlemeyince çalışır; bu nedenle, gerçekten güvenebileceğiniz bir doğrulayıcı, ayrılmaya cesaret edebileceğiniz tek nedenidir. Alt agens, her bir agent'ın kendi model çağrısını ve araç çağrısını yapması nedeniyle daha fazla token tüketir; bu nedenle onları "ikinci görüşün ödenecek değer taşıdığı" yerlerde kullanmalısınız. Bu temelde Claude Code'un /goal'inin alt seviyede yaptığı şeydir: işi yapan modelin değil, yeni bir modelin döngünün tamamlandığını karar vermesi. Yani, bu, "üretici" ve "denetleyici" ayrımını durma koşuluna uygular.

Bir döngü nasıl görünür

Bu şeyleri bir araya getirin, tek bir iş parçacığı küçük bir kontrol paneline dönüşür. Aşağıda sık kullandığım bir yapı var.

Her sabah, bir otomasyon kod deposunda çalışır. İpucu, dünün CI hatalarını, açık olan sorunları ve son commitleri okuyan bir triage becerisini çağırır ve bulguları bir Markdown dosyasına veya Linear panosuna yazar. Her bir ele alınması değerli sorun için, bir thread izole bir worktree açar, bir alt-ajantı düzeltme önerisi taslaklamak için gönderir ve ikinci bir alt-ajantı, proje becerilerine ve mevcut testlere göre bu öneriyi incelemek için gönderir.

Bağlayıcılar, bu döngünün kendi kendine PR açmasına ve bilet güncellenmesine izin verir. Döngü tarafından işlenemeyen her şey, triage inbox'a gönderilir ve benim tarafımdan işlenir. Durum dosyası, tüm sistemin omurgasıdır: neyin denenmiş olduğunu, neyin başarılı olduğunu ve neyin hâlâ tamamlanmamış olduğunu hatırlar. Bu nedenle, bir sonraki günün sabah çalışması, bugün durulan yerden devam eder.

Ne yaptığınızı dikkatli düşünün. Sadece bir kez tasarladınız. Bu adımları tek tek kendiniz önermediniz. İşte Steinberger'in bu sözünün gerçek versiyonu. Aynı döngü, Codex'te de Claude Code'da da çalışabilir, çünkü bileşenler aynı bileşenlerdir.

Loop hâlâ sizin için hiçbir şey yapmayacak

Loop çalışma şeklini değiştirdi, ancak sizi işten çıkarmaz. Aslında, loop daha güçlü hale geldikçe, üç sorun daha kolay değil, daha keskin hale gelir.

Doğrulama hâlâ sizin elinizde. Başkasının gözetimi olmadan çalışan bir döngü, aynı zamanda başkasının gözetimi olmadan hata yapma ihtimalini de barındırır. Doğrulayıcı alt-ajantı ve maker’ı ayırmak, döngünün “tamamlandı” demesinin bir anlam kazanmasını sağlamak içindir. Buna rağmen, “tamamlandı” hâlâ bir iddia, bir kanıt değil. Yapay zekânın çağında kod incelemesi konusunda sürekli aynı cümleyi tekrarlıyorum: Göreviniz, etkin olduğunu doğruladığınız kodu teslim etmektir.

Bırakırsanız, kendi anlayışınız çürür. Kendi yazmadığınız kodu Loop ne kadar hızlı teslim ederse, anladığınız şeyler ile sistemde gerçekten var olan şeyler arasındaki fark o kadar büyür. İşte comprehension debt (anlama borcu). Loop'un ürettiği şeyleri okumazsanız, sorunsuz bir Loop bu borcu daha da hızla artırır.

Ayrıca, evet, en rahat pozisyon muhtemelen en tehlikeli pozisyon olur. Loop kendi kendine çalışırken, kendi yargılarınızı oluşturmayı bırakıp döndürülen her şeyi kabul etmek kolaylaşır. Buna bilişsel teslimiyet diyorum. Loop'u yargılarınızla tasarlıyorsanız, bu ilacıdır; düşünceden kaçmak için loop tasarlıyorsanız, bu hızlandırıcıdır. Aynı eylem, tamamen karşıt sonuçlar doğurabilir.

Döngü oluşturun, ancak mühendis olmaya devam edin

Bence bu, gelecekteki işlerimizin gelişim yönünü öngörüyor. Bununla birlikte, kodu kendi gözümle incelemesem veya kodu tamamen otomatik döngülere güvensek, ürün kalitem zarar görecektir. Kendimi daha derin bir çukura çekmek için sürekli olarak bir aşağı doğru spiralde bulunma tehlikesiyle karşı karşıya kalırım.

Bu nedenle kendi döngünüzü kurabilirsiniz, ancak akıllı ajanınıza doğrudan talimat vermenin hâlâ etkili olduğunu unutmayın. Anahtar, uygun dengeyi bulmaktır.

Loop'un sonucu kişiye göre değişir. İki kişi tamamen aynı loop'u oluşturabilir, ancak tamamen farklı sonuçlar elde edebilir. Birisi, derinlemesine anladığı bir işte hız kazanmak için kullanır; diğeri, işi anlamaktan kaçmak için kullanır. Loop, bu ikisi arasındaki farkı bilmez. Siz bilirsiniz.

Bu, neden loop design’ın (döngü tasarımı) prompt engineering’den (ipucu mühendisliği) daha kolay değil, daha zor olduğunu açıklar. Cherny’nin kastettiği, işin daha kolaylaşması değil, kaldıraç noktasının değişmesidir.

Döngü oluşturun. Ancak sadece “başlat” düğmesine basmakla görevli biri gibi değil, hâlâ mühendis olmayı planlayan biri gibi oluşturun.

[原文链接]

Dinamik BlockBeats'ta açık pozisyonları öğrenmek için tıklayın

Lütfen BlockBeats Resmi Topluluğuna katılın:

Telegram abone grubu: https://t.me/theblockbeats

Telegram iletişim grubu: https://t.me/BlockBeats_App

Twitter resmi hesabı: https://twitter.com/BlockBeatsAsia