--- title: "AI agent'lar teknoloji seçiyor: ekipler ve vendor'lar ne yapmalı" description: "AI agent kod yazarken kütüphane ve aracı da seçiyor. Bu seçimi denetlemek ve belgeleri agent'a göre yazmak için uygulanabilir adımlar." image: "https://sezer.in/wp-content/uploads/2026/11/4242958-0-43738100-1793696527-prepare-your-workforce-for-AI-agents-shutterstock_2698018127-scaled.jpg" url: "https://sezer.in/haberler/ai-agent-teknoloji-secimi-aeo/" date: "2026-11-03T13:21:34+03:00" updated: "2026-11-03T13:21:34+03:00" author: "Sezer Şanlıkan" lang: "tr" source: "https://sezer.in/haberler/ai-agent-teknoloji-secimi-aeo/" --- # AI agent'lar teknoloji seçiyor: ekipler ve vendor'lar ne yapmalı AI agent'lar kod yazarken hangi kütüphane ve aracın kullanılacağına giderek daha sık kendileri karar veriyor. Anthropic'in 50 profesyonel analistle yaptığı çalışmada katılımcılar, gizlice rastgele tercihler verilmiş agent'ların yönlendirmesine dört analitik seçimde yüzde 86 oranında uydu. Microsoft, Supabase ve Google örnekleri, agent'ın okuduğu belgelerin uygulama tercihini değiştirebildiğini gösteriyor. ## AEO nedir, ne işe yarar? AEO (Answer Engine Optimization), içeriği LLM tabanlı asistanların ve agent'ların yanıtlarında görünür ve doğru aktarılır hâle getirmeyi hedefleyen optimizasyon yaklaşımıdır. Klasik SEO arama sonucu sıralamasına odaklanırken AEO, bir modelin soruya verdiği cevapta ürünün ya da belgenin önerilmesini hedefler. Yazılım vendor'ları, açık kaynak projeler ve geliştirici ilişkileri ekipleri bu yaklaşımı belge ve örnek kod tasarımında kullanıyor. ## AI agent önerisi neden fiilen bir karar Bu tartışmanın DevOps ekipleri için asıl karşılığı tedarik zinciri. Bir AI agent projeye kütüphane eklediğinde, siz dependency listesine bakana kadar etrafında çalışan kod çoktan birikmiş oluyor. Geri dönmek, yazılmış işi çöpe atmak demek. Çoğu ekip de o noktada agent'ın seçimiyle devam ediyor. Yüzde 86'lık oranı dikkatli okuyun. Çalışma analistlerle yapıldı, yazılım geliştiricilerle değil. Kod tarafına aynı oranı taşımak bir çıkarım. Ama yön açık: insanlar agent'ın ilk önerisine neredeyse her zaman uyuyor. Kaynakta geliştiriciye önerilen üç alışkanlık pratikte şöyle uygulanabilir: - Öneri istemeden önce kısıtları yazın: lisans politikası, desteklenen runtime sürümleri, kurum içi registry, onaylı kütüphane listesi. - Agent'a hangi kanıtın farklı bir seçeneği öne çıkaracağını sorun. - Kararın ağırlığı varsa alternatifleri, agent tek bir seçenek etrafında kod yazmadan önce karşılaştırın. ## Agent'a ne yapacağını değil, nedenini anlatın Microsoft'tan Garry Trinder'ın örneği platform ekipleri için öğretici. SharePoint Framework projesini yükselten agent, paket sürümlerini elle değiştirip duruyordu. Doğru yol CLI for Microsoft 365 aracını kullanmaktı. Belgeye doğrudan bir ipucu eklemek, agent'ı beş denemeden yalnızca birinde araca yöneltti. Yalnızca sürüm değiştirmenin build hatası üreteceğini açıklayan metin ise beş denemenin beşinde işe yaradı. Beş deneme küçük bir örneklem, yazı da bunu kabul ediyor. Yine de kurum içi runbook ve platform belgeleri için somut bir ders var. "Bunu elle değiştirmeyin" yazmak yetmiyor; elle değiştirince neyin kırıldığını yazmak gerekiyor. Agent bu gerekçeyi görünce planını düzeltiyor. Supabase'in deneyimi de güvenlik tarafına dokunuyor. Agent'lar ayrı referans dosyalarını bazen atlıyordu, bu yüzden şirket güvenlik yönergelerini ana talimatlara taşıdı. Agent'ları ezberdeki API bilgisi yerine güncel belgelere yönlendirdi. Kendi ekibinizde secret yönetimi ya da yetkilendirme kuralları ayrı bir dosyada duruyorsa, agent'ın bunları gerçekten okuduğunu varsaymayın. ## Talimat değişikliğini kod değişikliği gibi yönetin Google, Agent Skills tarafında her değişiklik için sürümleme, değerlendirme kanıtı, otomatik kontroller, AI incelemesi ve bir konu uzmanının onayını istiyor. Ancak bundan sonra içerik GitHub'a çıkıyor. Mantık basit: talimat değişikliği bir davranış değişikliği. Bu model şirket içinde de çalışır. Agent talimat dosyalarını repository'de tutun, değişikliği pull request ile alın, birinin onaylamasını şart koşun. Tek satırlık bir talimat düzeltmesi, agent'ın o andan sonra yazdığı her pull request'i etkiler. Etki alanı pipeline yapılandırmasından küçük değil. ## Agent'ın eklediği bağımlılığı yakalamak Agent'ın seçimini sonradan sorgulamanın en ucuz yeri pull request incelemesi. Manifest dosyalarındaki farkı ayrıca görmek, yeni bağımlılığı gözden kaçırmamayı kolaylaştırır: ``` git diff --stat main...HEAD git diff main...HEAD -- package.json go.mod requirements.txt ``` Yeni bir paket görünüyorsa üç soru sorun: neden bu, onaylı listede var mı, kurum içi registry üzerinden mi geliyor. Agent'ın ezberden yazdığı eski API çağrıları da en çok bu aşamada ortaya çıkıyor. ## Açık kaynak projeler ve vendor'lar için iki test Kendi projenizi ya da ürününüzü geliştiriyorsanız, Microsoft'tan Waldek Mastykarz'ın önerdiği ayrım işe yarar. Ürün adını geçirmeyen prompt'larla agent'ın sizi seçip seçmediğini ölçün. Ürün adını geçiren prompt'larla da yanıtın doğru olup olmadığını kontrol edin. Birincisi görünürlük, ikincisi doğruluk testi. Yazının en değerli önerisi, ürünün kazanmaması gereken durumları da test etmek. MongoDB'nin ilk yıllarında kurucu ortak Dwight Merriman, veritabanının iyi olduğu ve olmadığı alanları listeleyen bir sayfa istemişti. AEO (Answer Engine Optimization) yalnızca adınızın ne sıklıkla geçtiğini ölçerse, ürün başarısız olacağı uygulamalara girer ve güven kaybı size döner. Agent'ın desteklenmeyen bir deployment gereksinimini tanıyıp tanımadığını, müşterinin ölçeğinde önemli bir maliyet uyarısı verip vermediğini ayrı test senaryosu olarak yazın. Veritabanı vendor'ı için faydalı içerik, mevcut şemadan çalışan uygulamaya giden, yetkileri ve hata kurtarmayı içeren test edilmiş bir yol olabilir. API şirketi için ise retry'ları çift ücretlendirme yapmadan ele alan bir örnek. Agent'ın bu içeriği uygulama kararının verildiği anda bulabilmesi, altı ay önceki bir webinar'dan daha çok iş görür.