Son iki yıldır, yapay zeka ajanlarıyla ilgili kariyer tavsiyeleri büyük ölçüde onlara iyi prompt yazmayı öğrenmek üzerineydi. Artık kıt olan beceri bu değil. Kıt olan beceri, bir ajanın içinde barındığı iskeleti kurmak — giderek harness olarak adlandırılan şey — ve bu o kadar özel ve o kadar zor ki, bir ekipte "yapay zeka işini bilen kişi"nin yan sorumluluğu olmaktan çıkıp kendi başına bir iş tanımı haline geliyor.

Bunun aslında neyi kapsadığına dair en net kamuya açık anlatım, ürün yönetimi aracı ChatPRD'nin Sentry hatalarını otomatik olarak ayıklamak için nasıl bir harness kurduğunu belgeleyen Lenny's Newsletter'dan geliyor. Bu alanda uzmanlaşıp uzmanlaşmayacağınızı tartıyorsanız yazının tamamını okumaya değer, çünkü kolayca gözden kaçabilecek bir noktaya değiniyor: darboğaz hiçbir zaman model olmadı. Ekip, temel olarak Claude Agent SDK'yı kullandı, ardından mühendislik çabalarının büyük bölümünü özel bir terminal arayüzüne ve ajanı Sentry, Linear, GitHub ve Vercel'e bağlayan bir dizi adaptöre harcadı. İş, küçük ölçekte tam olarak bu. Dört sistem, dört farklı kimlik doğrulama şeması, dört farklı veri biçimi ve bir insanın her adımı dadılık yapmadan izleyip müdahale etmesini sağlayan bir arayüz.

'Harness' aslında neye ayrışıyor

Bunun geliştirmeye değer bir beceri seti olup olmadığını anlamaya çalışıyorsanız, işi ayrı ayrı işe alınan — ya da en azından bir mülakatta ayrı ayrı değerlendirilen — parçalara bölmek işe yarar:

  • İzin tasarımı. Bir ajanın gözetimsiz olarak yapmasına izin verilen şeyleri (bir bileti okumak, bir PR taslağı hazırlamak) insanın devrede olması gereken şeylerden (birleştirme, dağıtım, silme, para harcama) ayırmak — ve bunu, modelin baskı altında göz ardı edebileceği bir prompt talimatı olarak değil, kodda gerçek bir politika olarak kodlamak. Bu, prompt yazmaktan çok erişim kontrolü mühendisliğine yakındır.
  • Araç adaptörleri. Her bir dış sistem (Sentry, Linear, GitHub, Vercel veya şirketinizin yığını her ne ise) etrafında, ajanın niyetini güvenli, doğrulanmış bir API çağrısına çeviren ve yanıtı modelin akıl yürütebileceği bir şeye geri çeviren ince, iyi test edilmiş sarmalayıcılar. Bu, hata yönetimi, yeniden denemeler, şema doğrulaması gibi sıradan yazılım mühendisliğinin yeni bir tüketiciye uygulanmasından ibaret.
  • Terminal veya konsol arayüzü. Bir insanın ajanın ne yaptığını görmesini, eylemleri onaylamasını veya reddetmesini ve ajan takıldığında araya girmesini sağlayan bir yol. ChatPRD kendi özel arayüzünü kurdu; birçok ekip bunun yerine hazır ajan konsolları kullanacak, ama yine de birinin neyin gösterileceğine, neyin gizleneceğine ve neyin gerçekleşmeden önce bir tıklama gerektireceğine karar vermesi gerekiyor.
  • Ölçekte araç seçimi. Machine Learning Mastery'den bir yazı, bir demodan öteye geçen herhangi bir şey inşa ediyorsanız bilinmeye değer bir şeye dikkat çekiyor: araç kataloğu yaklaşık bir düzine seçeneği aştığında, ajanın araç çağrılarındaki doğruluğu düşme eğilimindedir — model araçları yanlış çağırmaya, parametreleri halüsinasyon görmeye veya kötü çağrılarda takılıp kalmaya başlar. Listelenen çözümler (belirli bir bağlamda hangi araçların görünür olacağının kısıtlanması, alma tabanlı araç arama, uzmanlaşmış alt ajanlara yönlendirme, açık planlama adımları, yedek mantık ve gerilemeleri yakalamak için kıyaslama harness'leri) bir harness mühendisinin sadece bilmesi değil, nasıl uygulayacağını da bilmesi gereken şeylerin bir kontrol listesi.
  • Bağlam ve bellek mühendisliği. Aynı kaynak, içselleştirilmeye değer bir ayrım yapıyor: bağlam mühendisliği (tek bir çıkarım çağrısına nelerin ve nerede gireceği) ile bellek mühendisliği (oturumlar arasında nelerin kalıcı olduğu, nasıl saklandığı, nasıl geri getirildiği) farklı başarısızlık biçimlerine sahip farklı disiplinlerdir. İddiası şu: uzun süre çalışan, çok oturumlu ajanlardaki çoğu bozulma, bu ikisinin karıştırılmasına — oturum belleğini sanki sadece daha fazla bağlammış gibi ele almak ya da bunun tersi — özellikle de sistemin neyi geri getireceğine karar verdiği noktada, geri dayanıyor.

Bunun gerçek, finanse edilebilir bir rol olduğuna dair kanıt — sadece amatör bir niş değil

Şüpheciler haklı olarak "harness mühendisi"nin bir meslek mi yoksa başka birinin işinin içindeki bir görev mi olduğunu soracaktır. Derlemedeki iki veri noktası, işin birincisine doğru evrildiğini gösteriyor. Birincisi, Microsoft'un 10 kişilik Aspire ekibi, depolar arası dokümantasyon PR'larını otomatikleştirmek için GitHub'ın Agentic Workflows'unu kullandı ve iki sürüm boyunca, karşılık gelen ürün PR'ı yayımlandıktan medyan 44,8 saat sonra, hiçbir yeni işe alım ve hiçbir süreç yeniden eğitimi olmadan 82 PR birleştirdi. Bu, küçük bir ekibin, mühendislere dokümantasyon PR'larını elle yazdırmak yerine biri iskeleye (iş akışı tanımları, inceleme yönlendirmesi, tetikleyici mantığı) yatırım yaptığı için orantısız bir kaldıraç elde etmesi. İkincisi, Microsoft Research'ün SkillOpt projesi, bir ajanın harness'i içinde nasıl davranacağını şekillendiren talimatlar ve kısıtlamalar olan ajan "skill" dosyalarını elle düzenlenecek bir şey değil, sistematik olarak optimize edilecek bir şey olarak ele alıyor ve bir kıyaslama ızgarasının (altı kıyaslama, yedi model, üç yürütme modu) 52 hücresinin tamamında en iyi ya da en iyiyle eş düzeyde sonuç verdiğini, optimize edilmiş skill'lerin farklı modeller ve farklı harness'ler arasında aktarılabildiğini bildiriyor. Bu belirli araç standart hale gelsin ya da gelmesin, sektörün harness yapılandırmasını kendi araçları ve kıyaslamaları olan bir mühendislik ürünü olarak ele almaya başladığının bir işareti — tıpkı "DevOps"u bir dizi rastgele betikten bir disipline dönüştüren aynı gidişat gibi.

Şu anda özellikle bu katman için açıkça inşa edilen bir altyapı da var. Google'ın Gemini API'sinde yeni duyurduğu "Managed Agents" (Yönetilen Ajanlar) yetenekleri — arka plan ve eşzamansız yürütme, uzak MCP sunucu entegrasyonu, özel fonksiyon çağırma, etkileşimler arasında kimlik bilgisi yenileme — aslında ChatPRD ekibinin elle çözdüğü tam da o sorunlar için önceden inşa edilmiş bir tesisat. Bu normal bir örüntü: bir ekibin bu yıl özel olarak inşa ettiği şeyi, bir platform sağlayıcısı gelecek yıl ürünleştiriyor. Bu, harness mühendisliği rolünü ortadan kaldırmıyor; tabanı yükseltiyor ve işi her adaptörü sıfırdan yazmak yerine yönetilen ilkel yapı taşlarını entegre etmeye ve yapılandırmaya doğru kaydırıyor — bulut altyapısının operasyon mühendislerini ortadan kaldırmayıp zamanlarını neye harcadıklarını değiştirmesine benzer şekilde.

Bu role yöneliyorsanız bunun anlamı ne

Bu iş için güvenilir olmak istiyorsanız portföyünüze veya özgeçmişinize koyabileceğiniz birkaç somut, doğrulanabilir şey: kontrol etmediğiniz gerçek bir API'ye karşı uçtan uca bir adaptör inşa edin (kimlik doğrulama, hata yönetimi, hız sınırları dahil, sadece mutlu-yol demosu değil); bir ajan için okuma/öneri/eylem eylemlerini birbirinden ayıran ve her sınırın neden orada olduğunu gösteren bir izin modeli tasarlayıp belgeleyin; ve bir insanın ajan eylemlerini yürütülmeden önce onayladığı bir inceleme arayüzü inşa edin veya yapılandırın, çünkü çoğu şirketin bir ajanın üretime dokunmasına izin vermeden önce ısrar edeceği parça bu. Bir harness mühendisliği iş teklifini değerlendiriyorsanız veya kendi sorumluluklarınızın kapsamını belirliyorsanız, izin modelinin sahibinin kim olduğunu, adaptörlerin sahibinin kim olduğunu ve insan-inceleme yüzeyinin sahibinin kim olduğunu özellikle sorun — şu anda birçok ekipte bu üç şeyin net bir sahibi yok, ki bu tam olarak bu rolün doldurmak üzere oluştuğu boşluk.

Açıkça belirtilmeye değer bir uyarı: yukarıdaki kaynakların hiçbiri bu spesifik unvan için bir işe alım piyasası rakamı ortaya koymuyor ve "harness mühendisi" henüz ilanlarda göreceğiniz bir iş unvanı değil — "yapay zeka altyapı mühendisi", "ajan platform mühendisi" veya sadece "kıdemli backend mühendisi, yapay zeka sistemleri" gibi unvanların içinde ortaya çıkıyor. Bunu LinkedIn'de aranacak bir unvan değil, geliştirilecek ve doğru şekilde tarif edilecek bir beceri seti olarak ele alın.