Remi d'Almeida6 dk okumaBilgisayarımı bir yapay zekâ ajanına emanet etmeden YOLO modu
Aitopus'u geliştirirken her kodlama ajanı oturumunu neden Docker Sandbox içinde çalıştırdığımı ve yeniden kullanılabilir bir proje kiti sayesinde karmaşık bir native geliştirme ortamı kurmayı nasıl rutin hâle getirdiğimi anlatıyorum.
Bu sayfada
En yetenekli kodlama ajanları bile birkaç saniyede bir durup komut çalıştırmak için izin istediğinde son derece can sıkıcı olabiliyor.
Bu paketi yükleyebilir miyim? Evet. Testleri çalıştırabilir miyim? Evet. Bir derleme betiği başka bir derleme betiğini çağırabilir mi? Evet.
Bir noktadan sonra cazip seçenek belli: “YOLO modunu” açıp ajanın işini kesintisiz yapmasına izin vermek.
Ne var ki bunu kendi bilgisayarımda yaptığımda, aslında birbirinden ayrı iki kararı tek bir kararmış gibi ele alıyorum:
- Ajanın beni beklemeden çalışmasını istiyorum.
- Kullanıcı hesabımın erişebildiği her şeyi ona da açmaya hazırım.
İlkine katılıyorum, ikincisine değil.
Aitopus'u geliştirirken tek bir soruyu sürekli göz önünde bulunduruyorum: Bir yapay zekâ süreci nerede çalışıyor ve nelere erişmesine izin veriliyor? Aynı soruyu geliştirme ortamım için de soruyorum.
Bu nedenle proje için çalıştırdığım her kodlama ajanı oturumunu bir Docker Sandbox içinde başlatıyorum. Aitopus'un kapsamlı bir Rust kod tabanı ve zorlu bir native derleme ortamı var. Ajanın bağımlılıkları yükleyebilmesi, kodu derleyebilmesi, testleri çalıştırabilmesi ve betikleri yürütebilmesi gerekiyor. Üstelik tüm bunları bilgisayarıma sınırsız erişim kazanmadan yapabilmeli.
Bu iş akışı dört sınır üzerine kurulu: ajanı bir microVM içinde yalıtmak, deponun nasıl paylaşılacağını seçmek, ağ erişimini kısıtlamak ve ortaya çıkan işi güvenilmeyen kod olarak incelemek.
Neden yalnızca bir konteyner kullanmıyorum?
Sıradan bir geliştirme konteyneri bağımlılıkları paketlemek için kullanışlıdır; ancak kendiliğinden güçlü bir güvenlik sınırı oluşturmaz.
Yaygın kestirme yol, konteyner içindeki bir aracın başka konteynerler oluşturup çalıştırabilmesi için ana makinenin Docker socket'ini konteynere bağlamaktır. Böyle yapıldığında araç ana makinedeki Docker daemon'ını fiilen denetleyebilir. Özerk bir ajan söz konusu olduğunda bu yaklaşım hedeflenen yalıtımın büyük bölümünü boşa çıkarır.
Docker Sandboxes farklı bir yaklaşım benimser. Her sandbox kendi Linux ortamına, dosya sistemine, ağına ve Docker Engine'ine sahip bir microVM içinde çalışır.
Bu ortamda ajan şunları yapabilir:
sudoile paket yükleyebilir- Docker imajları oluşturabilir
- konteyner başlatabilir
- Docker Compose çalıştırabilir
- geliştirme ortamını değiştirebilir
Tüm bunları ana makinedeki Docker daemon'ına veya bilerek paylaştığım çalışma alanının dışındaki dosyalara erişmeden yapabilir.
Asıl güvence ajanın hiç zarar verememesi değil; olası zararın etki alanının daha dar ve daha kolay anlaşılır olmasıdır.
Doğrudan mod ve klon modu
Docker Sandboxes bir projeyi paylaşmak için iki kullanışlı yöntem sunar.
Doğrudan mod
Proje okuma ve yazmaya açık biçimde bağlanır. Ajanın yaptığı değişiklikler yerel çalışma kopyamda anında görünür. Ajanla aynı dosyalar üzerinde çalışabildiğimiz için olağan geliştirme işlerinde bu modu kullanıyorum.
Dezavantajı açık: depo ajanın verebileceği zararın etki alanında kalır.
Klon modu
Tanımadığım ajanlarla çalışırken, yıkıcı olabilecek denemelerde veya paralel işlerde klon modu daha güçlü bir sınır sağlar. Ana makinedeki depo salt okunur olarak bağlanır; ajan ise sandbox içinde kendine ait bir klon üzerinde çalışır. Ben açıkça geri aktarmadıkça değişiklikler yerel çalışma kopyama yansımaz.
Klon modu deponun değiştirilmesini engeller, incelenmesini değil. Depo salt okunur olarak bağlansa bile içindeki dosyalar görülebilir; buna Git tarafından yok sayılan dosyalar da dâhildir. Bu nedenle gizli bilgiler çalışma alanının dışında tutulmalıdır.
Yeniden kullanılabilir proje kiti
Boş bir sandbox yalıtım sorununu çözer, kurulum sorununu değil.
Her yeni oturumun başında projenin ihtiyaç duyduğu native kütüphaneleri, derleme için gereken araç zinciri sürümlerini veya yerel model ortamının nasıl yapılandırılacağını uzun uzun açıklamak istemedim.
Docker Sandboxes kit adı verilen yeniden kullanılabilir proje yapılandırmalarını destekler. Proje kitimde ajanın ihtiyaç duyduğu araçlar ve ortam ayarları yer alır:
- native derleme bağımlılıkları
- Rust araçları
- tarayıcı testi bağımlılıkları
- ortam değişkenleri
- kurulum sırasında gereken ağ erişimi
Yapılandırmanın ayrıntılarından çok şu ilke önemlidir: kurulum bilgisini her seferinde akıldan yeniden toparlamak yerine projeyle birlikte saklamak.
Bir yapay zekâ ajanı depoyu inceleyerek projeye özel bir spec.yaml taslağı hazırlayabilir. Depodan çıkaramadığı bilgileri de sorularla netleştirebilir: sistem paketleri, derleme ve test komutları, arka plan servisleri, ağ erişimi, portlar ve ana makinenin yönettiği kimlik bilgileri.
Örneğin bir web uygulamasının kiti sandbox içinde Playwright ile headless bir tarayıcıyı da kapsayabilir. Böylece ajan sayfaları render edebilir, uçtan uca testler çalıştırabilir ve görsel inceleme için ekran görüntüleri alabilir. Seçilen ajan ve model görsel girdisini destekliyorsa bu ekran görüntülerini kendisi de inceleyebilir.
Oluşturulan dosyanın yine de gözden geçirilmesi ve sbx kit validate ile doğrulanması gerekir.
Kit aynı zamanda bir sorun giderme günlüğüdür
Kitin ilk sürümü çok daha küçüktü. Gerçekler ne zaman varsayımlarımla çelişse biraz daha büyüdü.
Bir sürümde PATH genişletilmek yerine tamamen değiştiriliyordu. Bu değişiklik sandbox çalışma zamanı tarafından eklenen yolları kaldırmış ve kodlama ajanının doğru biçimde başlamasını engellemişti.
Başka bir sürümde RUSTFLAGS genel düzeyde tanımlanmıştı. Bu ayar gerçek model sağlayıcılarına istek gönderen testleri hariç bırakmak için kullanılan projeye özel CI bayrağını istemeden geçersiz kıldı.
Bu sorunlar shell geçmişinde veya kişisel notlarımda kalabilirdi. Bunun yerine düzeltmeler artık doğrudan ilgili yapılandırmada yer alıyor; neden gerekli oldukları da böylece görülebiliyor.
Kitin asıl değeri burada. Yalnızca yazılım kurmakla kalmıyor; ortam bilgisini gözden geçirilebilen, sürümlenebilen ve geliştirilebilen proje koduna dönüştürüyor.
Günlük iş akışı
Olağan geliştirme işleri için proje kitini kullanarak aitopus adlı bir sandbox oluşturuyorum:
# Desteklenen diğer ajanlar arasında claude, gemini ve opencode da bulunur.
sbx run codex \
--name aitopus \
--kit ./sandbox/aitopus/
Bu komut projeyi doğrudan bağlar; dolayısıyla ajanın değişiklikleri çalışma ağacımda görünür.
Daha güçlü bir sınıra ihtiyaç duyduğumda bunun yerine klon modunda ayrı bir sandbox oluşturabiliyorum:
sbx run --clone --no-share-skills codex \
--name aitopus-review \
--kit ./sandbox/aitopus/
İlk kurulum epey uzun sürebilir; çünkü ortamda native araç zincirleri, tarayıcı ikili dosyaları ve derleme bağımlılıkları bulunur. Buna karşılık sandbox'ın durumu ve derleme önbellekleri oturumlar arasında korunur.
İlk kurulum tamamlandıktan sonra ortamı baştan oluşturmak yerine aynı sandbox'a yeniden bağlanabilirim.
Ağ erişimini bilinçli biçimde belirleyin
Bir kodlama ajanının yine de internete erişmesi gerekir. Kullandığı model sağlayıcısına, paket kayıt sistemlerine, kaynak kod depolarına ve sürüm arşivlerine bağlanması gerekebilir.
Daha hassas oturumlarda kısıtlayıcı bir ağ politikasıyla başlayıp yalnızca ajanın ve derleme sürecinin ihtiyaç duyduğu servislere izin veriyorum.
Docker Sandboxes'ın sunduğu kimlik bilgisi proxy'si desteklenen kimlik bilgilerini ana makinede tutup yalnızca onaylanmış isteklere ekleyebilir. Bu yaklaşım uzun süre geçerli bir API anahtarını sandbox'a kopyalayıp nerede kaldığını sonradan unutmaktan daha iyidir.
Ağ denetimlerinin de sınırları vardır. İzin verilen bir servis ajanın kendisine gönderdiği bilgileri yine de alabilir. Hedefleri kısıtlamak maruziyeti azaltır; ancak dışarı giden her isteğin uygun olduğu anlamına gelmez.
Sandbox'ın çözmediği sorunlar
Sandbox ajanın erişimini sınırlar; kodun doğru olduğunu garanti etmez. Ajanın çıktısını güvenilmeyen bir kaynaktan gelmiş bir pull request gibi inceliyorum.
- Doğruluk. Ajan yine de güvenlik açığı bulunan bir bağımlılık ekleyebilir, bir gereksinimi yanlış yorumlayabilir veya testlerden geçtiği hâlde amaçlanan tasarımı ihlal eden kod üretebilir.
- Ana makinedeki yan etkiler. Doğrudan modda ajan sıradan kaynak dosyalarından çok daha fazlasını değiştirebilir. Git hook'ları, CI iş akışları, IDE görevleri, derleme betikleri ve ajan yapılandırması daha sonra ana makinede kod çalıştırabilir.
- Depo değişiklikleri. Klon modu ana makinedeki çalışma kopyasına doğrudan yazmayı önler; ancak geri aktarılan her şey yine de incelenmelidir.
- Hedef platformlar. Linux tabanlı bir sandbox daha güvenli ve tutarlı bir çalışma ortamı sunar; tamamlanan uygulamanın her hedef platformda doğru çalıştığını kanıtlamaz.
Özerklik ortamın bir özelliği olmalı
Daha güçlü bir sınır yoksa komut başına onay almak işe yarar. Ancak bu, baştan sağlam bir sınır tasarlamanın yerini tutmaz.
Ajan kendisine ayrılmış bir microVM içinde geniş yetkilerle çalışabilir. Her komuttan sonra onay beklemeden derleyiciler yükleyebilir, paketleri değiştirebilir, konteynerler oluşturabilir ve baştan sona bir hata ayıklama döngüsü yürütebilir.
Proje deposunu bilinçli olarak ona açıyorum. Ancak ana makinenin Docker daemon'ına, projeyle ilgisi olmayan dosyalara veya makinemin geri kalanına sınırsız erişim vermiyorum.
Bu yöntem yalnızca daha güvenli değil, aynı zamanda daha verimli.
Rutin işlemleri tek tek onaylamakla daha az uğraşıyorum, kendi makinemdeki araç zincirlerini düzeltmeye daha az zaman ayırıyorum ve geliştirme ortamını açıklamak için istemlerimde daha az yer ayırıyorum. Ajan işini yapacak kadar özgür; bense denetleyebileceğim net bir sınır çizmiş oluyorum.
Aynı ilke yerel yapay zekâ için de geçerli: hesaplamanın nerede yapıldığını seçin, hangi bilgilerin sınırı aşabileceğine karar verin ve geri kalanını kendi denetiminizde tutun.
Benim içime sinen YOLO modu tam olarak bu:
Bir ajana körü körüne güvenmek değil, hatalarının etkileyebileceği alanı benim belirlediğimden emin olmak.
Not: Docker Sandboxes kitleri şu anda deneyseldir. Üretim iş akışında belirli komutlara veya yapılandırma alanlarına güvenmeden önce güncel dokümantasyonu inceleyin.