Döngü mühendisliği nedir ve nasıl uygulanır?

Döngü mühendisliği ne anlama gelir

Döngü mühendisliği, bir AI ajanının çalıştırdığı tekrarlayan döngüyü tasarlama pratiğidir: ajanı neyin uyandırdığı, nelere erişebildiği, çıktısının nasıl denetlendiği ve sürecin ne zaman durdurulacağı bu kapsamdadır. Prompt mühendisliği, modele gönderilen tek bir mesajı şekillendirir. Döngü mühendisliği ise siz uyurken binlerce mesaj gönderen süreci şekillendirir. İş birimi, prompt seviyesinden döngü seviyesine taşınır.

Kısaca özetlemek gerekirse: talimat yazmayı bırakıp bir kontrol sistemi yazmaya başlarsınız. Ajanın hala iyi talimatlara ihtiyacı vardır, ancak bu talimatlar artık belirli bir zaman çizelgesinde çalışan, kodunuzun yalıtılmış bir kopyası üzerinde işlem yapan, kendi sonucunu bir test ile doğrulayan ve bütçe tükendiğinde duran bir döngünün parçası haline gelir.

Terim neden 2026 yılında ortaya çıktı

İsim şu anda kamuoyunda netleşmektedir. cobusgreyling/loop-engineering GitHub deposu, ilk ortaya çıkışından (Temmuz 2026 itibarıyla) sonraki iki ay içinde "İstem girmeyi bırakın. Döngüyü tasarlayın. Bir skor elde edin." sloganı altında 9,600 yıldızı geçti. Bu durum, değişimi altı yapı taşına ayırıyor: zamanlama, çalışma ağaçları (worktrees), beceriler, eklentiler ve bağlayıcılar, alt-ajanlar ve konuşmanın dışında tutulan kalıcı bellek.

Bu durum, Anthropic'te Claude Code'u yöneten Boris Cherny'den alıntı yapıyor:

Artık Claude'a istem girmiyorum. Claude'u yönlendiren döngüler çalıştırıyorum.

İkinci bir depo olan AI-Builder-Club/skills, (Temmuz 2026 itibarıyla) 1,100 yıldız civarında seyrediyor ve iki rolü doğrudan isimlendiriyor: bir ajanın testleri çalıştırması ve dağıtım yapması için bir depoyu güvenli hale getiren bir "kod tabanı donanımı" (codebase harness) ve bir tetikleyici ile uyanan, işi yapan ve öğrendiklerini bir sonraki döngünün okuyabilmesi için paylaşılan bir dosyaya yazan iş akışları oluşturan bir "döngü mühendisi" (loop engineer).

Her iki depo da bu uygulamayı icat etmedi. Gece derlemesi (nightly build), sürekli entegrasyonda bir linter veya bir bilet açan bir cron işi çalıştıran herkes, bu yapının şeklini zaten biliyor. Yeni olan şey, döngünün içindeki çalışanın artık deterministik olmamasıdır; bu da çevresindeki mekanizmanın yapması gerekenleri değiştirmektedir.

Döngünün dört parçası

Çalışan her döngü bu dört parçadan oluşur; bunlardan birini atlayan bir döngü, sizi gece saat 03:00'te uyandıracak olan döngüdür.

• Tetikleyici (Trigger). Çalıştırma işlemini başlatan olay: bir zamanlayıcı, bir webhook, yeni bir pull request veya bir uyarı.
• Sınır (Boundary). Aracın çalışma süresi boyunca erişebileceği dosyalar, kimlik bilgileri ve ağ.
• Doğrulama (Verification). Çalıştırma çıktısının saklanıp saklanmayacağına karar veren, çıkış kodu tabanlı bir denetim.
• Bütçe (Budget). Başarılı olup olmadığına bakılmaksızın çalıştırma işlemini sonlandıran token, zaman ve maliyet sınırı.

Bu dört maddeyi soru olarak tekrar okuduğunuzda, çalışır durumda bırakacağınız herhangi bir aracı gözden geçirmek için gerekli tasarım denetimini yapmış olursunuz.

Tetikleyici: Aracın çalışmasını ne başlatır

Zamanlayıcı en basit tetikleyicidir. Linux sunucularda systemd zamanlayıcı, cron'a göre daha üstündür; çünkü günlük kaydı tutar, belirlediğiniz şartlara göre yeniden deneme yapar ve halihazırda çalışmakta olan bir birimin ikinci bir kopyasını başlatmaz. Bu son özellik, aracı döngülerindeki en yaygın çakışma hatasını ortadan kaldırır: aynı dal üzerinde işlem yapan iki eşzamanlı çalışma.

Birim dosyasını /etc/systemd/system/agent-loop.service konumunda oluşturun:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Ve zamanlayıcıyı /etc/systemd/system/agent-loop.timer konumunda oluşturun:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers komutu, gelecekteki bir zamanı gösteren bir NEXT sütunu ve geri sayım yapan bir LEFT sütunu göstermelidir. Boş bir sonuç, zamanlayıcının etkinleştirilmediği anlamına gelir; çünkü --now kullanılmadan çalıştırılan enable, zamanlayıcıyı yalnızca bir sonraki önyükleme için planlar. TimeoutStartSec=1800 göründüğünden daha önemlidir: girdi beklerken takılan bir araç, birimi sonsuza kadar aktif tutar ve zamanlayıcı bir daha asla tetiklenmez. Çalışma kayıtlarını journalctl -u agent-loop.service -n 50 ile okuyun.

Döngüyü cron üzerinden yönetmeyi tercih ederseniz, kendi çakışma korumanızı ekleyin; çünkü cron, ikinci bir kopyayı başlatmaktan çekinmeyecektir:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n, kilit tutulduğunda 1 durum koduyla hemen sonlanır; böylece ikinci çalışma, ilkiyle yarışmak yerine sessizce kaybolur. Aynı systemd servis ve zamanlayıcı kurulumu, araç olsun ya da olmasın, sunucudaki tüm uzun süreli işler için geçerlidir.

Sınır: her çalıştırmaya kendi kopyasını atayın

Çalışma ağacınız üzerinde değişiklik yapan bir aracı, kaydedilmemiş çalışmalarınızı kaybetmenize neden olabilir. Git worktrees bu sorunu düşük maliyetle çözer: her çalıştırma, tek bir nesne deposunu paylaşarak kendi dizinine ve kendi dalına sahip olur.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list, her ağaç için yolu, commit bilgisi ve dalı içeren tek bir satır yazdırır. Çalıştırma sona erdiğinde git worktree remove /srv/agent/work/triage-01 dizini siler ve git worktree prune, dizini artık mevcut olmayan girdileri temizler. İki farklı dizindeki iki farklı dal üzerinde çalışan iki aracı birbirinin üzerine yazamayacağı için, paralel döngüler bu noktada güvenli hale gelir.

Sınır aynı zamanda kimlik bilgileriyle de ilgilidir. Gözetimsiz çalışan bir döngü uzun ömürlü belirteçler (token) tutar ve her çalıştırma, bu belirteçlerden birini bir günlüğe, bir commit işlemine veya model bağlamına sızdırma riski taşır. Belirteci döngünün eriştiği tek bir depo ile sınırlandırın, mümkün olduğunca aracın kendi kabuğunun gördüğü ortamdan uzak tutun ve bir döngüye üretim ortamı erişimi vermeden önce yapay zeka araçlarından sırları nasıl uzak tutacağınızı okuyun. Daha katı bir duvar için, tüm döngüyü her çalıştırmadan sonra yok edebileceğiniz geçici bir sanal makineye taşıyın. Hangi aracı çalıştırdığınız da herhangi bir kod yazmadan önce sınırın bir kısmını belirler; bu nedenle ne kadar izolasyon inşa etmeniz gerektiğine karar vermeden önce Cowork'ün yönetilen korumalı alanının kendi makinenizdeki Claude Code ile nasıl karşılaştırıldığını okumanızda fayda vardır.

Doğrulama: döngüyü güvenli kılan kapı

Burası, bir döngüyü sadece komut yazan bir cron işinden ayıran kısımdır. Ajanın çıktısı bir öneridir. Kapı ise kararı verir.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail, bu betik içerisinde gerçek işi yapan kısımdır. -e olmadan, başarısız olan bir git fetch göz ardı edilir ve çalışma, güncelliğini yitirmiş bir origin/main üzerinde devam eder. -u olmadan, bir değişken ismindeki yazım hatası boş bir dizgiye genişler ve temizleme işlemi başarısız olmak yerine yanlış bir yol üzerinde çalışır.

if ! npm test bloğu, tüm fikrin temelidir. Zaten güvendiğiniz bir kontrolün, test paketinizin veya tip denetleyicinizin çıkış kodu, dalın gönderilip gönderilmeyeceğine veya silinip silinmeyeceğine karar verir. Kapısı olmayan bir döngü, kimsenin incelemeye vakti olmayan işler üretir; bu da hiç iş üretmemekten daha kötüdür. Kapısı olan bir döngü ise, insan bir katkıcının dalının geçmesi gereken aynı standartları karşılayan bir dal üretir. Yeşil bir kapı, ajanın oraya ulaşmak için koda ne kadar müdahale ettiği hakkında hiçbir şey söylemez; bu nedenle kontrolü, ajanın çalışan en küçük değişikliği yapmasını sağlayan kural gibi daimi bir talimatla eşleştirmek faydalıdır. Bu, diff boyutunu incelemenin ucuz kalacağı kadar küçük tutar.

Dürüstçe başarısız olan bir kapı seçin. Boş bir diff üzerinde başarılı olan bir test paketi, döngüye hiçbir şey yapmamanın bir başarı olduğunu öğretir. Zayıf testlere sahip depolar zayıf döngüler üretir; bu yüzden popüler depolar "kod tabanını ajan için hazır hale getirmeyi", "döngüyü yazmaktan" önce tutar. Paketinizin satırları çalıştırmak yerine gerçekten bir regresyonu yakalayıp yakalamayacağını bilmek istiyorsanız, mutasyon testi bu soruyu yanıtlayan kontroldür ve sizden diff'ini okumanızı istemek yerine yeniden çalıştırılabilir bir kanıt raporu sunan bir ajan, bu yanıtı kendiniz doğrulayabileceğiniz bir şeye dönüştürür.

Bütçe: bir çalışmayı ne durdurur

Sürekli yeniden deneme yapan bir aracı, sınırsız bir fatura demektir. Her döngüye, yukarıdaki TimeoutStartSec ile zorunlu kılınan bir zaman sınırı; betiğinizin içinde bir yeniden deneme sayısı; ve sağlayıcı hesabınız tarafından uygulanan bir harcama limiti koyun. Ardından, her çalışmanın maliyetini günlüğe kaydedin; böylece fatura gelmeden önce döngüdeki sapmayı görebilirsiniz. Her zaman açık bir aracı VPS için maliyet kontrolü muhasebe tarafını ele alır ve bir aracın turlar arasında taşıdığı bağlamı yönetmek, çalışma başına maliyeti etkileyen en büyük tekil unsuru kapsar; çünkü her 30 dakikada bir aynı depoyu yeniden okuyan bir döngü, bunun bedelini her 30 dakikada bir öder.

Maliyet, döngülerin genellikle tek bir uzun oturumdan daha avantajlı olmasının nedenidir. Sıfırdan başlayan, tek bir dar kapsamlı işi yapan ve sonlanan bir çalışma, bağlamını küçük tutar. Sekiz saat boyunca açık bırakılan bir oturum, geçmişindeki her hatayı taşır ve her turda tüm transkriptin bedelini öder.

Trend olan depoların kodlaştırdığı modeller

loop-engineering deposu yedi adet üretim modeli listeler; bunlar bir manifesto olmaktan ziyade bir menü olarak okunmaya değerdir. Günlük önceliklendirme (triage). Gözden geçirme yorumlarını izleyen ve yanıtlayan bir pull-request sorumlusu. Hatalı derlemeleri (red builds) tespit eden bir sürekli entegrasyon temizleyicisi. Bir bağımlılık temizleyicisi. Bir değişiklik günlüğü (changelog) taslakçısı. Merge sonrası temizlik. Sorun önceliklendirme.

Bu modellerin ortak noktası, belirgin bir geçiş koşuluna sahip dar kapsamlı işler olmalarıdır. "Başarısız olan derlemeyi düzelt" görevi, makinenin okuyabileceği bir başarı koşuluna sahiptir. "Kod tabanını iyileştir" görevi ise böyle bir koşula sahip değildir, bu yüzden asla bir döngüye dönüşemez. Sadece bir takvime bağlanmış bir karmaşaya dönüşür.

Ayrıca yazılı bir kayıt tutma konusunda da ortaktırlar. Her iki depo da durumu konuşma içerisinden çıkarıp depo içerisindeki dosyalara aktarır: ne çalıştırıldı, ne bulundu, neye karar verildi. Bu dosya döngünün hafızasıdır ve ikinci bir döngünün, ilk döngünün işini yeniden keşfetmek yerine onun üzerine inşa edebilmesinin nedenidir. Aynı zamanda bir ajanı işlem sonrasında denetlemenin yolu da budur, çünkü modelin bağlamı çalışma bittiği anda kaybolur. Canlı koordinasyon ayrı bir kanaldır ve bir Claude Code oturumu, aynı makine üzerinde çalışan başka bir oturuma iş devredebilir; ancak bu alışverişteki hiçbir şey oturumların ömrünü aşmaz, bu yüzden dosya daha sonra dönüp okuyacağınız kısım olarak kalır.

Döngülerin başarısız olduğu durumlar

Hatalar sıkıcıdır ve ekipler arasında sürekli tekrarlanır.

• Denetim eksikliği. Çıktı birikir, kimse incelemez, güven sarsılır ve döngü kapatılır.
• Çakışma. Aynı dal üzerinde iki çalıştırma veya bir çalışma ağacında iki aracı bulunması, aracın çözmeye çalıştığı çakışmalara yol açar.
• Sessiz sapma. Kontrol mekanizması başarısızlığı tespit edemeyecek kadar zayıf olduğu için döngü başarılı sayılmaya devam eder.
• Sınırsız kapsam. Yoğun bir depoda her commit işleminde tetiklenen bir süreç, bir gün içinde maliyet sorununa dönüşür.

Her birinin çözümü aynıdır: işi küçültün, kontrolü keskinleştirin ve çalıştırma kaydını tutun. Başarı koşulunu tek bir cümleyle tanımlayamıyorsanız, o iş otomasyona hazır değildir.

Kelime dağarcığına ihtiyaç duymadan başlangıç

Bir framework kullanmanıza gerek yoktur. Her zaman açık, küçük bir Linux sunucusu, test paketi gerektiğinde hata veren bir git deposu, bir adet systemd timer ve içinde if bulunan bir shell script, tam bir döngü oluşturmak için yeterlidir. Çoğu kişi için başlangıç noktası gerçekten burası olmalıdır; çünkü tasarım soruları bir araç seçilerek değil, sistem çalıştırılarak yanıtlanır. Bir döngü kararlı hale geldiğinde, ikincisini çalıştırmak büyük oranda başka bir timer ve başka bir worktree eklemekten ibarettir. Temel kurulum için bir VPS üzerinde kodlama yapan yapay zeka ajanı nasıl çalıştırılır kısmına, ajanın kendi kontrolünüzdeki donanımda çalışmasını istiyorsanız mevcut self-hosted yapay zeka ajanı seçenekleri kısmına göz atın.

FAQ

Loop engineering, prompt engineering'den farklı mıdır?

Prompt engineering tek bir mesajı; ifade biçimini, örnekleri ve çıktı formatını optimize eder. Loop engineering ise mesajın etrafındaki döngüyü optimize eder: çalışmayı başlatan tetikleyici, çalışmanın gerçekleştiği sandbox, çıktıyı kabul eden veya reddeden denetim mekanizması ve süreci sonlandıran bütçe sınırı. Döngü içerisinde hala iyi bir prompt'a ihtiyaç duyarsınız. Ancak prompt, günlük olarak üzerinde ince ayar yaptığınız bir öğe olmaktan çıkar; çünkü sonuç üzerinde denetim mekanizması ve tetikleyicinin etkisi daha fazladır.

Bir agent döngüsü oluşturmak için bir framework kullanmam gerekir mi?

Hayır. Bir systemd timer, her çalışma için ayrı bir git worktree, test komutuyla sonlanan bir shell script ve sağlayıcı hesabındaki harcama limiti, tanımın her parçasını karşılar. Framework'ler; zamanlama arayüzleri, paylaşımlı bellek formatları ve çoklu agent yönlendirmesi gibi özellikler ekler; bunlar birden fazla döngü çalıştırdığınızda kullanışlıdır. İlk döngü için giriş maliyeti değildirler.

Codebase harness nedir?

Bir agent'ın insan müdahalesi olmadan bir repository üzerinde çalışmasını sağlayan araçlar bütünüdür: tek komutla kurulum, etkileşimsiz çalışan ve hata durumunda belirgin şekilde başarısız olan testler, bir linter ve değişiklikleri deploy etme veya önizleme yöntemi. Terim, loop engineering ile aynı 2026 dönemi repository dalgasından çıkmıştır. Pratik test basittir: yeni bir insan katkı sağlayıcı, clone işleminden yeşil testlere tek komutla geçemiyorsa, bir agent da geçemez.

Bir agent döngüsünün yüksek fatura çıkarmasını nasıl engellerim?

Üç noktada sınırlandırın. Askıda kalan bir çalışmanın sonlandırılması için systemd unit üzerinde TimeoutStartSec ayarını yapın. Başarıya ulaşana kadar döngüye girmek yerine, script içerisindeki yeniden deneme sayılarını sınırlandırın. API hesabında kesin bir harcama limiti belirleyin; çünkü bu, agent'ın aşamayacağı tek tavan sınırıdır. Ardından çalışma başına maliyeti loglayın; çünkü maliyeti ikiye katlanan bir döngü, genellikle kapsamı sessizce genişletilmiş bir döngüdür.

Hangi işleri ilk olarak bir döngüye dönüştürmeye değer?

Makine tarafından okunabilir bir başarı koşulu olan ve etki alanı (blast radius) küçük bir iş seçin. Kırmızı bir build'i düzeltmek, bir bağımlılığı güncellemek ve bir changelog oluşturmak bu tanıma uyar; çünkü bir test paketi veya diff sonucu doğrulayabilir. Refactoring veya tasarım gibi ucu açık işler henüz bu tanıma uymaz; çünkü denetim mekanizmasının kontrol edebileceği bir veri yoktur ve denetim mekanizması olmayan bir döngü, inceleme borcu oluşturmanın pahalı bir yoludur.