- Anthropic, frontend tasarım kalitesini artırma ve uzun süreli otonom kodlama olmak üzere iki sorunu aynı anda çözmek için GAN'dan ilham alan çok ajanlı bir yapı geliştirdi
- Üretici (generator) ve değerlendiriciyi (evaluator) ayıran yapı, öznel tasarım kalitesini somut kriterlerle puanlanabilir hale getirerek ajanın öz değerlendirme yanlılığı sorununu çözüyor
- Planlayıcı-üretici-değerlendiriciden oluşan 3 ajanlı mimari, çok saatli otonom kodlama oturumlarında tam yığın uygulamaları tamamlıyor; sprint sözleşmesi müzakeresi ve Playwright tabanlı QA da buna dahil
- Opus 4.5'ten Opus 4.6'ya geçişle birlikte sprint'e bölmeden de 2 saatten uzun süre tutarlı kodlama mümkün hale geldi; böylece harness karmaşıklığı azalırken performans korundu
- Model performansı artsa bile ilginç harness kombinasyonlarının alanı daralmıyor, yer değiştiriyor; yapay zeka mühendislerinin temel görevi de yeni kombinasyonları bulmak
Basit uygulamanın sınıra dayanmasının nedeni
- Önceki deneylerde başlatıcı ajan, ürün spesifikasyonunu görev listesine ayırıyor; kodlama ajanı da her seferinde bir özelliği uyguladıktan sonra oturumlar arasında bağlamı artifact'ler üzerinden aktarıyordu
- Geliştirici topluluğunda da, "Ralph Wiggum" yöntemi gibi hook veya script ile ajanı sürekli tekrar döngüsünde tutan benzer yaklaşımlar ortaya çıktı
- Karmaşık görevlerde ajanın zamanla rotadan çıkma sorunu devam etti ve iki ortak başarısızlık modu gözlemlendi
- İlk başarısızlık modu: Bağlam penceresi doldukça model tutarlılığını kaybediyor ve bazı modeller "bağlam kaygısı (context anxiety)" nedeniyle kendi bağlam sınırına ulaştığını düşündüğünde işi erken toparlamaya eğilim gösteriyor
- Bağlam sıfırlama (bağlam penceresini tamamen boşaltıp, önceki ajan durumu ve sonraki adımları içeren yapılandırılmış bir handoff ile yeni bir ajan başlatma) bu iki sorunu da çözdü
- Bu, konuşmanın önceki kısımlarını özetleyip aynı ajanın devam etmesini sağlayan compaction yaklaşımından farklı; compaction sürekliliği korur ama temiz bir sayfa sunmadığı için bağlam kaygısı sürebilir
- Claude Sonnet 4.5'te bağlam kaygısı o kadar güçlüydü ki yalnızca compaction ile uzun görev performansı garanti edilemiyordu; bu yüzden bağlam sıfırlama, harness tasarımının temel unsuru haline geldi
- İkinci başarısızlık modu: öz değerlendirme (self-evaluation) sorunu; ajan kendi ürettiği çıktıyı değerlendirirken kalite açıkça vasat olsa bile kendinden emin şekilde övme eğiliminde
- Bu durum özellikle tasarım gibi öznel görevlerde ciddileşiyor; doğrulanabilir yazılım testlerindeki gibi ikili bir kontrol yok
- Çalışan ajan ile değerlendirme ajanını ayırmak güçlü bir kaldıraç; bağımsız değerlendiriciyi şüpheci olacak şekilde ayarlamak, üreticiyi öz eleştirel hale getirmekten çok daha kolay yönetiliyor
Frontend tasarımı: Öznel kaliteyi puanlanabilir hale getirmek
- Müdahale olmadığında Claude, teknik olarak çalışan ama görsel olarak vasat olan güvenli ve öngörülebilir düzenler üretmeye eğilimli
- Harness tasarımını yönlendiren iki temel içgörü var
- Estetik tamamen puanlanamasa da, tasarım ilkeleri ve tercihlerini kodlayan puanlama ölçütleriyle iyileştirilebilir — "Bu tasarım güzel mi?" sorusundan ziyade "Bu, iyi tasarım ilkelerini izliyor mu?" sorusu daha tutarlı puanlama sağlıyor
- Frontend'de üretim ve puanlamayı ayırmak, üreticiyi daha güçlü sonuçlara iten bir geri bildirim döngüsü oluşturuyor
- Hem üreticiye hem değerlendiriciye verilen 4 puanlama ölçütü:
- Tasarım kalitesi (Design quality): Renk, tipografi, düzen, görseller vb. birleşerek belirgin bir atmosfer ve kimlik oluşturan tutarlı bir bütün yaratıyor mu
- Özgünlük (Originality): Özel kararların izi var mı, yoksa şablon düzenler, kütüphane varsayılanları veya AI üretimi kalıplar mı kullanılmış — mor degrade üzerinde beyaz kart gibi AI üretimi işaretleri varsa başarısız sayılıyor
- İşçilik (Craft): Tipografi hiyerarşisi, boşluk tutarlılığı, renk uyumu, kontrast oranları gibi teknik uygulama düzeyi — yaratıcılık değil yetkinlik kontrolü
- İşlevsellik (Functionality): Estetikten bağımsız kullanılabilirlik — kullanıcı arayüzün ne yaptığını anlayabiliyor ve ana eylemleri bulabiliyor mu
- Tasarım kalitesi ve özgünlüğe, işçilik ve işlevsellikten daha yüksek ağırlık verildi — çünkü Claude işçilik ve işlevsellikte zaten yüksek puan alırken, tasarım ve özgünlükte vasat sonuçlar üretiyordu
- Ölçütler, çok genel "AI slop" kalıplarını açıkça cezalandıracak şekilde yazıldı; böylece model estetik risk almaya teşvik edildi
- Orkestrasyon Claude Agent SDK ile kuruldu; üretici HTML/CSS/JS frontend'i oluştururken değerlendirici Playwright MCP ile canlı sayfayla doğrudan etkileşime giriyor, ekran görüntüleri alıyor, uygulamayı ayrıntılı biçimde inceliyor, ardından puan ve detaylı eleştiri yazıyor
- Her üretim için 5 ila 15 tekrar yapıldı; her turda değerlendirici eleştirisine yanıt veren üretici daha özgün yönlere kaydı
- Tüm çalışma 4 saate kadar sürebildi
- Üreticiye her değerlendirmeden sonra stratejik karar vermesi söylendi: puan eğilimi iyiyse mevcut yönü iyileştir, yaklaşım çalışmıyorsa tamamen farklı bir estetiğe geç
- Ölçütlerin ifade biçimi üreticiyi beklenmedik şekilde etkiledi — "en iyi tasarımlar müze kalitesindedir" gibi ifadeler belirli bir görsel yakınsamayı teşvik etti; ölçütlerle bağlantılı istem dili çıktının karakterini doğrudan şekillendirdi
- Puanlar genelde tekrarlar boyunca yükseldi ama her zaman doğrusal değildi; son tur yerine ara turların tercih edildiği durumlar da sık görüldü
- Uygulama karmaşıklığı tekrarlar boyunca artma eğilimindeydi; değerlendirici geri bildirimine yanıt olarak daha iddialı çözümler aranıyordu
- İlk turdan itibaren, istemsiz temel çizgiye göre belirgin biçimde daha iyi sonuçlar görüldü; ölçütler ve ilişkili dil, değerlendirici geri bildiriminden önce bile modeli genel varsayılanlardan uzaklaştırdı
- Hollanda sanat müzesi web sitesi örneği: 9. tura kadar temiz bir koyu temalı açılış sayfası üretildikten sonra, 10. turda yaklaşım tamamen bırakıldı ve CSS perspective ile oluşturulmuş 3D oda, dama desenli zemin, duvarlara serbestçe asılmış eserler ve kapılardan galeriler arasında gezinme içeren mekânsal bir deneyim olarak yeniden tasarlandı — tek geçişli üretimde görülmeyen türden yaratıcı bir sıçrama
Tam yığın kodlamaya genişletme
Mimari
- Önceki uzun süre çalışan harness ile başlatıcı ajan, özellik bazlı kodlama ajanları ve oturumlar arası bağlam sıfırlama sayesinde tutarlı çok oturumlu kodlama çözülmüştü
- Sonnet 4.5'in bağlam kaygısı nedeniyle bağlam sıfırlama kritik olsa da, Opus 4.5'te bu davranış büyük ölçüde ortadan kalktı ve tüm derleme bağlam sıfırlama olmadan tek sürekli oturumda yapılabildi
- Claude Agent SDK'nın otomatik compaction özelliği artan bağlamı yönetti
- 3 ajanlı sistem şu şekilde kuruldu:
- Planlayıcı (Planner): 1 ila 4 cümlelik kısa bir istemi tam ürün spesifikasyonuna genişletiyor — ayrıntılı teknik uygulamadan çok ürün bağlamı ve üst düzey teknik tasarıma odaklanacak şekilde istem veriliyor; çünkü teknik ayrıntıları en baştan sabitlemek, hataların aşağı akışta yayılmasına yol açabiliyor
- Ürün spesifikasyonuna AI özellikleri örme (weave) fırsatlarını bulması da isteniyor
- Üretici (Generator): Spesifikasyondan sprint bazında özellikleri tek tek alıp React/Vite/FastAPI/SQLite (daha sonra PostgreSQL) yığınıyla uyguluyor; her sprint sonunda öz değerlendirme yapıp QA'e handoff ediyor ve git ile sürüm yönetimi yapıyor
- Değerlendirici (Evaluator): Playwright MCP ile çalışan uygulamayı gerçek bir kullanıcı gibi tıklayarak dolaşıyor; UI işlevlerini, API endpoint'lerini ve veritabanı durumunu test ediyor — ürün derinliği, işlevsellik, görsel tasarım ve kod kalitesi ölçütlerine göre puan veriyor; ölçüt bazında sert eşiklerin altında kalınırsa sprint başarısız sayılıyor
- Her sprint öncesinde üretici ile değerlendirici sprint sözleşmesi (sprint contract) müzakere ediyor — kod yazılmadan önce ilgili iş parçası için "tamamlandı" tanımı üzerinde uzlaşılıyor
- Ürün spesifikasyonu bilerek üst düzey tutulduğu için bu adım, kullanıcı hikâyeleri ile test edilebilir uygulama arasındaki boşluğu dolduruyor
- İletişim dosya tabanlı yürütülüyor — bir ajan dosya yazıyor, diğeri okuyup yanıtlıyor
Harness çalışma sonuçları: retro oyun yapımcısı
- "Seviye düzenleyici, sprite düzenleyici, varlık davranışları ve oynanabilir test modu içeren bir 2D retro oyun yapımcısı oluştur" istemiyle test edildi
- Tek ajan: 20 dakika / $9, buna karşılık tam harness: 6 saat / $200 — harness 20 kattan fazla pahalıydı ama çıktı kalitesindeki fark hemen açıkça görüldü
- Tek başına çalışma sonucu: İlk ekran beklentiyi karşıladı ancak tıklamaya başlayınca sorunlar ortaya çıktı — düzen alanı boşa harcıyor, iş akışı katı, önce sprite ve varlık oluşturmak gerekiyor ama arayüz bunu yönlendirmiyor; en kritik nokta ise oyunun gerçekten çalışmamasıydı (varlıklar ekranda görünse de girdiye tepki vermiyor, varlık tanımları ile oyun çalışma zamanı arasındaki bağlantı kopuk)
- Harness ile çalışma sonucu: Planlayıcı, tek cümlelik istemi 10 sprintte 16 özellik spesifikasyonuna genişletti — sprite animasyon sistemi, davranış şablonları, ses efektleri ve müzik, AI destekli sprite üreticisi ve seviye tasarımcısı, paylaşılabilir bağlantıyla oyunu dışa aktarma dahil
- Frontend tasarım becerilerini okuyup uygulamanın görsel tasarım dilini de spesifikasyonun parçası olarak oluşturdu
- Tuval tüm görüntü alanını kullanıyor, panel boyutları makul ve spesifikasyondaki tasarım yönünü izleyen tutarlı bir görsel kimlik sunuyor
- Sprite düzenleyici daha zengin ve tam özellikli; daha temiz araç paleti, daha iyi renk seçici ve daha kullanılabilir yakınlaştırma kontrolleri içeriyor
- AI entegrasyonu, istemlerle oyunun farklı bölümlerini oluşturarak iş akışını hızlandırıyor
- Oynatma modundaki temel fark: Tek ajanlı çalışmada oyun çalışmazken, harness çalıştırıldığında varlıklar gerçekten hareket ettirilebiliyor ve oyun oynanabiliyordu — fizik motorunda biraz pürüz (platformlarla karakterin çakışması) ve AI seviye düzeninde sınırlamalar (zıplanamayan büyük duvarlar) vardı ama temel işlev çalışıyordu
- Değerlendirici, uygulamanın spesifikasyona bağlı kalmasını sağladı — daha Sprint 3'te bile seviye düzenleyici için 27 kriteri kapsayan ayrıntılı bir sözleşme vardı
- Bulunan sorun örnekleri: dikdörtgen doldurma aracının yalnızca sürüklemenin başlangıç/bitiş noktalarına karo yerleştirmesi, varlık silme tuş işleyicisinde koşul hatası, FastAPI route sıralama sorunu nedeniyle
reorder değerinin tamsayı olarak parse edilip 422 hatası döndürülmesi
- Değerlendiriciyi ayarlamak ciddi emek istedi — Claude varsayılan haliyle zayıf bir QA ajanıydı; haklı sorunları bulsa bile kendini "çok da önemli değil" diye ikna edip onaylama eğilimindeydi, yüzeysel testlerle ince hataları kaçırıyordu
- Değerlendirici log'larını okuyup kararların ayrıştığı örnekleri bularak QA istemlerini güncelleyen geliştirme döngüsü birkaç kez tekrarlandıktan sonra makul puanlama elde edildi
Harness üzerinde yinelemeli iyileştirme
- İlk sonuçlar cesaret vericiydi ama büyük, yavaş ve pahalıydı; bu yüzden performansı düşürmeden harness'i sadeleştirmek bir sonraki adım oldu
- Harness'in her bileşeni, modelin tek başına yapamadığı bir şeye dair varsayım kodluyor ve bu varsayımlar stres testini hak ediyor — çünkü model geliştikçe hızla geçersiz hale gelebilirler
- İlke şuydu: "Mümkün olan en basit çözümü bul ve yalnızca gerektiğinde karmaşıklığı artır"
- Radikal sadeleştirme denemeleri orijinal performansı kopyalayamadı ve hangi parçanın gerçekten yük taşıdığını anlamak zor olduğundan, her seferinde tek bir bileşeni kaldıran sistematik bir yaklaşıma geçildi
- Opus 4.6'nın çıkışı, harness karmaşıklığını azaltmak için ek motivasyon sağladı — daha dikkatli planlıyor, agentic görevleri daha uzun sürdürüyor, daha büyük kod tabanlarında daha kararlı çalışıyor, kendi hatalarını yakalama konusunda kod inceleme/hata ayıklama becerileri iyileşmiş durumda ve uzun bağlam taraması da büyük ölçüde gelişti
Sprint yapısını kaldırmak
- Sprint yapısı tamamen kaldırıldı — Opus 4.6'nın gelişmiş yetenekleri sayesinde model, görevleri parçalamadan da tutarlı biçimde yürütebiliyor
- Planlayıcı ve değerlendirici korundu — planlayıcı olmadan üretici yetersiz kapsam ile, yani ham istemden doğrudan spesifikasyonsuz bir derlemeye başlayıp az özellikli uygulamalar üretiyordu
- Değerlendirici, sprint başına puanlamadan çalışma sonundaki tek geçişli değerlendirmeye taşındı
- Görev modelin tek başına yapabildiği alan içindeyse değerlendirici gereksiz ek yük olabiliyor; ancak model yeteneğinin sınırındaki görevlerde hâlâ anlamlı iyileşme sağlıyor
- Bu nedenle değerlendirici sabit bir evet/hayır meselesi değil; mevcut modelin tek başına güvenilir şekilde yapabildiği aralığın ötesine geçildiğinde maliyetine değiyor
- AI özellikleri oluşturmayı iyileştiren istemler de eklendi — üreticinin uygulamanın kendi işlevi olarak araçlar üzerinden çalışan uygun ajanlar inşa etmesini sağlamak için ciddi yineleme gerekti; ilgili bilgi çok yeni olduğundan Claude'un eğitim verisinde bu konu sınırlı kapsanıyordu
Güncellenen harness sonuçları: tarayıcı DAW
- "Web Audio API kullanarak tarayıcıda tam işlevli bir DAW oluştur" istemiyle test edildi
- Toplam yaklaşık 4 saat, $124.70 harcandı
- Planlayıcı 4.7 dk/$0.46, build turu 1 2 saat 7 dk/$71.08, QA turu 1 8.8 dk/$3.24, build turu 2 1 saat 2 dk/$36.89, QA turu 2 6.8 dk/$3.09, build turu 3 10.9 dk/$5.88, QA turu 3 9.6 dk/$4.06
- Builder, sprint'e bölmeden 2 saatten uzun süre tutarlı şekilde çalıştı
- QA ajanının ilk geri bildirimi: Tasarım sadakati ile AI ajanı ve backend güçlüydü, ancak işlevsel bütünlük ana başarısızlık noktasıydı — zaman çizelgesinde klip sürükleme/taşıma yoktu, enstrüman arayüz panelleri (synth knob'ları, drum pad'ler) eksikti, görsel efekt düzenleyicisi (EQ eğrisi, compressor meter) yoktu
- QA'nın ikinci geri bildirimi: Ses kaydı hâlâ stub durumundaydı, klip yeniden boyutlandırma ve bölme uygulanmamıştı, efekt görselleştirmeleri grafik yerine sayısal slider'lardan ibaretti
- Nihai uygulama profesyonel müzik prodüksiyon yazılımı düzeyine ulaşmadı ve ajanın beste üretme yeteneğinin gelişmesi gerekiyor; Claude gerçekten ses duyamadığı için QA geri bildirim döngüsü müzikal zevk açısından daha az etkili kaldı
- Buna rağmen çalışan arrangement view, mixer ve transport dahil işlevsel bir müzik üretim programının temel unsurlarına sahipti
- Yalnızca istemlerle kısa şarkı parçacıkları üretilebildi — ajan tempo ve tonu ayarladı, melodi yerleştirdi, davul parçası oluşturdu, mixer seviyelerini düzenledi ve reverb ekledi
Gelecek perspektifi
- Modeller geliştikçe daha uzun ve daha karmaşık görevleri yerine getirebilmeleri bekleniyor; bazı durumlarda modelin etrafındaki iskeletin önemi azalabilir ve bir sonraki modeli beklemek bazı sorunları doğal olarak çözebilir
- Buna karşılık model ne kadar iyi olursa, temel çizginin ötesindeki karmaşık görevleri başaran harness'ler geliştirmek için alan da o kadar genişler
- Temel dersler:
- Hedef modeli deneysel olarak incelemek, gerçek problemler üzerinde trace'leri okumak ve performansı istenen sonuca göre ayarlamak her zaman iyi bir pratiktir
- Daha karmaşık görevlerde, görevi parçalara ayırıp her yönüne özelleşmiş ajanlar uygulamak hareket alanı yaratabilir
- Yeni bir model çıktığında harness'i yeniden gözden geçirmek; artık performans yükünü taşımayan parçaları çıkarmak ve daha önce mümkün olmayan daha büyük yeteneklere ulaşmak için yeni parçalar eklemek iyi bir pratiktir
- Model gelişse de ilginç harness kombinasyonlarının alanı küçülmez, yer değiştirir; yapay zeka mühendislerinin görevi de sıradaki yeni kombinasyonları bulmaya devam etmektir
Henüz yorum yok.