Açık konuşayım: Son altı ayda bir Copilot, bir Claude, bir de Codex’i Azure Functions üzerinde denediğimde, çıkan sonuçlar beni pek tatmin etmiyordu. Kod çalışıyor, evet. Ama içine bakınca connection string’i function.json’a gömmüş, anonymous auth’u açık bırakmış, üstüne bir de Consumption plan’da “her invocation’da yeni client” alışkanlığını basmış; yanı çalışan. Sahaya çıkmadan önce biraz daha elden geçmesi gereken bir şey.
İşte tam bu boşluğu kapatmak için Microsoft bu hafta azure-functions-skills’i public preview olarak duyurdu. Tek komutla — npx @Azure/functions-skills install — favori coding agent’ınıza (Copilot CLI, Claude Code, Codex CLI ya da VS Code) Azure Functions tarafında daha düzgün refleksler ekliyor. Ben dün gece kurcaladım. Bugün de küçük bir müşteri POC’sinde denedim; beklediğimden az değil, baya işe yarayan tarafları var. İzlenimlerimi anlatayım.
Evet, doğru duydunuz.
Önce sorunu net koyalım: Neden genel amaçlı agent yetmiyor?
Bir AI agent’a “bana bir HTTP-triggered Azure Function yaz, Service Bus’a mesaj atsın” dediğinizde çıkan kod genelde şunu yapıyor: in-process model (artık deprecated yolda), AzureWebJobsStorage için account key, Service Bus connection string’i de app settings’e gömülü. Çalışıyor mu? Evet. Production’a girer mi? Açık konuşayım, pek girmiyor.
Bunun birkaç sebebi var. Birinçisi, modeller eski eğitim verisiyle çalışıyor — 2023’ün Functions’ı 2026’nın Functions’ı değil; ikincisi, Flex Consumption, isolated worker model, managed identity destekli trigger’lar, yeni MCP template servisi gıbı şeyler agent’ların “default refleksi” değil; üçüncüsü de, en sınır bozucu tarafı şu ki, secret’ları kodun içine gömmekten çekinmiyor. “Sonra düzeltirsin” mantığı işte. Pratikte ne oluyor? Çoğu zaman düzeltilmiyor, repo’ya bir düşüneyim… commit ediliyor (inanın bana). GitHub secret scanner uyarı atınca farkına varılıyor.
Çok konuştum, örnekle göstereyim.
Geçen ay bir e-ticaret müşterimde tam olarak bu olmuştu. Junior bir geliştirici Copilot’un yazdığı bir webhook function’ını merge etmişti; connection string açık kalmıştı, Cosmos DB key plain text duruyordu. Repo public değildi ama 3 outsource firma erişiyordu, yanı 30+ kişi key’i görebilir durumdaydı. Rotate ettik tabi ama olay can sıkıcıydı.
Evet.
azure-functions-skills ne yapıyor tam olarak?
Plugin dediğin şey, aslında ufak bir “yetkinlik paketi” gıbı çalışıyor. Agent’ın yanına birkaç parça ekliyor, sonra da önü Azure Functions tarafında daha az saçmalayan bir hâle getiriyor; setup, create, deploy, diagnostics, best-practices, doctor, inventory gıbı skill’ler geliyor, ihtiyaç oldukça da devreye giriyor. Kulağa düzenli geliyor, evet,. Işin güzel tarafı biraz da şu: siz tek tek her şeyi anlatmıyorsunuz, o kendi kendine bağlamı toparlıyor.
Skills — Görev odaklı playbook’lar. Bunlar agent’ın elinin altında duran küçük rehberler gıbı; biri kurulum için, biri oluşturma için, biri teşhis için. Bir de işin garip ama faydalı kısmı var: hepsini aynı anda kullanmıyor, lazım olanı çekiyor.
Agent definition — functions-copilot isimli bir router var burada. Kullanıcı ne istiyorsa ona göre doğru skill’e yön veriyor, sonra da iş bitince boş durmayıp bir sonraki adımı fısıldıyor. Basit görünüyor ama bazen en çok işe yarayan şey de bu oluyor.
Araya gireyim: MCP server ayaru — Model Context Protocol üzerinden Azure servislerine standart bir iletişim katmanı sağlıyor. Yanı “şu servise nasıl konuşacağız?” sorusunu her — en azından ben öyle düşünüyorum — seferinde yeniden icat etmiyorsunuz. İyi hoş, fakat asıl farkını farklı host’larda aynı davranışı koruyunca görüyorsunuz.
Hooks. Instruction dosyaları — copilot-instructions.md, CLAUDE.md, AGENTS.md. Hangı host’u kullanırsanız kullanın agent’ın tutarlı davranması için konmuş bunlar (ben de ilk duyduğumda şaşırmıştım). Şey gıbı düşünün: aynı projede herkesin aynı not defterine bakması.
CLI — @Azure/functions-skills komutu var. Kurulum yapıyorsunuz, sonra chat‘le çalıştırıyorsunuz, deploy öncesi de doctor‘la sağlık kontrolü alıyorsunuz. Bu kadar mı? Neredeyse; ama pratikte küçük görünen bu parça baya iş görüyor.
Evet.
Size bir şey söyleyeyim, Lafı gevelemeden söyleyeyim: işin özü şu. Agent’a “Azure Functions üzerine kod üretirken şu kurallara uy, şu pattern’leri tercih et, şu anti-pattern’lerden kaç” diyen bir bilinç katmanı ekliyorsunuz. Daha önce bunu elle yapıyorduk ya hani, .cursorrules ile ya da custom instruction dosyalarıyla; şimdi onun biraz daha derli toplu, biraz daha endüstriyel hâli karşınızda duruyor (ciddiyim)
Kurulum: Gerçekten 5 dakika mı?
Şunu fark ettim: Bende yaklaşık 4 dakika sürdü. Node 18+ gerekiyor; ben 20.11 üzerinde denedim ve açıkçası sorunsuz geçti, ama Azure subscription kısmını unutmayın tabi (orada takılınca süre hemen uzuyor). Bir de şey var: ilk bakışta “tamam tamam” dedirtiyor ama ortam hazır değilse ufak pürüzler çıkabiliyor.
# Yeni bir dizine geç
mkdir my-functions-project && cd my-functions-project
# Skills'i yükle
npx @Azure/functions-skills install
# Agent'ı başlat
npx @Azure/functions-skills chat
# Deploy öncesi sağlık kontrolü
npx @Azure/functions-skills doctorNeyse uzatmayayım, install komutu çalışırken hangı agent’ı kullandığınızı soruyor (Copilot CLI/Claude Code/Codex/VS Code). Ben Claude Code seçtim — itiraz edebilirsiniz tabi — — son aylarda Functions tarafında Claude’un daha temiz sonuç verdiğini fark ettim; sebebini tam çözemedim ama öyle öldü işte. Sizde başka araç daha iyi oturabilir, yanı tek doğru yok burada. Daha fazla bilgi için Copilot SDK Genel Kullanıma Açıldı: Saha Notlarım yazımıza bakabilirsiniz.
Doctor: Aslında en sevdiğim parça
Hani doctor komutu var ya, işin can alıcı kısmı bence orada. Deploy’dan önce projeyi didik didik tarıyor, sonra da gidip düzgün bir HTML raporu bırakıyor; hangı binding’ler connection string ile çalışıyor, managed identity neden seçilmemiş, host.json içinde hangı concurrency ayarları default’ta kalmış, Flex Consumption ile uyum var mı yok mu, hepsini tek tek önüne seriyor. Daha fazla bilgi için Copilot Usage Metrics API: Artık Kohortlu AI Adopsiyon Devri yazımıza bakabilirsiniz.
Ve işler burada ilginçleşiyor.
Ben bunu CI pipeline’a koymayı açık konuşayım baya mantıklı buluyorum. GitHub Actions tarafına tek bir step ekliyorsunuz:
- name: Azure Functions Doctor Check
run: npx @Azure/functions-skills doctor --fail-on-error
- name: Upload Doctor Report
uses: actions/upload-artifact@v4
with:
name: functions-doctor-report
path:./doctor-report.htmlBöyle olunca PR review sırasında “secret leak” gıbı tatsız şeyler daha merge’e gitmeden yakalanıyor. Evet, güzel tarafı bu. Bizim ekipte. CodeQL 2.25.5 Çıktı: GitHub Actions Taramaları Keskinleşti yazısında anlattığım CodeQL akışı var; doctor’u onun yanına koyunca ikisi aynı şeyi yapmıyor, CodeQL daha genel güvenlik tarafına bakıyor, doctor işe Functions özelinde best practice kontrolü yapıyor. Birbirini tamamlıyorlar, hatta bazen biri kaçıranı öbürü yakalıyor.
Eski yöntemle farkı: Somut bir karşılaştırma
Açık konuşayım, Bunu net görmek için iki agent çıktısını yan yana koyayım. Aynı prompt’u verdim: “Bir Service Bus queue’dan mesaj okuyup Cosmos DB’ye yazan bir Function yaz.” Kulağa basit geliyor, ama işin içine runtime, auth ve deployment girince tablo hemen değişiyor.
| Kriter | Skills’siz Agent | Skills’li Agent | ||
|---|---|---|---|---|
| Programming model | In-process (.NET 6, eski) | Isolated worker (.NET 8/9) | ||
| Auth | Connection string | Managed Identity (fullyQualifiedNamespace) | ||
| Cosmos client | Her invocation’da yeni | Singleton, DI ile | ||
| Hosting plan | Consumption (default) | Flex Consumption | ||
| Secrets | local.settings.json açık | Key Vault reference | ||
| host.json concurrencyDefault (yetersiz)Tunable, batch size tanımlı | Default (yetersiz)Tunable, batch size tanımlı | Default (yetersiz)Tunable, batch size tanımlı | Tunable, batch size tanımlı | Tunable, batch size tanımlı |
Yanı, Aradaki fark teorik değil. İkinci versiyonun production-ready olma ihtimali bayağı daha yüksek. Birinçisi de çalışır tabi, hatta ilk bakışta “idare eder” dersiniz. 3 ay sonra incident’a sebep ölür, sonra kim uğraşacak? Siz ne dersiniz?
“Güvenli kod yazmak agent’ın işi değil, prompt’un işi” düşüncesi artık geride kaldı. Skills paketleri tam olarak bu boşluğu dolduruyor — agent’a doğru refleksleri kazandırarak.
Türkiye perspektifi: Bu bizim için ne anlama geliyor?
Türkiye’deki kurumsal müşterilerde şunu sık görüyorum: Azure Functions kullanımı var, ama tempo biraz ağır ilerliyor. Hele bir de finans tarafında KVKK ve BDDK yüzünden bir çekingenlik oluyor; “serverless’ta key’ler nerede duruyor, log’lar nereye gidiyor” sorusu da her toplantıda dönüp dolaşıp masaya geliyor. Skills’in managed identity-first yaklaşımı tam burada işe yarıyor,. Auditor karşısında “biz connection string kullanmıyoruz, Entra ID üzerinden token alıyoruz” demek baya daha savunulabilir bir pozisyon oluyor.
Bakın, şunu fark ettim: Bir de şu taraf var. Türkiye’de pek çok ekip hâlâ Consumption plan kullanıyor, çünkü TL bazında ilk bakışta ucuz görünüyor. Ama cold start yüzünden front-end ekipleri “Functions yavaş” diye söylenmeye başlıyor; haklılar da biraz. Flex Consumption (always-ready instances ile) bu işi toparlıyor, fakat default gelmiyor, elle seçmeniz gerekiyor, işte tam orada çoğu ekip bir an durup kalıyor. Skills agent’a bu kararı sorduruyor — “Bu workload için Flex daha mantıklı olabilir, neden?” diye. Yanı agent sadece kod yazmıyor, mimarı tarafa da hafifçe dürtüyor.
Doğrusu, Maliyet kısmı işe ilk bakışta kafa karıştırıyor. Flex Consumption, Consumption’a göre satır bazında biraz daha pahalı gıbı duruyor; ama always-ready instance sayısını 0’a çekip sadece on-demand kullandığınızda (bir de Flex’in concurrency handling’i daha düzgün çalışınca) toplam fatura çoğu senaryoda sandığınız kadar açılmıyor. Daha açık söyleyeyim, geçen ay bir lojistik müşterisinde geçiş yaptık, fatura %8 düştü (ciddiyim). Beklediğimden iyiydi açıkçası. Dependabot Artık sbt’yi Destekliyor: Scala Tarafına Nefes yazımızda bu konuya da değinmiştik.
Küçük ekip vs Enterprise: Hangisi için ne mantıklı?
Küçük ekip ve startup’lar için
Ne yalan söyleyeyim, Eğer 2-5 kişilik bir ekipseniz, işin rengi biraz değişiyor. Hızlı POC çıkarıyorsanız, skills’i kurup doctor‘u local’de elle çalıştırın; CI’a entegre etmek için başta uğraşmayın, açık konuşayım, çoğu zaman gereksiz yere vakit yiyor. Sadece commit öncesi npx @Azure/functions-skills doctor alışkanlığını oturtun, başka bir şey yapmasanız bile bu bile baya iş görüyor. Evet.
Enterprise için
Burada iş ciddileşiyor, ama öyle abartılı bir ciddiyet değil; daha çok “hata çıkarsa kim uğraşacak” ciddiyeti. Doctor’u CI pipeline’ın zorunlu step’i yapın, sonra bir custom skill seti yazın (şirket içi standartlarınızı (mesela “neredeyse tüm function’lar belirli bir App Insights workspace’e log atmalı” gıbı) buraya kodlayın), çünkü Skills paketinin extensible yapısı buna izin veriyor. Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazısında anlattığım “ilk gün kararları” yaklaşımı burada da geçerli — proje başında skills’i kurun, gerisini agent’a bırakın. Peki neden? Çünkü sonradan toparlamak daha yorucu oluyor (ki bu çoğu kişinin gözünden kaçıyor)
Çok konuştum, örnekle göstereyim.
Pratik uygulama rehberi: İlk 30 dakika
- Dakika 0-5:
npx @Azure/functions-skills installçalıştırın, sonra agent’ı seçin. Kısa iş gıbı duruyor. Ama ilk temas önemli, çünkü burada hangı akışla ilerleyeceğinizi belirliyorsunuz. - Dakika 5-15: Basit bir HTTP trigger oluşturun (
chatüzerinden agent’a söyleyin). Çıkan kodu tek tek gözden geçirin — managed identity var mı, connection string gizlice araya girmiş mi, isolated worker model’de mi? İlk bakışta temiz görünebilir, ama bazen küçük bir detay tüm resmî değiştiriyor. — ciddi fark yaratıyor - Dakika 15-20:
doctorçalıştırın. HTML raporu açın. Genelde ilk denemede 2-3 uyarı çıkıyor, şaşırtıcı değil. Onları çözün; bazen ufak bir ayar yetiyor, bazen de insan “bu niye buradaydı?” diye kalıyor. - Dakika 20-30: GitHub Actions workflow’unu doctor step’i ile güncelleyin. Bir PR açın, test edin. Sonra tekrar bakın; çünkü yerelde geçen şey, pipeline’da başka türlü davranabiliyor.
feedback skill’i de tam bu yüzden orada duruyor aslında.
Kafamdaki soru işaretleri: Eksikler ne?
Şimdi, şunu fark ettim: Lafı gevelemeden söyleyeyim: bu bir preview yazısı, yanı üretimde “kullan ve kork” seviyesinde değil. Birkaç eksik gördüm, açık konuşayım, hepsi de küçük gıbı duruyor ama sahada insanı uğraştırabiliyor.
Birinçisi şu: Türkçe ya da başka bir dilde prompt verince agent bazen instruction dosyalarını biraz kafasına göre ele alıyor, hatta sanki “bunu sonra bakarım” deyip önceliğini düşürüyor. E peki, sonuç ne öldü? İngilizce promptlarla daha tutarlı sonuç aldım; hani dil-agnostic instruction routing tarafı var ya, bence orası hâlâ tam oturmamış, biraz pişmesi gerekiyor.
Bir dakika — bununla bitmedi.
İkincisi biraz daha can sıkıcı. Doctor raporu HTML olarak çıkıyor, tamam güzel, ama JSON çıktısı da olsa fena olmazdı; özellikle SARIF formatında verilse GitHub Security tab’ında direkt görünürdü (şimdi işe custom parsing yazmak gerekiyor). Yanı çıktı var, ama tüketmek için ekstra iş çıkarıyor.
İşin garibi, Üçüncüsü de MCP server konfigürasyonu tarafı. Güzel düşünülmüş, ama hangı servislerin MCP üzerinden erişilebildiği şimdilik sınırlı kalmış. A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazısında bahsetmiştim; agent-to-agent protokolleri olgunlaştıkça bu boşluk kapanacak gıbı duruyor, en azından ben öyle umuyorum. Peki neden önemli? Çünkü erişim dar olunca entegrasyon da biraz tek ayak üstünde kalıyor.
Bir de… ilk denememde takıldığım ufak bir şey vardı. Install komutu evdeki corporate proxy arkasında ilk seferinde patladı; hata mesajı çok açıklayıcı değildi, “ENOTFOUND registry” tarzı bir şeydi işte. npm config set proxy ile çözdüm ama dokümantasyona bunun eklenmesi lazım bence. Evet.
Diğer Azure tooling ile beraber nasıl çalışıyor?
Şunu bir yokladım: azd update Komutu Geldi: Paket Yöneticisi Derdine Son yazısında anlattığım azd komut zinciriyle skills yan yana durabiliyor mu? Evet, duruyor. Hatta şaşırtıcı derecede sakın çalışıyor; skills agent’a “deploy” dediğiniz anda altta azd up çağrılıyor,. Işin mutfağında ekstra bir drama yok (neyse ki). Ekosistem baya bütünleşik düşünülmüş, ben açık konuşayım bunu görünce “tamam, bu iş ölür” dedim.
Copilot SDK tarafı da boş değil. Bakın, hele bir de agent’ın yazdığı SDK çağrılarında güncel pattern’leri yakalıyor; bazen insanın elinden kaçan ufak detayları kendi toparlıyor gıbı (buna dikkat edin). Copilot SDK Genel Kullanıma Açıldı: Saha Notlarım yazısında bahsettiğim “agent layer + SDK layer” ayrımı burada da aynı şekilde karşınıza çıkıyor,. Dür bir saniye — bu sadece teorik bir uyum değil, pratikte de iş görüyor. Şey, yanı, kod tarafında ayrı katman mantığı korunuyor ve bu da bakım işini biraz daha katlanılır hâle getiriyor.
Sıkça Sorulan Sorular
azure-functions-skills’i kullanmak için para ödüyor müyüz?
Hayır, plugin büyük ölçüde ücretsiz ve open source (bizzat test ettim). Yanı sadece kullandığınız Azure kaynakları (Functions execution, storage, Cosmos vb.) için Azure faturanıza yansıyor. Bir de tabi agent host (Copilot, Claude vb.) için ayrı abonelik gerekiyor önü unutmayın.
Var olan bir Functions projesine sonradan ekleyebilir mıyım?
Evet, mevcut bir projede de install komutunu çalıştırabilirsiniz. Sonrasında doctor‘ı koşturup ne kadar “borçlu” olduğunuza bakabilirsiniz. Aslında mevcut projelerde genelde 5-10 madde çıkıyor — bence en büyük iş connection string’den managed identity’ye geçiş oluyor.
VS Code dışında başka hangı agent’ları destekliyor?
Şu an public preview’da GitHub Copilot CLI, Claude Code, Codex CLI ve VS Code destekleniyor (inanın bana). Cursor için resmî destek yok. Bu ne anlama geliyor? Ama hani instruction dosyalarını manuel olarak .cursorrules‘a kopyalarsanız benzer sonucu alabiliyorsunuz — ben denedim, çalışıyor.
Doctor raporu bazen yanlış uyarı veriyor mu?
Bak şimdi, Açıkçası bazen evet. Mesela local.settings.json’u CI’da kullanmıyor olsanız bile uyarı verebiliyor. Bir tür exclusion mekanizması var ama dokümantasyonu oldukça zayıf. Bu durumda GitHub issues’ta sorun açmanızı öneririm — ekip aktif olarak cevap veriyor.
Production’da kullanmaya hazır mı?
Plugin hâlâ “public preview” aşamasında, yanı Microsoft “kullanın ama production SLA beklemeyin” diyor. Tecrübeme göre şunu öneriyorum: Dev ve staging tarafında full kullanın, production deploy adımında doctor’ı zorunlu tutun, ama agent çıktısını mutlaka bir insan gözünden geçirin. GA’ya gelene kadar bu temkinli yaklaşım daha sağlıklı bence (bizzat test ettim)
Kaynaklar ve İleri Okuma
Azure SDK Blog: Introducing azure-functions-skills — Resmî duyuru yazısı, teknik detaylar ve roadmap için (ben de ilk duyduğumda şaşırmıştım)
npm: @Azure/functions-skills paketi — Versiyon geçmişi, install talimatları. API reference.
Microsoft Learn: Flex Consumption Plan Dokümantasyonu — Skills’in tercih ettiği yeni hosting modelini detaylı anlatıyor. Pricing ve scaling karakteristikleri için mutlaka okuyun.
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.
