Geçen ay İstanbul’da bir startup ekibinin toplantısındaydım. Masada herkes aynı cümleyi farklı tonlarda söylüyordu: “İş çok uzuyor.” Analiz ayrı dert, test ayrı dert, deployment zaten başlı başına macera… İşin aslı şu — itiraz edebilirsiniz tabi — ki yazılım geliştirme çoğu zaman kod yazmaktan çok koordinasyon işi oluyor. Ve koordinasyon da pahalı.
Orijinal haberi ilk okuduğumda aklıma 2023’te kendi denediğim küçük bir otomasyon geldi (en azından benim deneyimim böyle). Tek bir ajan bile değil, basit bir akış motoru kullanıyordum; yine de işin yarısı insan müdahalesiyle gidiyordu. Buradaki fark şu: artık tek bir “akıllı asistan” yerine farklı rollere bölünmüş ajanlar konuşuyor. Hani ekipte analist ayrı, geliştirici ayrı, testçi ayrı olur ya… Aynı mantık, ama bu kez dijital versiyonuyla.
Çok ajanlı yapılar kulağa havalı geliyor ama asıl mesele şov yapmak değil; tekrar eden işleri gerçekten azaltıp azaltmadığı. Kağıt üstünde süper duran sistemler var, pratikte ise ilk ciddi edge-case’te tökezliyorlar.
Neden Bu Kadar Sürünüyoruz?
Bakın şimdi… Yazılım geliştirme dediğimiz şey çoğu ekipte lineer ilerlemiyor. Bir ürün yöneticisi ihtiyaçları anlatıyor, analist not alıyor, mimar çiziyor, geliştirici kodluyor, QA yakalarsa test ediyor, DevOps son anda “bu container niye ayağa kalkmıyor?” diye bakıyor — her geçişte bilgi biraz daha eriyor,. Kayıp var. Ben bunu Ankara’da bir kurumsal projede birebir gördüm; gereksinim dokümanı üç hafta sonra öyle bir değişmişti ki kimse ilk sürümü hatırlamıyordu bile, kimse.
Bir dakika — bununla bitmedi.
Bu yüzden çok ajanlı sistem fikri bence fena değil. Hatta baya işe yarıyor olabilir. Çünkü sorun sadece hız değil; yanlış anlaşılma da var. İnsanların birbirine e-posta atıp cevap beklemesi gibi düşünün, ama burada e-postayı kod yazan botlar gönderiyor. E tabi bu da otomatik olarak çözüm olmuyor; yanlış kurgulanmışsa hatayı da seri üretir.
Garip gelecek ama, Bir de maliyet tarafı var. Büyük model her iş için kullanılırsa faturayı görünce yüzünüz düşer. Geçen sene Berlin’de çalışan bir arkadaşım küçük model artı büyük model hibrit yaklaşımıyla aylık AI maliyetini yaklaşık yüzde otuz beş düşürdüğünü söylemişti — rakamı ben de başta abartı sandım açıkçası. Ama mantık oturunca inandırıcı geliyor: basit işlere dev motor bağlamıyorsun. Bu kadar.
Hmm, bunu nasıl anlatsamdı…
Ajanlar Nasıl Bölünüyor?
Temel fikir şu: tek bir genel amaçlı yapay zeka yerine uzmanlaşmış roller kurmak. Biri gereksinimi topluyor, biri mimariyi düşünüyor, biri backend’i yazıyor, biri arayüzü toparlıyor… İnsan ekiplerinin yansıması gibi duruyor ama önemli fark şu — ajanlar gece uyumuyor ve “bunu yarın konuşsak mı?” demiyor.
Kullanılan roller arasında iş analisti var, mimar var, backend geliştirici var, frontend geliştirici var; test tarafında QA agent’ı hem unit hem integration hem de E2E testleri koşturuyor. Güvenlik tarafında da boşluk bırakmıyorlar; secret scanning’den bağımlılık kontrolüne kadar her şey sıraya giriyor.
Peki neden?
Rol bazlı yapı neden iyi çalışıyor?
Çünkü her problem aynı tür beyin istemiyor. Gereksinim netleştirmek başka şeydir; performans darboğazını çözmek bambaşka. Bir ajanın hepsini yapmaya çalışması yerine işi parçalara bölmek daha doğal geliyor bana. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Şöyle düşünün: mutfakta tek kişi hem yemek hazırlasın hem servis yapsın hem kasa tutsun… Bir noktada çorba taşar yani. Çok ajanlı yaklaşım bunu önlüyor gibi duruyor — en azından teoride.
Peki risk yok mu?
Var tabii. En büyük risklerden biri tutarlılık kaybı; bir ajan gereksinimi yanlış yorumlarsa sonraki tüm zincir etkileniyor, domino gibi. O yüzden insan onayı hala lazım. En çok da de stratejik kararlar ve ürün vizyonu konusunda yapay zekaya tam yetki vermek bana göre erken. Bu konuyla ilgili ChatGPT Pro’da Yeni Dönem: 100 Dolarlık Plan Ne Veriyor? yazımıza da göz atmanızı tavsiye ederim.
Maliyet Kontrolü ve Model Yönlendirme
Bence yazının en sağlam kısmı burasıydı: her işe en kuvvetli modeli çağırmamak. Açık konuşayım, bu — en azından ben öyle düşünüyorum — mantık yalnızca teknik değil ekonomik olarak da sağlıklı görünüyor. Basit biçimlendirme işleri için hafif model kullanmak ile karmaşık mimari kararlarında daha güçlü modele gitmek arasında ciddi fark var — hem hız hem para açısından. Gerçek Zamanlı Kargo Takibi: Sepeti Kurtaran Mimari yazımızda bu konuya da değinmiştik.
| İş Türü | Önerilen Yaklaşım | Neden Mantıklı? |
|---|---|---|
| Sade metin düzenleme | Küçük / yerel model | Düşük maliyet, hızlı yanıt |
| Kod inceleme | Orta seviye model | Denge iyi olur |
| Mimari kararlar | Güçlü model + insan onayı | Daha az hata riski |
| Güvenlik analizi | Kural tabanlı araç + LLM destekli kontrol | Tutarlılık ve kapsam artar |
Bu tabloyu görünce aklıma hemen kendi denediğim CI/CD akışı geldi — 2024 Mart’ında İzmir’de küçük bir SaaS ekibiyle çalışırken. Orada da her job için ağır runner açınca maliyet şişmişti; sonra işleri ayırınca nefes aldık resmen (yanlış duymadınız). Küçük şey, büyük fark.
Neyse uzatmayalım: doğru modele doğru işi vermek neredeyse bütün oyunun özü gibi duruyor.
# Basit örnek akış
if task == "format_text":
route_to("small_model")
elif task in ["architecture", "security_review"]:
route_to("large_model")
else:
route_to("mid_model")Test Kültürü Olmadan Olmaz mı? Olmaz!
Beni en çok ikna eden bölüm test tarafı oldu çünkü burada romantizm yok; ya çalışır ya çalışmaz. Unit testler tamam diyelim… integration testi patladıysa o kodun üretime çıkması bana göre hala riskli demektir. Nokta. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Sistem sadece “bir kere test et” demiyor; unit’ten E2E’ye kadar tüm katmanı dönduruyor gibi anlatılıyor. Playwright ile uçtan uca senaryoların koşulması güzel fikir ama şunu da söyleyeyim: visual regression bazen fazla hassas olabiliyor ve gereksiz alarm üretebiliyor. Yani evet faydalı, ama henüz ham tarafları var.
- Birim testleri hızlı geri bildirim verir. (bu kritik)
- Bütünleşik testler servisler arası kırılmayı yakalar.
- E2E senaryolar kullanıcı yolculuğunu doğrular.
- Sızma testi ve dependency taraması güvenliği öne çeker.
- Sistem sağlığı kontrolleri deployment sonrası rahatlatır.
Küçük startup için ne ifade eder?
Küçük ekiplerde böyle otomasyon hayat kurtarabilir çünkü herkes aynı anda beş şapka takıyor zaten. Ama başlangıçta kurulum yükü biraz can sıkabilir; yani “hemen verim alırım” beklentisi bazen hayal kırıklığı yaratır. Bu ne anlama geliyor? Bunu yaşayan ekip sayısı az değil. Metal Gear Solid filmi geri döndü: Hollywood neden vazgeçmedi? yazımızda bu konuya da değinmiştik.
Kurum ölçeğinde durum nasıl değişir?
İşin garibi, Büyük organizasyonda ise avantaj daha net çıkar çünkü süreç bozulmaları büyüdükçe maliyeti artar. Bir hata bin kişiye dokunuyorsa otomatik kalite kapıları ciddi değer sağlar — bunu tartışmak bile zor aslında (en azından benim deneyimim böyle)
Kendini Geliştiren Ajan Fikri Nereye Gider?
Ajanların geçmiş görevlerden öğrenmesi fikri kağıt üzerinde çok çekici. Peki bunu neden söylüyorum? Mesela hangi tip isteğin ne kadar sürdüğü, nerede takıldığı, hangi prompt’un kötü sonuç verdiği kaydediliyor olabilir; bu sayede sistem zamanla kendi davranışını ayarlıyor — kulağa neredeyse sihir gibi geliyor.
Ama burada ince çizgi var. Öğrenme mekanizması düzgün tasarlanmazsa sistem eski hataları kalıcı hale getirir. Ben buna benzer bir şeyi geçen yıl Londra’daki bir müşteri demosunda görmüştüm; loglardan beslenen öneri motoru yanlış sinyali optimize etmişti (buna dikkat edin). Sonra temiz veri gelmeden hiçbir şey düzelmedi. Hiçbir şey.
Bana sorarsanız self-learning kısmı en ilginç ama en tehlikeli alanlardan biri. Çünkü sistem iyi gününde zeki görünürken kötü gününde saçmalayabilir (kendi tecrübem). İnsan gözü burada hala şart; özellikle regülasyonlu sektörlerde.
En iyi otomasyon bile kör çalışmamalı. En çok da güvenlik, uyumluluk ve üretim yayını söz konusuysa insan denetimi sonradan eklenen lüks değil, baştan koyulmuş emniyet kemeri olmalı.
Güvenlik ve Uyumluluk Tarafı Hafife Gelmez
Kod üretimini hızlandırmak kolay, ama güvenliği sonradan düşünmek genelde pahalıya patlıyor. Bu yüzden security by default yaklaşımı hoşuma gitti. Secret scanning, dependency audit, GDPR veya NIS2 kontrolleri… bunlar “istersen bakarız” kategorisinde kalmamalı. Kalmamalı, nokta.
Bir dakika, şunu da ekleyeyim: otomasyon arttıkça saldırı yüzeyi de büyüyor. Daha fazla agent, daha fazla tool, daha fazla API key… yani saldırganın oynayacağı taş sayısı artıyor. Geçen sene Şubat ayında Frankfurt’taki bir workshop’ta tam bunu tartışmıştık; çok sayıda entegrasyon olan sistemlerin güvenlik borcu hızlı büyüyor, bunu ilk duyduğumda “abartıyorlar” dedim. Değiller.
Yani, Bu yüzden ben böyle yapılarda iki katman öneriyorum:
- Üretim öncesi statik analiz
- Üretim sonrası gözlemleme ve anomali takibi
Bi saniye — Ha bu arada, gözlemleme kısmını küçümsemeyin. Log yoksa olay yok sanıyorsunuz, ama aslında sadece körsünüz. Fark bu.
Nerede Parlıyor, Nerede Zorluyor?
Bu tip çok ajanlı mimari benim gözümde özellikle tekrarlı kurumsal işler için parlak duruyor: doküman işlemleri, danışmanlık platformları, compliance otomasyonu, standart API projeleri… Ama tamamen yaratıcı ürünlerde durum biraz karışık olabilir. Çünkü orada belirsizlik yüksek, insan sezgisi daha değerli. Hmm, nasıl desem — makine belirsizliği sevmiyor pek.
Mesela küçük bir startup’ta MVP çıkarmak için harika olabilir; kurumsalda ise standartlaştırılmış süreçleri hızlandırır. Ama tek kişilik girişimde önce aşırı mühendislik tuzağına düşmemek lazım (evet, doğru duydunuz). Tahmin eder misiniz? Her problemi agent swarm ile çözmeye kalkarsanız iş büyür, kod base kabarır, kimse ne olduğunu anlamaz — bunu bir arkadaşım acı yoldan öğrendi geçen yıl.
Ne yalan söyleyeyim, Kendi bloguma yazarken de bunu sık görüyorum. Otomasyon araçları ilk başta zaman kazandırıyor gibi görünür, sonra bakım yükü başlıyor. O yüzden ben hep şunu söylerim: “İlk (belki yanılıyorum ama) hedef hız değil, kontrollü hız.” Az önce hız dedim ama aslında istikrar daha doğru kelime olabilir. Evet, istikrar.
Sonuç yerine kısa not:
Bu yaklaşım gelecekte önemli olacak gibi görünüyor; fakat mucize diye pazarlamak doğru olmaz. Bugün için en gerçekçi kullanım alanı insan ekibinin omzundaki tekrar eden yükleri hafifletmek. Kodun ruhunu tamamen makineye bırakmak mı? Orası hala erken.
Sıkça Sorulan Sorular
Çok ajanlı yapay zekâ sistemi nedir?
Farklı görevler için uzmanlaşmış AI ajanlarının birlikte çalıştığı yapıdır. Biri analiz eder, biri kod yazar, biri test eder. Tek asistan yerine mini ekip mantığı vardır.
Böyle bir sistem küçük şirketlere uygun mu?
Uygun olabilir ama kurulumu hafife almamak gerekir. Küçük ekiplerde kazanç sağlar;ancak bakım yükü ve entegrasyon maliyeti dikkat ister. Önce dar kapsamda denemek daha mantıklı olur.
Tamamen insan geliştiricilerin yerini alabilir mi?
Şimdilik hayır. Bilhassa ürün stratejisi,müşteri iletişimi ve kritik mimari kararlar hâlâ insanda kalmalı. AI burada yardımcı pilot gibi düşünülmeli.
Aynı anda hem hızlı hem güvenli olmak mümkün mü? Mümkün,ama disiplin ister. Test otomasyonu güvenlik taraması ve izlenebilirlik olmadan hızlı olmak genelde kısa vadeli rahatlık verir. Uzun vadede ise borcu büyütür.
Kaynaklar ve İleri Okuma
Orijinal makale — How We Automated Software Development with Multi-Agent AI Systems
GitHub Ana Sayfası — Proje örneklerini keşfetmek için başlangıç noktası
OpenAI API Dokümantasyonu — Model yönlendirme ve araç kullanımı hakkında resmi kaynak
Playwright Dokümantasyonu — Uçtan uca tect senaryoları için resmi rehber
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
