Yani, Bakın şimdi, yapay zekâ ajanları etrafındaki gürültü artık epey yükseldi. Herkes “bir ekip kurduk, kodu kendi yazdı” diye konuşuyor. Güzel. Ama işin aslı şu ki, gerçek proje masasına oturunca tablo biraz değişiyor. Geçen ay Şubat 2026’da İstanbul’da bir startup ekibiyle sohbet ederken aynı şeyi duydum: Demo başka, günlük geliştirme başka (yanlış duymadınız). İşte bu yazıda mesele tam da o ayrım.
Elimdeki örnek de buna benziyor. Bir geliştirici, birkaç AI ajanından oluşan küçük bir takım kurup onları neredeyse baştan sona otonom çalıştırmayı denemiş. Hedef net: İnsan sadece son kontrolde devreye girsin, geri kalan işi ajanlar halletsin. Kağıt üstünde kulağa baya iyi geliyor… ama pratikte işler genelde öyle akmıyor.
Deneyin fikri neden ilgi çekici?
Şunu kabul edelim: Kod yazan yapay zekâ artık yeni değil. Fakat tek bir sohbet ekranında “şu fonksiyonu üret” demekle, bir ürünün uçtan uca geliştirilmesini yönetmek arasında dağlar kadar fark var. Ajan yaklaşımı tam da burada devreye giriyor — yani tek bir model yerine görev dağıtan, plan yapan, test eden ve kontrol eden küçük rollerden oluşan bir yapı kuruyorsunuz.
Peki neden? Samsung’dan Sızıntı: One UI 8.5 İçin Tarih Göründü yazımızda bu konuya da değinmiştik.
Ben bunu ilk kez 2023 sonunda kendi yan projemde denediğimde çok heyecanlanmıştım. Ankara’da gece yarısı iki saat içinde basit bir CRUD paneli çıkarmıştı mesela… sonra veritabanı migrasyonlarında tökezledi ve beni yine elle düzeltmeye çağırdı. O yüzden bu tür deneylere bakarken içimden hep aynı cümle geçiyor: “Tamam güzel de, nerede kırılıyor?”
İşin garibi, Bu deneyin kıymeti de orada zaten. Sadece “ajanlar kod yazabiliyor mu?” sorusunu sormuyorlar; koordinasyon kurabiliyor mu, testleri takip edebiliyor mu, bağımlılıklarla boğuşunca ne yapıyor — bunları da ölçüyorlar. Yani oyuncak demo değil bu. Daha çok küçük çaplı saha testi gibi düşünün.
Evet, doğru duydunuz.
Ekip nasıl kurulmuş?
Kurgu oldukça tanıdık aslında: Bir koordinatör ajan var; onun altında iki geliştirici ajan, iki testçi ajan. Bir UX ajanı çalışıyor. Bu yapı bana eski ajans günlerimi hatırlattı — 2018’de Kadıköy’deki ofiste tasarımcıdan QA’ye kadar herkes ayrı kanaldan konuşurdu ya, birbirinin ne yaptığından habersiz, herkes kendi işinde, ortada da bir koordinasyon kaosuydu… Burada da benzer bir karmaşa var ama insanlar yerine token’lar dolaşıyor (buna dikkat edin)
Bence, Kullanılan araç Gemini-CLI olmuş. Sebebi de ücretsiz katmanın cömert olmasıymış. Açık konuşayım: bu tercih gayet mantıklı, çünkü agentic sistemlerde maliyet çabuk şişiyor. Bugün beş görevlik deneme yaparsın, yarın logların peşinde üç saat geçirirsen faturayı unutursun gider.
Ajan profilleri ve kural seti
İlk adımda her rol için ayrı profil üretilmiş; sonra bunlara proje özelinde yetenekler eklenmiş ve kodlama stili sabitlenmiş. Bu önemli. Çünkü aksi halde her ajan farklı tonda konuşuyor, biri TypeScript seviyor diğeri klasör isimlerini kafasına göre değiştiriyor, ve siz ortada kalıyorsunuz — neyi kim bozdu, hangi ajan nereye dokundu, hiçbir şey belli değil.
Tuhaf ama, Bir de gemini.md gibi sıkı yönergeler hazırlanmış. Mesajlaşma biçimi sınırlanmış, görev atama düzeni tanımlanmış ve token tüketimini azaltacak kurallar konmuş. Kısacası “serbest bırakınca koşar” sanmayın. Disiplin yoksa agent sistemi hızla gevezeliğe dönüyor. Ciddi fark var.
User story disiplini niye önemli?
Bana göre işin en akıllıca taraflarından biri user story’leri önce ayrı klasörde toplamak olmuş. Neden mi? Çünkü ajanlar bazen doğrudan koda atlıyor ve gereksinimi yarım yamalak anlıyorlar — sonra ortaya çalışan ama yanlış şey yapan özellikler çıkıyor. Fark ettiniz mi? Çalışıyor, ama yanlış. İkisi çok farklı şeyler. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
// Basit örnek akış
1) User story yaz
2) Öncelik sırala
3) Görevleri böl
4) Branch aç
5) Küçük commit at
6) progress.md ile durumu izleNerede iyi çalıştı?
Dürüst olayım: başlangıç kısmı fena gitmemişti, hatta baya umut vermişti diyebilirim (ben de ilk duyduğumda şaşırmıştım). Takım mantıklı klasör yapısı — ki bu tartışılır — oluşturmuş, gereksinimleri toparlamış ve işleri düzgün şekilde bölmüş görünüyordu. Zaman tahminleri bile verilmişti — ki bu insan ekibinde bile bazen zor çıkar.
Peki neden?
Böyle anlarda insanın içinden şu geçiyor: “Tamam galiba oluyor.” Benzer hissi geçen yıl Ekim 2025’te İzmir’de bir fintech demosunda yaşamıştım; otomatik dokümantasyon hazırlayan sistem ilk turda kusursuzdu ama ikinci turda edge-case gelince saçmaladı. Ajanlarda da durum biraz böyle. İlk yüzde altmış çok parlak görünüyor. Sonrası… hmm, farklı bir hikâye. Daha fazla bilgi için AI Arama Savaşı: Perplexity, SearchGPT ve Claude yazımıza bakabilirsiniz. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
| Aşama | Ajanların performansı | Sahadaki anlamı |
|---|---|---|
| Planlama | İyi | İşi parçalara ayırabiliyorlar |
| Klasörleme / düzen | İyi | Mantıklı iskelet kuruyorlar |
| Zaman tahmini | Tatmin edici | Kaba plan çıkarabiliyorlar |
| Sistem entegrasyonu | Zayıf | Kritik noktada takılıyorlar |
| Sürekli çalışma döngüsü | Dengesiz | Ara sıra kendi kuyruğunu kovalar hale geliyorlar |
Küçük ekip için ne ifade ediyor?
Küçük bir startup iseniz bu tarz ajan sistemi sizi rahatlatabilir. Sıfırdan iskelet çıkarmak can sıkıcıdır — özellikle pazarlama sitesi + admin panel + temel API gibi işleriniz varsa hızlı başlatma konusunda eli oldukça güçlü. Bu ne anlama geliyor? Neyse uzatmayalım: işe yarıyor, ama sınırlarını bilmek şart.
Büyük kurum için ne ifade ediyor?
Eh, Enterprise tarafında ise beklenti başka olurdu tabii. Orada sadece kod üretmek yetmez; güvenlik politikaları, gözlemleme araçları, audit izi ve onay mekanizmaları gerekir. Yani “ajan yaptı geçti” modeli pek işlemez. Hatta bence o ortamda deneyi bile yapamazsınız rahatça.
Tıkanma nerede başladı?
Şöyle söyleyeyim, Neyse, gelelim can sıkıcı tarafa. En büyük sorun araç zincirlerinde çıkmış. Vite gibi süreçler sürekli çalışmaya başlayınca ajanların workflow’u kilitlenmiş. Bu bana açıkçası hiç sürpriz gelmedi, çünkü uzun süre yaşayan build süreçleri otomasyona karşı nazlı davranır — sanki “benimle uğraşma” der gibi.
Aha, tam burada insan müdahalesi gerekiyor.
Garip gelecek ama, Maalesef.
Gel gelelim çözüm olarak Docker’a geçilmiş, ama bu daha çok yama gibi durmuş (ben de ilk duyduğumda şaşırmıştım). Çalıştı mı? Evet. Rahatlattı mı? Kısmen. Ama kök problemi çözdü mü? Pek sayılmaz.
Ajan sistemlerinde en tehlikeli an çoğu zaman kodun kötü olması değil; aracın durmadan dönüp hiçbir yere varmamasıdır.
C# API ile React birleşince neden duvar çıktı?
Kendi deneyimimden konuşuyorum, Bence hikâyenin kırılma noktası burasıydı. C# API ile React (belki yanılıyorum ama) uygulamasını konuşturmak teoride sıradan görünür — dur bir saniye, şöyle söyleyeyim aslında: teoride sıradan görünür ama pratikte kimlik doğrulama mı patladı dersiniz, CORS mu takıldı dersiniz, veri sözleşmesi mi uyuşmadı dersiniz (kendi tecrübem). hepsi olabilir, hepsi de olmuş zaten. Daha fazla bilgi için AI Ajanına 7 Zincirli Kripto Cüzdan: 5 Dakikada Kurulum yazımıza bakabilirsiniz.
Bu tip entegrasyon problemleri insan geliştiricide bile zaman yerken ajanın tamamen kaybolması şaşırtıcı değil aslında. Benim başımdan benzeri Kasım 2024’te Bursa’daki orta ölçekli bir projede geçmişti; backend tarafı hazırdı ama frontend ekip JSON alan adlarını farklı yorumlayınca iki gün gitti. İki gün. Ajanlarda ise sabır daha az gibi davranıyorlar. Denedikleri şeylerin izi kalıyor ama yön duygusu zayıflayınca ilerleme kopuyor.
Bi saniye — Bir de şu var:
- Kod üretmek ayrı şeydir;
- sistemi entegre etmek ayrı; — ciddi fark yaratıyor
- sorun çıktığında doğru yerde debug etmek bambaşka iştir;
- bazen insan eli olmadan çözüm aramak vakit kaybettirir.
Peki bundan hangi ders çıkar?
- Ajanları yardımcı olarak düşünün, otonom çalışan takım lideri olarak değil.
- Kritik entegrasyonları hâlâ insan kontrolünden geçirin.
- Süreç izleme koyun; aksi halde araç döngüsüne saplanırsınız.
- User story disiplinini başta kurun; sonradan toparlamak zorlaşıyor.
💡 Bilgi: Küçük projelerde AI agent kullanımı hız kazandırabilir, ama hata toleransı düşük hayati sistemlerde hâlâ kontrollü hibrit yaklaşım daha sağlıklı duruyor.
Neyi gerçekten iyi yapıyor?
Proje bootstrapping, dokümantasyon taslağı, görev bölme, ilk test senaryolarını çıkarma… bunlarda eline su dökmek zor. Bilhassa tek kişinin omzundaki yükü azaltıyorsa değer yaratıyor. Ben bunu Mart 2026’da Eskişehir’de freelance çalışan bir arkadaşımda gördüm; landing page’i yarım günde ayağa kaldırdı, sonra detay temizliği için yine kendisi girdi. İşte doğru kullanım buydu. Tam da öyle.
Neyi henüz beceremiyor?
Karmaşık hata ayıklama, çoklu servis entegrasyonu, sistem kararlılığı. Belirsiz gereksinimlerle uğraşma noktasında hâlâ ham. Biraz pişmesi lazım. Hele canlı ortamda log okuyup karar verme kısmında insana ihtiyaç duyuyor. Bence hayal kırıklığı burada: ajan iyi görünen işleri sever, kirli gerçek dünyayı ise pek sevmiyor — itiraf edeyim, beklentimin üstündeydi —
Eğer bugün benzer sistemi kuracak olsam, önce dar kapsamlı başlardım. Mesela yalnızca ticket’tan branch açıp test senaryosu öneren, PR özeti çıkaran ya da regresyon checklist’i oluşturan mini agent’larla. Tam özerklik yerine yarı özerklik… daha makul geliyor bana.
Sıkça Sorulan Sorular
AI agent ile normal chatbot arasındaki fark nedir?
Vallahi, Chatbot cevap verir; AI agent ise hedef alıp adımlar planlamaya çalışır (kendi tecrübem). Yani sadece konuşmaz, iş kovalar. Ama iş kovalamak demek, her zaman işi bitirmek demek değildir. Bu ayrımı gözden kaçırmayın.
AI agent’ler yazılım geliştirmede güvenilir mi?
Basit görevlerde epey faydalılar. Fakat entegrasyon, güvenlik ve kritik karar aşamalarında tek başına bırakmak risklidir. Ben hibrit modeli daha sağlıklı buluyorum: ajan yardım eder, insan onaylar.
Küçük ekipler için AI agent kullanmak mantıklı mı?
Evet, özellikle başlangıç aşamasında vakit kazandırabilir. Ancak kapsam büyüdükçe gözlemleme, versiyon kontrolü ve manuel inceleme şart olur. Yoksa hız kazanırken kaliteyi kaçırırsınız (ciddiyim). Farkında olmadan.
Bu tarz sistemlerde en büyük problem ne oluyor?
Genelde problem modelin zekâsından çok orkestrasyonda çıkıyor. Görev dağılımı, tool zinciri ve hata sonrası toparlanma zayıfsa sistem kendi etrafında dönmeye başlıyor. Kısacası asıl iş koordinasyonda.
Kaynaklar ve İleri Okuma
Bence, Orijinal Deney Yazısı
Gemini API Resmi Dokümantasyonu
Agentic Yapay Zekâda İz Sürmek: Monitor Et, Ölç, Kurtul
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.
