Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor?
Geçen hafta, bir müşteride tam da şu soruyu konuştuk: “Copilot’u neden uygulamanın içine gömüyoruz, zaten dışarıda çalışsa olmuyor mu?” Açık konuşayım, bazen oluyor. Ama bazen de olmuyor. Hele bir de işin içine çok adımlı akışlar, dosya okuma-yazma, onay mekanizması ve canlı yanıt deneyimi girince (kendi tecrübem). orada tablo değişiyor.
Garip gelecek ama, GitHub Copilot SDK’nın public preview’a açılması bence bu yüzden önemli. Çünkü mesele sadece bir model çağırmak değil; ajan davranışını, araç kullanımını. Oturum mantığını doğrudan kendi ürününe taşımak. Yanı “AI var” demekle kalmıyorsun, önü gerçekten iş yaptıran bir katmana dönüştürüyorsun. Bu biraz şuna benziyor: motoru dışarıdan kiralamak yerine kaputun altına yerleştiriyorsun.
Şimdi gelelim işin can alıcı noktasına.
Ben Azure tarafında yıllardır mimarı kurarken hep aynı şeyi gördüm: en pahalı kısım genelde model değil, etrafındaki orkestrasyon oluyor. 2024’te Logosoft’ta bir finans kuruluşu için tasarladığımız yardım masası akışında da bunu yaşamıştık; kullanıcı sorusunu alıp doğru aracı seçmek, log okumak, gerekiyorsa ticket açmak. Her adımı izlenebilir tutmak beklediğimizden daha uğraştırıcıydı. İşte SDK’nın verdiği şey biraz da bu yükü hafifletmek.
Neden şimdi önem kazandı?
Aslında, Şimdi gelelim esas meseleye. AI ajanları son iki yılda bayağı popüler öldü ama çoğu ekip aynı duvara çarptı: prototip hızlı çıkıyor, üretim ortamı işe başka hikâye anlatıyor. Prompt güzel yazılıyor ama tool çağrıları yarıda kalıyor; streaming yoksa kullanıcı beklemekten sıkılıyor; permission yoksa güvenlik ekibi kaşlarını kaldırıyor.
Şimdi gelelim işin can alıcı noktasına.
Copilot SDK burada “ben bunların çoğunu zaten düşünmüşüm” diyor gibi. Ben buna kötü demem — hatta iyi tarafı şu ki ekipler artık temel altyapıya daha az vakit harcıyor. Ama bir hayal kırıklığı kısmı da var: public preview olduğu için bazı alanlarda hâlâ hamlık hissi gelebilir. Kağıt üstünde süper duran şeylerin prod’da nasıl davrandığını biz sahada defalarca gördük; o yüzden temkinli olmakta fayda var. Bu konuyla ilgili PowerShell 7.6 Neden Geç Geldi? Perde Arkası ve Dersler yazımıza da göz atmanızı tavsiye ederim. GitHub Codespaces’ta Veri Yerleşimi: Kurumsalda Ne Değişti? yazımızda bu konuya da değinmiştik.
AZ-305’e hazırlanırken de benzer bir zihniyet kullanmıştım aslında: teknoloji ne kadar parlak görünürse görünsün, önce kim kullanacak, hangi veri geçecek, nerede log tutulacak diye bakarsın. Burada da aynı refleks lazım. Küçük startup ile enterprise arasında fark devasa olabilir.
Küçük ekipler için
Küçük ekiplerde Copilot SDK bayağı iş görüyor çünkü hızlı sonuç aldırıyor. Bir Node.js ya da Python servisinin içine koyup birkaç özel tool tanımladığınızda kısa sürede çalışan bir ajan elde ediyorsunuz. Hatta bazen fazla mühendislik yapmadan MVP çıkarabiliyorsunuz.
Ama dikkat: küçük ekipler genelde “önce çalışsın sonra düzeltiriz” modunda gidiyor… işte orada borç büyüyor. Tool izinleri gevşek bırakılırsa veya prompt katmanı baştan sona ölçülmezse ileride toparlamak zorlaşıyor. Bu konuyla ilgili GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımıza da göz atmanızı tavsiye ederim.
Büyük kurumlar için
Enterprise tarafında işe olay farklı oynuyor. Burada BYOK desteği kıymetli çünkü bazı kurumlar — en azından ben öyle düşünüyorum — OpenAI anahtarını kendi yönetmek istiyor, bazıları Foundry" data-glossary-term="Azure AI Foundry">Azure AI Foundry üzerinden gitmek istiyor, bazıları Anthropic’i bile gündeme alabiliyor (evet). Sız ne dersiniz? Böyle ortamlarda seçim esnekliği ciddi avantaj sağlıyor. Bu konuyla ilgili Python Eklentisinde Mart 2026: Hız, Arama ve Küçük Sürprizler yazımıza da göz atmanızı tavsiye ederim.
Bir telekom müşterisinde 2025’in sonlarına doğru yaptığımız PoC’de en büyük tartışma model kalitesi değildi; veri izi ve kontrol mekanizmasıydı. Kim neyi tetikledi? Hangi tool çalıştı? Hangi prompt parçası eklendi? Bunlar net olmayınca güven kazanmak zorlaşıyor. Bu konuyla ilgili copilot konusundaki yazımız da göz atmanızı tavsiye ederim.
| Konu | Küçük Startup | Enterprise |
|---|---|---|
| Süreç hızı | Çok hızlı deneme yapılır | Daha yavaş ama kontrollü ilerlenir |
| Güvenlik ihtiyacı | Orta seviye yeterli olabilir | Sıkı izin ve izleme gerekir |
| Anahtar yönetimi > |
Bazen basit tutulur
> |
BYOK ve merkezî politika tercih edilir
> |
| Efor dağılımı > |
Proukt geliştirme ağırlıklı
> |
Mimarı + uyum + operasyon dengesi
> |
Copilot SDK’nın elindeki güçlü parçalar
ve neden işe yarıyor?
Copilot SDK’nın bana göre en sağlam yanı custom tools konusu. Domain’e özel araç tanımlayıp ajanın ne zaman hangisini çağıracağına karar vermesine izin veriyorsun. Bu kulağa basit geliyor ama pratikte çok kritik; çünkü insan gibi düşünsün derken saçmalamasını istemezsin.
Bunun yanında fine-grained system prompt özelleştirmesi hoşuma gitti diyebilirim—replace, append, prepend ya da transform callback ile tüm prompt’u baştan yazmadan ince ayar yapabiliyorsun. Ben açık söyleyeyim, komple prompt’u kopyala-yapıştır eden çözümlerden pek hoşlanmıyorum; bakım maliyeti hemen şişiyor.
// Basit örnek mantık
const agent = createAgent({
instructions: {
prepend: "Kurumsal destek asistanısın.",
append: "Yanıtlarında kısa özet ver."
},
tools: [
{
name: "getIncidentStatus",
readOnly: true,
handler: async ({ id }) => fetchStatus(id)
}
]
});
E tabiî streaming tarafını unutmamak lazım. Token token yanıt gelmesi özellikle kullanıcı deneyimini ciddi rahatlatıyor. Bekleme ekranına bakıp iç geçiren kullanıcı sayısı azalıyor, bu küçücük detay gibi dürüyor ama saha etkisi büyük.
Dikkat çeken teknik noktalar
başka neler?
- Blob attachments: Ekran görüntüsü ya da binary dosyayı diske yazmadan gönderebiliyorsun. — bunu es geçmeyin
Riskli işlemleri onaya bağlayabiliyorsun. - Tam oturum desteği: Multi-turn senaryolarda sohbet kopmuyor.
Evet.
Bu son maddeyi özellikle seviyorum çünkü birçok demo ilk mesajda şahane görünür ama ikinci turda tökezler.
- Bir de şu var:
open telemetry desteği kağıt üstünde sıradan durabilir ama gerçek hayatta hayat kurtarıyor.
2023’te benzer tracing eksikliği yüzünden iki gün boyunca niye yanlış araca gidildiğini anlamaya çalışmıştık.
O gün bugündür izlenebilirlik benim gözümde lüks değil,
zorunluluk.Gel gelelim kusursuz mu?
Değil.
Public preview olması nedeniyle dokümantasyonla kod arasında ufak sürprizler çıkabilir.
Normal.
Hatta beklenen şey bu biraz.Dil seçimi meselesi:
herkes için seçenek olması neden önemli?
Copilot SDK beş dilde geliyor olmasıyla geniş kitleyi hedefliyor:
Node.js/TypeScript,
Python,
Go,
.NET
ve Java.
Bu çeşitlilik boşuna değil.
Kurumsalda kimi takım.NET ile akar,
kimi platform ekibi Go sever,
kimi data ekibi Python’dan vazgeçmez….NET cephesinde özellikle ilgimi çekti çünkü Azure projelerinde sık kullandığımız yapı taşlarıyla doğal biçimde örtüşüyor.
Java tarafının Maven üzerinden yeni gelmesi de güzel haber;
bazı büyük organizasyonlarda Java hâlâ ana omurga olduğu için bu destek gerçekten önemli.
Ha bu arada,
bir müşteri toplantısında geçen ay biri aynen şunu dedi:
“Bizde Java yoksa proje yok.”
Gülümsedim tabiî,
ama haklıydılar da.2019’da kendi lab ortamımda benzer ajan orkestrasyonu denemeleri yaparken dil uyumluluğu yüzünden zaman kaybetmiştim;
o yüzden böyle çoklu dil desteğini küçümsemiyorum artık.Aslında — dur bir saniye —
önce şunu söyleyeyim:
dilin kendisi kadar runtime davranışı daha kritik.
Yanı API yüzeyi tamam olsa bile retry politikası,
stream handling ve timeout yönetimi zayıfsa bütün güzellik boşa gider.Beni en çok düşündüren nokta:
güvenlik ve kontrol çizgisi
nerede başlıyor?
Ajanlara güç verirken sınırı iyi çizmezseniz…
bir süre sonra sistem sizin için çalışan araç olmaktan çıkıp sizi yöneten garip bir otomasyona dönebiliyor.
Bunu abartmıyorum.
Sahada gördüm.
Buradaki fark küçük görünür ama operasyonel etkisi bayağı büyük olur.Asıl mesele sadece yetki vermek değil;
hangi durumda geri çekileceğini de öğretmek.
Read-only tool kavramını önemsiyorum çünkü bazı işleri hiç onaya sormadan okutmak mümkünken,
bazıları mutlaka approval handler üzerinden gitmeli.
Mesela de finans,
sağlık veya kamu gibi sektörlerde bu çizgi incecik.Ben AZ-500 sınavına hazırlanırken sürekli aynı prensibe dönüyordum:
least privilege.
Burada da durum farklı değil.
Mesela rapor okuyan agent ayrı,
ticket açan ayrı,
silme yapan ayrı olmalı.
Tek ajan her şeyi bilsin dersen kolaylık kazanırsın belki;
ama risk faturası yükselir. - Bir de açık konuşayım:
BYOK kulağa özgürlük gibi geliyor ama anahtar yaşam döngüsünü düzgün yönetmezsen baş ağrıtır.
Anahtar rotasyonu,
secret storage,
audit trail…
Buralar ihmal edilirse oyuncak hızla kurumsal kabusa dönebilir.Nereden başlamalı?
Pratik yol haritası fena olmazdı
di mi?
- MVP kapsamını dar tut:
tek iş akışı seç, örneğin issue triage veya doküman özetleme.Sadece gerekli tool’ları tanımla;
fazlasını sonra eklersin.Pozitif test kadar negatif test de yaz;
ajan yanlış kararı nasıl veriyor gör.Proudction’a çıkmadan önce permission akışını gerçek veriyle dene. - Neyse uzatmayalım:
ilk sürümü mükemmel yapmak zorunda değilsin.
Ama ölçülmeyen şeyi iyileştiremezsin;
özellikle ajan dünyasında hiç.Geçen ay Ankara’daki bir müşteride bunu birebir konuştuk.
Onlar önce tek bir destek senaryosuyla başladılar,
iki haftada kabul kriterlerini netleştirdiler,
sonra ikinci use case’i eklediler.
Sonuç？
Hem ekip morali yükseldi hem de güvenlik incelemesinden daha rahat geçtiler.
Bu tarz kontrollü yayılım bence altın değerinde.Sıkça Sorulan Sorular
Copilot’u uygulamanın içine gömmek ne zaman gerçekten işe yarıyor?
Copilot dışarıda çalışır gibi görünse de çok adımlı akışlarda durum değişiyor. Dosya okuma-yazma, onay mekanizması ve canlı yanıt deneyimi gibi parçalar uygulama içinde daha kontrol edilebilir oluyor. Böylece model çağırmaktan öte, ajan davranışını uçtan uca yönetiyorsun.
Copilot SDK’nın “sadece prompt atmak”tan farkı tam olarak ne?
Copilot SDK, tool invocation, streaming ve multi-turn session gibi temel iskelet parçalarını hazırlıyor. Ayrıca izin (permission) çerçevesini de düşünerek akışın güvenli ve izlenebilir kalmasına yardım ediyor. Yani “cevap üret” değil, “araçlarla iş yaptır” tarafını hızlandırıyor.
Neden Copilot SDK’nın public preview olması bazı ekipler için risk yaratabiliyor?
Public preview olduğu için bazı alanlarda beklenen davranışlar tam oturmamış hissi verebiliyor. Prod ortamında gerçek kullanıcı trafiği, farklı veri türleri ve güvenlik kontrolleriyle detaylar ortaya çıkıyor. Bu yüzden temkinli ilerlemek ve küçük denemelerle doğrulamak önemli.
Küçük ekipler ile büyük kurumlar Copilot SDK’yı nasıl farklı kullanıyor?
Küçük ekipler genelde Node.js ya da Python servisinin içine birkaç özel tool tanımlayıp hızlı MVP çıkarıyor. Büyük kurumlarda ise BYOK desteği ve daha sıkı izin/denetim gereksinimleri öne çıkıyor. Bu yüzden küçük ekipte hız kazanılırken, enterprise tarafında yönetişim ve loglama daha kritik hale geliyor.
Kaynaklar ve İleri Okuma
- Azure AI Foundry / Azure OpenAI Service Dokümantasyonu — Azure’da OpenAI tabanlı çözümler için resmî başlangıç ve mimarı referanslar.
- Microsoft Copilot Platform (resmî dokümantasyon) — Copilot ekosistemi ve geliştirme yaklaşımı hakkında genel resmî kaynak.
- GitHub Copilot Dokümantasyonu — GitHub Copilot’un yetenekleri ve entegrasyonlara dair resmî rehber.
- GitHub Copilot Özellikler Sayfası — Copilot’un araç kullanım/akış odaklı yeteneklerini hızlıca anlamaya yardımcı resmî sayfa.
Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim26 Nis 2026.NET Modernizasyonunda Yepyeni Bir Dönem: GitHub Copilot ile İstediğin Yerden20 Mar 2026GitHub Issues ve Projelerde Ajan Aktivitesi: Gerçekten Ne Değişti?29 Mar 2026GitHub Güvenliği: Küçük Repoda Büyük Açıkları Kapatmak30 Mar 2026Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder