Anthropic'ın AI-Native SDLC Rehberi Mimari Zorunluluğunu Ele Almıyor

Rehber ne öneriyor

dev.to'daki son bir yazı, Anthropic'ın yeni yayınladığı AI-native yazılım geliştirme yaşam döngüsü rehberini inceliyor ve büyük ölçüde onaylıyor. Rehberin temel varsayımı, agent'ların yazdığı kodun darboğazı değiştirmiş olması: Kod üretimi artık hızlı, buna karşılık planlama, inceleme, güvenlik onayı ve sürüm çıkarma hâlâ insan hızında ilerliyor. dev.to yazarının çerçevelediği gibi, diff'lerin çoğunu agent'lar üretmeye başladığında bu uyumsuzluk iki yoldan biri ile çözülür — ya inceleme kuyrukları, hız kazanımları buharlaşana kadar birikir ya da kod gerektiğinden daha az denetimle projeyle birleşir. Düzenlenmiş bir ortamda ikisi de tolere edilemez, başka yerlerde de çekici değildir.

Anthropic'ın cevabı yapısal. Her aşama, bir sonraki aşamanın tükettiği bir artifact üretir — bir niyet dokümanı, bir spec, bir plan, testleriyle birlikte diff, inceleme bulgularını taşıyan PR, incident kaydı — böylece commit zinciri aynı zamanda denetim izi olarak işlev görür. İnsan dikkati, her devir noktasında bağlamı yeniden kurmaya harcanmak yerine aşamalar arasındaki kapılara yoğunlaşır.

Danışmalıktan deterministikliğe yükseliş

Analiz, rehberin kontrol mekanizmalarındaki ilerlemeyi öne çıkarıyor: Her oturumda okunan, sürümlendirilmiş ve PR ile incelenen kuralları içeren CLAUDE.md dosyaları; politikayı bir kez kodlayıp geniş çapta uygulayan ama danışma niteliğinde kalan Skills; eylemleri tamamlanmadan önce durduran deterministik katman olan Hooks; ve konfigürasyonun kendisini regresyon testine tabi tutan evals ile CI. Yazarın yaptığı ayrım şu: Yönlendirme ihlalleri daha seyrek yapar, deterministik kontroller ise onları neredeyse imkânsız kılar — ve en büyük agent satıcısı fiilen işletmelere zorunlu politikaların makine tarafından zorlanan bir desteğe ihtiyacı olduğunu söylediğinde, bu tartışma sonuçlanmış olur.

Boşluk: Mimari yollara indirgenemez

Rehberdeki hook örnekleri yol kapsamlı — üretilmiş kod dizinini korumak, formatter'ları çalıştırmak, kimlik bilgilerini diff'lerin dışında tutmak — ve kural ile tetikleyicinin örtüşmesi sayesinde işe yararlar. Mimari kararlar böyle değil. Bir servisin eşzamanlılık nedenleriyle SQLite yerine PostgreSQL çalıştırması, bağımlılıkların içeri işaret etmesi, token'ların yalnızca tek bir auth sınırından verilmesi veya bir kullanımdan kaldırmanın checkout için geçerli olması ama henüz billing için geçerli olmaması gibi kısıtların her biri aynı anda kararın, kapsamının ve önerilen eyleme bağlıdır. Bir kural bir alt sistemde mutlak olarak bağlayıcı olabilirken diğerinde ilgisiz olabilir ve daha yeni bir karar, kod tabanının bir bölümü için daha eski bir kararı geçersiz kılabilir. Bu bir değerlendirme meselesidir, string eşleştirmesi değil.

Dördüncü kontrol olarak ADR'ler

Çoğu ekip bu kararları zaten architecture decision record olarak kaydediyor ve bunlar rehberin artifact zincirine doğal biçimde oturuyor. Öneri, ADR külliyatını yapılandırılmış, kapsamlı ve öncelik farkında kısıtlara derlemek ve bunları önerilen her değişikliğe karşı deterministik olarak çözmek; kararı ise harness'in sunduğu hangi hook varsa onu sürmek.

İki tasarım kısıtı önemli. Birincisi, retrieval faydalı bir bağlamdır ama benzerlik araması hakem olmamalı — bir ADR diğerini geçersiz kıldığında her zaman öncelik kazanmalıdır, embedding sıralaması değil. İkincisi, kontrol eylemden önce çalıştığı için her karar, hangi kararın değerlendirildiğine ve neden geçtiğine ya da engellendiğine dair kanıt üretir; böylece sapma önleme bir umuttan çok mekanizmaya dönüşür. Yazar ayrıca politika katmanının tek bir oturumun ötesinde kalıcılığa, tek bir agent harness'ten bağımsızlığa ve süre sonu olan istisnalar ile sorgulanabilir karar geçmişi gibi gerçek yönetişim anlamlarına ihtiyacı olduğunu savunuyor.

Neden önemli

Rehberin kendisi de paralel oturumları tartışırken, hiçbir mühendisin her eşzamanlı agent akışını kişisel olarak denetleyemeyeceği için kontrollerin giderek paylaşılan repository konfigürasyonunda yaşamak zorunda olduğunu belirtiyor. Hooks bu işlevsel koruma rail'lerine zaten ev sahipliği yapıyor; mimari politika ise eksik kalan kısımdır. Yan yana dizildiğinde ortaya çıkan kontrol yüzeyi şöyle okunuyor: niyet neyin inşa edildiğini, testler çalışıp çalışmadığını, güvenlik güvenli olup olmadığını, mimari ise uygulamanın hâlâ sistemin amaçlanan biçimiyle eşleşip eşleşmediğini yönetir.

Önerilen adım çatışmacı değil ekleyici — artifact döngüsünü koruyun, skills ve hooks'u koruyun, üstüne derlenmiş ADR kısıtlarını ekleyin. Tartmaya değer bir uyarı: Yazar tam olarak bu boşluğa yönelik Mneme adlı bir ürün geliştiriyor, dolayısıyla eleştiri aynı zamanda bir tanıtım. Danışma niteliğindeki ile deterministik zorunluluk arasındaki argüman her durumda geçerli ve agent ağırlıklı iş akışları benimseyen ekipler aynı sorunu yakında yanıtlamak zorunda kalacaklar.