SSD Nodes Learn 8GB RAM — yılda $66
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-01

Döngü mühendisliği nedir? Tanım ve açıklama

Döngü mühendisliği, AI agent'ın tekrarladığı tetikleyici, sınır, doğrulama ve bütçeyi tasarlamaktır. Tek bir etkili prompt yazmaktan farkını öğrenin.

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

Döngü mühendisliği, bir AI agent'ın yürüttüğü yinelenen döngünün tasarlanmasıdır: onu neyin uyandırdığı, hangi kaynaklara erişebileceği, çıktısının nasıl denetlendiği ve döngüyü neyin durdurduğu belirlenir. Prompt mühendisliği, bir modele gönderilen tek bir mesajı şekillendirir. Döngü mühendisliği, siz uyurken binlerce mesaj gönderen süreci şekillendirir. İş birimi prompt'tan döngüye taşınır.

Kısaca, yönergeler yazmayı bırakıp bir kontrol sistemi yazmaya başlanır. Agent'ın hâlâ iyi yönergelere ihtiyacı vardır. Ancak bu yönergeler, bir zamanlamayla çalışan, kodunuzun yalıtılmış bir kopyasında işlem yapan, sonucunu bir testle doğrulayan ve bütçe tükendiğinde duran döngünün bileşenlerinden biri hâline gelir.

Terimin 2026'da ortaya çıkmasının nedeni

Adlandırma şu anda kamuya açık biçimde yerleşiyor. cobusgreyling/loop-engineering GitHub deposu, ilk ortaya çıkışından sonraki iki ay içinde 9,600 yıldız aldı (Temmuz 2026 itibarıyla). Depo, "Stop prompting. Design the loop. Get a score." ifadesini kullanıyor. Bu yaklaşımı altı yapı taşında topluyor: zamanlama, worktree'ler, beceriler, eklentiler ve bağlayıcılar, alt aracılar ve konuşmanın dışında tutulan kalıcı bellek.

Anthropic'te Claude Code'un liderliğini yapan Boris Cherny'den şu alıntı yapılıyor:

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

İkinci bir depo olan AI-Builder-Club/skills, yaklaşık 1,100 yıldız almış durumda (Temmuz 2026 itibarıyla) ve iki rolü doğrudan adlandırıyor: Bir deponun içinde bir aracının testleri çalıştırmasını ve dağıtımları gerçekleştirmesini güvenli kılan "codebase harness" ve bir tetikleyiciyle uyanan, işi yapan ve öğrendiklerini paylaşılan bir dosyaya yazarak sonraki döngünün okuyabilmesini sağlayan iş akışları oluşturan "loop engineer".

Bu uygulamayı iki depo da icat etmedi. Her gece çalışan bir derleme, sürekli tümleştirme içinde çalışan bir linter veya ticket açan bir cron job çalıştırmış olan herkes temel yapıyı zaten bilir. Yeni olan, döngünün içindeki çalışanın artık deterministik olmamasıdır. Bu durum, çevresindeki mekanizmaların yapması gerekenleri değiştirir.

Bir döngünün dört bölümü

Çalışan her döngü bu dört bölüme sahiptir. Bunlardan birini atlayan döngü, sizi saat 3'te uyandırır.

  • Tetikleyici. Bir çalıştırmayı başlatan olaydır: zamanlayıcı, webhook, yeni bir pull request veya uyarı.
  • Sınır. Agent'ın bu çalıştırma sırasında erişebileceği dosyalar, kimlik bilgileri ve ağdır.
  • Doğrulama. Çalıştırmanın çıktısının korunup korunmayacağına veya atılıp atılmayacağına karar veren, exit code kullanan denetimdir.
  • Bütçe. Çalıştırma başarılı olsa da olmasa da onu sonlandıran token, süre ve maliyet sınırıdır.

Bu dört bölümü soru olarak yeniden okuyun. Böylece çalışır durumda bırakmayı planladığınız herhangi bir agent için tasarım incelemesi yapmış olursunuz.

Tetikleyici: aracıyı ne çalıştırır

Zamanlayıcı en basit tetikleyicidir. Linux sunucusunda systemd timer bu iş için cron'dan daha uygundur. Günlük kaydı tutar, yeniden denemeleri belirlenen kurallara göre yapar ve hâlâ çalışan bir unit'in ikinci kopyasını başlatmaz. Son özellik, aracı döngülerindeki en yaygın çakışma hatasını ortadan kaldırır: aynı branch üzerinde çalışan iki işlem.

Unit'i /etc/systemd/system/agent-loop.service konumuna yazın:

[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

Timer'ı /etc/systemd/system/agent-loop.timer konumuna yazın:

[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, gelecekteki bir zamanı gösteren NEXT sütununu ve geri sayım yapan LEFT sütununu göstermelidir. Sonucun boş olması, timer'ın etkinleştirilmediği anlamına gelir. Bunun nedeni, enable komutunun --now olmadan kullanıldığında timer'ı yalnızca bir sonraki açılış için zamanlamasıdır. TimeoutStartSec=1800 beklenenden daha önemlidir. Girdi beklerken takılan bir aracı, aksi hâlde unit'i süresiz olarak etkin durumda tutar ve timer bir daha çalışmaz. Bir çalıştırmanın günlüğünü journalctl -u agent-loop.service -n 50 ile okuyun.

Döngüyü cron üzerinden çalıştırıyorsanız kendi çakışma korumanızı ekleyin. Çünkü cron ikinci bir kopyayı başlatır:

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

Kilit alınmışsa flock -n hemen status 1 ile çıkar. Böylece ikinci çalıştırma, ilk çalıştırmayla yarışmak yerine sessizce sonlanır. Aynı systemd service ve timer kurulumu, aracı olsun veya olmasın, sunucudaki tüm uzun süre çalışan işler için geçerlidir.

Sınır: her çalıştırma için ayrı bir kopya kullanın

Çalışma ağacınızı düzenleyen bir aracı, commit edilmemiş çalışmalarınızı kaybedebilecek bir işlem olarak değerlendirin. Git worktree bu sorunu düşük maliyetle çözer: her çalıştırma kendi dizinine ve kendi branch'ine sahip olur, ancak aynı nesne deposunu paylaşır.

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'ini ve branch'ini içeren bir satır yazdırır. Çalıştırma sona erdiğinde git worktree remove /srv/agent/work/triage-01 dizini siler, git worktree prune ise dizini ortadan kalkmış girdileri temizler. Bu aşamada paralel döngüler güvenli hale gelir; çünkü farklı dizinlerdeki iki branch üzerinde çalışan iki aracı birbirinin üzerine yazamaz.

Sınır, kimlik bilgilerini de kapsar. Denetimsiz çalışan bir döngü, uzun ömürlü token'lar barındırır ve her çalıştırma, bunlardan birinin günlüğe, commit'e veya model bağlamına sızması için bir fırsattır. Token'ı döngünün eriştiği tek repository ile sınırlandırın. Mümkün olduğunda token'ı aracının kendi shell'inin gördüğü ortamdan uzak tutun. Döngüye production erişimi vermeden önce gizli bilgileri AI aracılarından uzak tutma yöntemini okuyun. Daha güçlü bir yalıtım için tüm döngüyü, her çalıştırmadan sonra yok edebileceğiniz geçici bir VM üzerinde çalıştırın.

Doğrulama: döngüyü güvenli kılan geçit

Bu bölüm, bir döngüyü komut yazan bir cron job'ından ayırır. Aracının çıktısı bir öneridir. Kararı geçit 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 betikte gerçekten iş yapar. -e olmadan başarısız bir git fetch yok sayılır ve çalıştırma eski origin/main üzerinde devam eder. -u olmadan değişken adındaki bir yazım hatası boş bir dizgeye genişler. Bunun sonucunda cleanup, işlemi açıkça başarısız kılmak yerine yanlış yol üzerinde çalışır.

if ! npm test bloğu bütün fikri içerir. Zaten güvendiğiniz bir denetimin (test paketinizin veya tür denetleyicinizin) çıkış kodu, dalın push edilmesine veya silinmesine karar verir. Geçidi olmayan bir döngü, kimsenin inceleyecek zamanı olmayan işler üretir. Bu, hiç iş üretmemekten daha kötüdür. Geçidi olan bir döngü ise insan katkıcının dalının geçmesi gereken aynı ölçütü zaten geçmiş bir dal üretir.

Dürüstçe başarısız olan bir geçit seçilmelidir. Boş bir diff üzerinde başarılı olan bir test paketi, döngüye hiçbir şey yapmamanın başarı olduğunu öğretir. Testleri zayıf olan depolar zayıf döngüler üretir. Bu nedenle trend olan depolar, "döngüyü yaz" işleminden önce "kod tabanını agent-ready hale getir" işlemini koyar.

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

Sonsuza kadar yeniden deneyen bir ajan, sınırlandırılmamış bir fatura anlamına gelir. TimeoutStartSec tarafından yukarıda uygulanan duvar saati sınırını her döngü için belirleyin; betiğinizin içinde yeniden deneme sayısını sınırlayın; sağlayıcı hesabı tarafından uygulanan bir harcama üst sınırı belirleyin. Ardından her çalıştırmanın maliyetini günlüğe kaydedin. Böylece fatura oluşmadan önce döngüdeki sapmayı görebilirsiniz. Sürekli çalışan bir ajan VPS için maliyet denetimi muhasebe tarafını, bir ajanın turlar arasında taşıdığı bağlamı yönetme ise çalıştırma başına maliyeti en fazla etkileyen unsuru ele alır. Bunun nedeni, aynı repository'yi her 30 dakikada yeniden okuyan bir döngünün bu işlem için her 30 dakikada bir ücret ödemesidir.

Döngüler genellikle tek bir uzun oturumdan daha verimli olduğu için maliyet önemlidir. Yeni başlayan, tek bir dar kapsamlı işi yapan ve çıkan bir çalıştırma bağlamını küçük tutar. 8 saat boyunca açık bırakılan bir oturum, önceki tüm hataları geçmişinde taşır ve her turda tüm transcript için ücret öder.

Trend olan depoların somutlaştırdığı örüntüler

loop-engineering deposu yedi üretim örüntüsünü listeler. Bunları bir bildiri yerine menü gibi okumakta yarar vardır. Günlük tasnif. İnceleme yorumlarını izleyip yanıtlayan bir pull request takipçisi. Başarısız derlemeleri ele alan bir sürekli tümleştirme temizleyicisi. Bağımlılık temizleyicisi. Değişiklik günlüğü taslağı hazırlayıcısı. Birleştirme sonrası temizlik. Sorun tasnifi.

Bu örüntülerin ortak noktası, sınırı açık olan dar kapsamlı bir iştir. "Başarısız derlemeyi düzelt" ifadesinin, makinenin okuyabileceği bir başarı koşulu vardır. "Kod tabanını iyileştir" ifadesinin ise böyle bir koşulu yoktur; bu nedenle hiçbir zaman bir döngüye dönüşmez. Bir programa sahip karmaşık bir işe dönüşür.

Bunların ortak bir başka özelliği de yazılı bir kayıttır. Her iki depo da durumu konuşmanın dışına, depo içindeki dosyalara taşır: ne çalıştı, ne buldu ve neye karar verdi. Bu dosya, döngünün belleğidir. İkinci bir döngünün ilk döngünün çalışmasını yeniden keşfetmek yerine onun üzerine kurulum yapabilmesinin nedeni budur. Ayrıca, çalıştırma sona erdiği anda modelin bağlamı ortadan kalktığından, bir aracıyı sonradan denetlemenin yolu da budur.

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

Başarısızlık nedenleri genellikle basittir ve ekipler arasında tekrarlanır.

  • Kapı kontrolü yok. Çıktı birikir, kimse incelemez, güven ortadan kalkar ve döngü devre dışı bırakılır.
  • Çakışma. Aynı branch üzerinde iki çalıştırma veya aynı working tree içinde iki agent çalışır ve agent'ın çözmeye çalıştığı çakışmalar oluşur.
  • Sessiz sapma. Kontrol başarısız olacak kadar güçlü olmadığı için döngü çalışmaya devam eder.
  • Sınırlandırılmamış kapsam. Yoğun kullanılan bir repository'de her commit için tetiklenen bir işlem, bir gün içinde maliyet sorununa dönüşür.

Her biri için aynı çözüm uygulanır: işi küçültün, kontrolü kesinleştirin ve çalıştırmayı günlüğe kaydedin. Başarı koşulu tek cümleyle açıklanamıyorsa iş henüz otomatikleştirilmeye hazır değildir.

Söz Dağarcığı Olmadan Başlama

Bir framework gerekmez. Her zaman açık olan küçük bir Linux sunucusu, gerektiğinde test paketi başarısız olan bir git repository'si, bir systemd timer'ı ve içinde if bulunan bir shell script'i tam bir döngü oluşturur. Çoğu kişi için doğru başlangıç noktası gerçekten budur. Çü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 çoğunlukla başka bir timer ve başka bir worktree eklemekten ibarettir. Temel kurulum için VPS üzerinde bir coding AI agent nasıl çalıştırılır bölümüne, agent'ın kendisini denetiminizdeki donanım üzerinde çalıştırmak istiyorsanız güncel self-hosted AI agent seçenekleri bölümüne bakın.

FAQ

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

Prompt mühendisliği tek bir mesajı optimize eder: ifade biçimini, örnekleri ve çıktı formatını. Döngü mühendisliği ise mesajın çevresindeki süreci optimize eder: çalıştırmayı başlatan tetikleyiciyi, çalışmanın yürütüldüğü sandbox ortamını, çıktıyı kabul veya reddeden denetimi ve çalışmayı sonlandıran bütçeyi. Döngünün içinde yine iyi bir prompt gerekir. Ancak prompt, günlük olarak ayarlanan temel unsur olmaktan çıkar. Bunun nedeni, geçidin ve tetikleyicinin sonuç üzerinde daha fazla etkili olmasıdır.

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

Hayır. Bir systemd timer, her çalıştırma için bir git worktree, test komutuyla sonlanan bir shell script ve sağlayıcı hesabında tanımlı bir harcama sınırı, tanımın tüm bölümlerini karşılar. Framework'ler planlama arayüzleri, paylaşılan bellek formatları ve çoklu agent yönlendirmesi ekler. Bunlar birden çok döngü çalıştırıldığında kullanışlıdır. Ancak ilk döngü için zorunlu değildir.

Codebase harness nedir?

Bir agent'ın insan bulunmadan bir repository üzerinde çalışmasını sağlayan bileşenler kümesidir: tek komutla kurulum, etkileşimsiz çalışan ve hatayı açıkça bildiren testler, bir linter ve değişikliği deploy etme veya önizleme yöntemi. Bu terim, loop engineering ile aynı 2026 repository dalgasından ortaya çıkmıştır. Uygulamadaki test basittir: yeni bir insan katkıcısı clone işleminden geçerek tek komutla başarılı test sonuçlarına ulaşamıyorsa, bir agent da ulaşamaz.

Bir agent döngüsünün yüksek bir fatura oluşturmasını nasıl önlerim?

Üç yerde sınırlandırın. Takılan bir çalıştırmanın sonlandırılması için systemd unit üzerinde TimeoutStartSec değerini ayarlayın. Başarı elde edilene kadar döngüye girmek yerine, yeniden deneme sayısını script içinde sınırlandırın. API hesabında kesin bir harcama sınırı belirleyin. Çünkü agent'ın aşamayacağı tek sınır budur. Ardından çalıştırma başına maliyeti günlüğe kaydedin. Maliyeti iki katına çıkan bir döngü genellikle kapsamı fark edilmeden genişleyen bir döngüdür.

Önce hangi işleri döngüye dönüştürmek gerekir?

Makine tarafından okunabilen bir geçme koşuluna ve küçük bir etki alanına sahip bir iş seçin. Başarısız bir build'i düzeltmek, bir dependency'yi güncellemek ve bir changelog'u yeniden oluşturmak bu kapsama girer. Bunun nedeni, bir test suite'inin veya diff'in sonucu doğrulayabilmesidir. Refactoring veya tasarım gibi açık uçlu işler henüz uygun değildir. Çünkü geçidin denetleyebileceği bir sonuç yoktur. Geçidi olmayan bir döngü, inceleme borcu üretmenin pahalı bir yoludur.

#loop-engineering#ai-agents#claude-code#workflow#automation