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şiyor. cobusgreyling/loop-engineering GitHub deposu, ilk ortaya çıkışından itibaren iki ay içinde 9,600 yıldızı (Temmuz 2026 itibarıyla) geçti ve 2026-10-27 tarihinde "İstem yazmayı bırakın. Döngüyü tasarlayın. Puan alın." satırı altında yaklaşık 11,600 yıldız gösterdi. Temmuz 2026'daki README dosyası, bu değişimi altı yapı taşına ayırmıştı: 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. Mevcut README dosyası artık bu listeyi içermiyor (2026-10-27 tarihinde kontrol edildi), ancak döngünün durumunu konuşmanın dışında bir dosyada tutmaya devam ediyor.

Depo, Anthropic bünyesinde Claude Code'u yöneten Boris Cherny'yi ilham kaynaklarından biri olarak gösteriyor. Cherny'nin sıkça alıntılanan ifadesi şöyledir:

Artık Claude'a istem yazmıyorum. Claude'a istem gönderen döngüler çalıştırıyorum.

İkinci bir depo olan AI-Builder-Club/skills, 1,300 yıldız civarında seyrediyor (2026-10-27 itibarıyla) ve iki rolü doğrudan isimlendiriyor: bir ajanın testleri ve dağıtımları güvenli bir şekilde çalıştırabilmesi için depoyu hazırlayan 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ını inşa eden bir "döngü mühendisi".

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ü içindeki çalışanın artık deterministik olmamasıdır; bu durum, ç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: ajanı ne uyandırır

Zamanlayıcı en basit tetikleyicidir. Bir Linux sunucusunda systemd zamanlayıcı, cron'dan daha üstündür; çünkü günlük kaydı tutar, belirlediğiniz şartlarda yeniden dener ve hâlihazırda çalışmakta olan bir birimin ikinci bir kopyasını başlatmaz. Bu son özellik, ajan döngülerindeki en yaygın çakışma hatasını ortadan kaldırır: aynı dal üzerinde değişiklik yapan iki çalışma.

Öncelikle ajana kendi kullanıcı hesabını atayın. Bu kullanıcı sınırın bir parçasıdır, bu nedenle yalnızca /srv/agent dizinine sahiptir ve başka hiçbir şeye erişimi yoktur:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Ardından /etc/systemd/system/agent-loop.service konumundaki birim dosyasını 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 /etc/systemd/system/agent-loop.timer konumundaki zamanlayıcıyı 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 olmadan kullanılan enable, zamanlayıcıyı yalnızca bir sonraki açılış için planlar. TimeoutStartSec=1800, göründüğünden daha önemlidir. Bir Type=oneshot servisi, betiği sonlanana kadar çalışıyor sayılır ve systemd, oneshot birimler için varsayılan olarak başlatma zaman aşımını devre dışı bırakır. Bu satır olmazsa, girdi beklerken takılan bir ajan, birimi sonsuza kadar etkinleştirme durumunda bırakır ve sonraki her zamanlayıcı tetiklemesi, birimin hâlâ çalıştığını görerek hiçbir şey başlatmaz. Bu satır eklendiğinde, systemd çalışmayı 30 dakika sonra sonlandırır ve başarısız olarak işaretler. Birimi varsayılan Type=simple türüne çevirirseniz, TimeoutStartSec artık çalışmanın kendisini kapsamaz ve RuntimeMaxSec=, süreyi sınırlayan ayar olur. Bir çalışmayı journalctl -u agent-loop.service -n 50 ile okuyun.

Döngüyü bunun yerine cron ile yönetiyorsanız, 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 durumuyla hemen çıkar; böylece ikinci çalışma, ilkiyle yarışmak yerine sessizce kaybolur. Aynı systemd servis ve zamanlayıcı kurulumu, ajan olsun veya 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ı kaybetme riski taşır. 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 yolunu, commit bilgisini ve dalını içeren tek satırlık bir çıktı verir. Çalıştırma sona erdiğinde, git worktree remove /srv/agent/work/triage-01 çalışma ağacını kaldırır ancak yalnızca temiz olanları siler. Eğer ağaçta takip edilmeyen dosyalar, değiştirilmiş takip edilen dosyalar veya alt modüller varsa, git siz --force ekleyene kadar işlemi reddeder; bu nedenle aşağıdaki geçit betiği, kaldırma işlemini yalnızca çalıştırmayı sonlandıran yol üzerinde zorunlu kılar. git worktree prune, dizini kaybolmuş girdileri temizler. Paralel döngüler bu noktada güvenli hale gelir, çünkü iki farklı dizindeki iki farklı dal üzerinde çalışan iki aracı birbirinin üzerine yazamaz.

Sınır aynı zamanda kimlik bilgileriyle de ilgilidir. Gözetimsiz çalışan bir döngü uzun ömürlü token'lar barındırır ve her çalıştırma, bir token'ın log dosyasına, bir commit'e veya model bağlamına sızması için bir fırsattır. Token'ı 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 erişimi vermeden önce yapay zeka araçlarından sırları nasıl uzak tutacağınızı okuyun. Daha sert bir duvar için, tüm döngüyü her çalıştırmadan sonra yok edebileceğiniz tek kullanımlık 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 sandbox ortamı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ı

Bu kısım, bir döngüyü sadece yazan bir cron işinden ayıran bölü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 olup hata vermek yerine yanlış bir yol üzerinde çalışır. Son satırda kasten --force kullanılmamıştır: eğer çalışma ağaçta izlenmeyen veya commit edilmemiş dosyalar bıraktıysa, git dizini silmeyi reddeder ve -e, kimsenin commit etmediği çalışmaları sessizce silmek yerine push işleminden sonra çalışmayı bir hata ile sonlandırı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 push edilip edilmeyeceğine veya yok edileceğine karar verir. Kapısı olmayan bir döngü, kimsenin incelemeye vakti olmayan işler üretir; bu ise hiç iş üretmemekten daha kötüdür. Kapısı olan bir döngü ise, bir insan katkıcının dalının geçmesi gereken standartları zaten geçmiş 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ü, bir ajanın çalışan en küçük değişikliği yapmasını sağlayan kural gibi kalıcı bir talimatla eşleştirmek, 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ı ajana hazır hale getirmeyi", "döngüyü yazmaktan" önce tutar. Test paketinizin satırları sadece çalıştırmak yerine bir regresyonu gerçekten 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ı kendinizin doğrulayabileceği 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

Döngü mühendisliği deposu sekiz üretim modeli listeliyor (2026-10-27 itibarıyla) ve bunlar bir manifestodan ziyade bir menü olarak okunmalıdır. Günlük triyaj. GitHub Action olarak çalışan ve durum dosyası tutmayan ince bir döngü. İnceleme yorumlarını izleyen ve yanıtlayan bir çekme isteği (pull-request) bakıcısı. Hatalı derlemeleri (red builds) toplayan bir sürekli entegrasyon süpürücüsü. Bağımlılık süpürücüsü. Değişiklik günlüğü taslakçısı. Birleştirme sonrası temizlik. Sorun triyajı.

Paylaştıkları ortak nokta, belirgin bir geçiş kapısına sahip dar kapsamlı bir iştir. "Başarısız derlemeyi düzelt" komutunun makine tarafından okunabilen bir başarı koşulu vardır. "Kod tabanını iyileştir" komutunun ise yoktur, bu yüzden asla bir döngüye dönüşmez. Sadece bir zaman çizelgesine sahip bir karmaşaya dönüşür.

Ayrıca yazılı bir kayıt tutma konusunda da ortaktırlar. Her iki depo da durumu konuşmanın dışına iterek depodaki dosyalara aktarır: ne çalıştı, ne buldu, neye karar verdi. O dosya döngünün belleğidir ve ikinci bir döngünün, ilk döngünün işini yeniden keşfetmek yerine onun üzerine inşa edebilmesinin nedenidir. Modelin bağlamı çalışma bittiği anda kaybolduğu için, bir ajanı sonradan denetlemenin yolu da budur. Canlı koordinasyon ayrı bir kanaldır ve bir Claude Code oturumu, her ikisi de çalışırken aynı makinedeki başka bir oturuma iş devredebilir, ancak bu alışverişte hiçbir şey oturumların ömrünü aşmaz, bu yüzden dosya daha sonra geriye 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

Döngü mühendisliği, istem mühendisliğinden farklı mıdır?

İstem mühendisliği tek bir mesajı optimize eder: ifade biçimi, örnekler ve çıktı formatı. Döngü mühendisliği ise mesajın etrafındaki döngüyü optimize eder: çalışmayı başlatan tetikleyici, içinde çalıştığı korumalı alan, çıktısını kabul eden veya reddeden denetim ve çalışmayı sonlandıran bütçe. Döngü içinde hâlâ iyi bir isteme ihtiyacınız vardır. İstem, günlük olarak üzerinde ince ayar yaptığınız şey olmaktan çıkar; çünkü kapı ve tetikleyici, sonuç üzerinde daha fazla etkiye sahiptir.

Bir ajan döngüsü oluşturmak için bir çatık (framework) kullanmam gerekir mi?

Hayır. Bir systemd zamanlayıcı, her çalışma için bir git worktree, test komutuyla biten bir kabuk betiği ve sağlayıcı hesabındaki harcama sınırı, tanımın her parçasını karşılar. Çatılar; zamanlama arayüzleri, paylaşımlı bellek formatları ve çoklu ajan yönlendirmesi ekler; bunlar birden fazla döngü çalıştırdığınızda yararlıdır. İlk döngü için giriş maliyeti değildirler.

Kod tabanı donanımı (harness) nedir?

Bir ajanın, insan müdahalesi olmadan bir depoda çalışmasını sağlayan araçlar bütünüdür: tek komutla kurulum, etkileşimli olmayan ve başarısız olduğunda belirgin hata veren testler, bir linter ve değişiklikleri dağıtmanın veya önizlemenin bir yolu. Terim, döngü mühendisliği ile aynı 2026 depo dalgasından çıkmıştır. Pratik test basittir: yeni bir insan katkıcı, tek bir komutla klonlamadan yeşil testlere geçemiyorsa, bir ajan da geçemez.

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

Üç noktada sınırlayın. Yukarıdaki gibi bir Type=oneshot systemd biriminde TimeoutStartSec ayarını yapın, böylece takılan bir çalışma öldürülür (Type=simple servisinde bunun karşılığı RuntimeMaxSec değeridir). Başarılı olana kadar döngüye girmek yerine, betik içindeki yeniden deneme sayılarını sınırlayın. API hesabına katı bir harcama limiti koyun; çünkü bu, ajanın aşamayacağı tek sınırdır. Ardından çalışma başına maliyeti kaydedin; çünkü maliyeti ikiye katlanan bir döngü, genellikle kapsamı sessizce genişletilmiş bir döngüdür.

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

Makine tarafından okunabilir bir geçiş koşulu ve küçük bir etki alanı olan bir iş seçin. Kırmızı bir derlemeyi düzeltmek, bir bağımlılığı güncellemek ve bir değişiklik günlüğünü yeniden oluşturmak, test paketi veya bir diff sonucu kanıtlayabildiği için uygundur. Yeniden düzenleme (refactoring) veya tasarım gibi ucu açık işler henüz uygun değildir; çünkü kapının kontrol edeceği bir şey yoktur ve kapısı olmayan bir döngü, inceleme borcu oluşturmanın pahalı bir yoludur.