Harness engineering ve loop engineering nedir, farkı ne?

Harness nedir?

Bir dil modeli tek başına girdi alır ve metin üretir. Kod çalıştıramaz, bir konuşmada olanı bir sonrakinde hatırlayamaz, eğitiminden sonra ortaya çıkan bilgiye ulaşamaz. Bunları yapabilmesi için modelin çevresine bir yapı kurulur: onu tekrar tekrar çağıran bir döngü, kullanabileceği araçlar, her oturumda önüne konan dosyalar, çıktısını test eden kontroller. Bu yapıya harness denir.

Okuduğumuz kaynaklardaki en geniş tanım LangChain’in yazısında: “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.” Yani modelin kendisi dışındaki bütün kod, ayarlar ve çalıştırma mantığı. Kodlama ajanlarının içinde de böyle bir katman çalışır. OpenAI, ajan döngüsünü ve çalıştırma mantığını sağlayan katmana “Codex harness” diyor. Anthropic de Claude Code’u çalıştıran katmana “agent harness” diyor.

Harness engineering, bu yapıyı tasarlama işidir. Biz de böyle bir yapı geliştiriyoruz: diffox, pull request’leri inceleyen bir yapay zekâ kod inceleme aracı. Aşağıdaki örnekler onun inceleme hattından ve bir pull request boyunca kurduğu döngüden geliyor (nasıl çalıştığını ayrı bir yazıda anlattık).

Kaynaklar harness engineering’i nasıl tanımlıyor?

Terim yeni ve okuduğumuz kaynaklar onu aynı şekilde tanımlamıyor. Tabloda her kaynağın kendi cümlesi ve tarihi var.

Kaynak: her yazının kendi sayfası, 15 Ekim 2026. Alıntılar özgün dilinde.

Hashimoto bir alışkanlığı tarif ediyor. Aynı paragrafta bunun için yerleşik bir terim olup olmadığını bilmediğini de yazıyor. LangChain ise bir sınır çiziyor: modelin dışındaki her şey harness’tir. Birincisi size ne yapacağınızı, ikincisi nereye bakacağınızı söylüyor.

Tabloda görünmeyen iki ayrıntı var. “Agent = Model + Harness” formülü Hashimoto’nun değil, LangChain’in yazısında geçiyor. “Harness” kelimesi de terimden eski: Anthropic 26 Kasım 2025’te Claude Agent SDK için “general-purpose agent harness” demişti. Okuduğumuz beş Anthropic yazısının hiçbirinde “harness engineering” ifadesi geçmiyor.

Her katmanda neyi değiştirirsiniz?

Bu dört terim birbirinin yerine kullanılamaz; iç içe geçmiş dört katmandır. Anthropic’in tanımına göre prompt engineering, modelin talimatlarını yazma ve düzenleme yöntemlerini kapsar. Context engineering ise çıkarım sırasında modelin önüne hangi token’ların konacağını seçme ve yönetme stratejilerini kapsar. Prompt’un dışında oraya giren her bilgi de buna dahildir. Bağlam, modelin o çağrıda gördüğü her şeydir.

Context engineering terimini tek bir kişiye mal eden birincil bir kaynak bulamadık. Okuduğumuz iki kullanım da Haziran 2025’ten: Tobi Lütke 19 Haziran’da bu adı “prompt engineering”e tercih ettiğini yazdı (“the art of providing all the context for the task to be plausibly solvable by the LLM”), Andrej Karpathy de 25 Haziran’da ona katıldı. Anthropic’in tanımı 29 Eylül 2025 tarihli.

Harness engineering bir katman daha dışarıda durur. Yalnızca modelin ne gördüğüyle ilgilenmez, model cevap verdikten sonra olanları da tasarlar: çıktı hangi kontrolden geçecek, iş nasıl bölünecek, bir hata tekrar edince ne değişecek. Katmanlar birbirinin içindedir: LangChain’e göre bugünkü harness’lerin işi büyük ölçüde iyi bir context engineering’i hayata geçirmek. Loop engineering ise bir kat daha dışarıda: tek bir çalıştırmayı değil, zaman içindeki çalıştırmaları tasarlar. Ona aşağıda ayrı bir bölüm ayırdık.

Bir harness hangi parçalardan oluşur?

Okuduğumuz yazılar parçalara farklı adlar veriyor. Aşağıdaki altı başlığın her biri en az iki kaynakta geçiyor.

İşin merkezinde döngü var. Anthropic ajanları, ortamdan aldıkları geri bildirime göre bir döngü içinde araç kullanan modeller olarak tanımlıyor. Agent SDK yazısında döngünün adımları şunlar: bağlamı topla, harekete geç, işi doğrula, tekrarla. Araçlar ve gözlemlenebilirlik, modelin yaptığı işin sonucunu görmesini sağlar: OpenAI’ın anlattığı depoda loglar, metrikler ve izler ajana açık. Alt ajanlar işi böler; Anthropic’e göre her biri tek bir işe odaklanır ve temiz bir bağlam penceresiyle başlar.

Kontroller ayrı durur, çünkü onları model değil siz yazarsınız. Agent SDK yazısına göre en iyi geri bildirim, çıktı için net kurallar koymak ve hangisinin neden çiğnendiğini açıklamaktır. OpenAI, mimari kurallarını kendi linter’ları ve yapısal testleriyle otomatik olarak denetliyor.

Loop engineering nedir?

Harness tek bir çalıştırmayla ilgilenir. Loop engineering bir soru daha sorar: ajanı kim, ne zaman çalıştıracak ve işin bitip bitmediğine kim karar verecek? Terime adını Addy Osmani 7 Haziran 2026 tarihli yazısında verdi: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Yani ajana her turda prompt yazan kişi olmayı bırakıp bu işi yapan sistemi tasarlamak.

Terimin çıkışında iki cümle var. Peter Steinberger aynı gün, ajanlara prompt yazmak yerine onlara prompt yazan döngüler tasarlamayı önerdi. Osmani’nin aktardığına göre Claude Code’un başındaki Boris Cherny de “My job is to write loops” demişti. İkisi de “loop engineering” ifadesini kullanmıyor; adı Osmani’nin yazısı koydu.

Kaynak: her yazının kendi sayfası, 15 Ekim 2026. Alıntılar özgün dilinde.

Kaynaklar altı parça üzerinde anlaşıyor. Derleme bunları şöyle sıralıyor: tetiklenen çalıştırmalar, otomatik denetlenebilen durma koşulları, kalıcı durum dosyaları, doğrulayıcı alt ajanlar, token bütçeleri ve işin insana bırakıldığı noktalar.

• Tetikleyici. Çalıştırmayı başlatan şey: bir zamanlayıcı ya da bir olay.
• Durma koşulu. İşin bittiğine makinenin karar verebildiği bir ölçüt: testler geçti, liste boşaldı.
• Durum. Bir çalıştırmadan sonrakine taşınan kayıt. Bağlam penceresinde değil, onun dışında tutulur.
• Doğrulayıcı. İşi yapan ajandan ayrı bir denetçi.
• Bütçe. Tur ya da token sınırı; aşılınca döngü durur.
• İnsana bırakma. Döngünün çözemediği işin bir insana düştüğü yer.

Anthropic’in yazısı bu parçalardan üçünü bir arada gösteriyor. Claude Code her durmak istediğinde ayrı bir değerlendirici model koşulu kontrol ediyor. Hedefe ulaşılana ya da sizin belirlediğiniz tur sayısı dolana kadar Claude Code’u işe geri gönderiyor. Osmani’nin deyişiyle böylece kodu yazan ajan, kendi işine not veren ajan olmuyor.

Kaynakların ayrıldığı bir nokta var: “loop” derken hangi döngüden söz ediliyor? Derleme iki döngüyü birbirinden ayırıyor. Ajan döngüsünde model, tek bir çalıştırmanın içinde araç çağırır ve sonuca göre hareket eder; bu döngü harness’in bir parçasıdır. Loop engineering ise bu çalıştırmaları zaman içinde başlatan, denetleyen ve yeniden başlatan yapıları yönetir. Bazı şirketlerin yazıları kelimeyi ilk anlamda kullanıyor; Anthropic’in mühendislik blogu da harness’i “Claude’u çağıran döngü” diye tanımlıyor. Bu yazıda loop’u ikinci anlamda kullanıyoruz.

Terimin kendisi de henüz oturmadı. Aynı derlemeye göre loop engineering’in yeni bir disiplin mi, geçici bir teknik mi, yoksa bir pazarlama etiketi mi olduğu tartışmada netleşmiş değil. Temmuz 2026’da yerine geçmesi için “graph engineering” adı bile önerildi.

Bir kod inceleme aracında harness nasıl görünür?

Parçaların bir arada nasıl çalıştığını diffox’un inceleme hattında görebilirsiniz. Bir pull request yorumlara dönüşene kadar dört aşamadan geçer ve her aşamada harness’in bir fikri öne çıkar.

Bağlam ve yönlendirme, model işe başlamadan önce harness’in ona verdiği şeydir. Uzman ajanların önüne dört şey konur: diff, dosyaların önceki ve sonraki hâli, pull request’in açıklaması ve varsa deponuzdaki kural dosyası (AGENTS.md ya da CLAUDE.md). Kural dosyası pull request’in kendi dalından değil, birleşeceği daldan okunur; böylece bir pull request kendi incelemesinin kurallarını değiştiremez. Bunu bir talimat cümlesi değil, dosyanın okunduğu yer garanti eder.

Uzman incelemesi aşamasında iş bölünür. “Bunda hata var mı?” geniş bir soru. diffox aynı değişikliği uzman ajanlara okutur. Takımda 17 uzman ajan var. Her birinin kendi talimatı var ve her biri tek bir şeyin peşinde: biri mantık hatalarının, biri eşzamanlılık sorunlarının, biri hiçbir şeyi test etmeyen testlerin.

Çıktının biçimini de harness belirler. Bir bulgunun sayılması için üç şey söylemesi gerekir: ne iddia ettiği, hangi durumda neyin ters gideceği ve iddianın dayandığı kod. Kod, birebir kopyalanmış bir alıntıyla verilir. Ajanlar satır numarası vermez; diffox alıntıyı dosyada arar ve satırı kendisi bulur.

Seçim ve yayın ayrı bir adımdır. Her bulgunun bir sınıfı var: Kritik, Uyarı ya da Öneri. Pull request’e düzeltmeniz gerekenler, yani kritik bulgular ve uyarılar yazılır. Öneriler konsoldaki Bulgular sayfasında bir süre bekler; istediğinizi oradan yayımlayabilirsiniz. İnceleme merge’i hiçbir zaman engellemez.

Modelin ikna edemediği bir kontrol

Üçüncü aşama olan kanıt kontrolleri, harness fikrinin bu örnekte en açık göründüğü yer. Bir dil modeli ikna edici ama yanlış şeyler yazabilir: dosyada olmayan bir satırı alıntılar, pull request’in dokunmadığı bir koda itiraz eder, aynı sorunu üç ayrı cümleyle üç kez söyler. Bu aşama her bulguyu modelin sözüne değil, dosyanın kendisine dayandırır.

Bu kontroller bir model çağrısı değil, sıradan koddur: aynı girdiye her seferinde aynı cevabı verir.

• Bulgunun alıntısı dosyada aranır. Bulunamayan alıntı hiçbir satırı gösteremez. Bulunan satır pull request’in değiştirdiği yerde değilse bulgu kapsam dışı sayılır.
• Aynı yere aynı itirazı yapan bulgular tek bulguda birleştirilir.
• Bir bulgu kodun bir metinle çeliştiğini söylüyorsa, ikinci alıntısı da kelimesi kelimesine aranır.

Model alıntı kontrolünü ikna edemez, çünkü kontrol gerekçeye bakmaz; yalnızca alıntıyı dosyada arar.

Bir modeli başka bir modele denetletmek de mümkün, ama sonuç yine bir modelin yargısı olur. Anthropic kendi değerlendirici modelinin ilk denemelerde gerçek sorunlar bulduğunu yazıyor. Ama model sonra bunların önemli olmadığına kendini ikna etmiş ve işi onaylamış. Bu yüzden kodla test edilebileni kodla test etmek ayrı bir parça; yargı gerektiren sorular modele kalıyor.

Küçük bir projede aynı fikir birkaç satırı geçmez. Aşağıdaki örnek diffox’un kodu değil; yalnızca kalıbı gösteriyor.

# ÖRNEK: modelin verdiği alıntıyı dosyada arar
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

Bir pull request boyunca dönen loop

Tek bir inceleme bir harness’ten geçer; bir pull request ise birçok incelemeden. Kod yazılır, diffox inceler, kod değişir, yeniden push edilir. Kodu ister bir insan ister bir kodlama ajanı yazsın, bu bir döngüdür. Döngünün altı parçasının her birinin diffox’un kodunda bir karşılığı var.

Bu döngünün asıl dersi iki seçimde. Birincisi, doğrulayıcı bir değişikliği başarı saymaz. Bir bulgunun satırları değiştiğinde, yorumun sonuna yalnızca bu satırların hangi commit’te değiştiği eklenir. “Düzeltildi” yazılmaz, çünkü kod yeniden yazılsa da hata yerinde kalabilir. Haziran 2026 tarihli bir makale de durma kuralı için aynı şartı koyuyor: bir hatayı asla başarı sanmamak.

İkincisi, durma koşulunu siz seçersiniz. Otomatik incelemeler her pull request’te belirli bir sınırda durur; bu sınırı konsolun Ayarlar sekmesinden değiştirebilirsiniz. Sınırdan sonra yeni bir inceleme için bir yorumda diffox’u anmanız yeterli. Merge kararı da sizin: inceleme merge’i hiçbir zaman engellemez. Döngünün işi insana bıraktığı yer burası.

Harness hatalarla nasıl büyür?

Harness bir kez kurulup bir kenara bırakılmaz. Hashimoto’nun anlattığı yöntemde iki yol var: basit hatalar için kural dosyasına bir satır eklemek, gerisi için bir araç yazmak. Kendi projesinin kural dosyasındaki her satırın, bir ajanın yanlış bir davranışından doğduğunu yazıyor.

OpenAI’ın yazısı aynı döngüyü bir ekibin içinden anlatıyor: ürünün bütün kodunu Codex yazıyor, mühendisler de ortamı kuruyor. Ajan zorlandığında bunu bir işaret olarak görüyorlar; eksik olan araç, koruma ya da belge neyse bulup depoya ekliyorlar. Belge yetmediğinde kuralı koda taşıyorlar. Kural dosyasını da kısa tutuyorlar: yaklaşık 100 satırlık bir AGENTS.md; ansiklopedi değil, içindekiler sayfası.

Bir de ters yön var. Anthropic’e göre harness’teki her parça, modelin tek başına neyi yapamadığına dair bir varsayımdır ve modeller geliştikçe bu varsayımlar eskiyebilir. Yeni bir model geldiğinde harness yeniden gözden geçirilir ve artık bir işe yaramayan parçalar çıkarılır.

Bu aracı geliştirirken kendi depomuzda bu döngüden üç alışkanlık edindik:

• Her kural, ona yol açan hatayla birlikte yazılır. Nedeni yazılmamış bir kuralı, ondan ilk rahatsız olan kişi siler.
• Bir teste ancak düzeltmeyi geri aldığımızda kırmızıya döndüğünü gördükten sonra güveniyoruz. Hiçbir şeyi test etmeyen bir test de yeşil yanar.
• Kodla yazılmış bir kontrolü değiştirirken eski ve yeni hâlini kayıtlı sonuçlar üzerinde yeniden çalıştırıyoruz. Böylece yeni ve ücretli bir koşuya gerek kalmıyor; iki hâlin farklı sonuç verdiği her durumu tek tek görüyoruz.

Kendi projenizde nereden başlamalı?

Başlamak için bir framework seçmeniz ya da model değiştirmeniz gerekmiyor. Kullandığınız kodlama ajanının içinde zaten bir harness çalışıyor; sizin işiniz ona kendi projenizin parçalarını eklemek.

Önce hatayı görün, sonra en ucuz çözümü seçin. Basit hatalarda ilk çözüm kural dosyasına bir satır eklemektir. Hata kurala rağmen tekrar ediyorsa kuralı koda taşıyın: bir linter kuralı, bir test ya da bir script. Anthropic’in genel önerisi burada da geçerli: en basit çözümü bulun, karmaşıklığı yalnızca gerektiğinde artırın.

İlk loop’unuzu kurarken de sıra aynı: önce tek bir çalıştırmanın güvenilir olduğundan emin olun, sonra durma koşulunu ve sınırı yazın. Anthropic’in önerisi açık: hedefe ulaşınca ya da tur sayısı üst sınıra gelince durun. Token kullanımını kontrol altında tutmak için döngünün sınırları net olmalı.