Engineering ekipleri kodlama ajanlarını değerlendirirken genellikle yanlış soruyla işe başlar. Ajanın ne kadar otonom olabileceğini bilmek isterler. İş akışının (pipeline) ne kadarını üstlenebilir? Kimseyi rahatsız etmeden spesifikasyonu yazabilir, depoyu (repository) düzenleyebilir ve canlıya (production) alabilir mi? Demolar bu takıntıyı körüklüyor. Tek bir istemin (prompt) bir dizi düzenleme ve dağıtımı tetiklediği şık bir iş akışı gördüğünüzde, içgüdünüz kendi organizasyonunuzda da aynı yeteneğin peşinden koşmak olur. Ancak ihtişam, berbat bir tasarım ilkesidir. Daha iyi sorular çok daha az heyecan vericidir: Bu şeye yetkiyi kim verdi, hangi sistemlere gerçekten dokunabilir ve kaçınılmaz olarak bir şeyi yanlış yaptığında ne olur?

Otonomi Tuzağı

Heyecan verici otonomi bir tuzaktır. Bizi; spesifikasyonlar üreten, depoları değiştiren ve görevin tamamlandığını sakince iddia ederek kodu dağıtan botları kutlamaya alıştırır. Bu mühendislik değildir. Bu, shell erişimi olan bir "güven düşüşü" (trust fall) oyunudur. İşin kendisi üretilmesi çok kolay bir hale gelir. Herhangi bir model saniyeler içinde kod, dokümantasyon veya mimari planlar çıkarabilir. Ancak yazılım geliştirmedeki asıl maliyet hiçbir zaman yazma hızı olmamıştır. Bu her zaman doğrulama, inceleme ve "evet, bu doğru ve gönderilmesi güvenli" deme kararının titizliği olmuştur. Üretilen iş ucuzdur. Onay ise pahalıdır. Onay sürecini temiz ve tutarlı bir şekilde nasıl yöneteceğini çözen şirketler, gerçekten güvenilir sistemler sunanlar olacaktır.

Öz-İnceleme Neden Başarısız Olur?

Riskler öngörülebilir kalıplar halinde ortaya çıkar. Bir model bir plan taslağı hazırlar ve ardından bu planın iyi olup olmadığını değerlendirir. Bir ajan kod tabanınızı düzenler ve değişikliklerinin neden güvenli olduğunu size açıklar. Bir araç bir komut yürütür ve izin istemek yerine affedilmek için yalvarır. Bunların her biri aynı temel başarısızlığı temsil eder. Eğer bir ajan bir spesifikasyon üretiyorsa, bu bir gerçek haline gelmeden önce o ajanın dışındaki bir şeyin bunu onaylaması gerekir. Eğer bir ajan kodu değiştiriyorsa, ayrı bir süreç farkı (diff) incelemelidir. Üreticinin kendi doğrulayıcısı olarak hareket etmesine izin vermek bir kestirme yol değildir. Bu, kolaylık kılıfına sokulmuş yapısal bir hatadır.

İstemler (Prompts) İzin Sistemleri Değildir

Bir ajanı zekice kelimelerle güvence altına alamazsınız. Bir modele dikkatli olmasını veya bir şeyi silmeden önce sormasını söylemek bir sınır oluşturmaz. İstemler izin sistemleri değildir. Bir ajanın üretim ortamına (production) yaklaşmasına izin vermeden önce, yeteneklerinin dürüst bir envanterine ihtiyacınız vardır. Tüm depoyu okuyabilir mi? Shell komutlarını yürütebilir mi? Bir tarayıcı açabilir mi? Müşteri verilerini bağlam penceresine (context window) çekebilir mi? Çoğu ekip bu soruların tam yanıtlarını bilmez. Aracın aslında kritik yollara yazma erişimi varken, bir sandbox (kum havuzu) ile sınırlı olduğunu varsayarlar. Önce yüzey alanını haritalandırın. Sonra duvarları inşa edin.

Kademeli Bir Kontrol Sistemi Kurun

Ajanın neler yapabileceğini anladıktan sonra, riski sürtünmeyle (friction) eşleştiren bir kontrol sistemi tasarlayın. Dahili dokümantasyonu güncellemek veya tutarlı kod formatlamak gibi düşük riskli eylemler otomatik olarak çalışabilir. Bir modülü yeniden yapılandırmak (refactoring) veya yeni bir bağımlılık eklemek gibi orta riskli eylemler, bir insanın veya doğrulanmış bir test paketinin (test suite) hareketi onayladığı bir kontrol noktasına çarpmalıdır. Üretim ortamına dağıtım yapmak, altyapıyı değiştirmek veya hassas verilere erişmek gibi yüksek riskli eylemler, üretim sürecine dahil olmamış ayrı bir onaylayıcıya ihtiyaç duyar. Her bir eylem bir denetim izi (audit trail) bırakmalıdır. Tam olarak hangi dosyaların okunduğunu, hangi araçların çağrıldığını ve hangi kararların verildiğini yeniden oynatabilmelisiniz. Ajan tabanlı geliştirme, incelemeleri atlamak için bir lisans değildir. Sıkıcı sürtünme bir özelliktir. Uygun bir onay kapısı, işler kontrolden çıkmaya başladığında bir devre kesici (circuit breaker) gibi işlev görür.

Sınırı Riskle Eşleştirin

Sınırlarınızı gerçek tehlikeye göre kalibre edin. Her Markdown biçimlendirme değişikliğini bir uyumluluk törenine dönüştürmek ekibinizi durma noktasına getirir. Ancak ajanın kendinden emin görünmesi nedeniyle yüksek riskli eylemleri zararsız olarak değerlendirmek de aynı derecede aptalcadır. Hedef tiyatral kısıtlama değil, orantılı kontroldür.

Çıktıları (Artifacts) Küçük ve Gözlemlenebilir Tutun

The most useful agent systems do not try to wow you with massive autonomous runs. They produce small, reviewable artifacts. A tight plan. A focused diff. A readable log. Giant autonomous executions are nightmares to debug. When something breaks after a fifty-file agent session, you have to untangle intent, execution, and side effects all at once. Keep the blast radius small. Insist on knowing which files the agent read and which tools it called. Observable systems are maintainable systems. Black-box autonomy is just technical debt with better marketing.

Six Questions Before You Grant Access

Before you hand an agent any real responsibility, pressure-test your setup with six hard questions.

  • What capabilities does the system actually have?
  • Which actions are denied by default, blocked at the infrastructure level rather than discouraged by a polite sentence in the system prompt?
  • Which actions require explicit approval?
  • Which artifacts get frozen before the agent consumes them, so it cannot silently manipulate its own inputs?
  • Which validator, entirely separate from the generator, judges the final output?
  • Which log proves, without ambiguity, what actually happened?

This is basic engineering hygiene. Separate the generator from the validator. Keep human authority at the boundary.

The Real Test

There