Anthropic'un Yapay Zekâ Doğal SDLC Oyun Kitabı Darboğazı Doğrulamaya Taşıyor

Ajanlar etrafında yeniden yapılan bir yaşam döngüsü

Anthropic, mirrord Kubernetes geliştirme aracının arkasındaki şirket MetalBear'ın analizine göre, yazılım geliştirme yaşam döngüsünü yapay zekâ kodlama ajanları etrafında yeniden düzenlemek için bir oyun kitabı yayınladı; analiz Hacker News'in ön sayfasında öne çıktı. MetalBear'ın özetlediği üzere oyun kitabının öncülü, geleneksel SDLC'nin kod yazmanın yavaş adım olduğu bir dönemi için tasarlanmış olduğudur. Ajanlar bu adımı ortadan kaldırdı ve darboğaz çevresindeki her şeye kaydı: planlama, tasarım, inceleme ve doğrulama.

Altı aşama, her biri bir dosya bırakıyor

Çerçeve altı aşamayı kapsıyor ve her birinin bir sonraki aşamanın okuyabileceği bir yapı commit etmesi bekleniyor. Planlama bir intent.md dosyası üretiyor. Tasarım bunu bir spec.md'ye çeviriyor. Koda dokunulmadan önce, build aşaması bir plan.md yazıyor. Deployment, inceleme politikasını bir REVIEW.md içinde taşıyor. Anthropic ayrıca okların hangi uygulamalara önce başlanacağını gösterdiği bir benimseme grafiği de içeriyor; üst satır ön koşulu olmayan pratikleri listeliyor — geri bildirim döngüsü bu satırda yer alıyor, yani ekipler oradan başlayabilir.

Aşama 4: ajan kendini denetliyor

MetalBear'ın odaklandığı aşama, ajanın bir insan ona bakmadan önce kendi çıktısını kontrol ettiği Aşama 4, yani geri bildirim döngüsü. Oyun kitabı, ekiplerden ajana kontrol edebileceği somut bir şey vermelerini istiyor: bir test paketi, bir build veya bir ekran görüntüsü farkı. Oyunu manipulate etmeyi önlemek için, ajan bir hatayı düzeltirken test dosyalarındaki düzenlemeleri engelleyen bir hook öneriyor, böylece kırmızı bir testi testi yeniden yazarak yeşile çeviremiyor. Arayüz çalışması için bir tarayıcının veya ekran görüntüsü aracının MCP üzerinden bağlanmasını öneriyor.

MetalBear, oyun kitabının çoğu süreç belgesinden daha ileri giderek ekiplerden ajanın kendi yapılandırmasını üretim koduyla aynı titizlikle yönetmelerini istediğini belirtiyor: CI'da çalışan eval'ler, CLAUDE.md, skills ve hooks'tan herhangi biri her değiştiğinde bunları yeniden test ediyor ve her üretim olayı kalıcı bir eval vakası haline geliyor. Bunların tümü için belirtilen ön koşul, her biri tek bir komutla yerel olarak çalışan bir test paketi ve bir build.

Oyun kitabının açık bıraktığı soru

MetalBear'ın eleştirisi tam bu ön koşulda başlıyor. Oyun kitabı ajanın çalıştırılabilir testlere ihtiyacı olduğunu söylüyor ama bu testlerin neye karşı çalışması gerektiğini değil. Veritabanlarına, kuyruklara ve düzinelerce diğer servise bağımlı bir servis için — ki bu çoğu gerçek yazılımı tanımlıyor — MetalBear'a göre sorunun büyük kısmı tam olarak bu.

Kontroller yerel fake'lere karşı çalışıyorsa, geçen bir çalışma yalnızca kodun fake'lere karşı çalıştığını kanıtlar. İnsan bir geliştirici, mock faturalandırma servisinin bir kimlik doğrulama değişikliğinden önceye ait olduğunu ya da sahte arama endpoint'inin hiç sayfalama yapmadığını hatırlayarak onlara ne kadar güveneceğini ayarlayabilir. Bir ajanın bu bağlamdan hiçbiri yok; yeşil testler görüyor ve görevi tamamlandı olarak raporluyor.

MetalBear ayrıca yapay zincirinin tamamının insanların yazdığı şeylerden oluştuğuna dikkat çekiyor. İçinde canlı sistemi gösteren hiçbir şey yok: bir upstream servisin bugün gerçekte ne döndürdüğü, kuyrukta hangi mesajların beklediği ya da staging veritabanının şemasının ajanın üzerinde çalıştığı branch ile eşleşip eşleşmediği.

mirrord'un önerdiği yanıt

MetalBear, şaşırtıcı olmayan bir şekilde, bir çözüm satıyor. mirrord, kodun yerel olarak, CI'da veya bir ajan sandbox'ında çalışmasına izin verirken trafiği, ortam değişkenlerini, secret'ları ve dosyaları paylaşılan bir staging kümesine ve kümeden proxy'liyor; böylece ajanın kontrolleri mock yerine gerçek bağımlılıklara karşı çalışıyor. Aynı bağlantı, ajanın gerçek API yanıtlarını ve kuyruk içeriklerini incelemesine, dokümantasyona güvenmek yerine, olanak tanıyor.

Oyun kitabı ayrıca birkaç Claude Code oturumunun paralel çalıştırılmasını, her birini kendi git worktree'sinde, bir oturum içinde subagent'larla birlikte öneriyor. MetalBear, worktree'lerin kodu ama altyapıyı yalıtmadığına dikkat çekiyor: tek bir staging servisine yönlendirilen beş ajan hem birbirleriyle hem de onu kullanan mühendislerle çakışacak. Ticari mirrord operator'ü bunu, trafiği header'a göre filtreleyerek her oturuma yalnızca kendi isteklerini ileterek, kuyruk topic'lerini özel dilimlere bölerek ve veritabanlarını oturum başına branch'leyerek çözüyor. mirrord'un kendisi açık kaynak; operator ücretli ürünün bir parçası olarak geliyor. MetalBear kullanıcı olarak monday.com, National Australia Bank ve SurveyMonkey'i sayıyor.

Neden önemli

Oyun kitabı, birçok mühendislik ekibinin zaten hissettiği bir kaymayı resmileştiriyor: kod üretimi ucuzladığında, maliyetli kısımlar niyeti yakalamak, sonuçları doğrulamak ve çıktıyı incelemektir. Yapı zinciri yaklaşımı — her aşama bir sonrakine makine tarafından okunabilir bir dosya bırakır — ekiplerin hemen benimseyebileceği somut, araçtan bağımsız bir kalıptır. Ama MetalBear'ın eleştirisi gerçek bir sınırı işaret ediyor: oyun kitabı bir depodaki dosyaları yönetirken, bir sistem hakkındaki gerçek kısmen konuştuğu altyapıda yaşar. Ajan ağırlıklı iş akışları kuran ekipler, ajanlarının neye karşı doğrulayacağına ve o ortamın gerçekçi olup olmadığına, çok sayıda eşzamanlı ajan için yeterince yalıtılmış olup olmadığına ve yeşil bir test çalışmasının gerçekten bir şey ifade etmesi için yeterince güvenilir olup olmadığına erken karar vermek zorunda kalacak.