Ajan Özerklik Düzeyleri

• Ajanik mühendislik, prompt yazmaktan çok operasyon tasarımına yaklaşıyor; her iş için izin verilecek özerklik düzeyi ile bunu destekleyecek doğrulama yöntemi birlikte belirlenmeli
• Tek eksenli merdiven modeli, tek bir ajana duyulan güveni sayıyla ifade etmekte yararlı olsa da, birden çok ajanı aynı anda ele alma yeteneği agency ve orchestration olmak üzere iki eksende değerlendirilmelidir
• 0~5 düzey modeli, yalnızca öneri sunan Assist'ten istisna durumlarda insanın devreye girdiği Managed-by-exception orchestration aşamasına kadar uzanır; düzey yükseldikçe hedef, kapsam, kanıt, yetki ve bütçe daha net olmalıdır
• Anthropic'in Claude Code analizinde yaklaşık 400 bin oturum ve yaklaşık 235 bin kullanıcıya ait veriler, planlama kararlarının yaklaşık %70'inin insanlar tarafından, uygulamanın yaklaşık %80'inin ise Claude tarafından üstlenildiğini gösteriyor
• Olgun ajan kullanımı, yüksek özerkliği sergilemekten değil; risk ve geri alınabilirlik düzeyine uygun calibrated autonomy uygulamak ve doğrulama darboğazlarını yönetmekten geçer

---

Prompt yazımından operasyon tasarımına kayan ajanik mühendislik

• Ajanik mühendisliğin odağı, prompt yazımından operasyon tasarımına kayıyor
• Yazılım fabrikası, hedefler, döngüler, arka plan oturumları, alt ajanlar, hook'lar, sandbox'lar ve ajanların başka ajanları onaylama biçimleri öne çıkıyor
• Claude Code ve Codex, bu değişimi gösteren başlıca ürünler olarak ele alınıyor
• Mühendisler, riski azaltmak ve geri almayı kolaylaştırmak için düşük özerklik kullanabilir; net tanımlı faaliyetlerde veya büyük kod tabanı refactor işlemlerinde ise daha yüksek özerklik ve paralel ajan filoları kullanılabilir
• Temel soru, her görev için hangi düzeyde özerkliğe izin verileceği ve bu düzeyi hangi doğrulamanın savunabileceğidir

Tek bir merdiven yerine iki eksende özerklik

• Steve Yegge'nin “Welcome to Gas Town” yazısında değinilen tek eksenli merdiven, tek bir ajana duyulan güveni sayısal olarak ifade etmekte yararlıdır
• 2026'nın başlarında, işlerin delegasyondan orkestrasyona kaydığı dönemde bile tek eksen, risk ölçümü için kaba bir vekil gösterge işlevi görüyordu
• Aynı anda birden çok ajan çalıştırılabildiğinde, tek bir seviye çoklu ajan yeteneğini açıklamakta yetersiz kalır
• Özerklik tartışmaları çoğu zaman birbirinden farklı iki soruyu karıştırır
  • Tek bir ajan, insandan ne kadar uzak gönderilebilir?
  • Birden çok ajan ne kadar iyi koordine edilebilir?
• Bunu ayırmak için iki eksen gerekir
  • agency: Tek bir ajanın öneri sunma, sınırlı görevler yapma veya hedefe ulaşmayı ne kadar özerk biçimde yerine getirdiği
  • orchestration: Tek bir thread'den çoklu görev ağaçlarına, backlog/issue tracker/zamanlama temelli sürekli işlere kadar ne kadar iyi koordinasyon sağlandığı

agency ve orchestration ne anlama geliyor?

• agency ekseninin düşük düzeylerinde ajan, olası eylemleri önerir ve insan kararını bekler
• Orta düzeylerde ajan belirli görevleri yerine getirir ama kapsam sınırlıdır; yaptığı işleri kanıtlarla birlikte sürekli raporlayarak insanın yönlendirme yapmasına imkan tanır
• Yüksek agency düzeyinde ajan, hedefe ulaşmak için deney yapar, öğrenir, test eder, tıkanmaları giderir, soru sorar, farklı yaklaşımlar dener ve bunları kanıt olarak geri sunar
• orchestration ekseninin düşük düzeyi, tek ajan ve tek thread'dir
• Orta düzeyde, birden çok ajan ayrı worktree'lerde farklı hedefler üzerinde çalışır
• Yüksek düzeyde ise orkestratör, backlog, issue tracker, zamanlama ve kuyrukları sürekli işe dönüştürür; insan ise yalnızca başarısızlık durumlarında devreye giren management by exception modeline yaklaşır
• İlgili özellik ve ürün örnekleri şunlardır
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, alt ajanlar, hook'lar, checkpoint'ler, ajan delegasyonu ve yönetim biçimleri, arka plan oturumları, ajan ekip kalıpları, /schedule argümanı
  • Codex: yerel/bulut thread'leri, Goal mode, worktree, Automations, alt ajanlar, review panel, GitHub code review, hook'lar, sandbox'lar, Auto-review, rerun

Üç dönem ve altı seviye

• Merdiven aşağıdan yukarı okunduğunda agency ve orchestration'ın birlikte yükseldiği izlenimi oluşur
• Altı seviye, üç döneme ayrılır
  • İnsanın direksiyonda olduğu, ajanın yardımcı olduğu ve insan komutunu beklediği dönem
  • Ajanın sınırlı görevleri veya hedefleri üstlendiği ama insanın yönlendirme ve doğrulama yaptığı dönem
  • Sistemin işleri birden çok ajana dağıttığı, insanın ise çoğunlukla sorun çıktığında devreye girdiği orkestrasyon dönemi
• Gerçek mühendislikte gün boyunca birden çok seviye arasında gidip gelmek doğaldır

Level 0: Assist

• Ajan çoğu zaman iyi, bazen de kusursuz öneriler sunar; ancak çalıştırılıp çalıştırılmayacağına her zaman insan karar verir
• Örnekler arasında otomatik tamamlama, satır içi düzenleme önerileri ve henüz kimsenin sahiplenmediği değişikliklerin sohbet içinde tartışılması yer alır
• Maliyeti yüksek hatalar, çok küçük değişiklikler ve henüz yargı oluşturma aşamasındaki işler için uygundur
• Doğrulama çoğunlukla yerel olarak yapılır

Level 1: Supervised action

• Ajan sizin yerinize düzenleme yapar veya komut çalıştırır; ancak önemli adımlardan önce insandan izin ister
• Çoğu insanın kullandığı varsayılan çalışma tarzına yakındır
• Yerel sandbox'ta, değişiklik uygulanmadan önce onay alarak veya etkileşimli bir oturum içinde çalışabilir
• Her onay, ilgili değişikliğin uygulanmasının güvenli olup olmadığını doğrulayan bağımsız bir kontrol gibi işlev görür
• Başlıca hata modu onay yorgunluğudur
  • Hangi şeye onay verilirse verilsin tüm onaylar birbirine benzer gelmeye başlayabilir
  • Buna, diff'i hızlıca gözden geçirme, sezgisel kurallar kullanma, başka birine kontrol ettirme veya sorumluluğu ajana bırakma gibi yollarla tepki verilebilir
• Codex Auto-review, sınırdaki durumlar için son onayı ayrı bir reviewer ajanına devrederek bu sorunu ele alır

Level 2: Scoped task delegation

• Bu aşamada sınırlı bir görev ajana devredilir
• Görevin açık bir hedefi, kısıtları ve tamamlanmış sayılma koşullarını tanımlayan bir iş tanımı olmalıdır
• İnsan yakında kalır ve isterse durdurabilir, ancak çoğu zaman doğrudan müdahil olmaz
• Yazılım mühendisliğinde merkezi konuma en yakın seviye olarak ele alınır
• Doğrulama, insanın doğrudan kontrolünden ajanın üretebileceği kanıtlara kayar
  • Geçen otomasyon testleri
  • Uygun type'lar
  • Lint önerileri
  • Ekran görüntüleri
  • Yeniden üretim adımları
  • Örnek temelli kaynaklar

Level 3: Goal-driven autonomy

• Ajan, belirli bir koşul sağlanana kadar hedefe ulaşmak için gereken işleri yapar
• Prompt modunda prompt'un kendisi hedefe dönüşür
  • Örnek: “Bu sayfanın time-to-interactive süresi 1 saniyenin altına indirilebilir mi?”
• Codex'te buna Goal mode karşılık gelir; ajan plan -> act -> test -> review adımlarını tekrarlar ve başarı ölçütünü artık karşılayamaz hale geldiğinde durur
• Claude Code'da /goal, /loop, /schedule komutları bu düzeye karşılık gelir
• Bu seviyenin yararlı olması için durma koşulunun otomatikleştirilebilir biçimde ölçülebilir olması gerekir
• “Kullanıcı deneyimini genel olarak iyileştir” veya “kod tabanını daha test edilebilir hale getir” gibi belirsiz hedefler uygun değildir
• Daha uygun hedefler somut, ölçülebilir ve otomasyona elverişli olmalıdır
  • Statik analizi atlatan production bug'larını bulmak
  • Yükleme süresini azaltmak
  • Açık any içermeyen katı bir TypeScript build'ini garanti etmek
  • Yalnızca anlaşılabilir ve testleri geçen bağımlılıkları bırakacak şekilde tüm bağımlılıkları sınıflandırmak
• Production bug bulmak için ajanın production benzeri bir ortamda olması gerekir

Level 4: Parallel delegation

• Bu aşamada birden çok ajan paralel çalışır
• Her ajan işin ayrılmış bir parçasını üstlenir
• En büyük darboğaz, hangi parçaların devredileceğine karar veren parçalama sürecidir
• Destekleyici özellikler arasında alt ajanlar, arka plan oturumları, /batch, worktree ve ajan ekipleri bulunur
• Başlıca hata modu sahte paralelliktir
  • Birden çok ajan çakışan parçalar üzerinde aynı anda çalışırsa, daha fazla çıktı yerine merge conflict ve yinelenen kararlar üretebilir
• İyi işletmek için ajanların birbirinden yalıtılması gerekir
  • Her birinin sahip olduğu dosyalar ve durumlar olmalıdır
  • Her birinin ayrı bir review kuyruğu da olmalıdır
• Her ajan için token maliyeti oluşur ve bu maliyet eşzamanlı çalışan ajan sayısıyla orantılıdır
• İnsan tarafında ise belirli bir sayıdan sonra yeni ajan eklemenin marjinal maliyeti orkestrasyon vergisi nedeniyle artar

Level 5: Managed-by-exception orchestration

• İnsan başarı tanımını ve uygulanacak politikaları belirler; manager agent ise tetikleyicilere göre uyanıp işleri dağıtır
• Tetikleyici örnekleri: yeni issue, yeni görev, saat
• manager agent worker agent'ları görevlendirir, ilerlemeyi izler, çıktıları doğrular ve hata durumunda yeniden dener
• Koşullar sağlandığında daha yetenekli bir ajana veya insana escalation yapar; sonuçları bir araya getirip PR gibi iş çıktıları ve kanıtlarla birlikte dış sistemlere geri verir
• Bu seviye bir fabrikaya benzetilir
  • Girdi, issue tracker veya backlog'dur
  • Çıktı, çözülmüş birden çok issue veya bug'dır
• Ajanlar, yeterli sınırların ve gerektiğinde çıkış yollarının bulunduğu yalıtılmış ortamlarda çalışır
• Bu fabrikanın ne yapacağını, manager agent tarafından tanımlanan işletim sistemi belirler
• OpenAI, Symphony için bir spec önerdi ve bunu Linear board etrafında kurguladı
  • Her issue'nun kendine ait bir ajan workspace'i vardır
  • Ajan, kendi workspace'indeki spec dosyasında tanımlanan hedefe doğru ilerlemeyi sürdürüp sürdürmediğini kontrol eder
• Orkestrasyonda ön cephe, yüzlerce hatta binlerce ajanın çalıştığı sürekli ajan fabrikaları kurmaktır
• Bu aşamada bağımsız doğrulama daha da önemli hale gelir
  • Uygulayıcı ile reviewer'ın ayrılması
  • Test çalıştıran ile QA'nın ayrılması
  • Güvenlik kontrollerinin ayrılması
  • Kabul için süreç kapılarının ayrılması

Risk ve geri alınabilirlik özerkliğin üst sınırını belirler

• Anthropic'in Claude Code ile ilgili araştırmasında, en zor bazı görevlerde Claude Code'un, kullanıcının işi kesmesinden iki kattan daha sık açıklayıcı soru sorduğu görüldü
• Deneyimli kullanıcılar, yaklaşık 750 oturuma sahip kullanıcılar olarak tanımlandı; bunlar 50'den az oturumu olanlara göre otomatik onay ve kesme özelliklerini daha sık kullanıyor, aynı zamanda ilerlemeyi izleme eğilimi gösteriyordu
• Anthropic'in daha geniş kapsamlı analizi, 2025 Ekim ile 2026 Nisan arasında yaklaşık 235 bin kişiye ait yaklaşık 400 bin oturumu kapsıyordu
• Her oturumda, kullanıcıların her prompt'ta kaç davranış talep ettiği, neleri otomatik onayladığı ve ne sıklıkta durdurduğu gibi kararlar incelenebildi
• İnsanlar planlama kararlarının yaklaşık %70'ini, Claude ise uygulamanın yaklaşık %80'ini üstleniyordu
• Yüksek özerklik, insanı döngünün dışına çıkarmak değil; insanın her adımı tek tek yapmasından bir sonraki yönü belirlemesine geçmek anlamına gelir
• Büyük bir yapay zeka sisteminin gerçekten yüksek özerklikle çalışıp çalışmadığını anlamak için üç soru gerekir
  • Neyin yanlış gittiğini ne kadar hızlı anlayabiliyoruz?
  • Yapılan şeyi ne kadar temiz biçimde geri alabiliyoruz?
  • Yapılan şeyin doğru olduğunu ne kanıtlıyor?
• Eğer yanıt “hızlı anlayamıyoruz, geri almak zor ve özete güvenmek zorundayız” ise, bu yüksek özerklik değildir

Ajan çalıştırmadan önce sözleşmede neler olmalı?

• Her ajan çalıştırılmadan önce, ne yapacağını tanımlayan bir sözleşme gerekir
• Bu sözleşmede şu başlıklar yer almalıdır
  • Hedef: faaliyet veya teknik değil, ulaşılmak istenen sonuç
  • Kapsam: çalışılacak alan ve izin verilen teknikler
  • Hedef dışı alanlar: amaca dahil olmayan şeyler
  • Araçlar ve yetkiler: ajanın dış dünyayla nasıl etkileşime gireceği
  • Durma koşulu: ne zaman duracağı; mümkünse ölçülebilir değişkenlerle
  • Kanıt: tamamlandığını bağımsız olarak doğrulayabilecek testler, ekran görüntüleri, log'lar, veritabanı kayıtları vb.
  • Escalation: hangi durumda kimin devreye gireceği ve ajanı kimin çalıştırdığı
  • Bütçe: zaman, emek ve token sınırları
• Token'lar büyük yapay zeka modellerinin bütçesidir; buna deneme sayısı ve paralellik düzeyi için sınırlar da dahil edilebilir

Metrikler özerkliği biraz daha güvenilir kılar

• Metrikleri sonradan belirlemek tek başına yeterli olmayabilir
• Metrikler kısa bir belge halinde önceden yerleştirilebilir ve özerkliği daha güvenilir kılar
• Özerklik seviyelerine göre izlenebilecek metrik örnekleri şunlardır
  • Müdahaleler arasındaki ortalama süre
  • Kabul edilen iş ölçütüne göre en uzun insansız çalışma süresi
  • Sandbox içinde yürütülen eylemler ile escalation edilen eylemlerin oranı
  • Otomatik onaylanan eylemler ile reddedilen eylemlerin oranı
  • İnsan başına verilen tek bir yönerge için ortalama ajan eylemi sayısı
  • Açıklama isteme oranı
  • Durdurma talebi oranı
  • Kabul edilen değişiklik başına review süresi
  • Güven düzeyine göre yeniden iş yapma oranı
  • Güven düzeyine göre defect sızıntı oranı
  • Kabul edilen değişiklik başına token maliyeti
• İnsan tarafından sıradaki iş verilen tek bir yoğun ajan, dashboard eklenmiş bir Level 4'e daha yakındır; otomatik alım, yeniden deneme ve yeterli kanıt olmadan ilerlemeyen muhafazakar bir ajan ise gerçek kapılara sahip bir Level 5'e daha yakındır

Hazırlık durumu ve özerklik seviyesi seçimi

• Görevler risk ve geri alınabilirlik düzeyine göre sınıflandırılmalıdır
• Özerklik muhafazakar uygulanmalı, yalnızca daha yüksek düzeyleri destekleyen kanıt biriktikçe artırılmalıdır
• Güçlü testleri, reviewer ajanları ve temiz rollback yolları olan bir ödeme motoru refactor'u; doğru cevap anahtarı olmayan dokümantasyon otomasyonu işine göre daha yüksek özerkliği destekleyebilir
• Özerklik seviyesi, işin adına değil doğrulama sürecine göre belirlenmelidir

Dört özerklik anti-pattern'i

• Autonomy as status

  • Ajanın özerklik derecesi, anlamı olmayan bir statü rozeti gibi işlemeye başlar
  • Yüksek özerklik, güvenliğin değil yeteneğin kanıtıymış gibi görülür ve doğrulamanın desteklemediği düzeylerde ajan çalıştırılır
  • Doğru özerklik seviyesini seçen ve sınırı aşmayan kişiler takdir edilmeli ve ödüllendirilmelidir

• Permission laundering

  • Onay yorgunluğu nedeniyle AI ajanlarına ve araçlara gereğinden geniş erişim hakları verilir
  • Sandbox profilleri, kapsamı sınırlı yazma kökleri, izinli komut listeleri, hook'lar ve Auto-review gibi sınırlar güçlendirilmelidir

• Summary substitution

  • Ajanın iş özeti, review'un yerini alır
  • Buna karşı, manuel review benzeri kanıt paketleri de birlikte sunulmalıdır
  • Bu paketler diff, testler, log'lar, ekran görüntüleri, reviewer bulguları, riskler ve boşluklar içerebilir

• Fleet cosplay

  • Onlarca ajan paralel çalıştırılır ama insan tüm bağımlılıkları hâlâ elle koordine eder
  • Paylaşılan durum, sahiplik kuralları ve daha iyi bağımlılık takibi manuel koordinasyon ihtiyacını azaltır
  • Daha küçük WIP sınırları, koordinasyon adımlarını kodlayıp belgelemeye odaklanmayı teşvik ederek orkestrasyon otomasyonuna kapı açabilir

Güvenli biçimde nasıl yukarı çıkılır?

• Son dönemde ajan yardımıyla yapılan 10 işin gözden geçirildiği bir kalibrasyon alıştırması önerilir
  • Her işin özerklik seviyesi
  • Riski
  • Geri almanın ne kadar kolay olduğu
  • Doğrulama gereksinimini karşılamak için üretilen kanıt
  • Review süresi
  • Yeniden iş yapılıp yapılmadığı
  • Aynı özerklik seviyesinin bir dahaki sefere de uygun olup olmadığı
• Bir seferde yalnızca tek eksende yükselmek gerekir
• Başlangıç noktası, savunulabilir başarı kanıtı üreten tek bir sınırlı görevi yerine getiren tek bir supervised agent olmalıdır
• Bundan sonra üç yönde kademeli genişleme yapılabilir
  • Okuma ağırlıklı keşif işleri paralelleştirilebilir
  • Sınırlı dosya sahipliği kuralları olan ayrı worktree'lerde yazan ajanlar eklenebilir
  • Tekrarlı otomasyonlar eklendikten sonra issue veya ses gibi girdilere dayalı ajan yönlendirmeli orkestrasyon eklenebilir
• Her seviye artışı, yeni hata modlarına karşı yeni güvenlik önlemleri gerektirir
• Hata modları şunlardır
  • Uzun tek ajan çalışmaları: sürüklenme, bağlam bozulması, eksik iletişim, hedeften sapma
  • Arka plan işleri: eskimiş varsayımlar, zayıf devir teslim
  • Aşırı paralel işler: merge conflict, yinelenen kararlar
  • Aşırı tekrarlı işler: sessiz token harcaması, eskimiş prompt'lar
  • managed-by-exception: uzun review kuyrukları, bildirim yorgunluğu
• Daha sert güvenmek yerine kapsamı daraltmak, daha iyi kanıt toplamak, daha ucuz rollback yolları kurmak, kapıları güçlendirmek ve sahiplik kurallarını netleştirmek gerekir

Seviyelere göre uygun kullanım alanları

• Level 0, hassas işler ve henüz yargı oluşturma aşamasındaki durumlar için en uygundur
• Level 1, sınırları iyi anlaşılmış alanlara yakın çoğu keşif işi için uygundur
• Level 2, bilinmeyen bağımlılıklar ve beklenmeyen sorunlar içerebilecek çoğu sınırlı görev için uygundur
• Level 3, başarı koşullarının yeterince net ifade edilebildiği durumlar için uygundur
• Level 4, işin başarı koşullarına göre temiz biçimde bölünebildiği durumlar için uygundur
• Level 5, birden çok başarı koşulu arasındaki gerekli koordinasyon ve iletişim tamamen kodlandıktan sonra uygundur

Doğrulama hâlâ darboğaz olmaya devam ediyor

• Mevcut güven düzeyi ve araçlara rağmen, AI ajanlarıyla çalışan olgun mühendislik ekiplerinin yaklaşımı calibrated autonomy olmaya devam ediyor
• Yakın gelecekte, ne zaman çalışılacağını, ne zaman doğrulama yapılacağını ve ne zaman soru sorulacağını bilen döngüleri tasarlamak gerekecek
• Mühendisin yetkinliği, uygun özerklik seviyesini seçme, onun karanlık taraflarını engelleyen kalıplar kurma ve savunulabilir kanıtlar üretme etrafında şekillenmeye devam edecek