AI Ajanları Kod Yazarken PR Tufanı: Sürekli Doğrulama ve Güvenli Sandbox Mimarisi Nasıl Kurulur?

Pazartesi 09.10. Beş kişilik ekipte üç kod ajanı aynı anda çalışıyor. Biri ödeme modülünü refactor ediyor, biri ORM katmanını değiştiriyor, diğeri cache ekliyor. İlk ajan üç dakikada 812 satırlık PR açıyor. İnsan inceleyici diff’i, migration’ı, test varsayımlarını ve çağrı zincirini anlamak için 47 dakika harcıyor. Öğlene kadar kuyrukta 11 PR var; gün sonunda 20 PR üretilmiş ama yalnız dördü gerçekten incelenebilmiş. Kod üretimi hızlandı, teslimat hızlanmadı.

Bu PR tufanında asimetri yapısaldır. Ajan değişikliği üretirken bütün dosyaları paralel tarayabilir ve boilerplate’i sıfıra yakın marjinal maliyetle yazabilir. İnsan ise güven oluşturmak için kodu sırayla okur, eski davranışı hatırlar, yan etkileri zihninde simüle eder ve belirsizlikte bağlam arar. İnceleme kapasitesi sabitken üretim oranını artırmak queue depth ve bekleme yaşını büyütür.

1. LGTM sendromu ve gizli çürüme

Reviewer uzun diff’ler arasında yoruldukça inceleme satır satır kanıt aramaktan örneklemeye dönüşür. İsimler düzgün, testler yeşil ve yapı tanıdık görünüyorsa LGTM gelir. Böylece hiç var olmayan dependency, yanlış package adı, unutulmuş transaction boundary, gereksiz abstraction veya mevcut helper’ın ikinci kopyası sisteme girer. Her PR lokal olarak makul, sistem toplamda daha zor anlaşılır olur.

Doğrulama maliyetine logaritmik demek doğru değildir. Salt satır sayısı için en iyi durumda yaklaşık doğrusal okuma gerekir. Mimari fan-out, dokunulan modül sayısı, eşzamanlı PR çakışması ve migration riski eklendiğinde maliyet süper-doğrusal davranabilir. Değişiklik yüzeyi iki katına çıkarken olası etkileşim kenarları ikiden fazla artar.

5 engineers x 20 agent PR/day = 100 PR arrivals/day
careful review capacity: 5 x 8h / 45min = 53 reviews/day (theoretical)
utilization rho = 100 / 53 = 1.89

rho > 1: queue is unstable even before meetings, incidents and rework.
The solution is not faster clicking; reduce arrivals and automate evidence.

2. Klasik CI neden yeşil yanıp yanlış olabilir?

Ajan kodu ve testini aynı varsayımla yazdığında circular validation oluşur. Örneğin indirim fonksiyonu vergi öncesi çalışmalı sanılır; implementasyon ve unit test aynı yanlış sırayı kullanır. Test yeşildir çünkü bağımsız bir oracle yoktur. Coverage yalnız hangi satırın çalıştığını gösterir; doğru iş kuralının sınandığını göstermez.

Linter, type checker ve SAST değerlidir fakat gözlem alanları sınırlıdır. Transaction test mock repository ile geçerken production’da commit iki yan etki arasına girebilir. Async context bir request’ten diğerine sızabilir. Retry iki fatura yaratabilir. Cache key tenant içermeyebilir. Bellek sızıntısı 30 saniyelik testte görünmez. Bu hatalar orkestrasyon, zaman ve gerçek bağımlılık davranışıdır.

3. Continuous Verification: PR bir diff değil kanıt paketi olmalı

Sürekli doğrulama, her PR’a daha çok araç eklemek değildir. Değişikliğin risk sınıfına göre bağımsız kanıt üretir. Üreten ajan diff’i önerir; policy engine değişiklik yüzeyini çıkarır; sandbox farklı doğrulayıcıları çalıştırır; sonuçlar imzalı evidence manifest’e yazılır. Merge kararı yalnız yeşil/kırmızı değil, hangi iddianın hangi kanıtla desteklendiğidir.

{
  "change_id":"sha256:...",
  "risk":{"db_migration":true,"auth":false,"public_api":true},
  "evidence":[
    {"kind":"typecheck","tool_version":"...","result":"pass"},
    {"kind":"property","cases":1000,"result":"pass"},
    {"kind":"mutation","score":0.87,"survivors":4},
    {"kind":"schema_diff","result":"backward-compatible"}
  ],
  "sandbox":{"image_digest":"sha256:...","network_policy":"registry-only"}
}

4. Property-based testing: örnek değil değişmez kural

Hypothesis ve QuickCheck yaklaşımında birkaç elle seçilmiş örnek yerine bir girdi uzayı ve her durumda korunması gereken property tanımlanır. Framework sınır değerleri ve beklenmedik birleşimleri üretir; hata bulduğunda girdiyi küçülterek minimal counterexample verir. Ajanın kendi happy-path varsayımı böylece bağımsız bir invariant’a çarpar.

@given(st.lists(transfers(), min_size=1, max_size=50))
def test_money_is_conserved(transfers):
    ledger = apply_all(initial_ledger(), transfers)
    assert sum(ledger.balances.values()) == INITIAL_TOTAL
    assert all(balance >= 0 for balance in ledger.balances.values())

class PaymentMachine(RuleBasedStateMachine):
    @invariant()
    def no_duplicate_capture(self):
        assert unique(self.gateway.capture_ids)

    @invariant()
    def outbox_matches_commits(self):
        assert self.db.committed_payments == self.db.outbox_payment_events

Property test de sihirli değildir; yanlış invariant bütün implementasyonları yanlış yönlendirebilir. Değişmezler domain sahibi ve mühendis tarafından gözden geçirilir, test jeneratörünün gerçek veri dağılımını kapsaması ölçülür. Stateful test özellikle create-retry-cancel-refund gibi sıra bağımlı protokollerde değerlidir.

5. Mutation testing: test suite gerçekten hata görüyor mu?

Mutation runner koşul tersine çevirir, sınırı değiştirir veya satırı kaldırır. Testler hâlâ geçerse mutant yaşamıştır; suite ilgili davranışı ayırt edemiyordur. Mutation score öldürülen mutantların geçerli mutantlara oranıdır. Yüzde 100 coverage ve yüzde 42 mutation score, çok kod çalıştıran ama az davranış doğrulayan bir suite’in güçlü sinyalidir.

Threshold tek başına oyunlaştırılabilir. Equivalent mutant’lar ve önemsiz getter’lar skoru bozar; büyük repoda tam mutasyon pahalıdır. Diff bazlı mutation, kritik modüllerde daha yüksek eşik ve surviving mutant listesi kullanırız. Ajan kendi testlerini yazabilir, fakat mutant üretimi ve kabul policy’si bağımsız pipeline’a aittir.

6. Bağımsız denetçi ajan: aynı modele ikinci kez sormak yetmez

Auditor agent üretici ajanın açıklamasını kabul ederek başlamaz. Diff, contract, eski davranış ve threat model verilir; görev race, yetki, maliyet, migration ve rollback counterexample’ı üretmektir. Mümkünse farklı model ailesi ve ayrı prompt kullanılır. Yine de auditor kararı merge yetkisi değildir; bulgusu deterministic test, static query veya insan kararıyla kanıta çevrilir.

7. Sandbox: ajan kodunu körlemesine çalıştırmamak

Untrusted PR doğrudan geliştirici laptopunda veya uzun ömürlü staging’de çalışmaz. Her doğrulama immutable image’dan disposable sandbox açar; repo salt okunur base ve yazılabilir geçici layer ile bağlanır; CPU, RAM, PID, disk ve süre cgroups ile sınırlandırılır. İş bitince disk ve bellek yok edilir. Firecracker KVM tabanlı microVM sınırı, gVisor ise userspace application-kernel yaklaşımı sunar; seçim tehdit modeli ve performansa bağlıdır.

Firecracker belgeleri uygun host ve hazır image ile 125 ms altı boot ve düşük ek bellek hedefi bildirir; bunu her CI ortamında garantili 100 ms diye yazamayız. gVisor güçlü syscall izolasyonu sağlar fakat kendi dokümantasyonunda sandbox’ın güvenli mimarinin yerine geçmediğini belirtir. Her iki durumda egress, secret, artifact ve resource policy ayrıca gerekir.

sandbox:
  rootfs: read_only
  writable: ["/workspace", "/tmp"]
  env_allowlist: ["CI", "TEST_DATABASE_URL"]
  secrets: none
  network:
    default: deny
    allow:
      - registry.internal.example:443
      - test-db.internal.example:5432
  limits:
    cpu: 4
    memory: 6Gi
    pids: 512
    wall_time: 15m

8. Zero-trust dependency ve secret politikası

npm install veya pip install keyfi internete çıkarsa PR’daki tek karakterlik package adı typosquatting paketini çalıştırabilir. CI yalnız şirket registry proxy’sine erişir; lockfile zorunlu, registry namespace sabit, checksum/signature doğrulaması açık ve yeni dependency ayrı approval gerektirir. Install script’leri varsayılan kapalı veya ayrı daha sıkı sandbox’ta çalışır.

Ajanın gerçek .env, SSH agent socket, cloud metadata veya host home dizinine ihtiyacı yoktur. Test secret’ları kısa ömürlü, scope’u dar ve yalnız ilgili job’a enjekte edilir. Log redaction savunmanın son katmanıdır; secret’ın sandbox’a hiç girmemesi daha güçlü kontroldür.

9. Ajan PR’ı için CI sözleşmesi

1. AST/static analysis ve strict type check geçmeli.
2. Değişen kritik kod için property/stateful test kanıtı olmalı.
3. Diff mutation score risk sınıfı threshold’unu aşmalı; survivor’lar açıklanmalı.
4. Public API, event schema ve DB migration backward compatibility kontrol edilmeli.
5. Sandbox egress/secret policy ihlali olmamalı.
6. Inference, sandbox CPU zamanı ve artifact maliyeti PR bütçesi içinde kalmalı.
7. Riskli auth, ödeme, destructive migration ve yeni dependency insan onayı gerektirmeli.

10. PR boyutu ve geliş hızına admission control

Doğrulama kapasitesi aşılmışsa yeni agent PR tetiklemek üretkenlik değildir. Repo başına açık agent PR, günlük changed-line, risk puanı ve reviewer WIP limiti tanımlarız. 800 satırlık karışık değişiklik; mekanik rename, davranış değişikliği ve migration olarak ayrı kanıtlanabilir PR’lara bölünür. Küçük PR amaç değil, tek bir falsifiable iddia taşıyan değişiklik birimidir.

Metrikler merge sayısını değil doğrulama sağlığını izler: PR age p95, evidence üretim süresi, mutation survivor, rollback oranı, review rework, escaped defect ve reviewer odak süresi. Ajanın yazdığı satır sayısını KPI yapmak sisteme gereksiz abstraction üretmeyi öğretir.

11. İnsan rolü: kabul kriteri mimarı

Mühendis syntax okuyucusu olmaktan çıkmaz; fakat kıt dikkatini her satıra eşit harcamaz. Domain invariant, threat boundary, migration sözleşmesi, risk sınıfı ve bağımsız oracle tanımlar. Otomasyon geniş girdi uzayını tarar; insan belirsiz kararları, yeni abstraction’ı ve geri döndürülemez etkileri inceler.

İyi continuous verification insanı pipeline’dan çıkarmaz; insan kararını daha yüksek kaldıraçlı yere taşır. PR, neden doğru olduğuna dair makinece tekrar üretilebilir kanıt sunar. Reviewer ‘testler yeşil’ yerine ‘hangi failure modeline karşı hangi invariant kanıtlandı?’ sorusunu sorar.

Sonuç: kod üretimi ucuzladıkça kanıt bütçesi tasarlanmalı

Ajan hızını teslimat hızı sanmak PR tufanını üretir. Klasik CI gerekli ama circular testleri, zaman bağımlı yan etkileri ve supply-chain riskini tek başına çözmez. Property test, mutation, adversarial denetim, schema compatibility ve disposable sandbox ortak evidence sözleşmesinde birleşmelidir.

Önceki multi-agent hata izolasyonu rehberi, PoC’den production mimarisi ve AI otomasyon güvenilirliği bu doğrulama katmanının çalışma zamanı tarafını tamamlar.