Bakın şimdi, AI ajanları konuşmayı iyi yapıyor diye iş bitmiyor. Hatta çoğu zaman işin en kolay kısmı o zaten. Asıl mesele, ajanın eline ne verdiğiniz — elinde doğru araç yoksa, model ister GPT olsun ister Claude, sonuçta pahalı bir tahmin makinesinden fazlası olmuyor ki (yanlış duymadınız). Geçen ay Kadıköy’de bir müşteri toplantısında bunu yine yaşadım; ekip “ajan neden yanlış cevap veriyor?” diye soruyordu ve cevap aslında çok basitti: Model kötü değildi, veriyle konuşamıyordu.
Bence, İşin aslı şu ki, agent tarafında büyülü bir şey arayınca hayal kırıklığı geliyor. Ben de 2024’ün — kendi adıma konuşayım — sonlarına doğru, bir Laravel projesinde kullanıcı izinlerini ve medya dosyalarını ajanla yönettirmeye çalışırken bunu net gördüm. Bir iki deneme yaptım, olmadı. Sonra küçük ama doğru tool’lar yazınca tablo değişti — işte tam o an anladım: Zekâ dediğimiz şey bazen modelde değil, modelin erişebildiği kapılarda saklı duruyor.
Ve işler burada ilginçleşiyor.
Ajanın Beyni Var Ama Eli Yoksa Ne Olur?
Bir AI modeli metin üretmeyi bilir. Cümle kurar, özet çıkarır, hatta bazen bayağı iyi mantık yürütür — bunu kimse inkâr etmiyor. Gel gelelim sizin uygulamanızda “admin rolünün hangi yetkileri var?” ya da “ürüne bağlı görseller hangileri?” gibi somut sorular sorulunca tek başına model duvara tosluyor (bu beni çok şaşırttı). Çünkü bu bilgi onun kafasında yok; sizin sisteminizde duruyor.
Ben bunu ilk kez geçen yıl Nişantaşı’nda bir SaaS paneli üzerinde test ettim. Ekip, destek ekibinin bazı rutin işlemleri ajanla hızlandırmasını istiyordu. Model her seferinde düzgün görünen ama yarım yamalak cevaplar verdi. Hani insan ilk bakışta “eh fena değil” diyor ama sonra loglara bakınca gerçek ortaya çıkıyor… Model tahmin ediyordu, doğrulamıyordu. İki farklı şey bunlar.
Ve işler burada ilginçleşiyor.
Aslında tam burada klasik fark çıkıyor ortaya. LLM size dil verir; tool ise aksiyon verir. Birini diğerine bağlamazsanız agent sadece konuşan bir sekreter olur. Kibar sekreter tabii… ama yine de sekreter.
Tool Tam Olarak Ne Yapar?
Laravel AI SDK tarafında tool dediğiniz şey çoğunlukla bir PHP sınıfı oluyor. Bu sınıfın içinde bir şema var; yani modelin doldurabileceği parametreler tanımlanıyor, sonra bir handle yöntemi geliyor ve orada gerçek iş yapılıyor: veritabanına sorgu atmak, izinleri çekmek, medya ilişkilerini okumak ya da eksik çevirileri listelemek gibi.
Bu yapı kulağa sade geliyor. Sade olmalı da zaten. Karmaşık olursa model şaşırıyor, geliştirici de saçını yoluyor (şaşırtıcı ama gerçek). Geçen sene İzmir’deki bir freelance projede tool’ları fazla genelleştirmiştim — sonuç tam felaket değildi ama beklediğim kadar iyi de değildi. Sonra her aracı tek iş yapacak şekilde küçülttüm; hem performans hem cevap kalitesi toparladı. Ciddi fark var.
class QueryPermissionsTool
{
public function schema(): array
{
return [
'action' => ['type' => 'string', 'enum' => ['list_roles', 'list_permissions', 'user_access']],
'user_id' => ['type' => 'integer', 'nullable' => true],
];
}
public function handle(array $arguments): array
{
// Gerçek uygulama mantığı burada çalışır
return match ($arguments['action']) {
'list_roles' => Role::query()->pluck('name')->all(),
'list_permissions' => Permission::query()->pluck('name')->all(),
default => $this->getUserAccess($arguments['user_id'] ? null),
};
}
}Neden Tek Bir Dev Tool Yetmiyor?
Bunu açık söyleyeyim. Büyük ve kapsayıcı tek araç fikri kağıt üstünde hoş duruyor ama pratikte çoğu zaman tökezliyor. Çünkü tool sayısı azaldıkça ajanın karar alanı genişliyor ve hata payı artıyor; mesela permissions ile media library aynı tool içinde birleşince model neyi ne zaman çağıracağını daha çok karıştırabiliyor. Neden mi? Çünkü şema geniş, seçenek fazla, bağlam bulanık.
Evet, doğru duydunuz.
Benzer şeyi kendi blog altyapımda da yaşadım. Ankara’daki ofiste otururken translatable içerikleri ve ayar kayıtlarını tek tool’da toplamayı denedim — evet, biraz tembellik yaptım. İki gün sonra geri döndüm. Çünkü kullanım desenleri ayrıydı: biri dil odaklıydı, diğeri konfigürasyon odaklıydı. Ayırınca hem promptlar kısaldı hem sonuçlar daha temiz geldi. Maalesef kısayol burada çalışmıyor (evet, doğru duydunuz) Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
| Yaklaşım | Artısı | Eksi tarafı |
|---|---|---|
| Tek büyük tool | Kod az görünür | Karmaşa artar, seçim hatası yükselir |
| Küçük uzman tool’lar | Daha isabetli çağrı | Başta daha çok plan ister |
| Karma yapı | Dengeli esneklik | Bakımı dikkat ister |
Küçük Startup ile Kurumsal Yapının Farkı
Küçük startup’ta genelde hedef hızlı hareket etmektir. Bir iki araç yazarsınız, destek ekibi rahatlar, satış tarafı birkaç işi otomatikleştirir ve tamamdır. Fazla mühendislik burada gereksiz bile olabilir — inanın, overengineering de kendi başına bir problem. Ama enterprise seviyesinde işler sertleşiyor: rol bazlı erişim var mı, audit log tutuluyor mu, hangi tool hangi tenant’a dokunabiliyor… bunların hepsi önemli hale geliyor ve bunları sonradan eklemek, baştan yazmaktan daha acı oluyor.
Şunu fark ettim: Neyse uzatmayalım… Startup’ta tolerans biraz yüksek olabilir ama kurumsalda “yanlış rol listesi verdi” demek ufak tefek hata sayılmaz. Ben bunu geçen kış Levent’te bir kurumsal demo sırasında gördüm; güvenlik ekibi ilk soru olarak “Bu tool permission bypass yapabilir mi?” dediğinde ortamın rengi değişti resmen. Haklıydılar da.
Tool’un gücü kod miktarında değil… doğru bağlandığı veri kaynağında gizli.
Lafı Gevelemeden: İyi Tool Nasıl Yazılır?
Bence burada üç şey öne çıkıyor: dar kapsam, temiz şema ve kontrollü çıktı formatı. Hepsi bu kadar mı? Evet, aslında bu kadar. Ajanınıza “her şeyi yapan” araç vermek yerine “tek işi düzgün yapan” araç verin; model ne kadar özgür görünse de aslında yönlendirmeye ihtiyaç duyuyor, bu değişmiyor.
- Tek amaç: Her tool yalnızca bir problemi çözsün.
- Açık isimlendirme: ListRoles ile UpdateEverything aynı cümlede olmamalı. — ciddi fark yaratıyor
- Sınırlı parametre: Gereksiz alanları şemadan çıkarın.
- Dönüş değerini sade tutun: Ham veriyi değil kullanılabilir cevabı verin.
- Erişim kontrolü: Tool öncesinde yetki katmanını unutmayın.
Bu yaklaşımı test ettiğimde en net fark hata oranında oldu. Mesela de doğal dille gelen isteklerde model artık daha az uydurmaya başladı — çünkü elindeki seçenekler sınırlanmıştı. İnsan beyni için de böyle değil mi zaten? Çok seçenek bazen kafa karıştırıyor.
Bak şimdi, Peki hiç eksisi yok mu? Var tabii. Tool sayısını artırdıkça bakım yükü büyüyor ve dokümantasyon ihtiyacı sıklaşıyor. Küçük ekiplerde bu sorun idare eder. Orta ölçek üstüne çıktığınızda düzen kurmazsanız ortalık kısa sürede çöplüğe döner. Uyarıyorum şimdiden. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Aynı Sorunu Farklı Şirket Ölçeğinde Düşünelim
Küçük ekipte en kritik ihtiyaç genelde hızdır. Mesela müşteri desteği için hazırladığınız ajan query_user_orders, check_subscription_status ve fetch_ticket_history gibi üç dört araçla bayağı iş görür. Eğer SaaS ürünü yeni doğuyorsa önce akışı halletmek gerekir; mükemmel mimariyi sonra cilalarsınız. Bu doğru bir yaklaşım. Daha fazla bilgi için Formlar Ölü Olmalı: React’te Neden Yaşatmayalım? yazımıza bakabilirsiniz. Daha fazla bilgi için Dijital Oyunlarda Yeni Vergi Dalgası: Türkiye’de Ne Değişiyor? yazımıza bakabilirsiniz.
Kurumsal tarafta ise oyun değişir. Entegrasyon sayısı artar, kimlik doğrulama sıkıdır ve veri sızıntısı korkusu boşuna değildir. Bir bankacılık demo’sunda bunu birebir gördüm; geliştiriciler çok sağlam bir agent deneyimi kurmuştu ama security ekibi araya girince herkes yavaşladı. Doğruydu da — yanlış tasarlanmış tek bir tool bile bütün sistemi riske atabiliyor. Bu abartı değil. Otomatik Pentest Yetmez: Webinarın Anlattığı Asıl Ders yazımızda bu konuya da değinmiştik.
Pratikte Ne Kazandırır?
Açıkçası, Birkaç somut fayda söyleyeyim:
- Daha az halüsinasyon (bu kritik)
- Daha güvenilir yanıt
- Daha net debug süreci
- Daha kolay ölçümleme
- Daha iyi kullanıcı deneyimi
Bunun tersini de söylemek lazım: çok fazla bağımlılık, fazla genel tanımlar, zayıf loglama — hepsi ajanınızı aptallaştırıyor. Acı ama gerçek bu.
Bende Kalan Ders Şu Oldu…
Bakın, Editör masasında bu konuyu incelerken aklıma hep aynı soru geldi: “Agent gerçekten akıllandı mı?” Açıkçası %100 emin değilim. Sanırım cevap şu — hayır, sadece çevresi zekileşti. Araçlar iyiyse model de iyi görünüyor. Araçlar zayıfsa en parlak model bile sırıtıyor. Bu kadar basit aslında.
İlginç olan şu ki, Londra’da yaşayan bir geliştirici arkadaşım geçen yaz kendi Laravel projesinde benzer şeyi yaptı. Spatie Permission için küçük bir wrapper yazdı, Media Library için ayrı, Translatable için ayrı. Üç ay sonra bana dönüş yaptı: “Destek — en azından ben öyle düşünüyorum — talepleri yüzde 40 düştü.” İnanamadım demeyeyim… bayağı inandım aslında, çünkü doğru problem ayrımı yapılmıştı. Sayılar yalan söylemez.
Sık Sorulan Sorular
AI ajan tool’u nedir, basitçe ne işe yarar?
Tool, modelin dış sistemlerle konuşmasını sağlayan yapıdır. Model kendi başına veritabanınıza, API’nize ya da dosya sisteminize erişemez; tool bu köprüyü kurar. Olmadan model tahmin eder, varken doğrular. Fark büyük.
Laravel’de tool yazmak zor mu?
Hayır, zor değil. Bir PHP sınıfı, bir şema tanımı ve bir handle metodu yeterli. Asıl zorluk teknik değil; hangi tool’un ne yapacağına karar vermek (yanlış duymadınız). O karar yanlış gidince teknik taraf ne kadar temiz olursa olsun sonuç tökezliyor (inanın bana)
Kaç tane tool kullanmalıyım?
Vallahi, Bunu net söylemek zor. Kural şu: ne kadar az, o kadar iyi — tabii ki ihtiyaçlarınızı karşıladığı sürece. Çok sayıda tool modeli şaşırtır, çok az tool ise yetersiz kalır. Küçük projeler için 3-6 arası genelde yeterli; kurumsal yapılarda bu sayı büyür. Her birinin sorumluluğu yine de net olmalı.
Tool güvenliği nasıl sağlanır?
Tool çalışmadan önce yetki kontrolü yapın. Kim çağırıyor, hangi tenant, hangi rol — bunları doğrulayın. Sonrasında loglayın; hem debug için hem de ileride “ne oldu?” sorusuna cevap vermek için. Bu adımı atlayanlar genellikle pişman oluyor (ki bu çoğu kişinin gözünden kaçıyor)
Startup ile kurumsal arasında tool mimarisi nasıl farklılaşır?
Startup’ta hız önceliklidir, birkaç basit tool işi görür. Kurumsalda ise multi-tenant izolasyonu, — itiraz edebilirsiniz tabi — audit logging ve rol bazlı erişim zorunlu hale gelir. Aynı tool kodu farklı katmanlarla sarılır. Geç kalırsanız refactor maliyeti katlanıyor — erken düşünmek daha az acıtıyor.
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.
