Bir kodlama ajanının kalitesi çoğu zaman model daha az yetenekli hâle geldiği için değil, projenin ajanın ne okuyacağını, ne yapacağını ve değişikliklerinin nasıl inceleneceğini düzenleyen açık bir çalışma sisteminden yoksun olması nedeniyle düşer. Çalışma haftalar ve binlerce değişiklik boyunca uzadığında, bu adımlar ajana zorunlu kılınmazsa ajan aynı dosyaları yeniden keşfedebilir, önceki bir kararla çelişebilir, test komutunu tahmin edebilir veya test yazmayı bırakabilir.
«LLM Sistemlerini Üretimde Çalıştırma» serisinin altıncı bölümünde Stack Overflow Blog, modelin etrafında kısa bir proje anayasası, özerklik sınırları, çok seviyeli bağlam, kalıcı bellek, bir inceleme kurulu ve her değişiklikten sonra çalışan bir kancadan oluşan bir düzenleme katmanı oluşturmayı öneriyor. Aynı depoda birden fazla ajan çalıştırıldığında dosya sahipliği haritası ile istem ve ortak karar kayıtları da ekleniyor.
Sorun yalnızca modelde değil, çalışma kemerinde
Makale, ajanı; talimatlar, araçlar, bağlam politikaları, kancalar, izolasyon, alt ajanlar ve izleme mekanizmalarıyla birlikte model olarak tanımlıyor. Terminal-Bench 2.0 kıstasından elde edilen genel bir sonuca atıfta bulunuyor: LangChain, yalnızca çalışma kemerini değiştirerek bir ajanı ilk 30'un dışından ilk 5'e taşıdı; model aynı kalırken puan %52,8'den %66,5'e yükseldi. Bu, 13,7 puanlık bir artış anlamına geliyor.
Pratik çıkarım, eksik araçların, belirsiz kuralların veya aşırı yoğun bir bağlamın giderilmesi en mümkün başarısızlık nedenleri arasında olabileceğidir. Modelin aksine geliştirme ekibi bu katmanı değiştirebilir ve kendi deposuna uyarlayabilir.
Disiplinli tek bir ajan için altı unsur
- Proje anayasası: CLAUDE.md veya AGENTS.md gibi bir dosya; planlama, belgeleme, uygulama, test, inceleme ve ardından commit oluşturma döngüsünü tanımlar. Kalite ölçütlerini ve tedarikçi paketlerinin kullanım sınırlarını da içermelidir; her oturumda okunduğu için kısa tutulmalıdır.
- Özerklik sınırları: Ajana okuma, düzenleme, test etme ve commit oluşturma gibi geri alınabilir işlemler için izin verilirken push, dağıtım ve altyapı değişikliklerini uygulama işlemleri onay gerektirir. npm:* gibi geniş kuralların yanlışlıkla dağıtıma izin vermemesi için komut eşleştirmesinin anlamları doğrulanmalıdır.
- Çok seviyeli bağlam: Kök CONTEXT.md dosyası projenin haritasını, çalıştırılma ve test edilme yöntemini içerirken her modülün dosyası o modülün sorumluluğunu, dosyalarını ve bağımlılıklarını açıklar. DECISIONS.md kararları, gerekçelerini ve reddedilen alternatifleri kaydeder. Eski bağlam, değişikliğin kendisinde düzeltilmesi gereken bir hata olarak değerlendirilir.
- Kalıcı bellek: Materyal, her gerçek için ayrı bellek dosyaları, kısa bir dizin ve modüllerle kararları «bağlıdır» veya «yerine geçer» gibi ilişkilerle birbirine bağlayan graph.jsonl adlı bir dosya öneriyor.
- Çoklu merceklerle inceleme kurulu: Alt ajanlar değişikliği ürün, mühendislik, altyapı, güvenlik ve test açılarından inceler. Yalnızca yüksek güven düzeyine sahip bir engel veya ciddi sorun değişikliği durdurur.
- Düzenleme sonrası kanca: PostToolUse, her Edit, Write veya MultiEdit işleminden sonra çalışır ve bağlamın, belleğin ve karar günlüğünün aynı değişiklik içinde güncellenmesini hatırlatan bir liste çıkarır; dosyaları sessizce yeniden yazmaz.
Bir ajan filosu çalıştırıldığında
Aynı depoda birden fazla ajan çalıştığında yeni bir sorun ortaya çıkar: Ajanlar aynı dosyaları değiştirebilir veya birbirlerinin kararlarını geri alabilir. Makale, ajanlar arasındaki doğrudan konuşmalara güvenmeyi önermiyor; bunun yerine yollar için sahiplik haritası, CLAIM ve RELEASE kayıtları, ilerleme günlüğü ve her görev için insan tarafından birleştirilen bağımsız bir dalı içeren, yazılı ve denetlenebilir ortak bir durumu öneriyor.
Bu talepler gerçek bir kilit değildir; iki ajan aynı durumu okuyup aynı yolu aynı anda talep edebilir. Gerçek izolasyon gerektiğinde makale, benzersiz adlandırılmış bir Git dalı veya bir koordinasyon deposunda koşullu yazma gibi atomik bir mekanizma öneriyor.
Bu yaklaşım neden önemli?
Buradaki gerçek değişim, odağı ajanın bir fonksiyon yazabilme yeteneğinden, onu zaman içinde yönlendirilmiş ve incelenebilir tutan çevre sisteminin kapasitesine kaydırmaktır. Karar günlüğü yalnızca belgesel değil, sözleşmesel bir rol de üstlenir: Eski kararlar değiştirilmez; bunların yerine geçen yeni kararlar, gerekçe ve reddedilen alternatiflerle birlikte eklenir. Böylece tasarım geçmişi görünür kalır ve belirli içe aktarmaları engellemek gibi otomatik kontrollerle ilişkilendirilebilir.
Bu yaklaşım, çıktıların doğruluğuna ilişkin bir güvence değil, düzenleyici bir rehber olarak kalır. Makale ayrıca dosya tabanlı taleplerin eşzamanlı çakışmalar söz konusu olduğunda tavsiye niteliğinde olduğunu ve birleştirme, push ve dağıtım aşamalarında insan incelemesinin kontrol noktası olmaya devam ettiğini kabul ediyor. Materyalin özeti şu: Modeli sınırlamak ve denetlenebilir izler oluşturmak, daha zeki bir model beklemekten daha uzun süreli çalışmanın güvenilirliği üzerinde etkili olabilir.