Bu, Addy Osmani’nin “Harness Engineering” üzerine derlediği bir analizdir. Ona göre son 2 yılda sektörün ilgisi yalnızca “hangi yapay zeka modeli daha akıllı” sorusuna odaklandı. GPT’nin daha temiz kod yazıp yazmadığı, Claude’un daha az halüsinasyon üretip üretmediği üzerine bitmeyen karşılaştırmalar yapıldı; ancak onun iddiası, gerçek dünyadaki kodlama yapay zekasının performansını belirleyen şeyin modelin kendisinden çok, o modeli çevreleyen harness olduğudur. Harness, model dışındaki her şeyi kapsayan bir terimdir: yapay zekaya işi yaptıran sistem prompt’u, kullanabileceği araçlar ve harici sunucular, bağlam yönetimi politikaları, yürütme sırasında otomatik devreye giren kontrol mekanizmaları (hook), güvenli çalıştırma alanı (sandbox), yardımcı yapay zekalar (subagent), geri bildirim döngüleri ve iş tıkandığında toparlanmayı sağlayan akışlar buna dahildir. Viv Trivedy bu kavramı “AI agent = model + harness” diye formüle etti; Anthropic mühendislik ekibi, HumanLayer ve Simon Willison gibi isimler de bu akımı daha rafine hale getiriyor. Osmani’ye göre bu yaklaşım artık başlı başına bir mühendislik alanı haline geldi.
Temel noktaları açarsak şöyle:
-
Harness nedir? Sadece model tek başına işi bitiren bir yapay zekaya dönüşmez. İlerlemenin hatırlanması, araçların çalıştırılması, sonuçların görülüp yeniden karar verilmesi ve yapılmaması gerekenlerin engellenmesi için ek kod ve ayarlar gerekir; ancak o zaman “çalışan bir yapay zeka” ortaya çıkar. Claude Code, Cursor, Codex, Aider ve Cline gibi ürünlerin hepsi birer harness’tir ve içlerindeki model aynı olsa bile kullanıcı olarak hissettiğimiz davranışı harness belirler. Simon Willison’ın ifadesiyle AI agent, “bir hedefe ulaşmak için araçları tekrar tekrar çalıştıran bir sistem”dir; bu araçların ve tekrar yapısının nasıl tasarlandığı asıl yetkinliğin özüdür.
-
Sorun modelde değil ayarlarda bakışı Mühendisler yapay zeka saçma bir şey yaptığında çoğu zaman modeli suçlar ve “bir sonraki sürümü bekleyelim” sonucuna gider. Harness Engineering bu tepkiyi reddeder. HumanLayer’ın ifadesiyle “bu model sorunu değil, ayar sorunu (
skill issue)”dur. Aynı Claude Opus 4.6 modeli, varsayılan harness olan Claude Code içinde Terminal Bench 2.0’da alt sıralarda kalırken, elle düzenlenmiş bir harness’e taşındığında üst sıralara çıkabilmiştir. Viv’in ekibi yalnızca harness’i değiştirerek aynı modeli 30’lu sıralardan ilk 5’e yükseltti. Bu da modelin sahip olduğu potansiyelin çoğu zaman harness tarafından budandığını gösterir. -
Hataları kurala dönüştüren “ratchet” ilkesi Yapay zekanın bir kez yaptığı hata rastlantısal bir kaza gibi görülmez; kalıcı bir sinyal olarak ele alınır. Aynı hatanın bir daha olmaması için kural belgesine yeni bir satır eklenir, otomatik engelleme mekanizması bağlanır ya da inceleme yapan yardımcı bir yapay zeka eklenir; sistem adım adım sıkılaştırılır. Örneğin yapay zeka test kodunu yorum satırına aldıysa, sonraki sürümün kural belgesine “testleri yorum satırına alma; sil ya da düzelt” maddesi eklenir ve commit öncesi denetim aşamasına bu paterni yakalayan bir kontrol yerleştirilir. İyi bir kural belgesindeki her satırın geçmişte yaşanmış somut bir başarısızlıkla bağlantılı olması gerekir. Bu yüzden Harness Engineering, hazır bir framework’ü alıp kullanmaktan çok, kendi kod tabanının hata geçmişine göre büyütülen bir “disiplin”e benzer.
-
İstenen davranıştan geriye doğru tasarlamak Viv’in önerdiği en kullanışlı düşünme biçimlerinden biri şudur: “Böyle bir davranış istiyorum → bunu mümkün kılan harness parçaları neler?” Eğer bir parçanın hangi davranış için var olduğunu tek cümlede açıklayamıyorsanız, onu çıkarmak daha iyidir. Somut örneklerle: dosya sistemi ve Git, yapılan işi uzun süre saklamak ve geri almak içindir; bash ve kod çalıştırma, her şeyi deneyebilen genel amaçlı araçlardır;
sandbox, bozsanız bile ana sistemi etkilemeyen güvenli bir çalıştırma alanıdır; bellek dosyaları ile web araması ve MCP araçları, yeni öğrenilen bilginin biriktiği kanallardır; özetleyerek sıkıştırma, araç çıktısını ayırma ve skill işlevleri, yapay zekanın bellek sınırını genişleten mekanizmalardır; Ralph loop ile planlayıcı/değerlendirici ayrımı ise günler süren uzun işleri sonuna kadar taşıma yöntemleridir. -
Context rot sorunu Yapay zeka, tek seferde okuyabileceği metin miktarı açısından sınırlıdır ve bu sınıra yaklaştıkça muhakeme gücü belirgin biçimde düşer. Bu nedenle harness, sınırlı alanı nasıl verimli kullanacağını belirleyen mekanizmaların toplamıdır. Birincisi, sınır dolmaya yaklaşınca eski içerik akıllıca özetlenip sıkıştırılır. İkincisi, 2.000 satırlık log gibi büyük çıktılarda sadece baş ve son kısım tutulur, gövde dosyaya alınır ve yalnızca gerektiğinde yeniden okunur. Üçüncüsü, araçlar ve talimatlar en başta topluca gösterilmez; sadece ilgili işte gerçekten ihtiyaç duyulduğu anda devreye sokulan “kademeli açığa çıkarma” yaklaşımı kullanılır. Çok uzun işlerdeyse bazen tamamen yeni bir pencerede, yalnızca devir-teslim belgesiyle baştan başlanır. Anthropic’in işaret ettiği gibi, “uzun işlerde yalnızca özet sıkıştırma yetmeyebilir; yapılandırılmış bir devir-teslim belgesiyle yeniden başlamak gerekebilir.” İnsandaki karşılığı, işi yeni bir ekip arkadaşına devrederken düzenli bir belge bırakmaya benzer.
-
Uzun işleri taşıyan kalıplar Günümüz modellerinin zayıf yönlerinden biri işi erken bitirmeye çalışmaları, büyük problemleri küçük parçalara bölememeleri ve context window değişince akışın kopmasıdır. Harness bu zayıflıkları telafi etmelidir. Ralph loop, model işi bitirmeye çalıştığında bir
hook’un devreye girip asıl hedefi yeni context window’a tekrar enjekte etmesiyle işin sürmesini sağlayan basit bir tekniktir. Her yineleme temiz bir durumdan başlar, ama bir önceki adımın çıktıları dosya sistemi üzerinden aktarılır. Öte yandan Anthropic, “üretimden sorumlu” ve “değerlendirmeden sorumlu” yapay zekaların ayrılması gerektiğini vurgular. Çünkü yapay zeka kendi çıktısını kendisi değerlendirince cömert puan verme eğilimindedir. Buna ek olarak, “bitmiş sayılmanın hangi durum olduğu”nun işin başında netleştirildiğisprint contractkalıbı, hedefin süreç içinde sessizce genişlemesini önlemede etkilidir. -
hook’ların rolü “Yapay zekaya böyle yapmasını söylemek” ile “sistemin bunu zorunlu kılması” aynı şey değildir.Hook, aradaki farkı kapatan otomatik bir mekanizmadır; araç kullanılmadan önce, dosya değiştirildikten sonra, commit öncesinde ya da oturum başlarken devreye girer. Örneğin her kod değişikliğinde otomatik olarak sözdizimi denetimi, lint ve test çalıştırabilir;rm -rfveyagit push --forcegibi tehlikeli komutları engelleyebilir ya da PR açılmadan önce insan onayı isteyebilir. Temel ilke şudur: “başarı sessiz, hata gürültülü olsun.” Kontrol geçerse yapay zeka hiçbir şey duymaz; başarısız olursa hata mesajı olduğu gibi akışa enjekte edilir ve yapay zekanın kendini düzeltmesi sağlanır. Normalde neredeyse hiç maliyet yaratmaz, ama sorun çıktığı anda tam yerinde yardım sağlar. -
Kural belgeleri ve araç seçimi kısa ve net olmalı Proje kökünde yer alan
AGENTS.md, her turda sistem prompt’una giren en etkili yapılandırma dosyasıdır. HumanLayer, bu belgeyi 60 satırın altında tutmayı önerir. Belge uzadıkça her satırın ağırlığı azalır; bu yüzden günlük stil notlarıyla dolu bir rehber değil, bir pilotun kontrol listesi gibi yalnızca zorunlu maddeleri içermelidir. Araçlarda da aynı mantık geçerlidir: ad, açıklama ve şema her istekte prompt’a gömüldüğü için, birbirine benzeyen 50 araç yerine iyi tasarlanmış 10 araç daha iyidir. HumanLayer güvenlik boyutuna da dikkat çeker. Araç açıklamaları yapay zekanın okuduğu metin haline geldiğinden, doğrulanmamış harici MCP sunucuları eklemek, birilerinin önceden yazdığı talimatları yapay zekaya gizlice enjekte etmenin yolu olabilir.
Öne çıkan avantajlar şunlar:
- Eforun nereye harcanacağı netleşiyor Benchmark verileri, modeli değiştirmeden de davranışı ciddi biçimde iyileştirebilecek yerin harness olduğunu gösteriyor. Yani “bir sonraki modeli bekleyelim” gibi belirsiz bir beklenti yerine, bugün doğrudan iyileştirilebilecek somut bir alan ortaya çıkıyor.
- Bilginin birikmesini sağlayan yapı Hataları kurala dönüştüren ratchet yaklaşımı sayesinde bir kez öğrenilen ders takımın kalıcı varlığına dönüşüyor. İnsanlar değişse bile kural belgeleri ve
hook’lar yerinde kalıyor, böylece sonraki kişiyi de koruyor. - Hazır harness’lerin ortaya çıkışı (HaaS) Viv’in “Harness-as-a-Service” dediği akım hızla yerleşiyor. Claude Agent SDK, Codex SDK ve OpenAI Agents SDK gibi; iş döngüsü, araçlar, bağlam yönetimi,
hook’lar vesandbox’ı önceden paketleyen ürünler sayesinde ekipler her şeyi sıfırdan kurmak yerine kendi alan bilgilerine odaklanabiliyor.
Daha zorlayıcı taraflar da var:
- Takip edilmesi gereken alan çok geniş Talimatlar, araçlar, güvenli çalıştırma alanı, otomatik denetimler ve log gözlemi gibi her şeyin sorumluluğunu doğrudan üstlenmek gerekiyor. Buradaki ana nokta, bunların model sağlayıcısının otomatik çözeceği alanlar olmaması.
- Model ile harness’in birbirine bağlanma riski Günümüz modelleri belirli harness’ler içinde sonradan işlenerek eğitildiği için, başka bir harness’e taşındıklarında performans aniden düşebiliyor. Sadece araç adı ya da parametre biçimi değişse bile sonuçlar sarsılabiliyor. Gerçekten genel amaçlı bir model, araç adından etkilenmemeli; ama birlikte öğrenilen yapı yüzünden bir tür aşırı uyum oluşuyor.
- Harici araçların güvenlik riski MCP sunucularında araç açıklamaları doğrudan yapay zekaya okutulduğu için, doğrulanmamış bir aracı bağladığınız anda kullanıcı tek bir karakter yazmadan önce bile harici metin yapay zekayı etkilemeye başlıyor.
Ayırt edici bakış açıları da şunlar:
- Model merkezli söylemden uzak durmak Daha akıllı bir GPT beklemek yerine, bugün eldeki modelle ulaşılabilecek sınırı yükselten mühendislik yöntemleri öneriliyor. Bugün gördüğümüz yapay zeka sınırları ile modelin gerçekte sahip olduğu yetenek arasındaki farkın büyük kısmı bir harness açığı olarak görülüyor.
- Harness kaybolmaz, sadece yer değiştirir Model iyileştikçe bazı harness parçaları gereksiz hale gelir. Örneğin Opus 4.6, Claude Sonnet 4.5’te sık görülen “context bitmek üzere, hemen toparlayayım” türü aceleciliği neredeyse ortadan kaldırdı; bu sayede daha önce kullanılan bazı güvence mekanizmaları tamamen ölü koda dönüştü. Ancak modelin ulaştığı yeni alanlarda yeni zayıflıklar ortaya çıkar ve bunları telafi eden yeni harness’lere ihtiyaç duyulur. Anthropic’in “Harness’in her parçası, modelin tek başına yapamadığı bir şeye dair varsayım taşır” sözü bu durumu iyi özetliyor.
- Model ile harness arasındaki öğrenme döngüsü Viv’in dikkat çektiği bir başka akım da harness tasarımı ile model eğitimi arasındaki geri besleme döngüsü. Harness içinde yararlı bir kalıp bulununca bu standartlaşıyor; sonraki nesil modeller bu kalıba göre eğitiliyor; ardından bu modellerin üzerinde yeni harness kalıpları ortaya çıkıyor. Sonuç olarak “iyi harness”, modelin eğitim gördüğü varsayılan harness değil, kişinin kendi işine göre yeniden rafine ettiği harness oluyor.
- Sektörün benzer bir yapıya yakınsaması Claude Code, Cursor, Codex, Aider ve Cline gibi kodlama yapay zekaları farklı modeller kullansa da harness yapıları giderek birbirine benziyor. Modeller farklıyken harness’lerin benzeşmesi, bu alanın nerede dengelenmeye başladığını gösteren bir işaret olarak okunabilir.
Osmani’nin yazısı, kodlama yapay zekasının rekabet gücünün model seçiminden çok onu çevreleyen harness tasarımına bağlı olduğunu ve harness’in bir kez ayarlanıp bırakılan bir yapılandırma dosyası değil, hata geçmişine göre sürekli güncellenen yaşayan bir sistem olduğunu savunuyor. Model iyileştikçe harness ortadan kalkmıyor; sadece ele alınan problemlerin seviyesi bir kat yukarı taşınıyor ve yeni harness o boşluğu dolduruyor. Onun aktardığı Viv sözüyle, “iyi bir agent yapmak iterasyon sanatıdır ve ilk sürüm yoksa iterasyon da yoktur.” Bu da alanın özünde, kimin daha hızlı başlayıp daha sık iyileştirebildiğiyle ilgili olduğunu gösteriyor. Sonuçta mühendislerin zaman ayırması gereken yer, gündemdeki modeli sürekli değiştirip durmak değil; kendi işine uygun harness’i durmadan geliştirerek modelin ulaşabildiği tavanı adım adım yukarı taşımaktır.
10 yorum
Gittikçe sadece pazarlama terimleri aşırı çoğalıyormuş gibi geliyor.
Model ne kadar iyi olursa, harness tasarımı üzerindeki yük de o kadar azalır.
Böyle şeyler uygulansa da gerçek kodlama sırasında bakınca pek büyük bir faydası olmuyor gibi... Geliştirme zorluk seviyesi
codexplanını koyup ajan çalıştırma düzeyinde olduğu için öyledir herhalde hahaAma promptta “A’yı yap, B’yi yapma” dediğimizde bunu gerçekten iyi anlayabiliyorsa böyle bir yaklaşım geçerli gibi görünüyor; ancak yapay zeka sunucusunun durumuna göre promptu olasılıksal olarak yerine getiriyorsa böyle bir yaklaşım yine de geçerli olur mu?
Eskiden prompt’a “A’yı yap” diye açıkça yazmama rağmen belirli bir olasılıkla bunu sürekli yerine getirmediği için
mrkdwnbold ile vurgulamayı, iki kez yazmayı, İngilizce yazmayı, başı sonu birbirine bağlayarak yazmayı, XML olarak yazmayı akla gelen her türlü şeyi denedim ama yine de belirli bir olasılıkla prompt’u görmezden geliyordu...Ben de Osmani’nin anlattığına benzer her şeyi doldurup
uygulama yaparken bu konu açıldı diye biraz acele ettim ama,
Osmani de sadece konuşmakla kalmayıp
Google Antigravity’ye kendi söylediklerini ekleseydi daha iyi olmaz mıydı diye düşünüyorum.
Kapathy için de aynı şey geçerli; artık doğrudan bir şey yapmayı düşünmeyip sadece ortaya bir yazı atıp bırakma tavrı bana göre pek öyle değil!dir
https://github.com/hang-in/tunaFlow
3 maddelik özet
harnessadı verilen çalışma ortamının tasarımına bağlıdır.Ratchetilkesi: Yapay zekanın hatalarını basit birer kaza olarak görmek yerine, bunları kural belgelerine (AGENTS.mdgibi) veya hook'lara hemen yansıtıp sistemin zamanla daha sağlam hale gelmesini sağlayacak şekilde yönetmek gerekir.Skill) meselesi: Yapay zekanın iyi çalışmaması çoğu zaman model zekasının yetersizliğinden değil, harness tasarımının zayıf olmasından kaynaklanır; bu yüzden istenen çıktıdan geriye doğru giderek gerekli bileşenleri ve kısıtları tasarlayan mühendislik yaklaşımı şarttır.Ama Harness geçen haftaya kadar deli gibi satıyordu, bu haftadan itibaren sessizleşti.. Sanırım Anthropic'in saçmalamaları ve Codex 5.5'in çok iyi olması yüzünden........
SDD gibi şeylerin hype’ı zaten çoktan söndü; şimdi sıra harness’e gelmiş gibi görünüyor.
Harness tarafında biraz ilginç olan kısım şu: eğitim verisinde açıkça yok ama model
harnessdiye bir kavramı çok hızlı anlıyor.Belki zaten var olan bir kelimenin anlamını aynen kullandığı içindir; ben hiç bahsetmemiş olmama rağmen önce
harness’i güncelleyelim gibi ifadeler de kullanıyor.Pek de özü olmayan bir şeyi kulağa makul gelecek şekilde anlatan kıdemli bir geliştiricinin yazısını, üstelik analiz ederek ele alan bir içerik olmuş (kişisel olarak Google'dan hoşlanmadığım için kusura bakmayın). Elbette olguya dair bir anlayış geliştirmeye dönük yaklaşımın iyi bir deneme olduğunu düşünüyorum.