Sunucusuz ajan

Bir Ajan oluşturmak kolay değildir.

Bir yıl önce, bağlamı ve hafızayı kendimiz yönetmemiz, RAG ve vektör veritabanlarını düşünmemiz ve araç kullanım doğruluğunu çok dikkatli bir şekilde ayarlamamız gerekiyordu. Claude Code / Claude Agent SDK'nın ortaya çıkışı tüm bunları değiştirdi. Artık giderek daha fazla ekip, Claude Agent SDK + VM kullanarak doğrudan Ajanlar inşa etmeye başlıyor. Peki sorun basitleşti mi? Hayır.

Claude Code'u VM'lerde çalıştırmak hâlâ çok zorlu bir iştir.

1. Her kullanıcı oturumu için bağımsız bir VM gerekir. Bazı senaryolarda VM'lerin kalıcılık yeteneği faydalı olabilir, ancak bu durum VM'leri yükseltmeyi ve orkestrasyonu zorlaştırır. Örneğin, kullanıcı açısından bakıldığında, VM'ye yüklenen yazılımın aylar sonra da kullanılabilir olmasını isterler. Ancak VM'deki orkestrasyon katmanıyla iletişim kuran bölümlerin de güncellemeleri alabilmesi gerekir.

2. Büyük ölçekte VM oluşturmak ve orkestrasyonunu sağlamak. Tek bir k8s kümesi yaklaşık birkaç bin pod için orkestrasyon desteği sunar, bu uygulama hizmet kümeleri için yeterlidir. Ancak her oturumun bir claude code pod başlatması gereken senaryolar için yeterli değildir.

3. k8s çözümlerini kullanmak, k8s'in getirdiği gecikmeyle karşı karşıya kalmak anlamına gelir ve 1 saniye içinde performans elde etmeyi zorlaştırır.

4. e2b çözümlerini kullanmak, kalıcılığı kendiniz sağlamanızı gerektirir ve dosya yükleme / indirme işlemleri çok yavaştır.

5. e2b çözümü, belirli ağ ortamı gereksinimlerini karşılayamaz ve özel kurulum zahmetlidir.

Peki bu sorunları nasıl çözeriz? Tarihten ders alalım. Takvim 2012 yılından on yıl öncesine döndüğünde, dünyada sunucusuz yoktu, k8s yoktu ve docker da yoktu. Arka uç mühendislerinin bir hizmeti çalıştırmak için fiziksel bir makinede hizmet sürecini manuel olarak sürdürmesi gerekiyordu. O zamanlar ssh ve ansible sunucu mühendislerinin standart araçlarıydı. Hizmet süreçleri, fiziksel makinedeki çeşitli araç ortamlarına büyük ölçüde bağımlıydı. Fiziksel makineler arasında tutarlı araç ortamı yapılandırmaları sağlamak çok zordu ve büyük ölçekli ölçeklendirme, ekiplerin önceden hazırlık yapmasını gerektiren büyük bir işti. Hâlâ hatırlıyorum, bir mühendis bir makinenin ortamını değiştirmiş ve diğer makinelerin ortamlarına senkronize etmeyi unutmuştu, bu da üretimde çok zor tespit edilen bir hayalet hataya yol açmıştı. O dönemler çok sancılı eski zamanlardı.

2012 yılında docker ortaya çıktı. Docker, tüm araç ortamlarını tek bir imajda paketleyerek ortam tutarsızlığı sorununu çözdü. Topluluk, fiziksel makinede çalışan bir hizmet sürecinin, fiziksel makinedeki bir süreç gibi yönetilebileceğini yavaş yavaş fark etti. Ancak docker orkestrasyonu hâlâ mühendislik ekiplerinin bir orkestrasyon sistemi kurmasını gerektiriyordu. Ve docker içindeki hizmet süreci fiziksel makinenin ağı ve dosya sistemiyle bütünleştiğinde, orkestrasyon çok sancılı bir iş haline geliyordu.

2014 yılında, durumsuz hizmetler ana akım trend olmaya başladı. O yıl Kubernetes ve AWS Lambda doğdu. Her biri, durumsuz hizmetlerin geleceğini farklı açılardan tanımladı. Durumsuz hizmetler, hizmet mantığının ağ adresleriyle bütünleşmekten kaçınması ve artık kalıcı dosya sistemlerine yerel olarak bağımlı olmaması anlamına geliyordu.

Sonra 10 bulut yerel yılları geldi, durumsuz hizmetlerin dalgası aşağıdaki gibi birçok bulut yerel altyapının doğmasına yol açtı:

• Hizmet ağ geçitleri Istio/Linkerd/Envoy/Treafik
• CI/CD platformları Argo CD / Flux
• Gözlemlenebilirlik platformları Prometheus/Grafana/ELK Stack
• Çağrı zinciri analizi Jaeger/Zipkin/OpenTelemetry
• Depolama Rook/MinIO/JuiceFS

Ve şimdi yeni bir başlangıçtayız. On yıl önce, bir hesaplama birimi bir java/python api hizmet süreciydi. Bu yıldan itibaren, bu hesaplama birimi bir kodlama ajanı oldu.

ACFS, fiziksel makinelerde hizmet süreçlerini manuel olarak sürdürme dönemine benziyor. E2B ise Docker'a benziyor. Görev orkestrasyon platformları, gözlemlenebilirlik platformları ve dağıtık durum kalıcılığı depolama yetenekleri olmadan, kodlama ajanları için ölçeklenebilirlik hâlâ zorlu bir iştir. Ve beklediğim Sunucusuz Ajan Altyapısı şu yeteneklere sahip olmalı:

1. Kodlama ajanının oturumlarını ve çalışma dizinlerini bağlamı kaybetmeden uygun şekilde kalıcı hale getirebilmek.
2. Süper hızlı, bir kodlama ajanını 100ms içinde çalışır hale getirebilmek.
3. İnsanların kolayca anlayabileceği Ajan davranışına dair Kayıt / Metrik / İzleme sunmak, böylece insanların Ajan davranış kalıplarını anlamasını ve ayarlamasını kolaylaştırmak.
4. Geliştiricilerin artık sanal makineler, konteynerler ve diğer operasyon detaylarıyla ilgilenmesine gerek kalmaması, büyük ölçekli orkestrasyonu çok kolay hale getirmek.

Bu yetenekleri karşılayabilen tüm altyapının aslında hazır olduğunu düşünüyorum, örneğin firecracker mikroVM'lerin performansını ve kararlılığını kanıtladı, ayrıca dağıtık gözlemlenebilirlik platformları ve dosya depolama sistemleri için de birçok seçenek var. Ancak e2b kullanarak claude code'u kapsülleyen bir geliştirici olarak, bunları birleştirmek hâlâ çok zor. Örneğin, E2B'deki claude code OOM nedeniyle beklenmedik şekilde kesildiğinde, mühendislerin bunu izlemesi zor, o anki durumu ve günlükleri almak ise daha da zor.

Umarım 2026 sonrası geliştiriciler böyle sancılı bir süreçten geçmek zorunda kalmaz, tıpkı 2026 yılındaki çoğu mühendisin artık fiziksel makineleri manuel olarak başlatmak için ssh kullanmak zorunda olmaması gibi.

Bu, VM0'ın hayali. Umarım bir gün ergonomik bir API ile bir kodlama ajanını şu şekilde çalıştırabilirim:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})