AI Kodlama Ajanlarını Bir Daha Çöp Gibi Atıp Gitmeyin—Onlara Gerçek Çalışma Alanları Verin

AI Kodlama Ajanlarını Bir Daha Çöp Gibi Atıp Gitmeyin—Onlara Gerçek Çalışma Alanları Verin

May 05, 2026 ai agents development workflow docker infrastructure-as-code parallel processing automation coding assistants

AI Ajanları Nasıl Evrimleşiyor: Koruma Altından Gerçek Takıma

İlk kez Claude gibi AI kod yardımcılarıyla çalışmaya başladığında, her tarafa güvenlik duvarı koymak isteme dürtüsü gayet anlaşılır. Doğrusu? Bu içgüdü sayısız geliştiriciyi rm -rf komutunun ev dizininde yıkım yaratması korkusundan kurtarmış.

İzolasyonlu ortamlar panik sorununu çözmüştü. Ajanlar içlerinde "saçma sapan hareket" edebilir, dotfiles'a zarar veremezdi. Ama sonra bir şey fark ettiler: bu araçlar gerçekten yeterince iyi çalışabiliyorlardı. Oyuncak görevler değil. Üretime gidecek hakiki projeler.

İşte o noktada tek ajanlı model çatlamaya başladı.

Paralel İşleme Sorunu: Kimse Konuşmuyor

Diyelim ki yapman gereken:

  • Bir API endpoint'i yeniden yapılandırmak
  • Test hatalarını düzeltmek
  • Docker konfigürasyonunu araştırmak
  • Frontend iyileştirmeleri yapmak

Doğal içgüdün bu işleri sırasıyla kuyruklamak. Ajan ilk işi bitir, kontrol et, ikincisini başlat. Peki bu, ajanın özü nedir? Seni takipçi olmaktan kurtarması. Oysa orada oturup gözetim yapıyorsun—tam da kaçmak istediğin şey bu.

O yüzden birden fazla ajayı aynı anda çalıştırmayı deniyorsun. Tam burası ilginçleşiyor.

Git cehenneme dönüşüyor. İki ajan aynı repo'yu aynı branshda editlemek kaos dersi. Birinin commiti diğerinin çatışması oluyor. Kod incelemesi neden var diye yeniden anlıyorsun.

Dosya sistemi savaş açıyor. Modern projeler çöpü toplar—node_modules, derleme cachesi, türetilmiş kod, SQLite veritabanları, bir güvenlik mühendisini ağlatacak .env dosyaları. Bunların hiçbiri git'te yok. Hepsi birden çoklu işlem çalıştırırken çarpışma yaratıyor.

Docker Compose cinayet işliyor. Her iki ajan da 5432 portunu istiyor. Her ikisi de "postgres-dev" isimli container. Aynı volume adı. Planladığın paralel ilerleme, container'ların senkron ölümüne dönüşüyor.

Git Worktrees Tuzağı

İşte bu noktada akıl hocası fısıltı yapıyor: "Git worktrees kullan!"

Teknik olarak doğru. Pratik olarak yetersiz.

Worktrees bir sorunu çözer—tek .git dizinine bağlı farklı branchlarda çoklu checkout. İnsan için kullanışlı. Ajanlar için? 15 tanesinin çözümünü veriyor, 85 tanesinin de prosedür kalabalığını yaratıyor.

Worktree sana ayrı node_modules vermez. .env konfigürasyonunu izole etmez. Her ajana Docker Compose namespace vermez. Yine de her worktree'yi elle kurman lazım—bağımlılıkları kur, cache'leri yeniden derle, containerları farklı port numaralandırmasıyla yeniden başlat, mutlak yolların hardcode edilmediğini umut et.

Bir çalışana eksik araçlarla bir masada çalışmasını söylemek gibisi.

Sorunu Yeniden Çerçevelemek: Ajanlar Gerçek Takım Üyeleri

Konseptsel kayış bu: ajanları araç olarak değil, geliştirici olarak düşün.

Alice'i işe aldığında, "Lütfen mevcut checkout'uma bağlı bir Git worktree gibi davran" demezsin. "Repo'yu clone et, ortamını kur, uygulamayı yerel olarak çalıştır, bir branch push et" dersin.

Böldüğün şey branch değil. Geliştirici—tüm geliştirme ortamı.

Ajanlar paralel çalışması için ihtiyaç duyuyor:

İzolasyonlu ortamlar. Her ajan kendi klonunu, kendi bağımlılık ağacını, kendi .env dosyasını alıyor. Ortak durum yok, çarpışma yok.

Bağımsız altyapı. Farklı namespace'e sahip ayrı Docker Compose projeleri. A Ajanının Postgres'i B Ajanının Redis'iyle çatışmıyor. Her ikisi de bağımsız çalışıp, debug'layıp, test edebiliyor.

Düzgün kimlik doğrulama ve izinler. Git işlemleri için SSH forwarding. GitHub kimlik bilgileri uygun şekilde kapsamlı. Tek bir yerde duran paylaşılan anahtar yok.

İçerik farkındalığı. Ajanlar geliştirme ortamında nerede olduklarını bilmeli—hangi branshta, spesifik sorumlulukları neler, başarı nasıl görünür.

Asenkron koordinasyon. Toplantıdaki insanlardan farklı olarak ajanlar bağımsız çalışmalı, incelenebilir bir durumda bırakmalı, sen neyin merge'leneceğine karar vermelisin.

Pratikte Nasıl Görünüyor

NameOcean'da AI destekli geliştirmeyi yapılandıran takımların bu yapıyı görmesi başlıyor. Bir proje başına bir ajan yerine, takımlar birden fazla ajan örneğini sağlıyor:

  • Containerize ortamlar (yolobox yaklaşımı gibi)
  • Bağımsız veritabanı örnekleri veya test veri setleri
  • Ayrı Docker Compose konfigürasyonları
  • Ajanların okuyabileceği proje seviyesi içerik manifestoları
  • Pano köprüleri ve sorunsuz entegrasyon için SSH forwarding

İş akışı şöyle oluyor:

  1. Ajan Alfa çalışma alanı A'da başlıyor, yetkilendirme modülüyle başlıyor
  2. Ajan Beta çalışma alanı B'ye aktarılıyor, API dokümantasyonu yapıyor
  3. Ajan Gamma çalışma alanı C'de test yazıp refine ediyor
  4. Her biri bağımsız olarak işi bitirip feature branch'e push ediyor
  5. Sen paralel inceliyor, stratejik şekilde merge ediyorsun

Kuyruk yok. Gözetim yok. Senkronize container ölümleri yok.

Altyapı Meselesi

Bu, geliştirme ortamlarını nasıl sağladığımız konusunda yeniden düşünmeyi gerektiriyor. Bulut barındırma platformları yetişmeye başlıyor—altyapı-kod hali artık iyi-olursa sevabı değil, zorunluluk oluyor. Docker, Kubernetes ve containerize geliştirme ortamları (NameOcean'ın Vibe Hosting'in keşfettiği gibi) şık olmaktan çok gerçek zorunluluk haline dönüşüyor.

Template katmanı da önemli. Dockerfile parçaları, docker-compose.yml varyasyonları, ortam kurulum scriptleri—bunlar ajanların okuduğu ve çalıştırdığı gerçek geliştirme spesifikasyonu oluyor.

Neden Şimdi Önemli

AI ajanları yeterince yetkin olmuş—hem tehlikeli hem faydalı olarak değer isteyen yer. Ajan iş akışını hakiki yazılım takımları gibi yapılandırmayı anlaşan geliştirici ve takımlar, hala ajanları tek görev kumbarasına sıkıştıran olanlardan daha hızlı ilerliyor.

Fark sadece hız değil. Geliştirme kapasitesini çoğaltan mı yoksa sadece bireysel tuş vuruşlarını otomate eden mi olduğun.

Sonraki Adımlar

İş akışında AI ajanlarıyla deney yapıyorsan:

  1. Tek ajan optimizasyonunu bırak. İlk günden ölçeklenebilir tasarla.
  2. Ortam template'leri için para harca. Docker ve IaC yükü değil—ajanın işletim sistemi.
  3. Düzgün kapsam ve izinleri uygula. Geniş erişimli ajanlar kaos ajanı.
  4. Sağlamayı birinci sınıf konu yap. Yeni ajan ortamı başlatma hızı produktiviteyi doğrudan etkiliyor.
  5. Ajan konfigürasyonlarını versiyonla. Kodu sürümlendirdiğin gibi, ajanların çalıştığı ortamları da sürümlendirsin.

Geliştirmenin geleceği bir insan + bir ajan değil. Orchestrated bir takım, her biri uygun izolasyon ortamında, ortak hedefi doğru çalışan.

Asıl üretkenlik, tam orada kilidi açılıyor.

Read in other languages:

RU BG EL CS UZ SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN