Labs — iç ajan sistemleri

Problem

Yayına çıkmadan önce bir projeyi baştan sona denetlemek, tek kişilik bir ekipte en kolay atlanan iş. "Bir kez göz gezdirdim" güvenilir değil, çünkü kontrol listesi kafada duruyor ve her projede farklı maddeler düşüyor. İkinci mesele daha ince: bir dil modeline "bu siteyi denetle" demek işe yaramıyor. Ölçüme dayanmayan bulgu kendinden emin ama yanlış çıkıyor, üstelik yanlışlığı ancak düzeltmeye kalkınca anlaşılıyor. Denetimin değeri bulunan sorunun sayısında değil, bulunan her sorunun gerçek olmasında.

Mimari

Hat sırayla ilerliyor. Scout projeyi profilliyor ve koşullu auditor'ların gerekip gerekmediğini belirliyor. Ardından Playwright harness'ı paralel çalışıyor: ekran görüntüsü, üç koşumluk Lighthouse ve axe erişilebilirlik taraması. Olgunluğu production seviyesinde olan projelerde ayrıca gerçek build çıktısı alınıyor. Bu ölçümler elde olduktan sonra 13 sabit ve 1 koşullu auditor paralel koşuyor — görsel tasarım, etkileşim, dönüşüm, metin, tasarım sistemi, teknik ve içerik SEO, ön yüz ve arka uç performansı, erişilebilirlik, güvenlik, hukuki uyum, veri bütünlüğü ve tespit edilirse veri görselleştirme. Her auditor'ın çıktısı kendi QA red team'ine giriyor; oradan geçen bulgular tek bir çapraz gözden geçiriciye gidiyor. Sonuç, her bulgunun yanında onay kutusu olan bir markdown raporu. Onaylanan düzeltmeleri tek write yetkili bir ajan uyguluyor, ardından doğrulama turu koşuyor.

Kritik Kararlar

1. Denetim ölçümden sonra başlar, ölçüm yerine geçmez

   Auditor'lar konuşmaya başlamadan önce Playwright ekran görüntüsünü, üç koşumluk Lighthouse medyanını ve axe çıktısını alıyor. Bir performans bulgusu artık "sayfa yavaş görünüyor" değil, ölçülmüş bir metrik üzerinden yazılıyor. Erişilebilirlik tarafında da aynı: axe'in yakaladığı ihlal ile modelin tahmini ayrı ağırlıkta.

   ÖdünleşimHarness kurulumu her projede ek bir adım ve rota yapılandırması elle yazılıyor. Ölçüm alınamayan bir projede — yerelde ayağa kalkmayan, veritabanı gerektiren bir uygulama gibi — hat daralıyor ve denetimin bir kısmı yapılamıyor.

2. Her auditor'ın çıktısı ayrı bir red team'den geçiyor

   Tek bir ajanın kendi bulgusunu gözden geçirmesi işe yaramıyor; kendi metnini savunuyor. Bu yüzden her auditor için ayrı bir QA turu var ve o turun görevi hata bulmak: halüsinasyon, önem derecesi şişirmesi, gözden kaçan alan. Geçemeyen bulgu en fazla iki kez geri gönderiliyor.

   ÖdünleşimAjan sayısı ve dolayısıyla maliyet neredeyse ikiye katlanıyor, denetim süresi uzuyor. Küçük bir projede bu maliyet, bulunan sorunun değerini aşabiliyor — kit'i her projede değil, yayına çıkacak projede çalıştırıyorum.

3. Yazma yetkisi tek ajanda ve kapsamı önceden sabit

   Bulgu üreten ajanların hiçbiri dosya değiştiremiyor. Düzeltmeyi yalnızca fix-applier uyguluyor ve onaylanan düzeltmenin dosya listesinin dışına çıkamıyor. Böylece "denetim sırasında bir şey bozuldu" durumu, hangi ajanın ne yaptığını aramayı gerektirmiyor.

   ÖdünleşimKapsam dışında kalan bariz bir hata düzeltilmeden bırakılıyor ve ayrı bir tur gerektiriyor. Toplu düzeltmeler tek ajandan geçtiği için hat burada darboğaza giriyor.

4. Hiçbir düzeltme onaysız uygulanmıyor

   Rapor markdown onay kutularıyla geliyor: uygula, ertele, yapılmayacak. Karar bende kalıyor çünkü bulguların bir kısmı doğru ama o proje için yanlış — erken bir prototipte hukuki uyum bulgusu teknik olarak haklı, pratikte sıradaki iş değil.

   ÖdünleşimYüz maddelik bir raporda onay adımı, işin kendisi kadar zaman alabiliyor. Toplu onay kısayolları bunu hafifletiyor ama ortadan kaldırmıyor; tam otomatik bir hat değil, olmasını da istemiyorum.

Performans

Lighthouse üç kez koşuyor ve metrik başına medyan alınıyor — tek koşum, özellikle soğuk başlangıçta, gerçeği temsil etmiyor. Auditor'lar paralel çalışıyor; hattın toplam süresi en yavaş auditor'a değil, en uzun zincire bağlı.

Sonuçlar

Ajan

18 ajan · 5 slash komut · 5 TypeScript harness script'i

Denetim kapsamı

13 sabit auditor + 1 koşullu (dashboard veya grafik kütüphanesi tespit edilirse)

Doğrulama katmanı

Ajan başına red team + tek çapraz gözden geçirici

Mimari garanti

Yazma yetkisi tek ajanda; o da onaylanmış dosya listesinin dışına çıkamıyor

Bugün Ne Farklı Yapardım

Çapraz gözden geçiriciyi baştan koymalıydım. İlk sürümde her auditor kendi başına rapor yazıyordu ve aynı sorun üç farklı ajandan üç farklı önem derecesiyle geliyordu; raporu okuyan kişi hangisine bakacağını bilmiyordu. Aynı desen portfolyodaki kod tarafında da var: Bergaz Operasyon'da garantiyi uygulama katmanında bırakmak, her yeni yolun aynı kuralı yeniden kurmasını gerektiriyordu. Burada da tekilleştirme kuralı tek bir yere taşınana kadar her auditor kendi tekilleştirmesini yapıyordu.

Problem

Araştırmacılara yeniden üretilebilir istatistik analizi desteği veriyorum. İstatistik benim uzmanlık alanım değil; kod öyle. Bu iki gerçek bir arada, sistemin nasıl kurulacağını belirledi. Bir dil modeline p değeri hesaplatmak, doğru görünen ama doğru olmayan bir sayı üretiyor; üstelik hata çoğu zaman en geç ve en pahalı anda, araştırma değerlendirilirken ortaya çıkıyor. Bu yüzden hattın tek bir sözü var: rapordaki her sayı, onu üreten koda ve girdiye kadar geri izlenebilmeli. Sonucun ne anlama geldiğini yorumlamak ve araştırmanın metnini yazmak araştırmacının işi; hat bunun yerine geçmiyor.

Mimari

Sekiz ajan sırayla çalışıyor: ölçek kütüphanecisi, veri profilleyici, skor üretici, tasarım yorumlayıcı, test seçici, analiz koşucusu, raporlayıcı ve gözden geçirici. Yanlarında görev bazlı ajanlar var; örneğin grafik üretici ve her aşamanın çıktısını araştırmacının isteğiyle karşılaştıran bir kalite kapısı. Sayısal işin tamamı Python tarafında: veri işleme, hipotez testleri, normallik, güvenilirlik katsayısı, regresyon tanılamaları ve etki büyüklüğü. Her sonuç, hangi testten ve hangi girdiden geldiğini taşıyan yapılandırılmış bir kayda yazılıyor; rapor sayıları bu kayıttan olduğu gibi alıyor. Model hesap yapmıyor: akışı yönetiyor, seçilen testin gerekçesini yazıyor ve sonuçları raporlama kurallarına uygun tablolara taşıyor. Hat üç noktada duruyor ve insan onayı bekliyor: ölçek eşlemesinin doğrulanması, hipotezin doğrulanması ve sonuçlarla gözden geçirme notlarının kabulü.

Kritik Kararlar

1. Hesaplamayı asla model yapmaz

   p değeri, F, t, güvenilirlik katsayısı, korelasyon ve regresyon çıktılarının tamamı gerçek istatistik kütüphaneleriyle hesaplanıyor. Modelin ürettiği bir sayı, kaynağı gösterilemediği için savunulamaz; hesabı kütüphaneye vermek, çıktının her rakamını yeniden üretilebilir kılıyor.

   ÖdünleşimModel ile hesap arasındaki her geçiş bir şema gerektiriyor: ajanın ne isteyeceği ve Python'un ne döndüreceği önceden tanımlı olmak zorunda. Bu, yeni bir test eklemenin iki tarafta birden iş çıkarması demek — serbest metinle iş gören bir hattan belirgin biçimde daha yavaş ilerliyor.

2. Üç onay noktası ve yerleri sabit

   Onay noktaları hattın en pahalı hatalarının hemen öncesine konuldu. Ölçek eşlemesi yanlışsa sonraki her hesap yanlış; hipotez yanlışsa doğru hesap yanlış soruya cevap veriyor; sonuçlar kabul edilmeden rapora geçilirse düzeltme maliyeti en yükseğe çıkıyor. Alan kararları araştırmacıda, istatistiksel test seçimi sistemde — bu ayrım da onay noktalarında görünür hâle geliyor.

   ÖdünleşimHat tam otomatik değil ve olamıyor: üç noktada dışarıdan cevap bekliyor. Cevap gecikirse iş duruyor, ve araştırmacı bu üç kararı verebilecek durumda değilse hat hiç ilerlemiyor.

3. Her sayı, onu üreten koda kadar izlenebilir

   Rapordaki her değer, hangi testin hangi girdiyle çalıştığını taşıyan bir sonuç kaydından geliyor; rapor sayıyı bu kayıttan olduğu gibi alıyor, yeniden yazmıyor. Onaylar da kimin verdiği ve hangi dosyaya dayandığıyla kayda geçiyor. Böylece "bu sayı nereden geldi" sorusunun cevabı bir tahmin değil, bir dosya ve bir adım oluyor. Yorumu ve metni araştırmacı yazıyor; hattın teslim ettiği şey sayılar, tablolar ve onların kaynağı.

   ÖdünleşimKayda uymayan bir sonuç bir sonraki aşamaya geçemiyor; küçük bir değişiklik bile kayıt biçiminin güncellenmesini gerektirebiliyor. Hattan hazır bir yorum bekleyen biri için bu sınır baştan açıkça konuşulmak zorunda.

4. Raporlama konvansiyonları ilk üretimden itibaren geçerli

   Bir teslimde hesaplar doğru çıktı ama rapor, biçim kuralları yüzünden revizyona gitti. Bu kurallar artık hattın içinde tanımlı ve ilk taslaktan itibaren uygulanıyor — sonradan düzeltilecek bir cila olarak değil.

   ÖdünleşimKurallar tek bir değerlendirme sürecinden gelen geri bildirimlerle oluştu ve her kurumda birebir aynı olmayabilir. Farklı bir kurumla çalışıldığında kural setinin gözden geçirilmesi gerekiyor; bugün bu elle yapılıyor.

Performans

Hattın süresi hesaptan değil, onay noktalarından geliyor: analiz koşusu dakikalarla, onay bekleme günlerle ölçülüyor. Bu yüzden hat, bir onay noktasında beklerken sonraki adımın hazırlığını yapabilecek şekilde bölündü.

Sonuçlar

Ajan

8 sıralı hat ajanı + 12 görev ajanı

Aktif geliştirme

22 commit

Mimari garanti

Sayısal sonuçların tamamı Python kütüphanelerinden gelir; model aritmetik yapmaz

Mimari garanti

Üç onay noktası geçilmeden rapor teslim edilmez

Bugün Ne Farklı Yapardım

Raporlama konvansiyonlarını baştan yazmadım; bir teslimde sorun çıktıktan sonra eklendi. Bugün bir hattı kurarken "çıktı nerede reddedilir" sorusunu, "çıktı nasıl üretilir" sorusundan önce sorardım — reddedilme kriterleri hattın şeklini belirliyor. Aynı ders Launch Audit Kit'te de çıktı: orada da doğrulama katmanı sonradan eklendi ve eklenene kadar üretilen bulguların bir kısmı kullanılamazdı.