AI ajanları için sandbox ve yeni Git: kononov.dev'i yerel kontrollerle nasıl yayınlıyorum

Ekim ayının bir haftasında aynı konuda birkaç haber çıktı: AI ajanları kodu, altyapının onu kontrol edip güvenle yayınlamaya yetişebileceğinden daha hızlı yazıyor. Anthropic Git'in yerine kendi sistemini koydu, GitLab Git'in sunucu tarafını ajanlara göre yeniden yazıyor, Docker ve Pulumi ajanın canlı veritabanına uzanamayacağı sandbox'lar gösteriyor. İşletme sahibi için bunun önemi basit bir nedene dayanıyor: geliştiriciniz ya da yükleniciniz zaten bir ajan kullanıyorsa, “ajan nereye uzanabilir” sorusu doğrudan sizin verilerinizle ilgili.

Ne çıktı, kimden

Simon Willison 13 Ekim'de Anthropic'in kendi sürüm kontrol sistemi Scion hakkındaki yazısını inceledi. Mayıs 2026'da şirketin monorepo'suna günde yaklaşık 2.500 değişiklik giriyordu, eylülde 30.000'den fazla. Ana dalın geçmişi neredeyse 100 GB, yalnızca CI için günde 25 milyon civarında checkout. Sistemi yedi kişilik bir ekip yaptı, Git'ten taşınma beş ay sürdü.

GitLab 13 Ekim'de kendi next-gen SCM'siyle yanıt verdi: Git protokolü kalıyor, altında ortak nesne deposu olan yeni bir mimari var. Onların verilerine göre sıradan Git'te tek bir ajan çağrısı, tek bir soru uğruna 5-10 GB trafik ve 30 saniyeden uzun hazırlık demek olabiliyor. Erken iç testlerde 50 kata kadar hız ve 1.000 kata kadar az trafik elde etmişler; çekince şu: bunlar belirli koşullardaki tepe değerler. Ürün kapalı betada.

İki gün sonra, 15 Ekim'de GitLab otomatik inceleme Code Review Flow'u anlattı: kendi runner'larınızda CI işi olarak çalışıyor, inceleme başına 0,25 dolar ve tek seferde bir proje, bir grup ya da instance'ın tamamı için açılıyor. Planda ajana değişikliği onaylama ya da düzeltme isteme hakkı vermek var.

Docker 16 Ekim'de Stack Overflow'un 2026 anketini aktardı: 169 ülkeden 30.000'den fazla katılımcı. Geliştiricilerin yalnızca %7'si önemli iş kararlarında AI sonucuna güveniyor, %48'i yalnızca kendisi kontrol edebiliyorsa güveniyor. Bu zeminde Docker, Cloud Sandboxes'ı ve CNCF'ye devretme sözü verdiği Sandbox Kit spesifikasyonunu duyurdu.

Pulumi 21 Ekim'de bir atölye kaydı yayınladı; en yararlı hikâye orada. Nisanda PocketOS şirketinin ajanı staging'deki rutin bir görevde canlı veri diskini 9 saniyede sildi: API token'ını alakasız bir dosyadan aldı ve silmenin staging ile sınırlı olduğunu varsaydı. Verileri hosting sağlayıcısı iki gün sonra geri getirdi. Şirketin kurucusu, sistem promptunun ajana yalnızca tavsiye verdiğini yazdı. Bu yüzden atölyede Pulumi Neo ajanı Docker Sandbox mikro sanal makinesinde çalıştı, yalnızca izin verilen dosya ve host'ları gördü, gerçek token'ı ise çıkışta bir proxy ekledi.

Vercel 19 Ekim'de durable harness'i gösterdi: ajanın her adımının günlüğü tutuluyor ki kesintiden sonra görev koptuğu yerden devam etsin. Benim için orada tek bir ayrıntı önemli: ajanın her aracı, kesintiden sonra tekrar edilip edilemeyeceğiyle işaretli. Dosya okumak tekrar edilebilir, müşteriye para iadesi edilemez.

Tek sunuculu bir şirket için bu ne anlama geliyor

Bir hizmet şirketi düşünelim: yüklenici siteyi ve CRM entegrasyonunu düzenliyor. Ajanı repoya bağlamış, repoda ise CRM token'ı ve veritabanı erişimi olan bir dosya duruyor. Ajan “test başvurularını temizle” görevini alıyor, token'ı buluyor ve uzanabildiği her yerde başvuruları temizliyor. PocketOS'un ajanı gibi, yalnızca daha küçük ölçekte.

Haberlerden çıkan sonuç basit. Sınır, ajanın tartışamayacağı yerde durmalı: token'ın yetkilerinde ve yayın düzeninde. PocketOS'un ajanı prompttaki talimatı okudu ve diski yine de sildi.

Bende nasıl kurulu

kononov.dev sitesi Next.js, Node.js 24 ve SQLite ile Docker'da çalışıyor: Nginx arkasında, 2 GB bellekli ortak bir sunucuda, “Birlikte Kahve” adlı iç servisin yanında. AI geliştirme hızımı birkaç kat artırdı, ama mimariyi ve kilit kararları kendim belirliyorum, araçların sonucunu da kontrol ediyorum. Kod için bu şöyle işliyor: değişiklik önce Docker'daki yerel kontrol hattından, testlerden ve derlemeden geçiyor, ancak ondan sonra sunucuya gidiyor. Sunucuda eski kopya yenisi başlamadan önce durduruluyor; derlemeye bellek yetmezse imaj sunucu dışında derlenip hazır olarak yükleniyor.

2021'den beri teknik ortağı olduğum ABD'deki PDR şirketinde güvenlik soruları bana geliyor: sistemin birkaç koruma katmanı ve yedeği var; 2022'de Google Cloud'da Debian üzerinde kendi sunucumuz kurulduğundan beri kurtarma gerektiren ciddi bir arıza olmadı. Ajanlar için sandbox'ları denerdim: görev PocketOS'unkiyle aynı, bende şu anda yetkilerle ve yayın düzeniyle çözülüyor.

Ben ne yapardım

Ajanın ne gördüğünü kontrol etmek. Token ve parolaları repodan ve çalışma makinesinin ortam değişkenlerinden çıkarmak, ajana yalnızca kod ve test veritabanı erişimi bırakmak.

Ajanı canlı sunucuya ağ erişimi olmayan ayrı bir konteynerde ya da sandbox'ta çalıştırmak. Haberdeki Docker Sandboxes seçeneklerden biri, ağı kısıtlanmış sıradan bir konteyner de uyar.

Ajanın değişikliklerini insanın değişiklikleriyle aynı kontrol hattından geçirmek: testler ve derleme.

Geri alınamaz işlemleri insana bırakmak: sunucuya yayın ve veri silme. Bu, durable harness'teki “tekrar edilemez” işaretinin ta kendisi, yalnızca süreç düzeyinde.

Kurtarması denenmiş yedekler tutmak. PocketOS'u, hosting sağlayıcısının verileri iki gün sonra geri getirebilmesi kurtardı. Ben kurtarmayı kendi elimde tutmayı tercih ediyorum.

İlgili içerikler

Uzun süren görevleri istek dışında nasıl çalıştırıp tekrarları nasıl kontrol ettiğimi Worker'lar: arka plan görevleri ve yeniden denemeler yazısında anlattım. Alan: yayınlanabilen ve kurtarılabilen altyapı, canlı örnek PDR şirketiyle teknik ortaklık vakasında. Diğer incelemelerden: canlı sunucuda AI ajanına neye izin veriyorum ve işi ajanla nasıl paylaşıyorum. Daha önce sürüm kontrolü için API mock'larını ve ayrı veritabanlarını ve canlı verilere erişimi olmayan preview ortamlarını ele almıştım. Yükleniciniz zaten bir ajanla çalışıyorsa ve onun nereye uzanabileceğini bilmiyorsanız, yayın sürecinizin şu anda nasıl işlediğini anlatın. Görevi konuşalım.