Döngü Mühendisliği (Loop Engineering) Nedir?

Evet, karşınızda yepyeni bir terim daha: döngü mühendisliği (loop engineering). Daha harness mühendisliğini (harness engineering) yeni öğrenmiştik, şimdi bir yenisi çıktı. Peki bu sadece pazarlama balonu mu, yoksa altında gerçekten dişe dokunur bir şey var mı? Gelin birlikte bakalım. Prompt mühendisliğinden (prompt engineering) başlayıp adım adım döngü mühendisliğine kadar yürüyeceğiz ve her adımda "neden buna ihtiyaç duyduk?" sorusunu cevaplayacağız. Hazırsanız başlıyoruz.

Önce Bir Hatırlayalım: Prompt Mühendisliği (Prompt Engineering)

Prompt mühendisliğini artık hepimiz biliyoruz. "Sen deneyimli bir Python geliştiricisisin, kodu her zaman açıklamalarla yaz" gibi bir prompt yazıyorsunuz ve model bu role bürünüyor. İşin özü şu: modele ne yapacağını tek seferlik, iyi yazılmış bir metinle söylüyorsunuz. Sıfır örnekli promptlar (zero-shot prompting), birkaç örnekli promptlar (few-shot examples), düşünce zinciri (chain-of-thought) gibi teknikler hep bu kategoriye giriyor [8]. Basit ve mantıklı. Peki madem bu kadar güzel çalışıyor, neden bir sonraki aşamaya ihtiyaç duyduk?

Bağlam Mühendisliği (Context Engineering): Ajan Kendi Context'ini Doldursun

Şöyle düşünelim: yazdığımız o prompt, ajanın (agent) bağlam penceresinin (context window) içinde yaşıyor ve geriye hâlâ kocaman bir alan kalıyor. O zaman ajana araçları (tools) kendi başına çağırma özerkliği versek ve context'ini ihtiyacına göre kendisi doldursa? İşte bağlam mühendisliği tam olarak burada doğdu.

Anthropic'in tanımıyla bağlam mühendisliği, çıkarım (inference) sırasında modelin gördüğü token kümesinin tamamını -- sistem talimatları, araçlar, Model Bağlam Protokolü (Model Context Protocol / MCP), harici veriler ve mesaj geçmişi dahil -- düzenleme ve yönetme stratejilerinin bütünü [5]. Yani mesele artık "soruyu nasıl sorarım" değil, "modelin şu anda hangi bilgiye erişmesi gerekiyor" sorusu [9]. Anthropic bunu prompt mühendisliğinin doğal bir evrimi olarak görüyor; çünkü çok turlu ve uzun soluklu çalışan ajanlar için tek seferlik güzel bir prompt yeterli olmuyor [5][7].

Aradaki farkı Claude Code üzerinden görelim: burada güzel bir çığır açıcı yaklaşım var. Anthropic'in anlattığına göre Claude Code, devasa bir veri dosyasını analiz ederken her şeyi belleğe yüklemek yerine hafif tanımlayıcılar (lightweight identifiers) tutuyor ve veriyi ancak ihtiyaç anında çekiyor; buna tam zamanında (just-in-time) veri stratejisi deniyor [7]. Yani ajan kendi bağlam penceresini yalın tutmak için ne zaman neyi yükleyeceğine kendisi karar veriyor. Bir promptla asla yapamayacağınız şey tam da bu: promptta ne yazarsanız yazın, çalışma anında hangi dosyanın gerekeceğini önceden bilemezsiniz.

Harness Mühendisliği (Harness Engineering): Dışarıdan Bir El Gerekiyor

Bağlam mühendisliğinin doğasında bir kusur yok aslında, ama sınırları var. Uzun süren görevler, ajanın taşıyabileceğinden çok daha fazla context gerektiriyor. Ajan bağlam penceresinin sınırına yaklaştıkça kendi context'ini sıkıştırmaya (compaction) çalışsa da bu süreç sızdırıyor; her özetleme adımında önemli detaylar kayboluyor. Anthropic de bunu açıkça söylüyor: uzun soluklu ajanların temel sorunu, ayrık oturumlar (discrete sessions) halinde çalışmak zorunda olmaları ve her yeni oturumun öncekine dair hiçbir hafıza olmadan başlaması; sıkıştırma tek başına yeterli değil [6]. Sonuç? Yarım bırakılmış özellikler, iki kere yapılmış işler, ya da "bitti" deyip erkenden projeyi kapatan ajanlar [29].

Çözüm ne? Context'i dışarıdan yöneten harici bir sistem: harness. Anthropic'in yayımladığı yaklaşımda bu iş iki parçalı bir mimariyle çözülüyor: ilk çalıştırmada ortamı kuran bir başlatıcı ajan (initializer agent) -- özellik listesi, git deposu, ilerleme dosyaları hazırlıyor -- ve her oturumda artımlı ilerleme kaydeden bir kodlama ajanı (coding agent) [6][29]. Ajan her oturumun başında ilerleme dosyasını (claude-progress.txt gibi) okuyor, sonunda güncelliyor ve böylece saatler, hatta günler süren projelerde -- mesela sıfırdan üretim kalitesinde tam yığın (full-stack) bir web uygulaması inşa etmek gibi -- tutarlı ilerleme sağlanabiliyor [29]. İşte bu dış iskeletin tamamına harness mühendisliği diyoruz.

Ve Karşınızda: Döngü Mühendisliği (Loop Engineering)

Buraya kadar bir desen fark etmiş olabilirsiniz: her katmanda bir döngü (loop) var. Bağlam mühendisliğinde ajan, yeterli context'e ulaştığını düşünene kadar araç üstüne araç çağırıyor. Harness mühendisliğinde ajan, bağlam penceresinin dışındaki görev listesini bitirene kadar görev üstüne görev işliyor. Yani aslında döngü üstüne döngü istifliyoruz. Döngü mühendisliği de bunun bir üst katmanı: harness'ın da dışına bir döngü daha ekliyor.

"Yeter artık, bunun sonu yok mu?" dediğinizi duyar gibiyim. Ama şu farkı görelim: şimdiye kadar anlattığımız her şeyde ajanı dürtükleyen hep bir insan vardı. Promptları biz yazıyorduk. Döngü mühendisliğinin hedefi tam da bu insan etkileşimi. Peki ajanın kendi kendine ne yapması gerektiğini bulduğu bir yapı iskelesi (scaffolding) kursak?

Terimi Haziran 2026'da Addy Osmani'nin yazdığı bir blog yazısı popülerleştirdi. Osmani'nin tanımı gayet net: "Döngü mühendisliği, ajanı yönlendiren kişi olarak kendinizi devreden çıkarmaktır. Onun yerine bunu yapan sistemi siz tasarlarsınız." Buradaki döngü, bir amaç tanımladığınız ve yapay zekânın tamamlanana kadar yinelediği özyinelemeli bir hedef (recursive goal) olarak düşünülebilir [1][2]. Aynı dönemde Claude Code'un yaratıcısı Boris Cherny de şunu söyledi: "Artık Claude'a prompt yazmıyorum. Claude'u yönlendiren ve ne yapılacağına karar veren döngülerim çalışıyor. Benim işim döngü yazmak." [3][10] OpenClaw'un yaratıcısı Peter Steinberger ise olayı tek cümleye sıkıştırdı: "Ajanlarınıza prompt yazmayı bırakın, onları yönlendiren döngüleri tasarlayın." [3][12]

Peki Bu Pratikte Neye Benziyor? Açık Kaynak Bakımcısının Kabusu

Teoriyi bırakıp elle tutulur bir senaryo kuralım; hem de bu sefer kaynaklardaki gerçek kullanım örneklerinden. Diyelim ki orta boy bir açık kaynak (open source) kütüphanenin bakımcısısınız (maintainer). Her sabah aynı film: gece boyunca açılmış issue'lar etiketlenmeyi bekliyor, CI boru hattı (pipeline) yine kırılmış, üç tane PR review yorumlarına cevap bekliyor, bağımlılıklar (dependencies) eskimiş. Claude Code'u açıp tek tek prompt yazıyorsunuz: "şu issue'ları kategorize et", "CI'daki hatayı özetle", "şu PR'daki geri bildirimi düzelt". Ajan işini harika yapıyor ama dürtükleyen hâlâ sizsiniz.

Şimdi döngü mühendisliği şapkasını takalım. OpenAI'ın kendi içinde otomasyonları (automations) tam da bu "sıkıcı" işler için kullandığı biliniyor: günlük issue triyajı, CI hatalarını özetleme, commit brifingleri yazma, geçen hafta birinin eklediği hataları avlama [1]. Aynı mantıkla siz de gece 03:00'te çalışan bir issue triyaj döngüsü kurarsınız; bulgular bir gelen kutusuna düşer, rapor edilecek bir şey yoksa görev kendini arşivler [20]. Daha da güzeli: bir PR'a "bebek bakıcılığı" (PR babysitting) yapan bir beceri (skill), PR'ın durumunu düzenli kontrol eden ve yeni review yorumlarını kendiliğinden düzelten yinelenen bir otomasyon kurabiliyor [20]. Claude Code tarafında ise /goal komutu size hazır bir üretici/değerlendirici döngüsü (generator/evaluator loop) veriyor: bir tamamlanma koşulu belirliyorsunuz, ayrı ve hızlı bir model her turdan sonra koşul sağlanana kadar kontrol ediyor [30].

Bu döngüler paralel çalışırken birbirini ezmesin diye her biri izole bir çalışma ağacında (worktree) koşuyor; böylece ana kod kopyanıza dokunmadan, çalışma zamanı kirliliği (runtime contamination) olmadan aynı depoda birden fazla ajan çalışabiliyor [21][22]. Fark ettiniz mi? Artık ajanı siz yönlendirmiyorsunuz; sistem işi buluyor, dağıtıyor, kontrol ediyor ve bir sonrakine geçiyor. İnsan güdümlü (human-guided) değil, öz güdümlü (self-guided) bir yapı bu.

Osmani'nin yazısında bir döngüyü döngü yapan temel bileşenler şöyle sıralanıyor: otomasyonlar (automations), çalışma ağaçları (worktrees), beceriler (skills), eklentiler ve bağlayıcılar (plugins & connectors), alt ajanlar (subagents) ve harici hafıza yani durum (state) [1][19]. Beceriler sayesinde ajan mevcut bir bilgi tabanına erişip yol boyunca bilgisini geliştirebiliyor; alt ajanlar ise ajanın kendi işini doğrulaması için kullanılıyor -- üreteni ve denetleyeni ayırmak, işi büyütmeden önce atılacak en kritik adımlardan biri [13].

Andrew Ng olaya bir kat daha yukarıdan bakıyor ve üç iç içe döngü tanımlıyor: dakikalar mertebesinde dönen ajan kodlama döngüsü (agentic coding loop), saatler mertebesindeki geliştirici geri bildirim döngüsü (developer feedback loop) ve günler-haftalar süren harici geri bildirim döngüsü (external feedback loop) [4][15][17]. Ng'nin vurgusu önemli: geliştirici geri bildirim döngüsü tamamen otomatikleştirilemez, çünkü insanın bağlam avantajı (context advantage) var -- kullanıcıları ve ürünün yaşadığı ortamı ajandan çok daha iyi biliyoruz [18].

Şüpheciler Haksız mı? Değil.

Şimdi işin eleştiri kısmına gelelim, çünkü burası es geçilecek gibi değil. Bir kere terimin kendisi bile alay konusu: soyup soğana çevirdiğinizde elinizde bir LLM çağrısını saran while döngüsü kalıyor [26]. Nitekim Claude Code'u inceleyen 2026 tarihli bir akademik makale bile sistemin çekirdeğini "modeli çağıran, araçları çalıştıran ve tekrarlayan basit bir while döngüsü" olarak tanımlıyor [4]. Hatta pratik, isimden bile eski: Geoffrey Huntley'nin Temmuz 2025'te yayınladığı "Ralph Wiggum döngüsü", Claude Code'u sonsuz bir bash döngüsüne saran tek satırlık bir betikten (script) ibaretti [24].

Ekonomik eleştiri daha da sert. Ed Zitron olayı "otonom token tüketimini kutlamak ve vaaz etmek" olarak özetliyor; sonuçta bu harcamayı en çok teşvik etmek isteyenler model sağlayıcılarının kendisi [23]. Steinberger'in kendi kullanım verileri, 30 günde 603 milyar tokena karşılık gelen 1,3 milyon dolarlık maliyeti ortaya koydu -- faturayı OpenAI ödedi, çünkü kendisi orada çalışıyor [24]. Gergely Orosz'un eleştirisi ise bir ön koşul eleştirisi: "Sınırsız token bütçesi olan ve ajanlara prompt yazmanın kendilerini yavaşlattığını hisseden gittikçe azalan bir kesim dışında, çoğu insanın bunlar için bir kullanım senaryosu olduğunu düşünmüyorum." [26] Osmani'nin kendisi bile yazısında şüpheci olduğunu ve token maliyetlerine çok dikkat edilmesi gerektiğini söylüyor [2][24].

Güvenilirlik tarafında da uyarılar var: "Başıboş çalışan bir döngü, aynı zamanda başıboş hata yapan bir döngüdür." Üretim ortamları için bu, döngü mühendisliğinin sadece otomasyon değil; doğrulama (verification), kayıt tutma (logging), onay kapıları (approval gates) ve hata limitleri de içermesi gerektiği anlamına geliyor [4]. Gözetimsiz döngülerde küçük hataların zamanla birikip büyüdüğü ajan sapması (agent drift) da topluluklarda sıkça dile getirilen bir endişe; hatta bazı geliştiriciler, otonom çıktıyı incelemenin maliyeti kazanılan zamanı aşınca insan destekli iş akışlarına (human-in-the-loop workflows) geri döndüklerini bildiriyor [24].

Peki Sonuç?

Döngü mühendisliğinin gerçekten büyük fark yarattığı bir örneği henüz sahada pek görmedik; gerçek potansiyeli hâlâ biraz teorik. Ama şunu da inkâr edemeyiz: Claude Code'un yaratıcısı, OpenClaw'un yaratıcısı ve Andrew Ng bir ay içinde bağımsız olarak aynı çerçevede buluştu [14]. Bu bir tesadüf gibi durmuyor; üretimde ajan çalıştıran her ekibin çarptığı bir duvara isim konmuş gibi duruyor [12].

Bir de şunu unutmayalım: döngü mühendisliği, altındaki mühendislik katmanlarının artık daha az önemli ya da daha az gerekli olduğu anlamına gelmiyor. Prompt hâlâ orada, context hâlâ orada, harness hâlâ orada. Olan şey, ajanların kapsamının büyümesi ve katmanların birbirinin üstüne inşa edilmesi. Yarın öbür gün "filo mühendisliği" (fleet engineering) diye bir terim çıkarsa da şaşırmayın; Steinberger şimdiden "üç ay sonra döngülerinizi tasarlayan filolardan bahsediyor olacağız" diye espri yapıyor [23]. Bakalım, göreceğiz. Ama görünen o ki bu tren istikametini belli etti: daha yüksek seviyeli otomasyona doğru gidiyoruz [28] -- biz de öğrenmeye devam edeceğiz.

Kaynaklar

1. Osmani, A. "Loop Engineering" — https://addyosmani.com/blog/loop-engineering/
2. O'Reilly Radar. "Loop Engineering" — https://www.oreilly.com/radar/loop-engineering/
3. Orosz, G. "What is 'loop engineering'?" — The Pragmatic Engineer — https://newsletter.pragmaticengineer.com/p/what-is-loop-engineering
4. ADTmag. "Loop Engineering Emerges as Developers Put AI Coding Agents on Repeat" — https://adtmag.com/articles/2026/07/01/loop-engineering-emerges-as-developers-put-ai-coding-agents-on-repeat.aspx
5. Anthropic. "Effective context engineering for AI agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
6. Anthropic. "Effective harnesses for long-running agents" — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
7. The Decoder. "Anthropic claims context engineering beats prompt engineering when managing AI agents" — https://the-decoder.com/anthropic-claims-context-engineering-beats-prompt-engineering-when-managing-ai-agents/
8. Marin, J. "Context Engineering vs. Prompt Engineering" — Medium / Data Science Collective — https://medium.com/data-science-collective/context-engineering-vs-prompt-engineering-3493c2925e99
9. IntuitionLabs. "Context Engineering vs. Prompt Engineering Explained" — https://intuitionlabs.ai/articles/context-engineering-vs-prompt-engineering-ai
10. Greyling, C. "Loop Engineering" — Substack — https://cobusgreyling.substack.com/p/loop-engineering
11. Greyling, C. "loop-engineering" (GitHub repo) — https://github.com/cobusgreyling/loop-engineering
12. Masood, A. "Loop Engineering: A Guide for Engineers and Practitioners" — Medium — https://medium.com/@adnanmasood/loop-engineering-a-guide-for-engineers-and-practitioners-893bb65ea943
13. AI Builder Club. "Addy Osmani's Loop Engineering: The 5 Components" — https://www.aibuilderclub.com/blog/loop-engineering-addy-osmani
14. AI Builder Club. "Loop Engineering Guide (2026)" — https://www.aibuilderclub.com/blog/loop-engineering-guide-2026
15. ExplainX. "Andrew Ng's 3 Loops for 0-to-1 AI Products" — https://explainx.ai/blog/andrew-ng-three-loops-0-to-1-products-2026
16. Ng, A. "Writing" (The Batch letters) — https://www.andrewng.org/writing
17. Ng, A. X (Twitter) post on the three key loops — https://x.com/AndrewYNg/status/2071988145667928442
18. Srinivasan, A. "Loop Engineering: The Missing Discipline for Production AI Agents" — Substack — https://aishwaryasrinivasan.substack.com/p/all-you-need-to-know-about-loop-engineering
19. ML4Trading Insights. "A Coding-Agent Reading List: Behind the Loops" — https://insights.ml4trading.io/p/a-coding-agent-reading-list-behind
20. OpenAI Developers. "Automations — Codex app" — https://developers.openai.com/codex/app/automations
21. OpenAI Developers. "Worktrees — Codex app" — https://developers.openai.com/codex/app/worktrees
22. IntuitionLabs. "OpenAI Codex App: A Guide to Multi-Agent AI Coding" — https://intuitionlabs.ai/articles/openai-codex-app-ai-coding-agents
23. The Register. "Loop engineering, latest AI buzzword, still needs humans in the loop" — https://www.theregister.com/ai-and-ml/2026/06/24/loop-engineering-latest-ai-buzzword-still-needs-humans-in-the-loop/5261735
24. Memeburn. "What Is Loop Engineering? The New AI Coding Shift Explained" — https://memeburn.com/what-is-loop-engineering/
25. Naresh B A. "Loop Engineering Beyond the Hype: An Engineer's Perspective" — Medium — https://medium.com/@phoenixarjun007/loop-engineering-beyond-the-hype-an-engineers-perspective-b3423292b237
26. Black Matter VC. "Loop Engineering: An Honest Verdict From Someone Who Actually Runs Agent Loops" — https://blackmatter.vc/lab/loop-engineering-an-honest-verdict-from-someone-who-actually-runs-agent-loops
27. Kokane, A. "What is Loop Engineering? How it is different than Harness Engineering?" — Level Up Coding — https://levelup.gitconnected.com/what-is-loop-engineering-how-it-is-different-than-harness-engineering-0e764f373fb1
28. Lyons, E. "Should we all implement 'loop engineering' for software development? Not yet." — EQengineered — https://www.eqengineered.com/insights/loop-engineering
29. ZenML LLMOps Database. "Anthropic: Long-Running Agent Harness for Multi-Context Software Development" — https://www.zenml.io/llmops-database/long-running-agent-harness-for-multi-context-software-development
30. Anthropic. "cwc-long-running-agents" (GitHub repo) — https://github.com/anthropics/cwc-long-running-agents
31. Kapak görseli: Photo by Aleksandr Popov on Unsplash