Harness Engineering: AI Ajanları İçin Güvenilirlik Mühendisliği

Teşhisten otonom iş akışlarına kadar Claude Code, Codex ve Cursor çevresinde talimatları, durumu ve doğrulamayı tasarlıyoruz

15 レッスン 5時間 56分 サブスク特典
対象者
Halihazırda bir AI kodlama ajanı (Claude Code, OpenAI Codex, Cursor, Gemini CLI, Aider) kullanmakta olan ve tutarsız sonuçlarla karşılaşan geliştiriciler ve teknik liderler. Ajanın gözetim altında yalnızca 10 dakika değil, saatlerce ve oturumlar boyunca verimli çalışmasını isteyenler; ayrıca ajanlar etrafında dahili araçlar veya platformlar geliştirenler.
必要条件
Git, komut satırı bilgisi ve en az bir AI kodlama ajanıyla çalışma deneyimi. Makine öğrenimi bilgisi gerekmez — kurs, modelin nasıl çalıştığından ziyade, onun etrafında güvenilir bir ortamın nasıl tasarlanacağına odaklanır.

コースカリキュラム

15 レッスン
1
入門 Ajanınız bozuk değil — bozuk olan onun etrafındaki şeyler
6 分
無料 視聴
Adım başına %95 doğruluk, onuncu adımda ajanı neden bitirir?
Harness engineering'in formel temellerini inşa ediyoruz: geri beslemeli bir sistem olarak ajan (algılama → karar → eylem → değerlendirme), çok adımlı çalıştırmalarda hata birikiminin matematiği, Ashby Yasası (gereken çeşitlilik) ve Goodhart Yasası (hedefe dönüştüğü anda metrik olma niteliğini yitiren metrik), gürültülü bir kanal olarak bağlam ile birlikte tek nesnel hazırlık ölçütü olarak sözleşmeler/değişmezler/son koşullar.
ajan kontrol döngüsü adım zincirinde hata birikimi Ashby Yasası Goodhart Yasası gürültülü kanal olarak bağlam sözleşmeler ve son koşullar
26 分
登録後 登録する
«Vibe» değil: Bir ajanın güvenilirliğini gerçekte ne ölçüyor?
Teorik temele devam ediyoruz: MTBF/MTTR ve hasar yarıçapı (blast radius) bir harness'ın güvenilirlik metrikleri olarak; kuyruk/WIP ve Little Yasası, ajanın paralel görevlerinin neden birbirini yavaşlattığını açıklayan model olarak; Markov oturum durumu (gelecek yalnızca mevcut duruma bağlıdır, geçmişe değil); güven kalibrasyonu (ajan ne zaman «kendinden emin» bir şekilde yalan söyler); entropi ve Lehman Yasaları'nın zamanla yaşanan harness bozulmasına uygulanması; ve tüm bu teorinin hızlı teşhis için tek bir tabloda özetlenmesi.
MTBF/MTTR hasar yarıçapı (blast radius) Little Yasası WIP Markov oturum durumu güven kalibrasyonu harness entropisi Lehman Yasaları
24 分
Piyasadaki en güçlü model — yine de canlı ortamda hatalar
Amiral gemisi modellerin bile gerçek kod depolarında basit görünen görevleri neden düzenli olarak başaramadığını inceliyoruz. Ajanın gerçekte kırıldığı beş katmanı (görev, talimatlar, durum, araçlar, doğrulama) ve tek geçişte ilgili katmanı tespit eden tanısal döngüyü tanıtıyoruz.
beş başarısızlık katmanı tanısal döngü model yeteneğine karşı yürütme güvenilirliği
22 分
Gerçekten Çalışan Bir Ajan Hangi Beş Parçadan Oluşur?
Harness'ın beş alt sistemi — talimatlar, araçlar, ortam, durum ve geri bildirim döngüleri — ile bunların birbirleriyle nasıl etkileşim kurduğu. Tipik benimseme eğrisini (önce neyin düzeltilmesi gerektiğini), sabit model üzerinde ablasyon yöntemiyle her bileşenin değerini nasıl ölçebileceğinizi ve alt sistemler arasındaki akışların nihai şemasını ele alıyoruz.
harness'ın beş alt sistemi ablasyon ölçümü benimseme eğrisi
24 分
Ajan, siz harita bırakmadığınız için proje yapısını uyduruyor
Depo (repository), oturumlar arasında hafızası bulunmayan bir ajan için tek doğruluk kaynağıdır. Bu derste depo haritası olarak neyi ölçmemiz gerektiğini, iyi bir haritanın dört ilkesini, işlevsel bir dosya yapısını ve ajan durumu için ACID benzeri garantileri inceliyoruz.
tek doğruluk kaynağı olarak depo (repository) depo haritası ajan durumu için ACID
24 分
Kural doğrudan dosyaya yazılmış. Ajan onu okumuyor. Peki neden?
Tek bir devasa talimat dosyasının, hiç olmamasından daha kötü olması nedeni. Talimatların bozulmasına yol açan dört bağımsız neden, talimatlar için SNR (sinyal/gürültü) metriği, yönlendirici → belgeler → yürütülebilir kontroller şeklindeki üç katmanlı mimari, kural pasaportu ve talimatları çalışır durumda tutmaya yönelik pratik kurallar.
yönlendirici mimarisi talimat SNR'ı üç katmanlı mimari kural pasaportu
26 分
Ajanın her oturumda amnezisi var — işte tedavi planı
Ajan, her sabah tam amnezili bir dahi mühendis gibi: yeni oturum neden dün zaten karara bağlanmış konuları yeniden soruyor ve kendi dünkü kararlarıyla çelişiyor? Kompaksiyonu bağlam sıfırlamasıyla karşılaştırıyor; dört süreklilik artefaktını (PROGRESS.md, session-handoff, git kontrol noktaları, karar günlüğü) ve kurtarma maliyeti metriğini ele alıyoruz. Ayrıca başlatmayı (init) ayrı bir faz olarak inceliyoruz: dört koşullu bootstrap sözleşmesi, kabul kontrol listesi, sıcak başlangıç ile soğuk başlangıç karşılaştırması ve minimal scripts/init.sh.
oturumlar arası süreklilik session-handoff bootstrap sözleşmesi sıcak başlangıç
28 分
Aynı Anda Üç Özellik, Sıfır Tamamlanan: Bir Ajanın Hikayesi
Ajanın neden frenleri olmadığını ve aynı anda üç göreve sarıldığında neler yaşandığını, sıkı WIP=1 sınırının ve net görev sınırlarının bu sorunu nasıl çözdüğünü inceleyeceğiz. Ardından — özellik listesi (feature_list.) gerçek bir harness ilkel öğesi (primitive) olarak ele alınacak: behavior/verification/state üçlü kayıt yapısı, dört durumdan oluşan sonlu durum makinesi, 'passing' durumunu koyma yetkisine sahip tek varlık olarak scripts/verify.sh ve katı (strict) ile zayıf (weak) doğrulama arasındaki fark.
WIP=1 görev granülaritesi (ayrıntı düzeyi) feature_list. özelliğin sonlu durum makinesi gate bekçisi (gate guard)
28 分
Ajan "Hazır ✅" yazdı. Ama özellik çalışmıyor. Nedenini inceliyoruz
Doğrulama boşluğu (verification gap) — "ajan hazır olduğunu söyledi" ile "özellik gerçekten çalışıyor" arasındaki uçurum. Üç katmanlı tamamlanma doğrulaması, AGENTS.md dosyasında tanımlanan Definition of Done, öncelik kısıtlaması (doğrulama tamamlanmadan refactoring yok), ajana yönelik kırmızı işaretler — kendiliğinden çözülen hata mesajları ve üç rollü mimari (uygulayıcı / denetleyici / hakem).
Doğrulama boşluğu (verification gap) Tamamlanmış Tanımı (Definition of Done) Üç katmanlı doğrulama Rol ayrımı
24 分
Tüm Testler Yeşil Ama Özellik Bozuk. Hata Nerede Saklanıyor?
Birim testlerinin kör noktaları: ajan tüm modül testlerinden geçiyor, ancak özellik bütün olarak çalışmıyor. E2E testleri hatayı yakalamadan önce bile ajanın davranışını neden değiştiriyor? "Servis veritabanına doğrudan erişemez" gibi bir mimari kuralı, dokümanda bir paragraf olmaktan çıkarıp çalıştırılabilir bir kontrole nasıl dönüştürürsünüz? Lint'ten E2E'ye uzanan doğrulama hiyerarşisi.
izolasyonun kör noktaları E2E testleri çalıştırılabilir mimari kurallar doğrulama hiyerarşisi
26 分
Ajan çalıştı ama ne yaptığını kimse açıklayamıyor
Her şey çalışıyor gibi görünse de kimse — ne bir insan ne de ajanın bir sonraki oturumu — tam olarak neyin yapıldığını ve nedenini açıklayamıyor. Bu derste iki gözlemlenebilirlik katmanını, sprint sözleşmesini (sprint contract: kapsam içinde / kapsam dışında / işe başlamadan önceki açık sorular) ve genel izlenim yerine değerlendirici rubriğini (rubric) ele alıyoruz. Devamında temiz vardiya devri ve entropiyle mücadele geliyor: beş boyutta temiz durum, oturumdan çıkış kontrol listesi, iki modlu temizlik ve temizleme işlemlerinin idempotentliği.
harness gözlemlenebilirliği sprint sözleşmesi (sprint contract) değerlendirici rubriği temiz devir teslim harness entropisi
28 分
Bir ajanı saatlerce sizin denetiminiz olmadan çalışacak şekilde nasıl bırakırsınız
Tek seferlik istekten otonom döngüye geçiş. Mümkün olan en basit döngü, birbirine karıştırılmaması gereken dört döngü türü, altı temel döngü öğesi (primitif), iptal edilemez tek garanti olarak üretici ve değerlendiricinin ayrılması, iyi tasarlanmış bir döngü örneği (hedef, metrik, kısıtlamalar, çalışma sırası, durdurma koşulları, eskalasyon), otonominin dört sessiz maliyeti, olgunluk merdiveni.
Döngü Mühendisliği üretici ve değerlendirici durdurma koşulları insana eskalasyon
26 分
Ajan için tek döngü artık yeterli olmadığında
Tek bir döngünün yetenekleri nerede sona erer: üç yapısal başarısızlık (geri alma mekanizması yok, paylaşımlı durum yok, gerçekliğe çapa yok). Dört seviyeli çerçeve ve grafiğin dört temel öğesi. Anchors — yerel optimizasyonla aşılamayan çapalar. Graf ile workflow arasındaki fark. İlk grafiğin altı adımda nasıl oluşturulacağı. Orchestration tax ve grafiğin gerçekten gerekli olduğu beş kriter.
Graf Mühendisliği (Graph Engineering) çapalar (anchors) orkestrasyon vergisi (orchestration tax) graf ile workflow farkı
24 分
Harness'ı Baştan Sona Kuruyoruz: Boş Bir Depodan Otonom Ajan'a
Kursun finali: uçtan uca projemiz olan FastAPI ödeme backend'inde adım adım inşa ettiğimiz her şeyi alıp tek bir çalışan sistem hâlinde birleştiriyoruz. Harness'ın tüm artefaktlarını baştan sona inceliyoruz: tematik belgelerle birlikte AGENTS.md yönlendiricisi, sonlu durum makinesi içeren feature_list., PROGRESS.md ve vardiya devir teslim protokolü, doğrulama kapısı (gate) görevi gören scripts/verify.sh ve scripts/arch-check.sh, sprint sözleşmesi ve değerlendirici rubriği, temiz oturum kapanışı kontrol listesi, otonom döngü için program.md ve çok rollü süreç için graph.md. Sonda ise ajanın metriklerini harness öncesi ve sonrası karşılaştırıyoruz.
harness'ı baştan sona birleştirme uçtan uca proje öncesi/sonrası metrikleri bitirme projesi (capstone)
20 分