The .NET Blog

.NET 10 Ubuntu 26.04 LTS ile Geliyor — Neler Yeni

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Ubuntu LTS günü. Ubuntu 26.04 (Resolute Raccoon) bugün .NET 10 ile yayımlandı.

.NET 10’u İki Komutla Yükle

sudo apt update
sudo apt install dotnet-sdk-10.0

Konteynerler: `-noble` yerine `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: 3ms Başlatma, 1,4MB İkili

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# 1,4MB yerel ikili, 3ms başlatma süresi

Soğuk başlangıç süresinin önemli olduğu cloud-native iş yükleri için — Functions, konteynerler, serverless — gerçek bir oyun değiştirici.

.NET 8 veya 9’a İhtiyacın Var mı?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Tam makale cgroup v2, kuantum sonrası kriptografi ve Linux 7.0 hakkında daha fazla ayrıntı içeriyor.

Agent Framework'te CodeAct: Ajanınızın Gecikmesini Yarıya Nasıl İndirirsiniz

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Her ajan projesinde, izlemeye bakıp “bu neden bu kadar uzun sürüyor?” diye düşündüğünüz bir an gelir. Model iyi çalışıyor. Araçlar çalışıyor. Ama tek seferinde hesaplanabilecek bir sonuç için yedi gidiş-dönüş oluyor.

CodeAct’ın tam olarak çözdüğü sorun bu — ve Agent Framework ekibi yeni agent-framework-hyperlight paketiyle alfa destek yayınladı.

CodeAct Nedir?

CodeAct deseni zarifçe basittir: Modele tek tek çağrılacak araçların listesini vermek yerine, tek bir execute_code aracı verin ve planın tamamını kısa bir Python programı olarak ifade etmesine izin verin.

Yaklaşım	Süre	Token
Geleneksel	27.81s	6.890
CodeAct	13.23s	2.489
İyileştirme	%52.4	%63.9

Güvenlik: Hyperlight Mikro-VM’leri

agent-framework-hyperlight paketi Hyperlight mikro-VM’leri kullanır. Her execute_code çağrısı kendi yeni mikro-VM’ini alır. Başlatma milisaniyelerle ölçülür. İzolasyon neredeyse ücretsizdir.

Araçlarınız ana bilgisayarda çalışmaya devam eder. Modelin oluşturduğu yapıştırıcı kod sandbox’ta çalışır. Bu doğru ayrımdır.

Minimum Kurulum

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

CodeAct Ne Zaman Kullanılır (Ne Zaman Kullanılmaz)

CodeAct kullanın:

Görev birçok küçük araç çağrısını zincirliyor (aramalar, birleştirmeler, hesaplamalar)
Gecikme ve token maliyeti önemliyse
Model tarafından oluşturulan kod için güçlü izolasyon istiyorsanız

Geleneksel araç çağrısında kalın:

Ajan tur başına yalnızca bir iki araç çağrısı yapıyorsa
Her çağrının bireysel onay gerektiren yan etkileri varsa

Şimdi Deneyin

pip install agent-framework-hyperlight --pre

Agent Framework blogundaki tam gönderiyi okuyun.

Ajanınız Şeyleri Nerede Hatırlıyor? Sohbet Geçmişi Depolama için Pratik Rehber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Bir AI ajanı oluştururken enerjinizin büyük bölümünü modele, araçlara ve istemlere harcarsınız. Konuşma geçmişinin nerede tutulduğu sorusu bir uygulama ayrıntısı gibi görünür — ancak alacağınız en önemli mimari kararlardan biridir.

Kullanıcıların konuşmaları dallandırıp dallandıramayacağını, yanıtları geri alıp alamayacağını, yeniden başlatmadan sonra oturumları devam ettirip ettiremeyeceğini ve verilerinizin altyapınızı terk edip etmediğini belirler. Agent Framework ekibi derinlemesine bir analiz yayımladı.

İki temel desen

Servis tarafından yönetilen: AI servisi konuşma durumunu depolar. Uygulamanız bir referans tutar ve servis her istekte ilgili geçmişi otomatik olarak ekler.

İstemci tarafından yönetilen: Uygulamanız tam geçmişi tutar ve her istekte ilgili mesajları gönderir. Servis durumsuzdur. Her şeyi siz kontrol edersiniz.

Agent Framework bunu nasıl soyutlar

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Adım Alice.", session);
var second = await agent.RunAsync("Benim adım ne?", session);

session = agent.create_session()
first = await agent.run("Adım Alice.", session=session)
second = await agent.run("Benim adım ne?", session=session)

Sağlayıcı hızlı referans

Sağlayıcı	Depolama	Model	Sıkıştırma
OpenAI/Azure Chat Completions	İstemci	Yok	Siz
Foundry Agent Service	Servis	Doğrusal	Servis
Responses API (varsayılan)	Servis	Dallanma	Servis
Anthropic Claude, Ollama	İstemci	Yok	Siz

Nasıl seçilir

Dallanma veya “geri al” gerekiyor mu? → Servis tarafından yönetilen Responses API
Veri egemenliği gerekiyor mu? → DB destekli istemci tarafından yönetilen
Basit bir sohbet botu mu? → Servis tarafından yönetilen doğrusal yeterli

Tam karar ağacı için tam makaleyi okuyun.

Azure MCP Server Artık .mcpb — Herhangi Bir Runtime Olmadan Yükle

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

MCP sunucularını kurarken can sıkıcı olan ne olduğunu biliyor musunuz? Bir runtime gerekiyordu. npm sürümü için Node.js, pip/uvx için Python, dotnet varyantı için .NET SDK.

Azure MCP Server bunu değiştirdi. Artık .mcpb — MCP Bundle — olarak kullanılabilir ve kurulum sürükle-bıraktır.

MCP Bundle Nedir?

VS Code uzantısı (.vsix) veya tarayıcı uzantısı (.crx) gibi düşünün, ama MCP sunucuları için. .mcpb dosyası, sunucu ikilisini ve tüm bağımlılıklarını içeren bağımsız bir ZIP arşividir.

Nasıl Kurulur

1. Platformunuz için bundle’ı indirin

GitHub Releases sayfasına gidin ve OS ve mimarinize uygun .mcpb dosyasını indirin.

2. Claude Desktop’a kurun

En kolay yol: Uzantılar ayarları sayfasındayken (☰ → Dosya → Ayarlar → Uzantılar) .mcpb dosyasını Claude Desktop penceresine sürükleyip bırakın. Sunucu ayrıntılarını inceleyin, Yükle’ye tıklayın, onaylayın.

3. Azure’da kimlik doğrulaması yapın

az login

Başlamak için

İndirme: GitHub Releases
Depo: aka.ms/azmcp
Belgeler: aka.ms/azmcp/docs

Tam makaleye bakın.

GPT-5.5 Burada ve Azure Foundry'e Geliyor — .NET Geliştiricilerinin Bilmesi Gerekenler

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Microsoft, GPT-5.5’in Microsoft Foundry’de genel kullanıma sunulduğunu duyurdu. Azure’da agent oluşturuyorsanız, beklediğiniz güncelleme bu.

GPT-5 Evrimi

GPT-5: akıl yürütme ve hızı tek bir sistemde birleştirdi
GPT-5.4: daha güçlü çok adımlı akıl yürütme, enterprise için erken ajansal özellikler
GPT-5.5: daha derin uzun bağlam akıl yürütme, daha güvenilir ajansal yürütme, daha iyi token verimliliği

Gerçekte ne değişti

Geliştirilmiş ajansal kodlama: GPT-5.5, büyük kod tabanlarında bağlamı korur, mimari düzeydeki hataları teşhis eder ve test gereksinimlerini öngörür. Model, harekete geçmeden önce bir düzeltmenin başka neyi etkilediğini akıl yürütür.

Token verimliliği: Daha az token ve daha az yeniden denemeyle daha yüksek kaliteli çıktılar. Üretimde doğrudan düşük maliyet ve gecikme.

Fiyatlandırma

Model	Girdi ($/M token)	Önbelleğe alınmış	Çıktı ($/M token)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Foundry Neden Önemli

Foundry Agent Service, agentları YAML’de tanımlamanıza veya Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ya da OpenAI Agents SDK ile bağlamanıza olanak tanır — ve bunları kalıcı dosya sistemi, Microsoft Entra kimliği ve sıfıra ölçekleme fiyatlandırmasıyla izole barındırılan agentlar olarak çalıştırır.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Yardımcı bir asistansınız.", name: "BenimAgentim");

Tüm ayrıntılar için tam duyuruya bakın.

VS Code 1.118: Copilot CLI Oturum Adları, Model Rozetleri ve TypeScript 7.0 Nightly Alıyor

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Visual Studio Code 1.118, ağırlıklı olarak Copilot CLI iyileştirmelerine odaklanan küçük bir sürümdür.

Copilot CLI: Oturumlara Gerçek Adlar Geliyor

Copilot CLI SDK oturum başlığı API’leri artık oturum adları için doğruluk kaynağı olarak kullanılıyor. Otomatik oluşturulan etiketler yerine SDK’daki gerçek ad gösteriliyor.

Klavye Kısayollarıyla Hızlı Oturum Değiştirme

Agents uygulamasına artık oturumlar arasında hızla geçiş için Ctrl+1, Ctrl+2 vb. tuş atamaları eklendi.

Sohbette Model Rozetleri

Copilot CLI’nin sohbet panelindeki yanıtlarında artık model rozeti gösteriliyor.

Copilot CLI’da Otomatik Model Seçimi

Otomatik model seçimi özelliği artık Copilot CLI ajanında da çalışıyor.

TypeScript 7.0 Nightly Katılımı

Artık VS Code ayarlarından doğrudan TypeScript 7.0 nightly sürümlerini test etmeyi etkinleştirebilirsiniz. TypeScript 7.0 önemli bir sürümdür (beta birkaç gün önce yayınlandı).

Tam sürüm notlarına bakın.

Foundry Toolboxes: Tüm Ajan Araçları için Tek Bir Endpoint

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Bizzat yaşayana kadar önemsiz görünen bir sorun var: Kuruluş birden fazla yapay zeka ajanı oluşturuyor, her birinin araçlara ihtiyacı var ve her ekip sıfırdan yapılandırıyor. Aynı web arama entegrasyonu, aynı Azure AI Search yapılandırması, aynı GitHub MCP sunucusu bağlantısı — ama farklı bir depoda, farklı bir ekip tarafından, farklı kimlik bilgileriyle ve paylaşılan yönetim olmadan.

Microsoft Foundry, genel önizlemede Toolboxes yayımladı ve bu soruna doğrudan bir yanıt niteliğinde.

Toolbox nedir?

Toolbox, Foundry’de bir kez tanımlanıp tek bir MCP uyumlu endpoint üzerinden sunulan, adlandırılmış ve yeniden kullanılabilir bir araç paketidir. MCP konuşabilen herhangi bir ajan çalışma zamanı bunu tüketebilir — Foundry Agents’a bağımlılık yoktur.

Vaat basittir: build once, consume anywhere. Araçları tanımla, kimlik doğrulamayı merkezi olarak yapılandır (OAuth doğrudan geçiş, Entra yönetilen kimlik), endpoint’i yayımla. Bu araçlara ihtiyaç duyan her ajan endpoint’e bağlanır ve tümünü alır.

Dört sütun (bugün ikisi mevcut)

Sütun	Durum	Ne yapar
Discover	Yakında	Elle arama yapmadan onaylı araçları bulma
Build	Mevcut	Araçları yeniden kullanılabilir pakete gruplama
Consume	Mevcut	Tek MCP endpoint tüm araçları sunar
Govern	Yakında	Merkezi kimlik doğrulama + tüm araç çağrılarının gözlemlenebilirliği

Pratik örnek

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Dokümanlarda arama yap ve GitHub sorunlarına yanıt ver.",
 tools=[
 {"type": "web_search", "description": "Genel belgelerde arama yap"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Yayımlandıktan sonra Foundry birleşik bir endpoint sağlar. Tek bağlantı, tüm araçlar.

Foundry Agents’a bağımlılık yok

Toolboxes, Foundry’de oluşturulur ve yönetilir; ancak tüketim yüzeyi açık MCP protokolüdür. Bunları özel ajanlardan (Microsoft Agent Framework, LangGraph), GitHub Copilot ve diğer MCP destekli IDE’lerden kullanabilirsiniz.

Neden şimdi önemli?

Çoklu ajan dalgası üretime ulaşıyor. Her yeni ajan, yinelenen yapılandırma, eski kimlik bilgileri ve tutarsız davranış için yeni bir yüzeydir. Build + Consume temeli merkezileşmeye başlamak için yeterlidir. Govern sütunu geldiğinde, tüm ajan filosu için tam gözlemlenebilir ve merkezi olarak kontrol edilen bir araç katmanı elde edilmiş olacak.

Sonuç

Henüz erken — genel önizleme, önce Python SDK, Discover ve Govern henüz yolda. Ancak model sağlam ve MCP yerel tasarımı, zaten inşa ettiğiniz araçlarla çalıştığı anlamına geliyor. Ayrıntılar için resmi duyuruya bakın.

Python, TypeScript ve .NET ile azd Hook Yazma: Shell Script'lere Veda

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Tamamen .NET ile yazılmış bir projeniz olmasına rağmen azd hook’ları için Bash scriptleri yazmak zorunda kaldıysanız, bu acıyı iyi biliyorsunuzdur. Projenin geri kalanı C# iken, neden bir pre-provisioning adımı için shell sözdizimine geçiş yapmak zorunda kalınsın?

Bu hayal kırıklığı artık resmi bir çözüme kavuştu. Azure Developer CLI hook’lar için çok dilli destek yayımladı ve tam olarak duyulduğu kadar iyi.

Hook nedir?

Hook’lar, azd yaşam döngüsünün kritik noktalarında çalışan scriptlerdir — provisioning öncesi, deployment sonrası vb. azure.yaml içinde tanımlanır ve CLI’yi değiştirmeden özel mantık eklemenizi sağlar.

Önceden yalnızca Bash ve PowerShell destekleniyordu. Artık Python, JavaScript, TypeScript veya .NET kullanılabilir — azd geri kalanını otomatik olarak halleder.

Algılama nasıl çalışır

Yalnızca hook’u bir dosyaya yönlendirin; azd uzantıdan dili çıkarır:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Ek yapılandırma gerekmez. Uzantı belirsizse kind: python (veya ilgili dil) ile açıkça belirtebilirsiniz.

Dile göre önemli ayrıntılar

Python

Scriptin yanına (veya herhangi bir üst dizine) requirements.txt ya da pyproject.toml koyun. azd otomatik olarak sanal ortam oluşturur, bağımlılıkları kurar ve scripti çalıştırır.

JavaScript ve TypeScript

Aynı desen — script yakınına package.json koyun ve azd önce npm install çalıştırır. TypeScript için derleme adımı ve tsconfig.json gerekmeden npx tsx kullanılır.

.NET

İki mod mevcuttur:

Proje modu: Script yanında .csproj varsa azd otomatik olarak dotnet restore ve dotnet build çalıştırır.
Tek dosya modu: .NET 10+ sürümünde bağımsız .cs dosyaları dotnet run script.cs ile doğrudan çalıştırılabilir. Proje dosyası gerekmez.

Executor’a özgü yapılandırma

Her dil isteğe bağlı bir config bloğunu destekler:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET geliştiricileri için önemi

Hook’lar, azd tabanlı bir projede dil değiştirmeyi zorunlu kılan son yerdi. Artık uygulama kodu, altyapı scriptleri ve yaşam döngüsü hook’ları dahil tüm deployment pipeline’ı tek bir dilde yaşayabilir. Mevcut .NET yardımcı programlarını hook’larda yeniden kullanabilir, paylaşılan kütüphanelere referans verebilir ve shell script bakımından kurtulabilirsiniz.

Sonuç

Küçük görünse de azd günlük iş akışından çok fazla sürtünme kaldıran değişikliklerden biri. Hook’lar için çok dilli destek şu anda kullanılabilir — resmi gönderinde tam belgelere ulaşabilirsiniz.

Windows App Dev CLI v0.3: Terminalden F5 Hata Ayıklama ve Ajanlar için UI Otomasyonu

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Visual Studio’nun F5 deneyimi harika. Ama yalnızca paketlenmiş bir Windows uygulamasını başlatıp hata ayıklamak için VS’yi açmak — bir CI boru hattında, otomatik bir iş akışında veya bir yapay zeka ajanı testleri çalıştırırken — fazla ağır bir yük.

Windows App Development CLI v0.3 yayınlandı ve bunu iki temel özellikle doğrudan ele alıyor: winapp run ve winapp ui.

winapp run: Her yerden F5

winapp run paketlenmemiş bir uygulama klasörü ve manifest alır; VS’nin hata ayıklama başlatmasında yaptığı her şeyi yapar: loose paket kaydeder, uygulamayı başlatır ve yeniden dağıtımlar arasında LocalState‘i korur.

# Uygulamayı derleyin, ardından paketlenmiş uygulama olarak çalıştırın
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia ve daha fazlası için çalışır. Modlar hem geliştiriciler hem de otomatik iş akışları için tasarlanmıştır:

--detach: Başlatır ve hemen terminale kontrolü geri döndürür. CI için ideal.
--unregister-on-exit: Uygulama kapatıldığında kayıtlı paketi temizler.
--debug-output: OutputDebugString mesajlarını ve istisnaları gerçek zamanlı yakalar.

Yeni NuGet Paketi: Paketlenmiş uygulamalar için dotnet run

.NET geliştiricileri için yeni bir NuGet paketi var: Microsoft.Windows.SDK.BuildTools.WinApp. Kurulumdan sonra dotnet run tüm iç döngüyü yönetir: derleme, loose-layout paketi hazırlama, Windows’ta kayıt ve başlatma — tek adımda.

winapp init
# veya
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: Komut satırından UI Otomasyonu

Bu, ajan senaryolarını açan özellik. winapp ui, terminalden çalışan herhangi bir Windows uygulamasına (WPF, WinForms, Win32, Electron, WinUI3) tam UI Automation erişimi sağlar.

Yapılabilecekler:

Tüm üst düzey pencereleri listele
Herhangi bir pencerenin tam UI Automation ağacında gezin
Ad, tür veya otomasyon kimliğine göre öğe ara
Tıkla, çağır ve değer ayarla
Ekran görüntüsü al
Öğelerin görünmesini bekle — test senkronizasyonu için ideal

winapp ui ile winapp run‘ı birleştirmek, terminalden eksiksiz bir derleme → başlatma → doğrulama iş akışı sağlar. Bir ajan uygulamayı çalıştırabilir, UI durumunu inceleyebilir, programatik olarak etkileşime girebilir ve sonucu doğrulayabilir.

Diğer yenilikler

winapp unregister: Tamamlandığında yandan yüklenmiş paketi kaldırır.
winapp manifest add-alias: Terminalden adıyla uygulama başlatmak için takma ad ekler.
Sekme tamamlama: PowerShell tamamlamayı tek komutla yapılandırın.

Nasıl edinilir

winget install Microsoft.WinAppCli
# veya
npm install -g @microsoft/winappcli

CLI genel önizleme aşamasında. Tam belgeleme için GitHub deposuna, tüm ayrıntılar için orijinal duyuruya bakın.

azd + GitHub Copilot: Yapay Zeka Destekli Proje Kurulumu ve Akıllı Hata Çözümü

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Mevcut bir uygulamayı Azure’a dağıtmak isteyip boş bir azure.yaml dosyasına bakarak Express API’nizin Container Apps mı yoksa App Service mi kullanması gerektiğini hatırlamaya çalıştığınız o anı biliyor musunuz? O an artık çok daha kısa.

Azure Developer CLI (azd) artık GitHub Copilot ile iki somut şekilde entegre: azd init sırasında AI destekli proje iskele kurma ve dağıtımlar başarısız olduğunda akıllı hata giderme. Her iki özellik de tamamen terminalde kalıyor.

azd init Sırasında Copilot ile Kurulum

azd init çalıştırıldığında artık “Set up with GitHub Copilot (Preview)” seçeneği görünüyor. Seçin ve Copilot, gerçek kodunuzu temel alarak azure.yaml, altyapı şablonları ve Bicep modülleri oluşturmak için kod tabanınızı analiz eder.

azd init
# Seçin: "Set up with GitHub Copilot (Preview)"

Gereksinimler:

azd 1.23.11 veya üzeri — azd version ile kontrol edin veya azd update ile güncelleyin
Aktif GitHub Copilot aboneliği (Bireysel, İş veya Kurumsal)
GitHub CLI (gh) — gerekirse azd oturum açmanızı isteyecek

Gerçekten faydalı bulduğum şey: her iki yönde de çalışıyor. Sıfırdan mı inşa ediyorsunuz? Copilot doğru Azure hizmetlerini başından itibaren yapılandırmanıza yardımcı olur. Dağıtmak istediğiniz mevcut bir uygulamanız mı var? Copilot’u ona yöneltin — kodu yeniden yapılandırmadan konfigürasyon oluşturulur.

Gerçekte Ne Yapar

PostgreSQL bağımlılığına sahip bir Node.js Express API’niz olduğunu varsayalım. Container Apps ile App Service arasında manuel seçim yapmak ve ardından sıfırdan Bicep yazmak yerine, Copilot yığınınızı algılar ve şunları oluşturur:

Doğru language, host ve build ayarlarına sahip azure.yaml
Azure Container Apps için Bicep modülü
Azure Database for PostgreSQL için Bicep modülü

Ve herhangi bir şeyi değiştirmeden önce ön kontroller yapar — git çalışma dizininin temiz olduğunu doğrular, MCP sunucu araç iznini önceden sorar. Her şey bilginiz dahilinde gerçekleşir.

Copilot ile Hata Giderme

Dağıtım hataları kaçınılmazdır. Eksik parametreler, izin sorunları, SKU kullanılabilirlik sorunları — ve hata mesajı nadiren gerçekten bilmeniz gereken tek şeyi söyler: nasıl düzeltilir.

Copilot olmadan döngü şöyle görünür: hatayı kopyala → belgelerden ara → ilgisiz üç Stack Overflow cevabı oku → birkaç az CLI komutu çalıştır → tekrar dene ve umut et. azd‘de Copilot ile bu döngü çöküyor. Herhangi bir azd komutu başarısız olduğunda anında dört seçenek sunuluyor:

Explain — ne yanlış gittiğinin anlaşılır dilde açıklaması
Guidance — sorunu gidermek için adım adım talimatlar
Diagnose and Guide — tam analiz + Copilot düzeltmeyi uygular (onayınızla) + isteğe bağlı yeniden deneme
Skip — kendiniz halledin

Kritik nokta: Copilot’un projeniz, başarısız olan komut ve hata detayları hakkında zaten bağlamı var. Önerileri sizin durumunuza özeldir.

Varsayılan Davranışı Ayarlama

Her zaman aynı seçeneği seçiyorsanız etkileşimli istemi atlayın:

azd config set copilot.errorHandling.category troubleshoot

Değerler: explain, guidance, troubleshoot, fix, skip. Otomatik düzeltme ve yeniden denemeyi de etkinleştirebilirsiniz:

azd config set copilot.errorHandling.fix allow

İstediğiniz zaman etkileşimli moda geri dönün:

azd config unset copilot.errorHandling.category

Sonuç

En son sürümü edinmek için azd update çalıştırın ve bir sonraki projenizde azd init deneyin.

Orijinal duyuruyu buradan okuyun.

Node.js için C# ile .NET Native AOT Kullanarak Yerel Eklenti Yazma

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

İşte sevdiğim bir senaryo: .NET araçları üzerinde çalışan bir ekibin node-gyp ile derlenen C++ ile yazılmış yerel Node.js eklentileri vardı. Çalışıyordu. Ama her geliştiricinin makinesinde Python’un yüklü olmasını gerektiriyordu — Python’un eski bir sürümü, dahası — sadece ekipten kimsenin hiç doğrudan dokunmayacağı bir paketi derlemek için.

Bunun üzerine çok makul bir soru sordular: zaten .NET SDK yüklüyken neden C++ yazıyoruz ki?

Cevap Native AOT oldu ve sonuç gerçekten zarif. C# Dev Kit ekibinden Drew Noakes bunu nasıl yaptıklarını anlattı.

Temel fikir

Node.js yerel eklentisi, Node.js’nin çalışma zamanında yükleyebildiği bir paylaşılan kütüphanedir (Windows’ta .dll, Linux’ta .so, macOS’ta .dylib). Arayüze N-API denir — kararlı, ABI uyumlu bir C API’si. N-API’nin kütüphaneyi hangi dilin ürettiğini umursamaz, sadece doğru sembolleri dışa aktarmasını önemser.

.NET Native AOT tam olarak bunu yapabilir. C# kodunuzu önceden isteğe bağlı giriş noktalarıyla yerel paylaşılan kütüphaneye derler.

Proje kurulumu

Proje dosyası minimumdur:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot, SDK’ya dotnet publish‘te paylaşılan kütüphane üretmesini söyler.

Giriş noktasını dışa aktarma

Node.js, kütüphanenizin napi_register_module_v1‘i dışa aktarmasını bekler. C#’ta [UnmanagedCallersOnly] tam olarak bunu yapar:

[UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
}

u8 soneki, herhangi bir encoding tahsisi olmadan doğrudan N-API’ye geçirilen UTF-8 string literaliyle bir ReadOnlySpan<byte> üretir.

TypeScript’ten çağırma

dotnet publish, platforma özgü yerel kütüphanenizi üretir. Onu .node olarak yeniden adlandırın ve standart require() ile kullanın:

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

İşte bu kadar. TypeScript’ten C#‘a, Python yok, C++ yok.

Sonuç

C# Dev Kit ekibi Python/C++ yükünü, ekipteki herkesin zaten nasıl yazılacağını ve hata ayıklayacağını bildiği temiz C# koduyla değiştirdi. Bu desen göründükten sonra karmaşık değil ve Native AOT’nun yeterince konuşulmayan gerçek bir sorunu çözdüğünün harika bir örneği.

.NET blogundaki orijinal yazıyı okuyun.

VS Code 1.117: Agentlar Artık Kendi Git Dallarını Alıyor ve Ben Bunun İçin Buradayım

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI asistanı” ile “AI takım üyesi” arasındaki çizgi giderek inceliyor. VS Code 1.117 az önce yayınlandı ve tam sürüm notları çok şey içeriyor, ancak buradaki hikaye açık: agentlar geliştirme iş akışınızda birinci sınıf vatandaş haline geliyor.

İşte gerçekten önemli olan şeyler.

Autopilot modu artık tercihinizi hatırlıyor

Daha önce her yeni oturum başlattığınızda Autopilot’u yeniden etkinleştirmeniz gerekiyordu. Can sıkıcıydı. Artık izin modunuz oturumlar arasında korunuyor ve varsayılanı yapılandırabiliyorsunuz.

Agent Host üç oturum yapılandırmasını destekliyor:

Default — araçlar çalışmadan önce onay istiyor
Bypass — her şeyi otomatik onaylıyor
Autopilot — tamamen özerk, kendi sorularını yanıtlıyor ve devam ediyor

Migrasyonlar, Docker ve CI ile yeni bir .NET projesi kuruyorsanız — Autopilot’u bir kez ayarlayın ve unutun. O tercih kalıcı.

Agent oturumları için worktree ve git izolasyonu

Bu en büyük özellik. Agent oturumları artık tam worktree ve git izolasyonunu destekliyor. Bu, bir agent bir görev üzerinde çalışırken kendi dalını ve çalışma dizinini aldığı anlamına geliyor. Ana dalınız dokunulmadan kalıyor.

Daha da iyisi — Copilot CLI bu worktree oturumları için anlamlı dal adları üretiyor. Artık agent-session-abc123 yok. Agentin ne yaptığını gerçekten açıklayan bir şey alıyorsunuz.

Birden fazla özellik dalı üzerinde çalışan veya uzun bir iskele görevi çalışırken hata düzelten .NET geliştiricileri için bu oyun değiştirici. Bir worktree’de API controller’larınızı oluşturan bir agent varken siz başka bir worktree’de servis katmanı sorununu ayıklıyor olabilirsiniz. Çakışma yok. Stash yok. Karmaşa yok.

Alt-agentlar ve agent ekipleri

Agent Host Protocol artık alt-agentları destekliyor. Bir agent, bir görevin parçalarını yönetmek için başka agentlar çalıştırabilir. Görevlendirme gibi düşünün — ana agent koordine eder, uzman agentlar parçaları yönetir.

Bu erken aşamada, ancak .NET iş akışları için potansiyel açık. EF Core migrasyonlarınızı yöneten bir agent varken diğeri entegrasyon testlerinizi kuruyor, bunu hayal edin. Tam olarak oraya henüz ulaşmadık, ancak protokol desteğinin şimdi gelmesi tooling’in hızla takip edeceği anlamına geliyor.

Agentlar girdi gönderdiğinde terminal çıktısı otomatik dahil ediliyor

Küçük ama anlamlı. Bir agent terminale girdi gönderdiğinde, terminal çıktısı artık otomatik olarak bağlama dahil ediliyor. Daha önce, agent ne olduğunu görmek için ekstra bir tur atmak zorundaydı.

Bir agentin dotnet build çalıştırdığını, başarısız olduğunu ve ardından hatayı görmek için başka bir gidiş-dönüş yaptığını izlediyseniz — bu sürtünme gitti. Çıktıyı hemen görüyor ve tepki veriyor.

macOS’ta Agents uygulaması kendi kendini güncelliyor

macOS’taki bağımsız Agents uygulaması artık kendi kendini güncelliyor. Artık yeni sürümleri manuel olarak indirmeye gerek yok. Güncel kalıyor.

Bilmeye değer küçük şeyler

package.json hover’ları artık hem yüklü sürümü hem de mevcut en son sürümü gösteriyor. .NET projelerinizin yanında npm tooling yönetiyorsanız kullanışlı.
JSDoc yorumlarındaki resimler hover ve tamamlamalarda doğru şekilde render ediliyor.
Copilot CLI oturumları artık VS Code tarafından mı yoksa harici olarak mı oluşturulduklarını gösteriyor — terminaller arasında atlıyorsanız kullanışlı.
Copilot CLI, Claude Code ve Gemini CLI kabuk türleri olarak tanınıyor. Editör ne çalıştırdığınızı biliyor.

Sonuç

VS Code 1.117 gösterişli bir özellik yığını değil. Altyapı. Worktree izolasyonu, kalıcı izinler, alt-agent protokolleri — bunlar, agentların kodunuza basmadan gerçek, paralel görevleri üstlendiği bir iş akışının yapı taşları.

.NET ile geliştirme yapıyorsanız ve henüz ajanlı iş akışına girmediyseniz, dürüstçe söylemek gerekirse, başlamak için şimdi tam zamanı.

Azure'daki AI Deneyimleriniz Para Yakıyor — İşte Bunu Düzeltmenin Yolu

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Şu an Azure üzerinde AI destekli uygulamalar geliştiriyorsanız, muhtemelen şunu fark etmişsinizdir: bulut faturanız eskisinden farklı görünüyor. Sadece daha yüksek değil — daha tuhaf. Ani sıçramalar yapıyor. Tahmin etmesi güç.

Microsoft, hâlâ geçerliliğini koruyan bulut maliyet optimizasyon ilkeleri üzerine harika bir yazı yayımladı ve dürüst olmak gerekirse, zamanlama daha iyi olamazdı. Çünkü AI iş yükleri, maliyetler söz konusu olduğunda oyunun kurallarını değiştirdi.

AI iş yükleri neden farklı hissettiriyor

Şöyle düşünün. Geleneksel .NET iş yükleri görece tahmin edilebilir. App Service katmanınızı bilirsiniz, SQL DTU’larınızı bilirsiniz, aylık harcamayı makul ölçüde doğru tahmin edebilirsiniz. AI iş yükleri? O kadar da değil.

Hangisinin uygun olduğunu görmek için birden fazla modeli test ediyorsunuz. İnce ayar için GPU destekli altyapı kuruyorsunuz. Prompt uzunluğuna ve kullanıcı davranışına göre token tüketiminin çılgınca değiştiği Azure OpenAI’ya API çağrıları yapıyorsunuz. Her deney gerçek para maliyeti içeriyor ve doğru yaklaşımı bulmadan önce düzinelerce deneme yapabiliyorsunuz.

Bu öngörülemezlik, maliyet optimizasyonunu kritik kılıyor — sonradan düşünülecek bir şey olarak değil, ilk günden itibaren.

Yönetim ile optimizasyon — farkı bilin

Makaledeki geliştiricilerin gözden kaçırdığını düşündüğüm bir ayrım var: maliyet yönetimi ile maliyet optimizasyonu arasında bir fark var.

Yönetim, takip etmek ve raporlamaktır. Azure Cost Management’ta bütçeler kurarsınız, uyarılar alırsınız, panolar görürsünüz. Bu temel gereksinimdir.

Optimizasyon, gerçek kararlar aldığınız yerdir. O S3 katmanına gerçekten ihtiyacınız var mı, yoksa S1 yükü kaldırır mı? O her zaman açık hesaplama örneği hafta sonları boşta mı oturuyor? Eğitim işleriniz için spot instance kullanabilir misiniz?

.NET geliştiricileri olarak koda odaklanma ve altyapı kararlarını “operasyon ekibine” bırakma eğilimindeyiz. Ama Azure’a dağıtıyorsanız, o kararlar sizin kararlarınızdır.

Gerçekten işe yarayan şeyler

Makaleye ve kendi deneyimlerime dayanarak, fark yaratan şeyler şunlar:

Ne harcadığınızı ve nerede harcadığınızı bilin. Kaynaklarınızı etiketleyin. Gerçekten. Hangi projenin ya da deneyin bütçenizi tükettiğini söyleyemiyorsanız hiçbir şeyi optimize edemezsiniz. Uygun etiketlemeyle Azure Cost Management en iyi dostunuzdur.

Deney yapmadan önce güvenlik sınırları koyun. Geliştirme/test ortamlarında pahalı SKU’ları kısıtlamak için Azure Policy kullanın. Azure OpenAI dağıtımlarınıza harcama limitleri belirleyin. Hafta sonu biri GPU kümesini çalışır durumda bırakmış diye fatura gelene kadar beklemeyin.

Sürekli boyutlandırın. Prototip aşamasında seçtiğiniz VM? Üretim için muhtemelen yanlış. Azure Advisor size öneriler sunuyor — gerçekten bakın. Yıllık değil, aylık olarak gözden geçirin.

Yaşam döngüsünü düşünün. Geliştirme kaynakları kapanabilmeli. Test ortamlarının 7/24 çalışması gerekmez. Otomatik kapatma politikaları kullanın. AI iş yükleri için özellikle, hesaplamayı sıcak tutmak yerine kullanım başına ödeme yaptığınız sunucusuz seçenekleri değerlendirin.

Maliyeti değil, değeri ölçün. Bunu unutmak kolay. Daha pahalı ama önemli ölçüde daha iyi sonuçlar veren bir model doğru seçim olabilir. Amaç en az harcamak değil — akıllıca harcamaktır.

Sonuç

Bulut maliyet optimizasyonu tek seferlik bir temizlik değildir. Bir alışkanlıktır. AI iş yükleri harcamayı her zamankinden daha az öngörülebilir hale getirirken, bu alışkanlığı erken edinmek sizi daha sonra acı sürprizlerden kurtarır.

Azure üzerinde geliştiren bir .NET geliştiricisiyseniz, bulut faturanıza kodunuza baktığınız gibi bakmaya başlayın — düzenli olarak gözden geçirin, karmaşıklaştığında yeniden yapılandırın ve ne kadara mal olacağını anlamadan asla dağıtmayın.

Foundry'nin RFT'si Daha Ucuz ve Daha Akıllı Hale Geldi — İşte Neler Değişti

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Fine-tune edilmiş modellere dayanan .NET uygulamaları geliştiriyorsanız, bu ayki Foundry güncellemeleri dikkat etmeye değer. Reinforcement Fine-Tuning daha erişilebilir ve önemli ölçüde daha ucuz hale geldi.

Tüm ayrıntılar resmi duyuruda mevcut, ancak işte pratik özet.

o4-mini için Global Eğitim

o4-mini, akıl yürütme ağırlıklı ve agentic iş yükleri için tercih edilen modeldir. Büyük haber: artık 13+ Azure bölgesinden fine-tuning işleri başlatabilirsiniz; Standart eğitime kıyasla daha düşük token başına eğitim maliyetiyle. Aynı altyapı, aynı kalite, daha geniş erişim.

Ekibiniz coğrafi olarak dağıtılmışsa bu önemlidir. Artık eğitim yapabilmek için birkaç bölgeyle sınırlı değilsiniz.

Global bir eğitim işi başlatmak için REST API çağrısı:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

trainingType: globalstandard bayrağı temel farktır.

Yeni Model Grader’lar: GPT-4.1 Ailesi

Grader’lar, modelinizin optimize ettiği ödül sinyalini tanımlar. Şimdiye kadar model tabanlı grader’lar daha küçük bir model setiyle sınırlıydı. Artık üç yeni seçenek var: GPT-4.1, GPT-4.1-mini ve GPT-4.1-nano.

Deterministik grader’lar yerine model grader’larına ne zaman başvurmalısınız? Görev çıktınız açık uçluysa, birden fazla boyutta kısmi puan almanız gerekiyorsa veya araç çağrısının doğruluğunun semantik bağlama bağlı olduğu agentic iş akışları oluşturuyorsanız.

Kademeli strateji pratik:

İlk iterasyonlar için GPT-4.1-nano. Düşük maliyet, hızlı geri bildirim döngüleri.
Grading rubric’iniz stabil olduğunda ve daha yüksek doğruluğa ihtiyaç duyduğunuzda GPT-4.1-mini.
Üretim grading’i veya her puanlama kararının önemli olduğu karmaşık rubric’ler için GPT-4.1.

Tek bir RFT işinde grader türlerini bile karıştırabilirsiniz. “Doğru cevap” boyutu için string eşleşmesi ve akıl yürütme kalitesini değerlendirmek için model grader kullanın. Bu esneklik, gerçek iş yükleri için kullanışlı kılan şey.

RFT Veri Formatı Tuzağı

Bu insanları tökezletiyor. RFT veri formatı SFT’den farklıdır. Her satırdaki son mesaj User veya Developer rolünde olmalıdır — Assistant değil. Beklenen cevap, grader’ın doğrudan referans aldığı reference_answer gibi üst düzey bir anahtara gider.

Denetimli fine-tuning yapıyorsanız ve RFT’ye geçmek istiyorsanız, eğitim verilerinizi yeniden yapılandırmanız gerekir. Bu adımı atlarsanız işleriniz sessizce başarısız olur.

.NET Geliştiricileri İçin Neden Önemli?

Azure OpenAI SDK üzerinden fine-tune edilmiş modelleri .NET uygulamalarınızdan çağırıyorsanız, daha ucuz eğitim daha agresif iterasyon yapabileceğiniz anlamına gelir. Model grader seçenekleri, nüanslı görevler için fine-tuning yapabileceğiniz anlamına gelir — yalnızca tam eşleşme senaryoları için değil. GitHub‘daki en iyi pratikler kılavuzu size gerçek hata ayıklama süresi kazandıracak.

Küçük başlayın. On ila yüz örnek. Basit grader. Döngüyü doğrulayın. Sonra ölçeklendirin.

Docker Sandbox, Copilot Agent'larının Makinenizi Tehlikeye Atmadan Kodunuzu Yeniden Düzenlemesini Sağlıyor

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Copilot’un agent modunu küçük düzenlemelerin ötesinde bir şey için kullandıysanız, acısını bilirsiniz. Her dosya yazma işlemi, her terminal komutu — bir izin isteği daha. Bunu 50 proje boyunca çalıştırdığınızı düşünün. Hiç eğlenceli değil.

Azure ekibi, GitHub Copilot agent’ları için Docker Sandbox hakkında bir yazı yayımladı ve dürüst olmak gerekirse, bu gördüğüm en pratik agentic araç geliştirmelerinden biri. MicroVM’ler kullanarak Copilot’a tamamen izole bir ortam sağlıyor; orada istediği gibi davranabilir — paket yükleyebilir, build çalıştırabilir, testleri yürütebilir — ana sisteminize dokunmadan.

Docker Sandbox size gerçekte ne veriyor

Temel fikir basit: tam Linux ortamıyla hafif bir microVM başlatın, çalışma alanınızı içine senkronize edin ve Copilot agent’ının içinde serbestçe çalışmasına izin verin. İşi bittiğinde değişiklikler geri senkronize edilir.

Bunu sadece “bir container’da bir şeyler çalıştır"dan fazlası yapan şeyler şunlar:

Mutlak yolları koruyan çift yönlü çalışma alanı senkronizasyonu. Proje yapınız sandbox içinde tamamen aynı görünür. Yol kaynaklı build hataları yok.
MicroVM içinde çalışan özel Docker daemon. Agent, ana makinenizin Docker soketini bağlamak zorunda kalmadan container oluşturabilir ve çalıştırabilir. Güvenlik açısından bu büyük bir kazanım.
Agent’ın ağda neye erişebileceğini kontrol eden HTTP/HTTPS filtreleme proxy’leri. Hangi registry’lere ve endpoint’lere izin verildiğine siz karar verirsiniz. Sandbox içindeki bir npm install‘dan gelen tedarik zinciri saldırıları mı? Engellendi.
YOLO modu — evet, gerçekten böyle çağırıyorlar. Agent izin istemi olmadan çalışıyor çünkü ana makinenize gerçekten zarar veremez. Her yıkıcı eylem sandbox içinde kalıyor.

.NET geliştiricilerinin neden önemsemesi gerekiyor

Pek çok ekibin şu an karşı karşıya olduğu modernizasyon işini düşünün. .NET 9’a taşımanız gereken, 30 projelik bir .NET Framework çözümünüz var. Bu yüzlerce dosya değişikliği demek — proje dosyaları, namespace güncellemeleri, API değişiklikleri, NuGet geçişleri.

Docker Sandbox ile bir Copilot agent’ını bir projeye yönlendirebilir, microVM içinde serbestçe yeniden düzenlemesine izin verebilir, doğrulama için dotnet build ve dotnet test çalıştırabilir ve yalnızca gerçekten çalışan değişiklikleri kabul edebilirsiniz. Denemeler yaparken yerel geliştirme ortamınızı yanlışlıkla mahvetme riski yok.

Yazı ayrıca paralel agent filosu çalıştırmayı da anlatıyor — her biri kendi sandbox’ında — farklı projeleri aynı anda ele alıyor. Büyük .NET çözümleri veya microservice mimarileri için bu muazzam bir zaman tasarrufu. Servis başına bir agent, hepsi izole çalışıyor, hepsi bağımsız olarak doğrulanıyor.

Güvenlik boyutu önemli

İnsanların çoğunlukla atladığı şey şu: bir AI agent’ının rastgele komutlar yürütmesine izin verdiğinizde, ona tüm makinenizle güveniyorsunuz demektir. Docker Sandbox bu modeli tersine çeviriyor. Agent, tek kullanımlık bir ortam içinde tam özerklik alıyor. Ağ proxy’si yalnızca onaylanan kaynaklardan çekebilmesini sağlıyor. Ana makine dosya sisteminiz, Docker daemon’unuz ve kimlik bilgileriniz dokunulmadan kalıyor.

Uyumluluk gereksinimleri olan ekipler için — ki bu çoğu kurumsal .NET mağazasıdır — bu, “agentic AI kullanamayız” ile “güvenle benimseyelim” arasındaki farktır.

Sonuç

Docker Sandbox, agentic kodlamanın temel gerilimini çözüyor: agent’ların kullanışlı olabilmek için özgürlüğe ihtiyacı var, ama ana makinenizde özgürlük tehlikelidir. MicroVM’ler her ikisini de sunuyor. Büyük ölçekli herhangi bir .NET yeniden düzenleme veya modernizasyon planı yapıyorsanız, bunu şimdi kurmaya değer. Copilot’un kod zekasını güvenli bir yürütme ortamıyla birleştirmek, üretim ekiplerinin beklediği tam olarak bu.

Terminalinizi Serbest Bırakın: Aspire'ın Detached Modu İş Akışını Değiştiriyor

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Bir Aspire AppHost çalıştırdığınız her seferinde terminaliniz kayboluyor. Kilitli. Ctrl+C ile çıkana kadar meşgul. Hızlı bir komut çalıştırmanız mı gerekiyor? Yeni bir sekme açın. Logları kontrol etmek ister misiniz? Başka bir sekme. Bu küçük sürtünme hızla birikerek büyüyor.

Aspire 13.2 bunu düzeltiyor. James Newton-King tüm ayrıntıları yazdı ve dürüstçe söylemek gerekirse bu, çalışma şeklinizi anında değiştiren özelliklerden biri.

Detached mod: bir komut, terminal geri

aspire start

Bu, aspire run --detach için kısayol. AppHost’unuz arka planda başlıyor ve terminalinizi anında geri alıyorsunuz. Ekstra sekme yok. Terminal çoğullayıcı yok. Sadece prompt’unuz, hazır ve bekliyor.

Çalışanları yönetmek

İşte şu an — arka planda çalıştırmak yalnızca orada ne olduğunu gerçekten yönetebiliyorsanız işe yarıyor. Aspire 13.2 tam bunun için eksiksiz bir CLI komut seti sunuyor:

# Çalışan tüm AppHost'ları listele
aspire ps

# Belirli bir AppHost'un durumunu incele
aspire describe

# Çalışan bir AppHost'tan log akışı al
aspire logs

# Belirli bir AppHost'u durdur
aspire stop

Bu, Aspire CLI’ı gerçek anlamda bir süreç yöneticisine dönüştürüyor. Birden fazla AppHost başlatabilir, durumlarını kontrol edebilir, loglarını takip edebilir ve bunları kapatabilirsiniz — hepsi tek bir terminal oturumundan.

Isolated modla birleştirin

Detached mod, isolated modla doğal olarak uyum içinde çalışır. Port çakışması olmadan aynı projenin iki örneğini arka planda çalıştırmak ister misiniz?

aspire start --isolated
aspire start --isolated

Her biri rastgele portlar, ayrı secret’lar ve kendi yaşam döngüsü alıyor. Her ikisini görmek için aspire ps, işi bitenini kapatmak için aspire stop kullanın.

Bu neden kodlama ajanları için büyük bir gelişme

İşte gerçekten ilgi çekici olan kısım. Terminalinizde çalışan bir kodlama ajanı artık şunları yapabiliyor:

aspire start ile uygulamayı başlatmak
aspire describe ile durumunu sorgulamak
Sorunları teşhis etmek için aspire logs ile logları kontrol etmek
İşi bittiğinde aspire stop ile durdurmak

Terminal oturumunu kaybetmeden. Detached moddan önce, AppHost’unuzu çalıştıran bir ajan kendi terminaline erişimini kaybederdi. Artık başlatabilir, gözlemleyebilir, yineleyebilir ve temizleyebilir — tam olarak özerk bir ajanın çalışmasını isteyeceğiniz şekilde.

Aspire ekibi bunu benimsedi. aspire agent init çalıştırmak, ajanlara bu komutları öğreten bir Aspire skill dosyası kuruyor. Bu sayede Copilot’un kodlama ajanı gibi araçlar Aspire iş yüklerinizi kutudan çıkar çıkmaz yönetebiliyor.

Özet

Detached mod, basit bir bayrak kılığında gizlenmiş bir iş akışı yükseltmesi. Terminaller arasında bağlam geçişlerini bırakıyorsunuz, ajanlar kendilerini bloke etmekten kurtuluyor ve yeni CLI komutları çalışanlar hakkında gerçek görünürlük sağlıyor. Pratik, temiz ve günlük geliştirme döngüsünü belirgin biçimde daha akıcı hale getiriyor.

Tüm ayrıntılar için tam yazıyı okuyun ve aspire update --self ile Aspire 13.2’yi edinin.

.NET MAUI Maps'e Nihayet Pin Kümeleme Geldi — Tek Özellik, Sıfır Acı

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Yüz pin’li bir harita yüklediğinizde ve her şeyin okunaksız bir kümreye dönüştüğü o anı bilirsiniz, değil mi? Evet, .NET MAUI Maps deneyimi şimdiye kadar tam olarak buydu. Artık değil.

David Ortinau, .NET MAUI 11 Preview 3’ün Android ve iOS/Mac Catalyst üzerinde kutudan çıkar çıkmaz pin kümeleme sunduğunu duyurdu. Ve en iyi kısım — etkinleştirmek gülünç derecede basit.

Hepsini Yöneten Tek Özellik

<maps:Map IsClusteringEnabled="True" />

Hepsi bu kadar. Yakın pinler, sayı rozeti olan kümeler halinde gruplanır. Yakınlaştırın ve genişlerler. Uzaklaştırın ve daralırlar. Kullanıcıların modern bir haritadan beklediği türden davranış — ve artık tek bir özellikle elde ediyorsunuz.

Bağımsız Kümeleme Grupları

İşte ilginçleştiği yer burası. Tüm pinler birlikte kümelenmemelidir. Kahve dükkanları ve parklar farklı şeylerdir ve haritanız bunu bilmelidir.

ClusteringIdentifier özelliği, pinleri bağımsız gruplara ayırmanızı sağlar:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Aynı tanımlayıcıya sahip pinler birlikte kümelenir. Farklı tanımlayıcılar, coğrafi olarak yakın olsalar bile bağımsız kümeler oluşturur. Tanımlayıcı yok mu? Varsayılan grup. Temiz ve öngörülebilir.

Küme Tap’larını Yönetme

Bir kullanıcı kümeye dokunduğunda, ihtiyacınız olan her şeyle birlikte bir ClusterClicked olayı alırsınız:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Varsayılan kümeye-yakınlaştırma davranışını bastır:
 // e.Handled = true;
};

Olay argümanları size Pins (kümedeki pinler), Location (coğrafi merkez) ve Handled (varsayılanı geçersiz kılmak istiyorsanız true olarak ayarlayın) sunar. Basit, pratik, tam olarak beklediğiniz şey.

Bilmeye Değer Platform Ayrıntıları

Android’de kümeleme, zoom değişikliklerinde yeniden hesaplanan özel ızgara tabanlı bir algoritma kullanır — harici bağımlılık yok. iOS ve Mac Catalyst’te, sorunsuz, platform-native animasyonlar anlamına gelen MapKit’ten yerel MKClusterAnnotation desteğinden yararlanır.

Bu, MAUI ekibinin doğru kararı verdiği durumlardan biri — mantıklı olduğunda platforma güvenmek.

Neden Önemli?

Pin kümeleme, .NET MAUI’de en çok talep edilen özelliklerden biri olmuştur (issue #11811), ve bunun iyi bir nedeni var. Haritada konumları gösteren her uygulama — teslimat takibi, mağaza bulucu, gayrimenkul — buna ihtiyaç duyar. Daha önce bunu kendiniz oluşturmanız veya üçüncü taraf bir kütüphane getirmeniz gerekiyordu. Artık yerleşik.

Cross-platform mobil uygulamalar geliştiren .NET geliştiricileri için bu, MAUI’yi harita yoğun senaryolar için gerçekten pratik bir tercih haline getiren türden bir yaşam kalitesi iyileştirmesi.

Başlarken

.NET 11 Preview 3‘ü kurun ve .NET MAUI iş yükünü güncelleyin. Maps örneği, hemen oynayabileceğiniz yeni bir Clustering sayfası içeriyor.

Gidin ve onunla bir şeyler oluşturun — haritalarınızın nihayet nefes almasına izin verin.

Azure MCP Araçları Artık Visual Studio 2022'ye Entegre — Uzantı Gerekmiyor

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Azure MCP araçlarını ayrı uzantı üzerinden Visual Studio’da kullandıysanız, süreci biliyorsunuzdur — VSIX’i kurun, yeniden başlatın, bir şeylerin bozulmamasını umun, sürüm uyumsuzluklarıyla uğraşın. O sürtünme artık tarihe karışıyor.

Yun Jung Choi duyurdu: Azure MCP araçları artık Visual Studio 2022’de Azure geliştirme iş yükünün doğrudan bir parçası olarak geliyor. Uzantı yok. VSIX yok. Yeniden başlatma dansı yok.

Bu aslında ne anlama geliyor

Visual Studio 2022 sürüm 17.14.30 itibarıyla Azure MCP Server, Azure geliştirme iş yüküyle birlikte geliyor. Bu iş yükünü zaten yüklediyseniz, tek yapmanız gereken GitHub Copilot Chat’te etkinleştirip kullanmaya başlamak.

45 Azure servisi genelinde 230’dan fazla araç — doğrudan sohbet penceresinden erişilebilir. Depolama hesaplarınızı listeleyin, ASP.NET Core uygulaması dağıtın, App Service sorunlarını tanılayın, Log Analytics’i sorgulayın — tek bir tarayıcı sekmesi açmadan.

Bu neden göründüğünden daha önemli

Geliştirici araçlarındaki şu gerçeği biliyoruz: her ekstra adım sürtünmedir, sürtünme ise benimsemeyi öldürür. MCP’nin ayrı bir uzantı olması; sürüm uyumsuzlukları, kurulum hataları ve güncel tutulması gereken bir şey daha demekti. İş yüküne entegre etmek şu anlama geliyor:

Visual Studio Installer üzerinden tek güncelleme yolu
Uzantı ile IDE arasında sürüm kayması yok
Her zaman güncel — MCP Server, düzenli VS sürümleriyle birlikte güncelleniyor

Azure üzerinde standartlaştıran ekipler için bu büyük bir avantaj. İş yükünü bir kez kuruyorsunuz, araçları etkinleştiriyorsunuz ve her oturumda hazır oluyorlar.

Bununla neler yapabilirsiniz

Araçlar Copilot Chat üzerinden tüm geliştirme yaşam döngüsünü kapsıyor:

Öğrenin — Azure servisleri, en iyi pratikler, mimari kalıplar hakkında sorular sorun
Tasarlayın ve geliştirin — servis önerileri alın, uygulama kodunu yapılandırın
Dağıtın — kaynakları sağlayın ve doğrudan IDE’den dağıtın
Sorun giderin — günlükleri sorgulayın, kaynak sağlığını kontrol edin, üretim sorunlarını tanılayın

Hızlı bir örnek — Copilot Chat’e şunu yazın:

List my storage accounts in my current subscription.

Copilot, arka planda Azure MCP araçlarını çağırır, aboneliklerinizi sorgular ve isimler, konumlar ve SKU’larla birlikte biçimlendirilmiş bir liste döndürür. Portal gerekmez.

Nasıl etkinleştirilir

Visual Studio 2022 17.14.30 veya üzerine güncelleyin
Azure development iş yükünün yüklendiğinden emin olun
GitHub Copilot Chat’i açın
Select tools düğmesine tıklayın (iki İngiliz anahtarı simgesi)
Azure MCP Server‘ı etkinleştirin

Hepsi bu. Oturumlar arasında etkin kalır.

Bir not

Araçlar varsayılan olarak devre dışıdır — katılımınız gerekiyor. VS 2026’ya özgü araçlar VS 2022’de mevcut değil. Araç kullanılabilirliği de portaldaki gibi Azure abonelik izinlerinize bağlı.

Büyük resim

Bu, net bir trendin parçası: MCP, bulut araçlarını geliştirici IDE’lerinde sunmanın standart yolu haline geliyor. Azure MCP Server 2.0 kararlı sürümünü ve VS Code ile diğer editörlerdeki MCP entegrasyonlarını zaten gördük. Visual Studio’nun iş yükü sistemine entegre olması doğal bir ilerleme.

Visual Studio’da yaşayan .NET geliştiricileri olarak bu, Azure portalına bağlam değiştirmek için bir neden daha ortadan kalkıyor. Ve dürüst olmak gerekirse, ne kadar az sekme değiştirirsek o kadar iyi.

.NET Nisan 2026 Bakım Güncellemesi — Bugün Uygulamanız Gereken Güvenlik Yamaları

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

.NET ve .NET Framework için Nisan 2026 bakım güncellemeleri yayımlandı ve bu sürüm yakında uygulamak isteyeceğiniz güvenlik düzeltmelerini içeriyor. İki uzaktan kod yürütme (RCE) açığı dahil olmak üzere altı CVE yamalandı.

Neler yamalandı

İşte hızlı özet:

CVE	Tür	Etkileyen
CVE-2026-26171	Güvenlik Özelliği Atlatma	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Uzaktan Kod Yürütme	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Uzaktan Kod Yürütme	.NET 10, 9, 8
CVE-2026-32203	Hizmet Reddi	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Hizmet Reddi	.NET Framework 3.0–4.8.1
CVE-2026-32226	Hizmet Reddi	.NET Framework 2.0–4.8.1

İki RCE CVE’si (CVE-2026-32178 ve CVE-2026-33116) en geniş .NET sürümü yelpazesini etkiliyor ve öncelikli olarak ele alınmalı.

Güncellenen sürümler

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Tümü olağan kanallar aracılığıyla mevcut — dotnet.microsoft.com, MCR’deki container imajları ve Linux paket yöneticileri.

Ne yapmalısınız

Projelerinizi ve CI/CD pipeline’larınızı en son yama sürümlerine güncelleyin. Container çalıştırıyorsanız, en son imajları çekin. .NET Framework kullanıyorsanız, ilgili yamalar için .NET Framework sürüm notlarına bakın.

Üretimde .NET 10 çalıştıranlar için (şu an güncel sürüm), 10.0.6 zorunlu bir güncellemedir. Bu LTS sürümlerindeyseniz .NET 9.0.15 ve .NET 8.0.26 için de aynısı geçerli. İki RCE açığı ertelenerek geçiştirilebilecek bir şey değildir.

Aspire 13.2, MongoDB EF Core ve Azure Data Lake Desteği Kazandı — Denemeye Değer İki Entegrasyon

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 dikkatinizi çekmeye değer iki yeni veritabanı entegrasyonuyla yayımlandı: MongoDB Entity Framework Core ve Azure Data Lake Storage. Bir Aspire uygulamasında MongoDB ile EF Core kullanmak istiyorsanız veya uygun servis keşfiyle data lake iş yüklerini bağlamanız gerekiyorsa, bu sürüm her ikisini de sunuyor.

MongoDB, Aspire’da EF Core ile buluşuyor

En çok heyecanlandığım bu. Aspire bir süredir MongoDB’yi destekliyordu ama her zaman ham sürücüydü — EF Core yok, DbContext yok, belgelerinize karşı LINQ sorgusu yok. Artık MongoDB ile tam EF Core deneyimini, ayrıca Aspire’ın otomatik sağlık kontrolleri ve servis keşfini elde ediyorsunuz.

Kurulum, tipik Aspire desenidir. AppHost’unuzda:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Ardından tüketen projenize EF Core entegrasyonunu ekleyin:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Ve DbContext‘inizi kaydedin:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Oradan itibaren standart EF Core. Varlıklarınızı tanımlayın, DbContext‘inizi herhangi bir sağlayıcıyla kullandığınız gibi kullanın. Entegrasyon, bağlantı havuzlamasını, OpenTelemetry izlerini ve sağlık kontrollerini arka planda yönetir.

Ham sürücüyle MongoDB kullanan ve bağlantı dizelerini manuel olarak ayarlayan .NET geliştiricileri için bu, güzel bir yaşam kalitesi yükseltmesi. Aspire’ın servis keşfini kaybetmeden tam EF Core soyutlamasını elde ediyorsunuz.

Azure Data Lake Storage katılıyor

İkinci büyük ekleme, Azure Data Lake Storage (ADLS) entegrasyonu. Veri pipeline’ları, ETL süreçleri veya analitik platformlar geliştiriyorsanız, artık Data Lake kaynaklarını herhangi bir diğer Aspire bağımlılığını bağladığınız gibi bağlayabilirsiniz.

AppHost’ta:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Tüketen projede:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Manuel bağlantı dizesi yönetimi yok, kimlik bilgisi avcılığı yok. Aspire kaynakları sağlar ve enjekte eder. Hem operasyonel veriye hem de analitik iş yüklerine dokunan cloud-native .NET uygulamaları geliştiriyorsanız, bu data lake’i Aspire modelinde birinci sınıf vatandaş gibi hissettiriyor.

Önemli küçük düzeltmeler

Manşet özelliklerin ötesinde, dikkate değer birkaç yaşam kalitesi iyileştirmesi var:

MongoDB bağlantı dizesi düzeltmesi — veritabanı adından önce eğik çizgi artık doğru şekilde işleniyor. Bunun etrafından dolaşıyorsanız, o geçici çözümü kaldırabilirsiniz
SQL Server dışa aktarmaları — Aspire.Hosting.SqlServer artık daha ince ayarlı kontrol için ek sunucu yapılandırma seçenekleri dışa aktarıyor
Emülatör güncellemeleri — ServiceBus emülatörü 2.0.0, App Configuration emülatörü 1.0.2 ve CosmosDB’nin önizleme emülatörü artık bir hazır olma kontrolü içeriyor
Azure Managed Redis — artık varsayılan olarak rediss:// (Redis Secure) kullanıyor; bağlantılar kutudan çıktığı gibi şifreli

Son madde ince ama önemli — varsayılan olarak şifreli Redis, üretimde yapılandırılacak bir şey daha az demek.

Sonuç

Aspire 13.2 artımlı bir sürüm, ancak MongoDB EF Core ve Data Lake entegrasyonları gerçek boşlukları dolduruyor. Aspire’da MongoDB için uygun EF Core desteğini bekliyorsanız veya Data Lake’in birinci sınıf bağımlılık olmasına ihtiyacınız varsa, 13.2’ye yükseltin ve bir deneyin. aspire add komutu ihtiyacınız olan her şeyi iskelet haline getiriyor.

Daha fazla ayrıntı için tam sürüm notlarını okuyun ve tam liste için entegrasyon galerisine göz atın.

azd update — Tüm Paket Yöneticileriniz İçin Tek Bir Komut

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Her birkaç haftada bir beliren “azd’nin yeni bir sürümü mevcut” mesajını biliyor musunuz? azd‘yi winget, Homebrew veya altı ay önce çalıştırdığınız curl betiğiyle mi yüklediğinizi hatırlayamadığınız için görmezden geldiğiniz mesajı? Evet, bu sonunda düzeldi.

Microsoft, azd update‘i piyasaya sürdü — Azure Developer CLI’ı, başlangıçta nasıl yüklediğinizden bağımsız olarak en son sürüme güncelleyen tek bir komut. Windows, macOS, Linux — fark etmiyor. Tek komut.

Nasıl çalışıyor

azd update

Hepsi bu. Yeni özelliklere erken erişim istiyorsanız, günlük insiders derlemesine geçebilirsiniz:

azd update --channel daily
azd update --channel stable

Komut, mevcut kurulum yönteminizi algılar ve arka planda uygun güncelleme mekanizmasını kullanır. Artık “bu makinede winget mi yoksa choco mu kullandım?” sorusuna gerek yok.

Küçük bir uyarı

azd update, 1.23.x sürümünden itibaren gönderilmeye başlandı. Daha eski bir sürümdeyseniz, orijinal kurulum yönteminizi kullanarak son bir manuel güncelleme yapmanız gerekecek. Bundan sonra azd update her şeyi halleder.

Mevcut sürümünüzü azd version ile kontrol edin. Yeni bir kuruluma ihtiyacınız varsa, kurulum dokümanları size yol gösterir.

Neden önemli

Bu küçük bir yaşam kalitesi iyileştirmesi, ancak Azure’a AI ajanları ve Aspire uygulamaları dağıtmak için azd‘yi günlük kullananlar için güncel kalmak daha az “bu hata zaten son sürümde düzeltilmişti” anı demek. Düşünmek zorunda kalmamanız gereken bir şey daha.

Daha fazla bağlam için tam duyuruyu ve Jon Gallant’ın daha ayrıntılı incelemesini okuyun.

Azure DevOps Server Nisan 2026 Yaması — PR Tamamlama Düzeltmesi ve Güvenlik Güncellemeleri

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Self-hosted Azure DevOps Server kullanan ekipler için hızlı bir hatırlatma: Microsoft, üç hedefli düzeltmeyle birlikte Nisan 2026 için Patch 3‘ü yayınladı.

Neler düzeltildi

Pull request tamamlama hataları — iş öğesi otomatik tamamlama sırasında ortaya çıkan bir null reference exception, PR merge işlemlerinin başarısız olmasına neden olabiliyordu. Rastgele PR tamamlama hatalarıyla karşılaştıysanız, muhtemelen nedeni buydu
Oturum kapatma yönlendirme doğrulaması — potansiyel kötü niyetli yönlendirmeleri önlemek amacıyla oturum kapatma sırasındaki doğrulama iyileştirildi. Bu, bir an önce uygulanmaya değer bir güvenlik düzeltmesi
GitHub Enterprise Server PAT bağlantıları — GitHub Enterprise Server’a Personal Access Token bağlantıları oluşturmak bozuktu, artık düzeltildi

Nasıl güncellenir

Patch 3‘ü indirin ve yükleyiciyi çalıştırın. Yamanın uygulandığını doğrulamak için:

<patch-installer>.exe CheckInstall

Azure DevOps Server’ı şirket içinde çalıştırıyorsanız Microsoft, hem güvenlik hem de güvenilirlik açısından en güncel yamada kalmayı güçlü bir şekilde öneriyor. Tam ayrıntılar için sürüm notlarına bakın.

Azure Smart Tier Genel Kullanıma Açıldı — Yaşam Döngüsü Kuralları Olmadan Otomatik Blob Depolama Maliyet Optimizasyonu

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Azure Blob Storage yaşam döngüsü politikalarını ayarlamak için zaman harcadınız ve ardından erişim kalıpları değişince bunların çöktüğünü izlediyseniz, bu yazı sizin için. Microsoft, Azure Blob ve Data Lake Storage için smart tier’ın genel kullanıma açıldığını duyurdu — nesneleri gerçek kullanıma göre hot, cool ve cold katmanları arasında otomatik olarak taşıyan, tam yönetimli bir katmanlama özelliği.

Smart tier aslında ne yapıyor

Konsept basit: smart tier, depolama hesabınızdaki her nesnenin son erişim zamanını sürekli değerlendiriyor. Sık erişilen veriler hot’ta kalıyor, etkin olmayan veriler 30 gün sonra cool’a geçiyor ve ardından 60 gün sonra cold’a iniyor. Verilere tekrar erişildiğinde hemen hot’a geri yükseltiliyor. Döngü yeniden başlıyor.

Yapılandırılacak yaşam döngüsü kuralı yok. Erişim kalıbı tahmini yok. Manuel ayarlama yok.

Önizleme sürecinde Microsoft, smart tier tarafından yönetilen kapasitenin %50’sinden fazlasının gerçek erişim kalıplarına göre otomatik olarak daha soğuk katmanlara geçtiğini bildirdi. Büyük depolama hesapları için bu anlamlı bir maliyet azalması.

Bu .NET geliştiricileri için neden önemli

Günlük, telemetri, analitik veri veya büyüyen herhangi bir veri kümesi üreten uygulamalar geliştiriyorsanız — ki dürüst olmak gerekirse kim üretmiyor — depolama maliyetleri hızla artıyor. Geleneksel yaklaşım, yaşam döngüsü yönetim politikaları yazmak, bunları test etmek ve uygulamanızın erişim kalıpları değiştiğinde yeniden ayarlamaktı. Smart tier bu iş akışının tamamını ortadan kaldırıyor.

Bunun işe yaradığı pratik senaryolar:

Uygulama telemetrisi ve günlükleri — hata ayıklama sırasında hot, birkaç hafta sonra nadiren erişilen
Veri pipeline’ları ve ETL çıktıları — işleme sırasında yoğun erişim, ardından çoğunlukla cold
Kullanıcı tarafından oluşturulan içerik — son yüklemeler hot, eski içerik zamanla soğuyor
Yedekleme ve arşiv verileri — uyumluluk için ara sıra erişilen, çoğunlukla atıl

Kurulum

Smart tier’ı etkinleştirmek tek seferlik bir yapılandırma:

Yeni hesaplar: Depolama hesabı oluşturma sırasında varsayılan erişim katmanı olarak smart tier’ı seçin (bölgesel yedeklilik gereklidir)
Mevcut hesaplar: Blob erişim katmanını mevcut varsayılandan smart tier’a geçirin

128 KiB’den küçük nesneler hot’ta kalır ve izleme ücretine tabi değildir. Diğer her şey için katman geçiş ücreti, erken silme ücreti ve veri alma maliyeti olmaksızın standart hot/cool/cold kapasite ücretleri ödüyorsunuz. Nesne başına aylık bir izleme ücreti orkestrasyon maliyetini karşılıyor.

Bilmeniz gereken takas

Smart tier’ın katmanlama kuralları sabit (30 gün → cool, 90 gün → cold). Belirli bir iş yükü için 7 günde cool’a geçmek gibi özel eşikler ihtiyacınız varsa, yaşam döngüsü kuralları hâlâ doğru seçenek. İkisini de karıştırmayın: smart tier tarafından yönetilen nesnelerde yaşam döngüsü kurallarından kaçının, çünkü çakışabilirler.

Sonuç

Bu devrim niteliğinde değil, ama gerçek bir operasyonel baş ağrısını çözüyor. Büyüyen blob depolama hesaplarını yönetiyorsanız ve yaşam döngüsü politikalarını korumaktan bıktıysanız, smart tier’ı etkinleştirin ve Azure’un üstlenmesine izin verin. Neredeyse tüm bölgesel genel bulut bölgelerinde bugün itibariyle kullanılabilir.

Azure'da AI Ajanlarınızı Nerede Barındırmalısınız? Pratik Bir Karar Rehberi

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Şu an .NET ile AI ajanları geliştiriyorsanız, muhtemelen bunu fark etmişsinizdir: Azure’da bunları barındırmanın pek çok yolu var. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — ve gerçekten birini seçmeniz gerekene kadar hepsi makul görünüyor. Microsoft, bunu netleştiren Azure AI ajan barındırma için kapsamlı bir rehber yayımladı ve ben bunu pratik bir .NET geliştirici perspektifinden ele almak istiyorum.

Altı seçeneğe genel bakış

Ortamı şöyle özetlerim:

Seçenek	En iyi kullanım	Siz yönetirsiniz
Container Apps	K8s karmaşıklığı olmadan tam container kontrolü	Gözlemlenebilirlik, durum, yaşam döngüsü
AKS	Kurumsal uyumluluk, çok kümeli, özel ağ	Her şey (bu onun amacı)
Azure Functions	Olay odaklı, kısa süren ajan görevleri	Çok az — gerçek serverless
App Service	Basit HTTP ajanları, öngörülebilir trafik	Dağıtım, ölçeklendirme yapılandırması
Foundry Agents	Portal/SDK aracılığıyla kod gerektirmeyen ajanlar	Neredeyse hiçbir şey
Foundry Hosted Agents	Yönetilen altyapıyla özel framework ajanları	Yalnızca ajan kodunuz

İlk dördü genel amaçlı işlem — üzerlerinde ajan çalıştırabilirsiniz, ancak bunlar bunun için tasarlanmadı. Son ikisi ajan doğasında: konuşmaları, araç çağrılarını ve ajan yaşam döngülerini birinci sınıf kavramlar olarak anlıyorlar.

Foundry Hosted Agents — .NET ajan geliştiricileri için tatlı nokta

İşte dikkatimi çeken kısım. Foundry Hosted Agents tam ortada duruyor: kendi kodunuzu çalıştırma esnekliğini alıyorsunuz (Semantic Kernel, Agent Framework, LangGraph — her neyse), ancak platform altyapıyı, gözlemlenebilirliği ve konuşma yönetimini üstleniyor.

Kilit parça Hosting Adapter — ajan framework’ünüzü Foundry platformuna köprüleyen ince bir soyutlama katmanı. Microsoft Agent Framework için şöyle görünüyor:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Barındırma hikayenizin tamamı bu. Adapter, protokol çevirisini, server-sent events aracılığıyla streaming’i, konuşma geçmişini ve OpenTelemetry izlemeyi otomatik olarak hallediyor. Özel middleware yok, manuel bağlantı yok.

Dağıtım gerçekten basit

Daha önce Container Apps’e ajan dağıttım ve çalışıyor, ancak durum yönetimi ve gözlemlenebilirlik için çok fazla yapıştırıcı kod yazıyorsunuz. Hosted Agents ve azd ile dağıtım şöyle:

# AI agent uzantısını yükle
azd ext install azure.ai.agents

# Bir şablondan başlat
azd ai agent init

# Derle, gönder, dağıt — tamam
azd up

Tek azd up komutu, container’ınızı derliyor, ACR’a gönderiyor, Foundry projesini oluşturuyor, model endpoint’lerini dağıtıyor ve ajanınızı başlatıyor. Beş adım tek komuta indirgeniyor.

Yerleşik konuşma yönetimi

Bu, üretimde en çok zaman kazandıran kısım. Kendi konuşma durum deposunuzu oluşturmak yerine, Hosted Agents bunu doğal olarak hallediyor:

# Kalıcı bir konuşma oluştur
conversation = openai_client.conversations.create()

# İlk tur
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Unutma: favori numaram 42.",
)

# İkinci tur — bağlam korunuyor
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Favori numamı 10 ile çarp.",
)

Redis yok. Cosmos DB oturum deposu yok. Mesaj serileştirme için özel middleware yok. Platform sadece hallediyor.

Karar çerçevem

Altı seçeneğin tamamını inceledikten sonra, işte hızlı zihinsel modelim:

Sıfır altyapı mı istiyorsunuz? → Foundry Agents (portal/SDK, container yok)
Özel ajan kodunuz var ama yönetilen barındırma mı istiyorsunuz? → Foundry Hosted Agents
Olay odaklı, kısa ömürlü ajan görevlerine mi ihtiyacınız var? → Azure Functions
K8s olmadan maksimum container kontrolü mü istiyorsunuz? → Container Apps
Katı uyumluluk ve çok kümeli mimariye mi ihtiyacınız var? → AKS
Öngörülebilir trafikli basit bir HTTP ajanınız mı var? → App Service

Semantic Kernel veya Microsoft Agent Framework ile geliştiren çoğu .NET geliştirici için, Hosted Agents muhtemelen doğru başlangıç noktası. Sıfıra ölçekleme, yerleşik OpenTelemetry, konuşma yönetimi ve framework esnekliği alıyorsunuz — Kubernetes yönetmeden veya kendi gözlemlenebilirlik yığınınızı bağlamadan.

Özet

Azure’daki ajan barındırma ortamı hızla olgunlaşıyor. Bugün yeni bir AI ajan projesi başlatıyorsanız, alışkanlıkla Container Apps veya AKS’e uzanmadan önce Foundry Hosted Agents’ı ciddi olarak değerlendirirdim. Yönetilen altyapı gerçek zaman kazandırıyor ve hosting adapter modeli, framework seçiminizi korumanıza olanak tanıyor.

Çalışan örnekler için Microsoft’ın tam rehberine ve Foundry Samples reposuna göz atın.

.NET'te Agent Skills Ciddi Anlamda Esnek Hale Geldi

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Microsoft Agent Framework ile agent geliştiriyorsanız rutini bilirsiniz: skill’leri tanımlarsınız, bir provider’a bağlarsınız ve agentın hangisini çağıracağına karar vermesini beklersiniz. Yeni olan şey ise bu skill’leri nasıl yazdığınız — ve esneklik sıçraması önemli.

Son güncelleme, agent skill’leri için üç farklı yazım deseni sunuyor: dosya tabanlı, sınıf tabanlı ve satır içi kod tanımlı. Üçü de tek bir AgentSkillsProviderBuilder‘a takılır; yani herhangi bir yönlendirme mantığı veya özel bağlantı kodu olmadan bunları karıştırıp eşleştirebilirsiniz. Her birini ve ne zaman kullanacağınızı anlatalım.

Dosya tabanlı skill’ler: başlangıç noktası

Dosya tabanlı skill’ler tam olarak adından anlaşıldığı gibi — diskte bir SKILL.md dosyası, isteğe bağlı scriptler ve referans belgelerle dolu bir dizin. Agentınıza yeni yetenekler vermenin en doğrudan yolu olarak düşünün:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md frontmatter’ı skill adını ve açıklamasını bildirir, talimatlar bölümü ise agenta scriptleri ve referansları nasıl kullanacağını söyler:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ardından script yürütmesi için SubprocessScriptRunner.RunAsync ile bağlantı kurarsınız:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Agent, skill’i otomatik olarak keşfeder ve hesap durumunu kontrol etmesi gerektiğinde provisioning scriptini çağırır. Temiz ve basit.

Sınıf tabanlı skill’ler: NuGet üzerinden yayımlayın

İşte ekipler için ilginç kısım. Sınıf tabanlı skill’ler AgentClassSkill<T>‘dan türetilir ve [AgentSkillResource] ile [AgentSkillScript] gibi attribute’lar kullanır; framework her şeyi yansıma (reflection) yoluyla keşfeder:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Buradaki güzellik, bir ekibin bunu NuGet paketi olarak paketleyebilmesidir. Projenize eklersiniz, builder’a bırakırsınız ve dosya tabanlı skill’lerinizle sıfır koordinasyonla birlikte çalışır:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Her iki skill de agentın sistem prompt’unda görünür. Agent, konuşmaya göre hangisini kullanacağına karar verir — yönlendirme kodu gerekmez.

Satır içi skill’ler: hızlı köprü

Başka bir ekibin tam ihtiyacınız olan skill’i geliştirdiğini ama bir sprint boyunca yayımlanmayacağını bildiğiniz anı tanıyor musunuz? AgentInlineSkill köprünüzdür:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Diğerleri gibi builder’a ekleyin:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGet paketi sonunda yayımlandığında, satır içi skill’i sınıf tabanlıyla değiştirirsiniz. Agent farkı anlamaz.

Ancak satır içi skill’ler sadece köprü için değil. Çalışma zamanında dinamik olarak skill üretmeniz gerektiğinde de doğru seçimdir — config’den yüklenen iş birimi başına bir skill gibi — veya bir scriptin DI container’ına ait olmayan yerel durumu kapatması (closure) gerektiğinde.

Script onayı: human-in-the-loop

Üretim agentları geliştiren .NET geliştiricileri için bu, dağıtım konuşmalarını gerçekten açık eden kısım. Bazı scriptlerin gerçek sonuçları var — birini sigorta planına kaydetmek, üretim altyapısını sorgulamak. UseScriptApproval‘ı açın ve agent herhangi bir scripti çalıştırmadan önce duraklar:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Agent bir script çalıştırmak istediğinde, bunun yerine bir onay isteği döndürür. Uygulamanız kararı toplar — onayla veya reddet — ve agent buna göre devam eder. Düzenlenmiş ortamlarda bu, “bunu dağıtabiliriz” ile “hukuk hayır diyor” arasındaki farktır.

Bu kombinasyonun önemi

Gerçek güç tek bir yazım deseninde değil — kompozisyondadır. Şunları yapabilirsiniz:

Küçük başlayın dosya tabanlı skill ile, talimatlarda yineleyin ve C# yazmadan yayımlayın
Yeniden kullanılabilir skill’ler yayımlayın NuGet paketleri olarak; diğer ekipler tek satırla ekleyebilir
Boşlukları kapatın satır içi skill’lerle ihtiyacınız olan şeyi hemen geliştirmek için
Paylaşılan skill dizinlerini filtreleyin predicate’lerle, agentınızın yalnızca gereken şeyi yüklemesi için
İnsan denetimi ekleyin üretim sistemlerine dokunan scriptler için

Bunların tümü AgentSkillsProviderBuilder üzerinden birleşir. Özel yönlendirme, koşullu mantık, skill tür kontrolleri yok.

Sonuç

.NET’te agent skill’leri artık gerçekten esnek bir yazım modeline sahip. İster dosya tabanlı skill’lerle prototip çizen solo bir geliştirici olun, ister NuGet aracılığıyla paketlenmiş yetenekler yayımlayan kurumsal bir ekip, desenler her duruma uyuyor. Ve script onay mekanizması, insan denetim noktasına ihtiyaç duyduğunuz ortamlar için üretime hazır hale getiriyor.

Tam rehber için orijinal duyuruya, Microsoft Learn’deki Agent Skills belgelerine ve uygulamalı deneyim için GitHub’daki .NET örneklerine göz atın.

Azure MCP Server 2.0 Yayınlandı — Self-Hosted Agentic Bulut Otomasyonu Artık Burada

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Son zamanlarda MCP ve Azure ile bir şeyler geliştirdiyseniz, yerel deneyimin gayet iyi çalıştığını muhtemelen zaten biliyorsunuzdur. Bir MCP server bağlayın, AI agent’ınızın Azure kaynaklarıyla konuşmasına izin verin, devam edin. Ama bu kurulumu bir ekip genelinde paylaşmanız gerektiğinde? İşte orada işler karmaşıklaşıyordu.

Artık değil. Azure MCP Server 2.0 kararlı sürüme ulaştı ve başlık özelliği tam olarak kurumsal ekiplerin istediği şey: self-hosted uzak MCP server desteği.

Azure MCP Server nedir?

Kısa bir hatırlatma. Azure MCP Server, Model Context Protocol spesifikasyonunu uygular ve Azure yeteneklerini AI agent’larının çağırabileceği yapılandırılmış, keşfedilebilir araçlar olarak sunar. Agent’ınız ile Azure arasında standartlaştırılmış bir köprü olarak düşünebilirsiniz — sağlama, dağıtım, izleme, tanılama, hepsi tek tutarlı bir arayüz üzerinden.

Rakamlar kendisi konuşuyor: 57 Azure servisi genelinde 276 MCP aracı. Bu ciddi bir kapsam.

Büyük haber: self-hosted uzak dağıtımlar

Şöyle ki. MCP’yi kendi makinenizde yerel olarak çalıştırmak geliştirme ve deneyler için sorun değil. Ama gerçek bir ekip senaryosunda şunlara ihtiyacınız var:

Geliştiriciler ve dahili agent sistemleri için paylaşımlı erişim
Merkezi yapılandırma (tenant bağlamı, abonelik varsayılanları, telemetri)
Kurumsal ağ ve politika sınırları
CI/CD pipeline’larına entegrasyon

Azure MCP Server 2.0 tüm bunları ele alıyor. HTTP tabanlı taşıma, uygun kimlik doğrulama ve tutarlı yönetişimle merkezi olarak yönetilen bir dahili servis olarak dağıtabilirsiniz.

Kimlik doğrulama için iki sağlam seçenek var:

Managed Identity — Microsoft Foundry ile birlikte çalışırken
On-Behalf-Of (OBO) akışı — Azure API’lerini oturum açmış kullanıcının bağlamını kullanarak çağıran OpenID Connect delegasyonu

Bu OBO akışı, .NET geliştiricileri olarak bizim için özellikle ilginç. Agentic iş akışlarınızın aşırı ayrıcalıklı bir servis hesabı yerine kullanıcının gerçek izinleriyle çalışabileceği anlamına geliyor. En az ayrıcalık ilkesi, doğrudan yerleşik.

Güvenlik güçlendirmesi

Bu yalnızca bir özellik sürümü değil — aynı zamanda bir güvenlik sürümü. 2.0 sürümü şunları ekliyor:

Daha güçlü endpoint doğrulaması
Sorgu odaklı araçlarda injection kalıplarına karşı koruma
Geliştirme ortamları için daha sıkı izolasyon kontrolleri

MCP’yi paylaşımlı bir servis olarak sunacaksanız, bu güvenceler önemli. Çok önemli.

Nerede kullanabilirsiniz?

İstemci uyumluluk hikayesi geniş. Azure MCP Server 2.0 şunlarla çalışıyor:

IDE’ler: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agent’ları: GitHub Copilot CLI, Claude Code
Bağımsız: basit kurulumlar için yerel server
Self-hosted uzak: 2.0’ın yeni yıldızı

Ayrıca düzenlenmiş dağıtımlar için kritik olan Azure US Government ve 21Vianet tarafından işletilen Azure için sovereign bulut desteği de var.

Bu .NET geliştiricileri için neden önemli

.NET ile agentic uygulamalar geliştiriyorsanız — ister Semantic Kernel, ister Microsoft Agent Framework, ister kendi orkestrasyon çözümünüz — Azure MCP Server 2.0, agent’larınızın Azure altyapısıyla etkileşime geçmesi için üretime hazır bir yol sunuyor. Özel REST wrapper’ları yok. Servise özgü entegrasyon kalıpları yok. Sadece MCP.

Birkaç gün önce yayınlanan MCP Apps için fluent API ile birleşince .NET MCP ekosistemi hızla olgunlaşıyor.

Başlarken

Kendi yolunuzu seçin:

GitHub Repo — kaynak kodu, dokümantasyon, her şey
Docker Image — container’lı dağıtım
VS Code Extension — IDE entegrasyonu
Self-hosting rehberi — 2.0’ın öne çıkan özelliği

Sonuç

Azure MCP Server 2.0, demoda gösterişli görünmeyen ama pratikte her şeyi değiştiren altyapı yükseltmesi türünden. Uygun kimlik doğrulama, güvenlik güçlendirmesi ve sovereign bulut desteğiyle self-hosted uzak MCP, gerçek ekiplerin Azure üzerinde gerçek agentic iş akışları oluşturması için hazır olduğu anlamına geliyor. “Kurumsal kullanıma hazır” sinyalini bekliyordunuz — işte bu.

.NET Aspire 13.2 AI Ajanınızın En İyi Dostu Olmak İstiyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

AI kodlama ajanınızın sağlam bir kod yazdığı, heyecanlandığınız ve ardından uygulamayı çalıştırmaya çalışırken her şeyin dağıldığı o anı biliyor musunuz? Port çakışmaları, hayalet süreçler, yanlış ortam değişkenleri — ve bir anda ajanınız özellik geliştirmek yerine başlangıç sorunlarını çözmek için token harcamaya başlıyor.

Aspire ekibi tam da bu sorun hakkında gerçekten düşünceli bir yazı yayımladı ve cevapları ikna edici: Aspire 13.2 yalnızca insanlar için değil, AI ajanları için de tasarlanmış.

Sorun gerçek

AI ajanları kod yazmakta inanılmaz derecede başarılı. Ancak çalışan bir full-stack uygulama göndermek, dosya oluşturmaktan çok daha fazlasını gerektiriyor. Servisleri doğru sırayla başlatmanız, portları yönetmeniz, ortam değişkenlerini ayarlamanız, veritabanlarını bağlamanız ve bir şeyler bozulduğunda geri bildirim almanız gerekiyor. Şu an çoğu ajan bunların hepsini deneme-yanılma yoluyla hallediypr — komutları çalıştırıyor, hata çıktısını okuyor, yeniden deniyor.

Markdown talimatları, özel skill’ler ve prompt’lar ekleyerek onlara rehberlik etmeye çalışıyoruz, ancak bunlar öngörülemez, derlenemiyor ve ayrıştırılmaları bile token harcıyor. Aspire ekibi temel içgörüyü doğru yakaladı: ajanların daha fazla Markdown’a değil, derleyicilere ve yapılandırılmış API’lara ihtiyacı var.

Ajan altyapısı olarak Aspire

Aspire 13.2’nin ajansal geliştirme masasına getirdikleri:

Tüm yığınınız yazılı kodda. AppHost, tam topolojinizi — API, frontend, veritabanı, önbellek — derlenebilir TypeScript veya C# olarak tanımlıyor:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Bir ajan, uygulama topolojisini anlamak, kaynak eklemek, bağlantıları oluşturmak ve doğrulamak için derlemek amacıyla bunu okuyabilir. Derleyici bir şeyin yanlış olduğunu anında söylüyor. Tahmin yok, yapılandırma dosyalarıyla deneme-yanılma yok.

Her şeyi yöneten tek komut. Ajanların docker compose up, npm run dev ve veritabanı başlangıç betikleri arasında denge kurması yerine tek yapmaları gereken şey aspire start. Tüm kaynaklar doğru sırayla, doğru portlarda, doğru yapılandırmayla başlıyor. Uzun süre çalışan süreçler ajanı engellemez — bunları Aspire yönetiyor.

Paralel ajanlar için isolated mod. --isolated seçeneğiyle her Aspire çalıştırması kendi rastgele portlarını ve ayrı user secret’larını alıyor. Git worktree’lerinde çalışan birden fazla ajanınız mı var? Çakışmayacaklar. Bu, paralel ortamlar açan VS Code’un background agent’ları gibi araçlar için çok büyük bir gelişme.

Telemetri aracılığıyla ajan gözleri. İşte burada gerçekten güçlü oluyor. Aspire CLI, geliştirme sırasında tam OpenTelemetry verilerini açığa çıkarıyor — trace’ler, metrikler, yapılandırılmış loglar. Ajanınız yalnızca konsol çıktısını okuyup en iyisini ummak zorunda değil. Başarısız bir isteği servisler arasında izleyebilir, yavaş endpoint’lerin profilini çıkarabilir ve neyin tam olarak nerede bozulduğunu saptayabilir. Bu, geliştirme döngüsünde üretim kalitesinde gözlemlenebilirlik demek.

Bowling koruma bandı analojisi

Aspire ekibi harika bir analoji kullanıyor: Aspire’ı AI ajanları için bowling koruma bantları olarak düşünün. Ajan mükemmel olmasa da (ve olmayacak), bantlar onu oluktan atmaktan koruyor. Yığın tanımı yanlış yapılandırmayı önlüyor, derleyici hataları yakalıyor, CLI süreç yönetimini üstleniyor ve telemetri geri bildirim döngüsünü sağlıyor.

Bunu Playwright CLI gibi bir şeyle birleştirdiğinizde, ajanınız uygulamanızı gerçekten kullanabilir — akışlara tıklayabilir, DOM’u kontrol edebilir, telemetride kırık şeyleri görebilir, kodu düzeltebilir, yeniden başlatabilir ve tekrar test edebilir. Derle, çalıştır, gözlemle, düzelt. Bu, peşinden koştuğumuz özerk geliştirme döngüsü.

Başlarken

Aspire’a yeni misiniz? CLI’ı get.aspire.dev adresinden yükleyin ve başlangıç rehberini takip edin.

Zaten Aspire kullanıyor musunuz? 13.2’yi almak için aspire update --self komutunu çalıştırın, ardından favori kodlama ajanınızı repoya yönlendirin. Aspire’ın koruma bantlarıyla ne kadar daha ileri gittiğini görünce şaşırabilirsiniz.

Özet

Aspire 13.2 artık sadece bir dağıtık uygulama framework’ü değil — temel ajan altyapısına dönüşüyor. Yapılandırılmış yığın tanımları, tek komutla başlangıç, izole paralel çalıştırmalar ve gerçek zamanlı telemetri, AI ajanlarına kod yazmaktan uygulama göndermek için tam olarak ihtiyaç duydukları şeyleri veriyor.

Tüm ayrıntılar ve demo videolar için Aspire ekibinin tam yazısını okuyun.

Ajanlı Platform Mühendisliği Gerçek Oluyor — Git-APE Bunu Nasıl Yapıyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Platform mühendisliği, konferans konuşmalarında harika duyulan ama genellikle “dahili bir portal ve bir Terraform sarmalayıcı geliştirdik” anlamına gelen terimlerden biridir. Gerçek vaat — gerçekten güvenli, yönetişimli ve hızlı self-servis altyapı — her zaman birkaç adım uzakta olmuştur.

Azure ekibi, ajanlı platform mühendisliği serisinin 2. Bölümünü yayımladı ve bu bölüm tamamen uygulamalı implementasyona odaklanıyor. Buna Git-APE (evet, kısaltma kasıtlı) diyorlar; GitHub Copilot agentları ile Azure MCP sunucularını kullanarak doğal dil isteklerini doğrulanmış, dağıtılmış altyapıya dönüştüren açık kaynak bir proje.

Git-APE gerçekte ne yapıyor

Temel fikir şu: geliştiricilerin Terraform modüllerini öğrenmesi, portal arayüzlerinde gezinmesi veya platform ekibine bilet açması yerine, bir Copilot agentıyla konuşması. Agent niyeti yorumlar, Infrastructure-as-Code üretir, politikalara göre doğrular ve dağıtır — tümü VS Code içinde.

İşte kurulum:

git clone https://github.com/Azure/git-ape
cd git-ape

Çalışma alanını VS Code’da açın; agent yapılandırma dosyaları GitHub Copilot tarafından otomatik olarak keşfedilir. Agent ile doğrudan etkileşime geçersiniz:

@git-ape deploy a function app with storage in West Europe

Agent, Azure servisleriyle etkileşim kurmak için arka planda Azure MCP Server’ı kullanır. VS Code ayarlarındaki MCP yapılandırması belirli yetenekleri etkinleştirir:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Neden önemli

Azure üzerine geliştirme yapanlar için bu, platform mühendisliği konuşmasını “nasıl bir portal inşa ederiz” yerine “kısıtlamalarımızı API’ler olarak nasıl tanımlarız” sorusuna kaydırıyor. Platformunuzun arayüzü bir AI agentı olduğunda, kısıtlamalarınızın ve politikalarınızın kalitesi ürün haline geliyor.

Bölüm teorisi ortaya koydu: iyi tanımlanmış API’ler, kontrol şemaları ve açık koruyucular platformları agent-hazır kılar. 2. Bölüm gerçek araçları yayımlayarak bunun işe yaradığını kanıtlıyor. Agent kaynakları körü körüne üretmez — en iyi uygulamalara karşı doğrular, adlandırma kurallarına saygı gösterir ve kuruluşunuzun politikalarını uygular.

Temizlik de aynı derecede kolaydır:

@git-ape destroy my-resource-group

Benim görüşüm

Dürüst olacağım — bu, belirli araçtan çok desen hakkında. Git-APE’nin kendisi bir demo/referans mimarisidir. Ama temel fikir — platformunuza arayüz olarak agentlar, protokol olarak MCP, host olarak GitHub Copilot — kurumsal geliştirici deneyiminin nereye gittiğidir.

Dahili araçlarını agent-dostu hale getirmeye bakan bir platform ekibiyseniz, daha iyi bir başlangıç noktası yok. .NET geliştiricisi olarak bunun dünyanzla nasıl bağlantılı olduğunu merak ediyorsanız: Azure MCP Server ve GitHub Copilot agentları herhangi bir Azure iş yüküyle çalışır. ASP.NET Core API’niz, .NET Aspire yığınınız, konteynerize mikro servisleriniz — hepsi ajanlı bir dağıtım akışının hedefi olabilir.

Sonuç

Git-APE, ajanlı platform mühendisliğine pratikte erken ama somut bir bakış. Repo’yu klonlayın, demoyu deneyin ve platformunuzun API’lerinin ve politikalarının bir agentın bunları güvenle kullanması için nasıl görünmesi gerektiğini düşünmeye başlayın.

Rehber ve video demolar için tam yazıyı okuyun.

Aspire'ın Isolated Modu Paralel Geliştirmedeki Port Çakışma Kabusu'nu Çözüyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aynı projenin iki örneğini aynı anda çalıştırmayı hiç denediniz mi? O acıyı bilirsiniz. Port 8080 zaten kullanımda. Port 17370 alınmış. Bir şeyleri kapatın, yeniden başlatın, ortam değişkenlerini dengeleyin — bu, üretkenliği mahveden bir durum.

Bu sorun daha da kötüleşiyor, iyileşmiyor. AI ajanlar bağımsız çalışmak için git worktree’ler oluşturuyor. Background agent’lar ayrı ortamlar başlatıyor. Geliştiriciler özellik dalları için aynı repoyu iki kez checkout yapıyor. Bu senaryoların her biri aynı engelle karşılaşıyor: aynı uygulamanın iki örneği aynı portlar için çarpışıyor.

Aspire 13.2 bunu tek bir bayrakla çözüyor. Aspire ekibinden James Newton-King tüm ayrıntıları yazdı ve bu, “bunu neden daha önce yoktu?” diye düşündüren özelliklerden biri.

Çözüm: `--isolated`

aspire run --isolated

Hepsi bu. Her çalıştırma şunları alıyor:

Rastgele portlar — örnekler arasında artık çakışma yok
İzole user secret’lar — bağlantı dizeleri ve API anahtarları örnek başına ayrı kalıyor

Manuel port yeniden ataması yok. Ortam değişkeni dengeleme yok. Her çalıştırma otomatik olarak taze, çakışmasız bir ortam alıyor.

Bunun parladığı gerçek senaryolar

Çoklu checkout’lar. Bir dizinde özellik dalı, başka bir dizinde hata düzeltmesi var:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Her ikisi de çakışma olmadan çalışıyor. Dashboard neyin nerede çalıştığını gösteriyor.

VS Code’daki background agent’lar. Copilot Chat’in background agent’ı kodunuz üzerinde bağımsız çalışmak için bir git worktree oluşturduğunda, Aspire AppHost’unuzu çalıştırması gerekebilir. --isolated olmadan, bu birincil worktree’nizle port çakışmasına yol açar. Bununla birlikte her iki örnek de çalışır.

aspire agent init ile birlikte gelen Aspire skill’i, worktree’lerde çalışırken ajanlara otomatik olarak --isolated kullanmalarını talimatlandırıyor. Dolayısıyla Copilot’un background agent’ı bunu kutudan çıkar çıkmaz halledebilmeli.

Geliştirmeyle eş zamanlı entegrasyon testleri. Özellik geliştirmeye devam ederken canlı bir AppHost’a karşı test çalıştırmanız mı gerekiyor? Isolated mod, her bağlama kendi portlarını ve yapılandırmasını veriyor.

Arka planda nasıl çalışıyor

--isolated geçirdiğinizde, CLI çalıştırma için benzersiz bir örnek kimliği oluşturuyor. Bu iki davranışı yönlendiriyor:

Port rastgeleleştirmesi — AppHost yapılandırmanızda tanımlanan öngörülebilir portlara bağlanmak yerine, isolated mod her şey için — dashboard, servis endpoint’leri, hepsi — rastgele uygun portlar seçiyor. Servis keşfi otomatik olarak ayarlanıyor, bu nedenle servisler hangi portlara düşerlerse düşsünler birbirlerini buluyor.
Secret izolasyonu — Her izole çalıştırma, örnek kimliğiyle anahtarlanan kendi user secret deposunu alıyor. Bir çalıştırmadan bağlantı dizeleri ve API anahtarları diğerine sızmıyor.

Kodunuzun değiştirilmesi gerekmiyor. Aspire’ın servis keşfi, endpoint’leri çalışma zamanında çözümlüyor, bu nedenle port atamasından bağımsız olarak her şey doğru şekilde bağlanıyor.

Ne zaman kullanmalı

Aynı AppHost’un birden fazla örneğini aynı anda çalıştırırken --isolated kullanın — ister paralel geliştirme, ister otomatik testler, ister AI ajanları, ister git worktree’ler olsun. Tahmin edilebilir portları tercih ettiğiniz tek örnekli geliştirme için, normal aspire run hâlâ gayet iyi çalışıyor.

Özet

Isolated mod, gerçek ve giderek yaygınlaşan bir sorunu çözen küçük bir özellik. AI destekli geliştirme bizi daha fazla paralel iş akışına — birden fazla ajan, birden fazla worktree, birden fazla bağlam — doğru iterken, portlar için çakışmadan yeni bir örnek başlatabilme yeteneği vazgeçilmez hale geliyor.

Tüm teknik ayrıntılar için tam yazıyı okuyun ve 13.2’yi almak için aspire update --self ile deneyin.

Azure Functions Üzerindeki MCP Server'larınızı Foundry Agent'larına Bağlayın — İşte Nasıl Yapılır

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP ekosistemi hakkında sevdiğim bir şey var: server’ınızı bir kez oluşturuyorsunuz ve her yerde çalışıyor. VS Code, Visual Studio, Cursor, ChatGPT — her MCP istemcisi araçlarınızı keşfedip kullanabiliyor. Şimdi Microsoft bu listeye bir tüketici daha ekliyor: Foundry agent’ları.

Azure SDK ekibinden Lily Ma, Microsoft Foundry agent’larıyla Azure Functions’a dağıtılmış MCP server’larını bağlamaya dair pratik bir kılavuz yayımladı. Zaten bir MCP server’ınız varsa, bu tamamen katma değer — yeniden yapılandırma gerekmiyor.

Bu Kombinasyon Neden Mantıklı?

Azure Functions, MCP server’larını barındırmak için ölçeklenebilir altyapı, yerleşik auth ve sunucusuz faturalama sunuyor. Microsoft Foundry ise akıl yürütebilen, plan yapabilen ve eylemler gerçekleştirebilen AI agent’ları sağlıyor. İkisini birleştirmek, özel araçlarınızın — veritabanı sorgulama, iş API’si çağrısı, doğrulama mantığı çalıştırma — kurumsal AI agent’larının özerk olarak keşfedip kullanabileceği yetenekler haline gelmesi anlamına geliyor.

Önemli nokta: MCP server’ınız aynı kalıyor. Yalnızca Foundry’yi başka bir tüketici olarak ekliyorsunuz. VS Code kurulumunuzda çalışan araçların aynısı artık ekibinizin veya müşterilerinizin etkileşime girdiği bir AI agent’ına güç veriyor.

Kimlik Doğrulama Seçenekleri

Yazının gerçek değer kattığı yer burası. Senaryonuza bağlı olarak dört auth yöntemi:

Yöntem	Kullanım Senaryosu
Key tabanlı (varsayılan)	Geliştirme veya Entra auth olmayan server’lar
Microsoft Entra	Yönetilen kimliklerle üretim
OAuth identity passthrough	Her kullanıcının bireysel olarak kimlik doğruladığı üretim
Kimlik doğrulamasız	Geliştirme/test veya yalnızca genel veriler

Üretim için, agent kimliğiyle Microsoft Entra önerilen yoldur. OAuth identity passthrough, kullanıcı bağlamının önemli olduğu durumlar içindir — agent kullanıcıların giriş yapmasını ister ve her istek kullanıcının kendi token’ını taşır.

Kurulum

Üst düzey akış:

MCP server’ınızı Azure Functions’a dağıtın — .NET, Python, TypeScript ve Java için örnekler mevcut
Function app’inizde yerleşik MCP kimlik doğrulamasını etkinleştirin
Endpoint URL’nizi alın — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
MCP server’ı Foundry’de araç olarak ekleyin — portaldaki agent’ınıza gidin, yeni bir MCP aracı ekleyin, endpoint ve kimlik bilgilerini sağlayın

Ardından araçlarınızdan birini tetikleyecek bir prompt göndererek Agent Builder playground’unda test edin.

Değerlendirmem

Buradaki kompozisyon hikayesi gerçekten güçleniyor. MCP server’ınızı .NET’te (veya Python, TypeScript, Java’da) bir kez oluşturun, Azure Functions’a dağıtın ve her MCP uyumlu istemci onu kullanabilsin — kodlama araçları, chat uygulamaları ve artık kurumsal AI agent’ları. Bu, gerçekten işleyen bir “bir kez yaz, her yerde kullan” pattern’ı.

.NET geliştiricileri için özellikle, Azure Functions MCP extension bunu kolaylaştırıyor. Araçlarınızı Azure Functions olarak tanımlayın, dağıtın ve Azure Functions’ın sağladığı tüm güvenlik ve ölçeklendirme özellikleriyle birlikte üretim kalitesinde bir MCP server’ınız olsun.

Son Söz

Azure Functions üzerinde çalışan MCP araçlarınız varsa, bunları Foundry agent’larına bağlamak hızlı bir kazanımdır — özel araçlarınız, server’ın kendisinde hiçbir kod değişikliği yapmadan ve uygun auth ile kurumsal AI yeteneklerine dönüşür.

Her kimlik doğrulama yöntemi için adım adım talimatlar için tam kılavuzu okuyun ve üretim kurulumları için ayrıntılı belgeleri inceleyin.

GitHub Copilot'un Modernizasyon Değerlendirmesi, Henüz Kullanmadığınız En İyi Göç Aracı

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Eski bir .NET Framework uygulamasını modern .NET’e taşımak, herkesin yapması gerektiğini bildiği ama kimsenin başlamak istemediği işlerden biri. Bu hiçbir zaman sadece “hedef framework’ü değiştir” meselesi değildir. Ortadan kalkan API’lar, artık mevcut olmayan paketler, tamamen farklı çalışan hosting modelleri ve neyin container’a alınacağı, neyin yeniden yazılacağı, neyin olduğu gibi bırakılacağına dair binlerce küçük karar var.

Jeffrey Fritz, GitHub Copilot’un modernizasyon değerlendirmesine derin bir dalış yayımladı ve dürüst olmak gerekirse? Bu, .NET için gördüğüm en iyi göç araçları. Kod oluşturma nedeniyle değil — bu artık herkes için temel gereksinim. Ürettiği değerlendirme belgesi nedeniyle.

Bu sadece bir kod öneri motoru değil

VS Code uzantısı bir Değerlendir → Planla → Uygula modeli izliyor. Değerlendirme aşaması tüm kod tabanınızı analiz ediyor ve her şeyi yakalayan yapılandırılmış bir belge üretiyor: neyin değişmesi gerektiği, hangi Azure kaynaklarının sağlanacağı, hangi dağıtım modelinin kullanılacağı. Aşağıdaki her şey — altyapı-kodu, containerlaştırma, dağıtım manifestoları — değerlendirmenin bulduklarından akıyor.

Değerlendirme, projenizde .github/modernize/assessment/ altında saklanıyor. Her çalıştırma bağımsız bir rapor üretiyor, böylece bir geçmiş oluşturabilir ve sorunları düzelttikçe göç pozisyonunuzun nasıl geliştiğini takip edebilirsiniz.

Başlamanın iki yolu

Önerilen Değerlendirme — hızlı yol. Seçilmiş alanlardan birini seçin (Java/.NET Yükseltme, Bulut Hazırlığı, Güvenlik) ve yapılandırmaya dokunmadan anlamlı sonuçlar alın. Uygulamanızın nerede durduğuna ilk bakış için harika.

Özel Değerlendirme — hedefli yol. Neyin analiz edileceğini tam olarak yapılandırın: hedef hesaplama (App Service, AKS, Container Apps), hedef işletim sistemi, containerlaştırma analizi. Göç yaklaşımlarını yan yana karşılaştırmak için birden fazla Azure hedefi seçin.

Bu karşılaştırma görünümü gerçekten yararlı. App Service için 3 zorunlu sorunu olan bir uygulamanın AKS için 7 sorunu olabilir. Her ikisini de görmek, bir göç yoluna bağlanmadan önce hosting kararını yönlendirmeye yardımcı oluyor.

Sorun dökümü uygulanabilir

Her sorun bir kritiklik düzeyiyle geliyor:

Zorunlu — düzeltilmeli, yoksa göç başarısız olur
Olası — göçü etkileyebilir, insan değerlendirmesi gerektirir
İsteğe bağlı — önerilen iyileştirmeler, göçü engellemez

Ve her sorun etkilenen dosyalara ve satır numaralarına bağlantı veriyor, neyin yanlış olduğunu ve neden hedef platformunuz için önemli olduğunu ayrıntılı açıklıyor, somut düzeltme adımları sunuyor (sadece “bunu düzelt” değil) ve resmi belgelere bağlantılar içeriyor.

Bireysel sorunları geliştiricilere verebilir ve harekete geçmek için ihtiyaç duydukları her şeye sahip olurlar. Bu, “bir sorun var” diyen bir araç ile nasıl çözüleceğini söyleyen bir araç arasındaki farktır.

Kapsanan yükseltme yolları

.NET için özellikle:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Her yükseltme yolunun, hangi API’ların kaldırıldığını, hangi desenlerin doğrudan eşdeğerinin bulunmadığını ve hangi güvenlik sorunlarının ele alınması gerektiğini bilen algılama kuralları var.

Birden fazla uygulamayı yöneten ekipler için çok-repo toplu değerlendirmeleri destekleyen bir CLI de var — tüm repoları klonlayın, hepsini değerlendirin, uygulama başına raporlar artı toplu portföy görünümü alın.

Benim düşüncem

Eski .NET Framework uygulamalarının üzerinde oturuyorsanız (ve gerçekçi olalım, çoğu kurumsal ekip oturuyor), bu başlamak için tek araçtır. Değerlendirme belgesi tek başına zamana değer — belirsiz bir “modernize etmeliyiz"i, somut ve önceliklendirilmiş, net ileriye dönük yolları olan bir iş öğeleri listesine dönüştürür.

İş birliğine dayalı iş akışı da akıllıca: değerlendirmeleri dışa aktarın, ekibinizle paylaşın, yeniden çalıştırmadan içe aktarın. Karar vericilerin araçları çalıştıranlar olmadığı mimari incelemeler? Karşılandı.

Sonuç

GitHub Copilot’un modernizasyon değerlendirmesi, .NET göçünü korkunç, tanımsız bir projeden yapılandırılmış, izlenebilir bir sürece dönüştürüyor. Nerede durduğunuzu görmek için önerilen değerlendirmeyle başlayın, ardından Azure hedeflerini karşılaştırmak ve göç planınızı oluşturmak için özel değerlendirmeleri kullanın.

Tam anlatımı okuyun ve kendi kod tabanınızda denemek için VS Code uzantısını alın.

Kara Kutu Hissi Vermeyen Gerçek Zamanlı Çoklu-Agent Arayüzleri Oluşturmak

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Çoklu-agent sistemler hakkında şunu söylemek gerekir: demo ortamlarında inanılmaz görünürler. Üç agent iş birbirine aktarır, sorunları çözer, kararlar alır. Sonra bunu gerçek kullanıcıların önüne koymaya çalışırsınız ve… sessizlik. Dönen bir yükleme göstergesi. Hangi agentın ne yaptığını ya da sistemin neden durduğunu anlatan hiçbir şey yok. Bu bir ürün değil — bu bir güven sorunudur.

Microsoft Agent Framework ekibi, MAF iş akışlarını AG-UI ile eşleştiren harika bir rehber yayımladı. AG-UI, agent yürütme olaylarını Server-Sent Events üzerinden bir frontend’e aktarmak için kullanılan açık bir protokoldür. Ve dürüst olmak gerekirse? Bu, eksik olan köprünün ta kendisi.

.NET geliştiricileri için neden önemli

AI destekli uygulamalar geliştiriyorsanız, muhtemelen bu duvarla karşılaşmışsınızdır. Backend orkestrasyonunuz mükemmel çalışır — agentlar birbirlerine iş devreder, araçlar tetiklenir, kararlar alınır. Ancak frontend, perde arkasında ne olduğundan habersizdir. AG-UI, agent olaylarını (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_* gibi) SSE üzerinden doğrudan UI katmanınıza aktarmak için standart bir protokol tanımlayarak bunu çözer.

Geliştirdikleri demo, üç agentlı bir müşteri destek iş akışı: istekleri yönlendiren bir triage agentı, para işlerini yöneten bir refund agentı ve ikame yönetimi yapan bir order agentı. Her agentın kendi araçları var ve devir teslim topolojisi açıkça tanımlanmış — “prompt’tan çöz” vibesinden eser yok.

Devir teslim topolojisi asıl yıldız

Dikkatimi çeken şey, HandoffBuilder‘ın agentlar arasında yönlendirilmiş bir rotalama grafiği tanımlamanıza izin vermesidir:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Her add_handoff, doğal dil açıklamasıyla yönlendirilmiş bir kenar oluşturur. Framework, bu topolojiye dayanarak her agent için devir teslim araçları üretir. Böylece yönlendirme kararları, LLM’in keyfine değil, orkestrasyon yapınıza dayanır. Bu, üretim güvenilirliği açısından son derece önemlidir.

Gerçekten işe yarayan human-in-the-loop

Demo, her gerçek dünya agent uygulamasının ihtiyaç duyduğu iki kesme (interrupt) deseni sergiliyor:

Araç onay kesmeleri — bir agent approval_mode="always_require" ile işaretlenmiş bir araç çağırdığında iş akışı duraklar ve bir olay yayımlar. Frontend, araç adı ve argümanlarıyla bir onay modalı gösterir. Token yakan yeniden deneme döngüleri yok — sadece temiz bir duraklat-onayla-devam et akışı.

Bilgi isteği kesmeleri — bir agentın kullanıcıdan daha fazla bağlam (örneğin bir sipariş ID’si) ihtiyacı olduğunda durur ve sorar. Frontend soruyu gösterir, kullanıcı yanıtlar ve yürütme tam kaldığı yerden devam eder.

Her iki desen de standart AG-UI olayları olarak stream edilir; bu nedenle frontend’inizin her agent için özel mantığa ihtiyacı yoktur — SSE bağlantısından gelen olayı olduğu gibi gösterir.

Bağlantı kurmak şaşırtıcı derecede basit

MAF ile AG-UI arasındaki entegrasyon tek bir fonksiyon çağrısıdır:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory, thread başına yeni bir iş akışı oluşturur; böylece her konuşma izole bir duruma sahip olur. Endpoint, tüm SSE altyapısını otomatik olarak yönetir. Zaten FastAPI kullanıyorsanız (ya da hafif bir katman olarak ekleyebiliyorsanız), bu neredeyse hiç sürtünme gerektirmez.

Benim görüşüm

.NET geliştiricileri olarak aklımıza gelen ilk soru şu: “Bunu C#’ta yapabilir miyim?” Agent Framework hem .NET hem de Python için mevcut ve AG-UI protokolü dilden bağımsız (aslında sadece SSE). Bu nedenle, bu demo Python ve FastAPI kullansa da, desen doğrudan çevrilebilir. Aynı AG-UI olay şemasını takip eden SSE endpoint’leriyle ASP.NET Core minimal API kurabilirsiniz.

Daha büyük çıkarım şu: çoklu-agent arayüzleri artık sonradan düşünülen bir konu değil, birinci sınıf bir endişe haline geliyor. Agentların insanlarla etkileşime girdiği herhangi bir şey geliştiriyorsanız — müşteri desteği, onay iş akışları, belge işleme — MAF orkestrasyonu ve AG-UI şeffaflığının bu kombinasyonu, izlenecek yol.

Sonuç

AG-UI + Microsoft Agent Framework, her iki dünyanın en iyisini sunar: backend’de sağlam çoklu-agent orkestrasyonu, frontend’de gerçek zamanlı görünürlük. Artık kara kutu agent etkileşimleri yok.

Daha fazla bilgi için tam rehbere ve AG-UI protokol deposuna göz atın.

MCP Uygulamaları Fluent API Kazandı — .NET'te Üç Adımda Zengin AI Araç Arayüzleri Oluşturun

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP araçları, AI agent’larına yetenekler kazandırmak için harika. Peki ya aracınızın kullanıcıya bir şey göstermesi gerekiyorsa — bir dashboard, bir form, etkileşimli bir görselleştirme? MCP Apps tam bu noktada devreye giriyor ve çok daha kolay hale geldi.

Azure SDK ekibinden Lilian Kasem, .NET Azure Functions’daki MCP Apps için yeni fluent yapılandırma API’sini tanıttı ve bu, neden başından beri bu kadar basit olmadığını düşündüren türden bir geliştirici deneyimi iyileştirmesi.

MCP Apps Nedir?

MCP Apps, araçların kendi UI görünümlerini, statik varlıklarını ve güvenlik kontrollerini taşımasına izin vererek Model Context Protocol’ü genişletir. MCP aracınız yalnızca metin döndürmek yerine tam HTML deneyimleri render edebilir — etkileşimli dashboard’lar, veri görselleştirmeleri, yapılandırma formları — bunların hepsi AI agent’ları tarafından çağrılabilir ve MCP istemcileri tarafından kullanıcılara sunulur.

Sorun şuydu: tüm bunları manuel olarak bağlamak MCP spesifikasyonunu yakından bilmeyi gerektiriyordu: ui:// URI’leri, özel mime türleri, araçlar ve kaynaklar arasında metadata koordinasyonu. Zor değil, ama zahmetli.

Üç Adımda Fluent API

Adım 1: Fonksiyonunuzu tanımlayın. Standart bir Azure Functions MCP aracı:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Adım 2: Bir MCP App’e yükseltin. Program başlatmanızda:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Adım 3: HTML görünümünüzü ekleyin. İhtiyacınız olan herhangi bir UI ile assets/hello-app.html dosyasını oluşturun.

Hepsi bu kadar. Fluent API tüm MCP spesifikasyon altyapısını halleder — sentetik kaynak fonksiyonu oluşturma, doğru mime türünü ayarlama, aracınızı görünümüne bağlayan metadata’yı ekleme.

API Yüzeyi İyi Tasarlanmış

Gerçekten beğendiğim birkaç şey:

Görünüm kaynakları esnektir. HTML’i diskteki dosyalardan sunabilir veya kendi kendine yetişen dağıtımlar için kaynakları doğrudan assembly’nize gömebilirsiniz:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP kompozisyona uygundur. Uygulamanızın ihtiyaç duyduğu kaynakları açıkça beyaz listeye alırsınız, en az ayrıcalık ilkelerini izleyerek. WithCsp‘yi birden fazla kez çağırın ve kaynaklar birikir:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Görünürlük kontrolü. Bir aracı yalnızca LLM’ye görünür, yalnızca host UI’a görünür veya her ikisine de görünür yapabilirsiniz. Yalnızca UI render eden ve model tarafından çağrılmaması gereken bir araç mı istiyorsunuz? Kolay:

.WithVisibility(McpVisibility.App) // Yalnızca UI, modelden gizli

Başlarken

Preview paketini ekleyin:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Zaten Azure Functions ile MCP araçları oluşturuyorsanız, bu yalnızca bir paket güncellemesi. Konsepte yeniyseniz MCP Apps hızlı başlangıç kılavuzu başlamak için en iyi yer.

Son Söz

MCP Apps, AI araçlama alanındaki daha heyecan verici gelişmelerden biri — yalnızca işler yapan değil, kullanıcılara şeyler gösterebilen araçlar. Fluent API protokol karmaşıklığını ortadan kaldırır ve önemli olan şeye odaklanmanızı sağlar: aracınızın mantığı ve UI’ı.

Tam API referansı ve örnekler için tam yazıyı okuyun.

Microsoft Foundry Mart 2026 — GPT-5.4, Agent Service GA ve Her Şeyi Değiştiren SDK Yenilemesi

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aylık “Microsoft Foundry’de Neler Yeni” yazıları genellikle kademeli iyileştirmelerin ve ara sıra bir manşet özelliğinin karışımı olur. Mart 2026 sayısı? Bu neredeyse tamamen manşet özelliklerden oluşuyor. Foundry Agent Service GA’ya geçiyor, GPT-5.4 üretime geliyor, SDK büyük bir kararlı sürüm alıyor ve Fireworks AI, Azure’a açık model çıkarımı getiriyor. .NET geliştiricileri için önemli olanları ele alayım.

Foundry Agent Service Üretime Hazır

Bu büyük haber. Yeni nesil agent runtime genel kullanıma sunuldu — OpenAI Responses API üzerine kurulu, OpenAI agent’larıyla wire uyumlu ve birden fazla sağlayıcının modellerine açık. Bugün Responses API ile geliştirme yapıyorsanız, Foundry’ye geçiş mevcut agent mantığınızın üstüne kurumsal güvenlik, özel ağ desteği, Entra RBAC, tam izleme ve değerlendirme ekler.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Önemli eklemeler: uçtan uca özel ağ desteği, MCP auth genişlemesi (OAuth passthrough dahil), konuşmadan konuşmaya agent’lar için Voice Live önizlemesi ve 6 yeni bölgede barındırılan agent’lar.

GPT-5.4 — Ham Zekadan Çok Güvenilirlik

GPT-5.4, daha akıllı olmak için değil. Daha güvenilir olmak için. Uzun etkileşimlerde daha güçlü akıl yürütme, daha iyi talimat uyumu, daha az iş akışı ortası başarısızlık ve entegre bilgisayar kullanım yetenekleri. Üretim agent’ları için o güvenilirlik, kıyaslama puanlarından çok daha önemlidir.

Model	Fiyatlandırma (M token başına)	En İyi Kullanım
GPT-5.4 (≤272K)	$2,50 / $15 çıktı	Üretim agent’ları, kodlama, belge iş akışları
GPT-5.4 Pro	$30 / $180 çıktı	Derin analiz, bilimsel akıl yürütme
GPT-5.4 Mini	Maliyet etkin	Sınıflandırma, çıkarım, hafif araç çağrıları

Akıllı hamle bir yönlendirme stratejisidir: GPT-5.4 Mini yüksek hacimli, düşük gecikmeli işleri yönetirken GPT-5.4 akıl yürütme ağırlıklı istekleri alır.

SDK Nihayet Kararlı

azure-ai-projects SDK tüm dillerde kararlı sürümler gönderdi — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 ve .NET 2.0.0 (1 Nisan). azure-ai-agents bağımlılığı kalktı — her şey AIProjectClient altında yaşıyor. pip install azure-ai-projects ile kurun; paket openai ve azure-identity‘yi doğrudan bağımlılık olarak birlikte getiriyor.

.NET geliştiricileri için bu, tam Foundry yüzeyi için tek bir NuGet paketi anlamına geliyor. Artık ayrı agent SDK’larını dengeleme yok.

Fireworks AI Açık Modelleri Azure’a Taşıyor

Belki de mimarısal açıdan en ilginç ekleme: günlük ~180K istek/saniye ile 13+ trilyon token işleyen Fireworks AI artık Foundry üzerinden kullanılabilir. Lansmanında DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 ve MiniMax M2.5.

Asıl hikaye kendi ağırlıklarını getir — sunum yığınını değiştirmeden her yerden nicel veya fine-tune edilmiş ağırlıklar yükleyin. Sunucusuz token başına ödeme veya sağlanan iş hacmi ile dağıtın.

Diğer Öne Çıkanlar

Phi-4 Reasoning Vision 15B — grafikler, diyagramlar ve belge düzenleri için çok modlu akıl yürütme
Evaluations GA — Azure Monitor’a aktarılan sürekli üretim izlemeyle hazır değerlendiriciler
Priority Processing (Önizleme) — gecikmeye duyarlı iş yükleri için ayrılmış hesaplama şeridi
Voice Live — doğrudan Foundry agent’larına bağlanan konuşmadan konuşmaya runtime
Tracing GA — sıralama ve filtrelemeyle uçtan uca agent iz incelemesi
PromptFlow kullanımdan kaldırma — Ocak 2027’ye kadar Microsoft Framework Workflows’a geçiş

Son Söz

Mart 2026, Foundry için bir dönüm noktası. Agent Service GA, tüm dillerde kararlı SDK’lar, güvenilir üretim agent’ları için GPT-5.4 ve Fireworks AI üzerinden açık model çıkarımı — platform ciddi iş yükleri için hazır.

Başlamak için tam özeti okuyun ve ilk agent’ınızı oluşturun.

O Visual Studio Kayan Pencere Ayarını Hiç Duydunuz mu? (Duymanız Gerekiyor)

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Birden fazla monitörle Visual Studio kullanıyorsanız (ve dürüstçe söylemek gerekirse, günümüzde kim kullanmıyor ki), muhtemelen o can sıkıcı durumu yaşamışsınızdır: ana IDE’yi küçülttüğünüzde kayan araç pencereleri kayboluyor, her zaman her şeyin üstünde kalıyor ve ayrı görev çubuğu butonları olarak görünmüyorlar. Bazı iş akışları için işe yarayabilir, ancak çoklu monitör kurulumlarında oldukça sinir bozucu.

Visual Studio ekibinden Mads Kristensen, kayan pencerelerin davranışını kökten değiştiren az bilinen bir ayarı paylaştı. Tek bir açılır menü. Hepsi bu kadar.

Ayar nerede?

Tools > Options > Environment > Windows > Floating Windows

“These floating windows are owned by the main window” açılır menüsünde üç seçenek bulunuyor:

None — tam bağımsızlık. Her kayan pencere kendi görev çubuğu girişini alır ve normal bir Windows penceresi gibi davranır.
Tool Windows (varsayılan) — belgeler serbestçe kalar, araç pencereleri IDE’ye bağlı kalır.
Documents and Tool Windows — klasik Visual Studio davranışı, her şey ana pencereye bağlı.

Çoklu monitör kurulumlarında neden “None” doğru seçim?

None olarak ayarlayın ve aniden tüm kayan araç pencereleriniz ve belgeleriniz gerçek Windows uygulamaları gibi davranmaya başlar. Görev çubuğunda görünürler, ana Visual Studio penceresini küçülttüğünüzde görünür kalmaya devam ederler ve artık her şeyin önüne zorla gelmiyor.

Bunu PowerToys FancyZones ile birleştirirseniz oyun değiştirucu bir deneyim elde edersiniz. Monitörlerinizde özel düzenler oluşturun, Solution Explorer’ınızı bir bölgeye, hata ayıklayıcıyı bir diğerine ve kod dosyalarını istediğiniz yere yerleştirin. Her şey yerinde kalır, her şeye bağımsız olarak erişilebilir ve çalışma alanınız kaotik yerine düzenli hissedilir.

Hızlı öneriler

Çoklu monitör güç kullanıcıları: None olarak ayarlayın, FancyZones ile birleştirin
Ara sıra kayan pencere kullananlar: Tool Windows (varsayılan) sağlam bir orta yol
Geleneksel iş akışı: Documents and Tool Windows her şeyi klasik tutar

İpucu: Herhangi bir araç penceresi başlık çubuğuna Ctrl + çift tıklayarak anında kayan veya yerleşik hale getirebilirsiniz. Ayarı değiştirdikten sonra yeniden başlatmaya gerek yok.

Sonuç

Bu, “bunu neden daha önce bilmiyordum” dedirten ayarlardan biri. Visual Studio’daki kayan pencereler sizi hiç rahatsız ettiyse şu anda gidip bunu değiştirin.

Ayrıntılar ve ekran görüntüleri için tam yazıyı okuyun.

SQL MCP Server — AI Ajanlarına Veritabanı Erişimi Vermenin Doğru Yolu

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dürüst olalım: bugün mevcut veritabanı MCP sunucularının çoğu gerçekten ürkütücü. Doğal dil sorgusu alıyor, anında SQL üretiyor ve bunu üretim verinize karşı çalıştırıyor. Ne yanlış gidebilir ki? (Her şey. Her şey yanlış gidebilir.)

Azure SQL ekibi az önce SQL MCP Server’ı tanıttı ve bu yaklaşım temelden farklı. Data API builder (DAB) 2.0’ın bir özelliği olarak geliştirilen bu araç, AI ajanlarına NL2SQL olmadan, şemanızı açıklamadan ve her adımda tam RBAC ile veritabanı işlemlerine yapılandırılmış, deterministik erişim sağlıyor.

Neden NL2SQL yok?

Bu, en ilginç tasarım kararı. Modeller deterministik değil ve karmaşık sorgular en büyük hata riskini taşıyan yapılar. AI’ın üretmesini umduğunuz tam sorgular da deterministik olmayan şekilde üretildiğinde en dikkatli incelenmesi gereken sorgular oluyor.

Bunun yerine SQL MCP Server bir NL2DAB yaklaşımı benimsiyor. Ajan, Data API builder’ın varlık soyutlama katmanı ve yerleşik sorgu oluşturucu ile birlikte çalışarak doğru ve düzgün biçimlendirilmiş T-SQL deterministik olarak üretiyor. Kullanıcı için aynı sonuç, ancak hayali JOIN’ler veya kazara veri ifşası riski olmadan.

Yedi araç, yedi yüz değil

SQL MCP Server, veritabanının büyüklüğünden bağımsız olarak tam olarak yedi DML aracı sunuyor:

describe_entities — mevcut varlıkları ve işlemleri keşfet
create_record — satır ekle
read_records — tablolar ve görünümleri sorgula
update_record — satırları değiştir
delete_record — satırları sil
execute_entity — saklı yordamları çalıştır
aggregate_records — toplama sorguları

Bu akıllıca bir tasarım çünkü bağlam pencereleri ajanın düşünme alanıdır. Yüzlerce araç tanımıyla doldurmak, muhakeme için daha az alan bırakır. Yedi sabit araç, ajanın gezinmek yerine düşünmeye odaklanmasını sağlar.

Her araç ayrı ayrı etkinleştirilebilir veya devre dışı bırakılabilir:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Üç komutla başlangıç

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Bu kadar. Customers tablonuzu açığa çıkaran çalışan bir SQL MCP Server’ınız var. Varlık soyutlama katmanı, adları ve sütunları takma adla kullanmanıza, rol başına alanları sınırlamanıza ve iç şema ayrıntılarını açıklamadan ajanların tam olarak neyi göreceğini kontrol etmenize olanak tanıyor.

Güvenlik hikayesi sağlam

Data API builder’ın olgunluğu burada meyvesini veriyor:

Her katmanda RBAC — her varlık hangi rollerin okuyabileceğini, oluşturabileceğini, güncelleyebileceğini veya silebileceğini ve hangi alanların görünür olduğunu tanımlıyor
Azure Key Vault entegrasyonu — bağlantı dizeleri ve gizli anahtarlar güvenli şekilde yönetiliyor
Microsoft Entra + özel OAuth — üretim düzeyinde kimlik doğrulama
Content Security Policy — ajanlar ham SQL değil, denetimli bir sözleşme üzerinden etkileşim kuruyor

Şema soyutlaması özellikle önemli. İç tablo ve sütun adlarınız asla ajana açıklanmıyor. Veritabanı ERD’nize göre değil, AI etkileşimi için mantıklı olan varlıkları, takma adları ve açıklamaları siz tanımlıyorsunuz.

Çok veritabanı ve çok protokol

SQL MCP Server, Microsoft SQL, PostgreSQL, Azure Cosmos DB ve MySQL’i destekliyor. Ve bir DAB özelliği olduğundan, aynı yapılandırmadan eş zamanlı olarak REST, GraphQL ve MCP endpoint’leri elde ediyorsunuz. Aynı varlık tanımları, aynı RBAC kuralları, aynı güvenlik — üç protokol genelinde.

DAB 2.0’daki otomatik yapılandırma, hızlı prototipleme için daha az soyutlamaya razıysanız veritabanınızı inceleyebilir ve yapılandırmayı dinamik olarak oluşturabilir.

Kişisel görüşüm

AI ajanları için kurumsal veritabanı erişimi işte böyle çalışmalı. “Hey LLM, biraz SQL yaz da üretime at bakalım” değil. Bunun yerine: iyi tanımlanmış bir varlık katmanı, deterministik sorgu üretimi, her adımda RBAC, önbellekleme, izleme ve telemetri. En iyi anlamda sıkıcı.

.NET geliştiricileri için entegrasyon hikayesi temiz — DAB bir .NET aracıdır, MCP Server bir container olarak çalışır ve çoğumuzun zaten kullandığı Azure SQL ile çalışır. Veri erişimine ihtiyaç duyan AI ajanları geliştiriyorsanız buradan başlayın.

Sonuç

SQL MCP Server ücretsiz, açık kaynaklı ve her yerde çalışır. AI ajanlarına güvenli veritabanı erişimi sağlamak için Microsoft’un öngörülü yaklaşımıdır. Başlamak için tam yazıyı ve dokümantasyonu inceleyin.

VS Code 1.116 — Agents Uygulaması Klavye Navigasyonu ve Dosya Bağlamı Tamamlamaları Kazandı

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

VS Code 1.116, Nisan 2026 sürümü; bazı yakın güncellemelerden daha hafif olsa da, değişiklikler odaklı ve anlamlı — özellikle Agents uygulamasını her gün kullanıyorsanız.

İşte resmi sürüm notlarına dayanarak neler geldi.

Agents uygulaması iyileştirmeleri

Agents uygulaması, günlük iş akışlarında gerçek fark yaratan kullanılabilirlik geliştirmeleriyle olgunlaşmaya devam ediyor:

Özel kısayol tuşları — artık Changes görünümüne, Changes içindeki dosya ağacına ve Chat Customizations görünümüne özel komutlar ve klavye kısayollarıyla odaklanabilirsiniz. Agents uygulamasında gezinmek için tıklıyorsanız, bu tam klavye odaklı iş akışlarını getiriyor.

Erişilebilirlik yardım diyaloğu — sohbet giriş kutusunda Alt+F1 tuşuna basmak artık mevcut komutları ve kısayol tuşlarını gösteren bir erişilebilirlik yardım diyaloğu açıyor. Ekran okuyucu kullanıcıları ayrıca duyuru ayrıntısını kontrol edebiliyor. İyi erişilebilirlik herkesin işine yarar.

Dosya bağlamı tamamlamaları — Agents uygulaması sohbetinde # yazarak mevcut çalışma alanınıza kapsamlı dosya bağlamı tamamlamalarını tetikleyin. Bu, her etkileşimi hızlandıran küçük bir yaşam kalitesi iyileştirmelerinden biri — koda referans verirken artık tam dosya yolları yazmak yok.

CSS `@import` bağlantı çözümlemesi

Frontend geliştiricileri için güzel bir özellik: VS Code artık node_modules yollarını kullanan CSS @import referanslarını çözümlüyor. Bundler kullanırken @import "some-module/style.css" gibi importlar üzerinden Ctrl+click yapabilirsiniz. Küçük ama CSS iş akışlarındaki bir sürtünme noktasını ortadan kaldırıyor.

Sonuç

VS Code 1.116, iyileştirmeyle ilgili — Agents uygulamasını daha kolay gezilebilir, daha erişilebilir ve klavye dostu hale getiriyor. Agents uygulamasında önemli zaman harcıyorsanız (ki pek çoğumuzun harcadığını düşünüyorum), bu değişiklikler birikir.

Tam liste için sürüm notlarına bakın.

VS Code 1.115 — Arka Plan Terminal Bildirimleri, SSH Agent Modu ve Daha Fazlası

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 az önce yayınlandı ve başlık özellikleri açısından hafif bir sürüm olsa da, AI kodlama asistanlarıyla her gün çalışıyorsanız agent ile ilgili iyileştirmeler gerçekten kullanışlı.

Gerçekten bilinmeye değer olanları öne çıkarayım.

Arka plan terminalleri agentlara geri bildirim veriyor

Bu, öne çıkan özellik. Arka plan terminalleri artık komutlar tamamlandığında çıkış kodu ve terminal çıktısını da içerecek şekilde otomatik olarak agentları bilgilendiriyor. Arka plan terminallerindeki giriş istemleri de tespit edilerek kullanıcıya iletiliyor.

Bu neden önemli? Copilot’un agent modunu arka planda build komutları veya test dizileri çalıştırmak için kullandıysanız, “o bitti mi acaba?” sancısını bilirsiniz — arka plan terminalleri esasen ateş et ve unut mantığıyla çalışıyordu. Artık agent, dotnet build veya dotnet test tamamlandığında haberdar ediliyor, çıktıyı görüyor ve buna göre tepki verebiliyor. Küçük bir değişiklik, ama agent odaklı iş akışlarını önemli ölçüde daha güvenilir kılıyor.

Ayrıca, agentların kullanıcı onayıyla arka plan terminallerine komut göndermesine olanak tanıyan yeni bir send_to_terminal aracı var; bu da run_in_terminal‘in zaman aşımıyla terminalleri arka plana taşıdığı ve salt okunur hale getirdiği sorunu çözüyor.

SSH uzak agent barındırma

VS Code artık SSH üzerinden uzak makinelere bağlanmayı, CLI’yi otomatik olarak yüklemeyi ve agent ana bilgisayar modunda başlatmayı destekliyor. Bu, AI agent oturumlarınızın uzak ortamları doğrudan hedefleyebileceği anlamına geliyor — Linux sunucularda veya bulut VM’lerinde geliştirme ve test yapan .NET geliştiricileri için kullanışlı.

Agent oturumlarında düzenleme takibi

Agent oturumları sırasında yapılan dosya düzenlemeleri artık farklar, geri alma/yeniden yapma ve durum geri yükleme ile birlikte takip ediliyor ve geri yükleniyor. Bir agent kodunuzda değişiklik yapar ve bir şeyler ters giderse, tam olarak neyin değiştiğini görebilir ve geri alabilirsiniz. Agentların kod tabanınızı değiştirmesine izin vermek için gönül rahatlığı.

Tarayıcı sekme farkındalığı ve diğer iyileştirmeler

Birkaç yaşam kalitesi iyileştirmesi daha:

Tarayıcı sekme takibi — sohbet artık bir oturum sırasında açılan tarayıcı sekmelerini takip edip bunlara bağlantı verebiliyor, böylece agentlar baktığınız web sayfalarına referans verebiliyor
Terminale dosya yapıştırma — Ctrl+V, sürükle-bırak veya sağ tıklamayla terminale dosya (resimler dahil) yapıştırın
Minimap’te test kapsamı — test kapsamı göstergeleri artık hızlı bir görsel özet için minimap’te gösteriliyor
Mac’te sıkıştırarak yakınlaştırma — entegre tarayıcı sıkıştırarak yakınlaştırma hareketlerini destekliyor
Sessions’da Copilot yetkilendirmeleri — durum çubuğu Sessions görünümünde kullanım bilgilerini gösteriyor
Go to File’da favicon — açık web sayfaları hızlı seçim listesinde favicon gösteriyor

Sonuç

VS Code 1.115 artımlı bir sürüm, ancak agent iyileştirmeleri — arka plan terminal bildirimleri, SSH agent barındırma ve düzenleme takibi — AI destekli geliştirme için fark edilir şekilde daha akıcı bir deneyim oluşturuyor. .NET projeleri için Copilot’un agent modunu kullanıyorsanız, bunlar günlük sürtünmeyi azaltan yaşam kalitesi düzeltmeleri.

Her ayrıntı için tam sürüm notlarına bakın.

C# 15 Union Türlerini Alıyor — ve Bunlar Tam İstediğimiz Şey

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Bunu bekliyordum. C# 15, union anahtar sözcüğünü tanıtıyor — derleyici tarafından zorunlu kılınan kapsamlı desen eşleştirmeli gerçek discriminated union’lar. F#‘ın discriminated union’larını ya da Rust’ın enum’larını hiç kıskandıysanız, bunun neden önemli olduğunu tam olarak biliyorsunuzdur.

Bill Wagner, .NET bloğunda konunun derinlemesine incelemesini yayımladı ve dürüst olmak gerekirse? Tasarım temiz, pratik ve son derece C# ruhuyla örtüşüyor. Gerçekte ne olduğunu ve neden ilk bakışta göründüğünden daha büyük bir mesele olduğunu size anlatayım.

Union türlerinin çözdüğü sorun

C# 15 öncesinde, bir metottan “birkaç olası türden biri” döndürmek her zaman bir uzlaşıydı:

object — kısıtlama yok, derleyici yardımı yok, her yerde savunmacı casting
İşaretçi arayüzler — daha iyi, ama herkes bunları uygulayabilir. Derleyici kümenin tamamlanmış olduğunu asla kabul edemez
Soyut taban sınıflar — aynı sorun, üstelik türlerin ortak bir atası olması gerekiyor

Bunların hiçbiri gerçekte istediğinizi vermiyor: derleyicinin her durumu ele aldığınızı garanti ettiği kapalı bir tür kümesi. Union türlerinin yaptığı tam olarak bu.

Sözdizimi güzelce basit

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Tek satır. Pet, bir Cat, bir Dog veya bir Bird tutabilir. Örtülü dönüşümler otomatik olarak oluşturulur:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Ve işte sihir — derleyici kapsamlı eşleştirmeyi zorunlu kılıyor:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

_ atma ifadesi gerekmiyor. Derleyici bu switch’in olası her durumu kapsadığını biliyor. Daha sonra union’a dördüncü bir tür eklerseniz, bunu ele almayan her switch ifadesi bir uyarı üretiyor. Eksik durumlar çalışma zamanında değil, derleme zamanında yakalanıyor.

Bu pratikte ne anlama geliyor

Pet örneği şirin, ama işte union’ların gerçek kodda asıl parladığı yer burası.

Farklı şekiller döndüren API yanıtları

public union ApiResult<T>(T, ApiError, ValidationFailure);

Artık her tüketici başarı, hata ve doğrulama başarısızlığını ele almak zorunda. “Hata durumunu kontrol etmeyi unuttum” hataları artık yok.

Tek değer veya koleksiyon

OneOrMore<T> deseni, union’ların yardımcı metotlarla nasıl bir gövdeye sahip olabileceğini gösteriyor:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Çağıranlar hangi form uygunsa onu kullanıyor:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

İlgisiz türleri birleştirme

Bu, geleneksel hiyerarşiler üzerindeki öldürücü özelliktir. Ortak atası olmayan türleri — string ve Exception, int ve IEnumerable<T> — union’layabilirsiniz.

Mevcut kütüphaneler için özel union’lar

İşte akıllı bir tasarım seçimi: [Union] özniteliğine sahip herhangi bir sınıf veya struct, temel deseni izlediği sürece (durum türleri için public constructor’lar ve bir Value özelliği) bir union türü olarak tanınır. OneOf gibi union benzeri türler zaten sağlayan kütüphaneler, iç yapılarını yeniden yazmadan derleyici desteğini benimseyebilir.

Değer türleriyle performans açısından kritik senaryolar için kütüphaneler, HasValue ve TryGetValue metotlarıyla boxing yapmayan erişim deseni uygulayabilir.

Büyük resim

Union türleri, C#‘a gelen daha kapsamlı bir bütünlük hikayesinin parçası:

Union türleri — kapalı bir tür kümesi üzerinde kapsamlı eşleştirme (şu an önizlemede mevcut)
Kapalı hiyerarşiler — closed değiştiricisi, tanımlayan derleme dışında türetilmiş sınıfları engelliyor (önerildi)
Kapalı enum’lar — bildirilmiş üyeler dışında değer oluşturulmasını engelliyor (önerildi)

Bu üç özellik birlikte, C#‘a herhangi bir ana akım dilde en kapsamlı tür güvenli desen eşleştirme sistemlerinden birini kazandıracak.

Bugün deneyin

Union türleri .NET 11 Preview 2’de mevcut:

.NET 11 Preview SDK‘yi yükleyin
Projenizde net11.0 hedefleyin
<LangVersion>preview</LangVersion> ayarlayın

Bir uyarı: Preview 2’de, henüz çalışma zamanında bulunmadıkları için UnionAttribute ve IUnion‘ı projenizde bildirmeniz gerekecek. Docs reposundan RuntimePolyfill.cs dosyasını alın veya şunu ekleyin:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Sonuç

Union türleri, nasıl bu olmadan idare ettiğimizi merak ettiren özelliklerden biri. Derleyici tarafından zorunlu kılınan kapsamlı eşleştirme, temiz sözdizimi, generic desteği ve mevcut desen eşleştirmeyle entegrasyon — C# yolunda yapılmış, istediğimiz her şey bu.

.NET 11 Preview 2’de deneyin, şeyleri kırın ve GitHub’da geri bildiriminizi paylaşın. Bu önizleme aşamasında ve C# ekibi aktif olarak dinliyor. Uç durumlarınız ve tasarım geri bildiriminiz nihai sürümü şekillendirecek.

Tam dil referansı için union türleri belgelerine ve özellik spesifikasyonuna bakın.

Aspire 13.2 Bir Dokümantasyon CLI'ı Sunuyor — ve AI Ajanınız da Kullanabilir

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Bir Aspire AppHost’un içinde derinlere dalıp entegrasyonları bağlarken Redis entegrasyonunun tam olarak hangi parametreleri beklediğini kontrol etmeniz gereken o anı biliyor musunuz? Tarayıcınıza geçersiniz, aspire.dev’de arama yaparsınız, API dokümanlarını incelersiniz, sonra editörünüze dönersiniz. Bağlam kaybolmuş. Akış bozulmuş.

Aspire 13.2 tam da bunun için bir çözüm sundu. aspire docs CLI’ı, terminali terk etmeden resmi Aspire belgelerini doğrudan arayıp okuyabilmenizi sağlıyor. Yeniden kullanılabilir servisler tarafından desteklendiği için, AI ajanları ve skill’ler de var olmayan API’ları uydurmak yerine belge aramak amacıyla aynı komutları kullanabiliyor.

Bu aslında ne sorunu çözüyor

David Pine orijinal yazısında konuyu net olarak özetliyor: AI ajanlar, geliştiricilere Aspire uygulamaları geliştirmede yardım etmekte berbattı. aspire run yerine dotnet run öneriyorlar, aspire.dev’deki belgeleri learn.microsoft.com’a yönlendiriyorlardı, güncel olmayan NuGet paketleri öneriyorlardı ve — kişisel favorim — var olmayan API’ları uyduruyorlardı.

Neden? Çünkü Aspire, çok dilli olmadan çok daha uzun süre .NET’e özel kaldı ve LLM’ler en son özelliklerin öncesindeki eğitim verileriyle çalışıyor. Bir AI ajanına mevcut belgeleri gerçekten arama yeteneği verdiğinizde, tahmin etmeyi bırakıp işe yarar hale geliyor.

Üç komut, sıfır tarayıcı sekmesi

CLI ferahlatıcı derecede basit:

Tüm belgeleri listele

aspire docs list

aspire.dev’de mevcut her belge sayfasını döndürür. Makine tarafından okunabilir çıktı mı istiyorsunuz? --format Json ekleyin.

Bir konu arayın

aspire docs search "redis"

Ağırlıklı ilgi puanlamasıyla hem başlıkları hem içeriği arar. Dahili olarak dokümantasyon araçlarını destekleyen arama motorunun aynısı. Başlıklar, slug’lar ve ilgi puanlarıyla sıralı sonuçlar alırsınız.

Tam sayfayı okuyun (ya da yalnızca bir bölümü)

aspire docs get redis-integration

Tam sayfayı markdown olarak terminalinize akıtır. Yalnızca bir bölüme mi ihtiyacınız var?

aspire docs get redis-integration --section "Add Redis resource"

Cerrahi hassasiyet. 500 satır kaydırma yok. Sadece ihtiyacınız olan kısım.

AI ajan boyutu

İşte AI araçlarıyla geliştirme yapan bizim için ilginç olan kısım. Aynı aspire docs komutları, AI ajanları için araç olarak çalışıyor — skill’ler, MCP sunucuları veya basit CLI sarmalayıcıları aracılığıyla.

AI asistanınızın eski eğitim verilerine dayalı Aspire API’ları uydurmak yerine, aspire docs search "postgres" çağırabilir, resmi entegrasyon belgelerini bulabilir, doğru sayfayı okuyabilir ve size belgelenmiş yaklaşımı sunabilir. Gerçek zamanlı, güncel belgeler — modelin altı ay önce ezberledikleri değil.

Bunun arkasındaki mimari kasıtlı. Aspire ekibi tek seferlik bir entegrasyon yerine yeniden kullanılabilir servisler (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) inşa etti. Bu, aynı arama motorunun terminaldeki insanlar, editörünüzdeki AI ajanları ve CI pipeline’ınızdaki otomasyonlar için çalışması anlamına geliyor.

Gerçek dünya senaryoları

Hızlı terminal aramaları: Üç dosya derindesiniz ve Redis yapılandırma parametrelerine ihtiyacınız var. İki komut, doksan saniye, işe geri dönüş:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI destekli geliştirme: VS Code skill’iniz CLI komutlarını sarmalıyor. “AppHost’uma bir PostgreSQL veritabanı ekle” diyorsunuz ve ajan cevap vermeden önce gerçek belgelere bakıyor. Halüsinasyon yok.

CI/CD doğrulama: Pipeline’ınız, AppHost yapılandırmalarını programatik olarak resmi belgelerle doğruluyor. --format Json çıktısı jq ve diğer araçlara temiz şekilde aktarılıyor.

Özel bilgi tabanları: Kendi AI araçlarınızı mı geliştiriyorsunuz? Yapılandırılmış JSON çıktısını doğrudan bilgi tabanınıza aktarın:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Web scraping yok. API anahtarı yok. Dokümantasyon araçlarının dahili olarak kullandığı aynı yapılandırılmış veri.

Belgeler her zaman canlı

En çok takdir ettiğim kısım bu. CLI bir anlık görüntü indirmiyor — aspire.dev’i ETag tabanlı önbelleklemeyle sorguluyor. Belgeler güncellenir güncellenmez, CLI’ınız ve üzerine inşa edilmiş tüm skill’ler bunu yansıtıyor. Eski kopyalar yok, “ama wiki şöyle diyordu…” anları yok.

Özet

aspire docs, gerçek bir sorunu temiz biçimde çözen küçük özelliklerden biri. İnsanlar terminale özgü belge erişimi kazanıyor. AI ajanları tahmin etmeyi bırakıp gerçek belgelere başvurmanın bir yolunu buluyor. Ve hepsi aynı gerçek kaynakla destekleniyor.

.NET Aspire ile geliştirme yapıyorsanız ve CLI’ı henüz denemediyseniz, aspire docs search "konunuz" çalıştırın ve nasıl hissettirdiğini görün. Sonra bu komutları kullandığınız AI skill veya otomasyon kurulumuna entegre etmeyi düşünün — ajanlarınız size teşekkür edecek.

Dokümantasyon araçlarının nasıl oluşturulduğuna dair David Pine’ın derinlemesine incelemesine ve tüm ayrıntılar için resmi CLI referansına göz atın.

Microsoft Agent Framework 1.0 Yayımlandı — .NET Geliştiricileri İçin Gerçekten Önemli Olan Şeyler

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Erken Semantic Kernel ve AutoGen günlerinden bu yana Agent Framework yolculuğunu takip ediyorsanız, bu gelişme önemli. Microsoft Agent Framework 1.0 sürümüne ulaştı — üretime hazır, kararlı API’lar, uzun vadeli destek taahhüdü. Hem .NET hem de Python için mevcut ve gerçek iş yükleri için gerçekten hazır.

Duyuru gürültüsünü bir kenara bırakarak, .NET ile AI destekli uygulamalar geliştiriyorsanız önemli olan şeylere odaklanayım.

Özet

Agent Framework 1.0, eski Semantic Kernel ve AutoGen’i tek, açık kaynaklı bir SDK’da birleştirir. Tek bir agent soyutlaması. Tek bir orkestrasyon motoru. Birden fazla AI sağlayıcısı. Kurumsal desenler için Semantic Kernel ile araştırma düzeyindeki çoklu-agent iş akışları için AutoGen arasında gidip geliyorsanız, buna son verebilirsiniz. Artık tek SDK bu.

Başlamak neredeyse haksız derecede kolay

İşte .NET’te çalışan bir agent:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Bu kadar. Birkaç satırla Azure Foundry üzerinde çalışan bir AI agentınız var. Python karşılığı da aynı derecede özlü. İlerlediğinizde function araçları, çok turlu konuşmalar ve streaming ekleyin — API yüzeyi tuhaflaşmadan büyür.

Çoklu-agent orkestrasyonu — işte asıl konu bu

Tek agentlar demolar için güzel, ama üretim senaryoları genellikle koordinasyon gerektirir. Agent Framework 1.0, Microsoft Research ve AutoGen’den gelen savaşta test edilmiş orkestrasyon desenlerini içerir:

Sequential (Sıralı) — agentlar sırayla işler (yazar → gözden geçiren → editör)
Concurrent (Eş zamanlı) — birden fazla agenta paralel olarak yayıl, sonuçları birleştir
Handoff (Devir teslim) — bir agent, niyete göre başka birine devreder
Group chat (Grup sohbeti) — birden fazla agent tartışır ve bir çözümde uzlaşır
Magentic-One — MSR’den araştırma düzeyindeki çoklu-agent deseni

Tümü streaming, checkpointing, human-in-the-loop onayları ve duraklat/devam et özelliklerini destekler. Checkpointing kısmı kritik — uzun süreli iş akışları süreç yeniden başlatmalarını atlatır. Azure Functions ile dayanıklı iş akışları geliştirmiş .NET geliştiricileri için bu tanıdık hissettiriyor.

En önemli özellikler

Bilmeye değer şeylerin kısa listesi:

Middleware kancaları. ASP.NET Core’un middleware pipeline’ları var ya? Aynı kavram, ama agent yürütmesi için. Her aşamayı yakalayın — içerik güvenliği, loglama, uyumluluk politikaları ekleyin — agent prompt’larına dokunmadan. Agentları kurumsal düzeyde hazır kılmanın yolu budur.

Takılabilir bellek. Konuşma geçmişi, kalıcı anahtar-değer durumu, vektör tabanlı erişim. Backend’inizi seçin: Foundry Agent Service, Mem0, Redis, Neo4j veya kendinizinkini yazın. Bellek, durumsuz bir LLM çağrısını gerçekten bağlamı hatırlayan bir agenta dönüştüren şeydir.

Bildirimsel YAML agentları. Agentınızın talimatlarını, araçlarını, belleğini ve orkestrasyon topolojisini sürüm kontrollü YAML dosyalarında tanımlayın. Tek bir API çağrısıyla yükleyin ve çalıştırın. Bu, kod yeniden dağıtmadan agent davranışını yinelemek isteyen ekipler için oyun değiştiricidir.

A2A ve MCP desteği. MCP (Model Context Protocol), agentların harici araçları dinamik olarak keşfetmesine ve çağırmasına izin verir. A2A (Agent-to-Agent protokolü), çalışma zamanları arası işbirliğini mümkün kılar — .NET agentlarınız diğer framework’lerde çalışan agentlarla koordinasyon kurabilir. A2A 1.0 desteği yakında geliyor.

Takip etmeye değer önizleme özellikleri

Bazı özellikler 1.0’da önizleme olarak yayımlandı — işlevsel ama API’lar gelişebilir:

DevUI — agent yürütmesini, mesaj akışlarını ve araç çağrılarını gerçek zamanlı olarak görselleştirmek için tarayıcı tabanlı yerel hata ayıklayıcı. Application Insights gibi ama agent muhakemesi için.
GitHub Copilot SDK ve Claude Code SDK — Copilot veya Claude’u doğrudan orkestrasyon kodunuzdan agent harness’i olarak kullanın. Kod yazabilen bir agentı aynı iş akışındaki diğer agentlarla birleştirin.
Agent Harness — agentlara shell, dosya sistemi ve mesajlaşma döngülerine erişim sağlayan özelleştirilebilir yerel çalışma zamanı. Kodlama agentları ve otomasyon desenlerini düşünün.
Skills — agentlara kullanıma hazır yapılandırılmış yetenekler sunan yeniden kullanılabilir alan yetkinliği paketleri.

Semantic Kernel veya AutoGen’den geçiş

Mevcut Semantic Kernel veya AutoGen kodunuz varsa, kodunuzu analiz eden ve adım adım geçiş planları üreten özel geçiş asistanları mevcuttur. Semantic Kernel geçiş rehberi ve AutoGen geçiş rehberi her şeyi adım adım anlatıyor.

RC paketlerindeyseniz, 1.0’a yükseltme sadece bir sürüm güncellemesidir.

Sonuç

Agent Framework 1.0, kurumsal ekiplerin beklediği üretim mihenk taşıdır. Kararlı API’lar, çoklu sağlayıcı desteği, gerçek ölçekte çalışan orkestrasyon desenleri ve hem Semantic Kernel hem de AutoGen’den geçiş yolları.

Framework GitHub’da tamamen açık kaynak ve dotnet add package Microsoft.Agents.AI ile bugün başlayabilirsiniz. Ellerinizi kirletmek için hızlı başlangıç rehberine ve örneklere göz atın.

“Üretimde kullanmak güvenli” sinyalini bekliyorsanız — işte bu.

Aspire 13.2 Dashboard'una Telemetri API'si Geldi — ve Her Şeyi Değiştiriyor

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

.NET Aspire ile dağıtık uygulamalar geliştiriyorsanız, dashboard’un tüm deneyimin en iyi parçası olduğunu zaten bilirsiniz. Tüm izleriniz, loglarınız ve metrikleriniz tek bir yerde — harici Jaeger yok, Seq kurulumu yok, “öbür terminale bakayım” anı yok.

Aspire 13.2 bunu önemli ölçüde daha iyi hale getirdi. James Newton-King güncellemeyi duyurdu ve dürüst olmak gerekirse? Telemetri dışa aktarma ve API özellikleri tek başına yükseltmeye değer.

Telemetriyi sağlıklı bir şekilde dışa aktarın

Hepimizin yaşadığı senaryoyu düşünün: dağıtık bir sorunu ayıklıyorsunuz, yirmi dakikalık kurulumun ardından sonunda yeniden üretiyorsunuz ve şimdi yaşananları ekibinizle paylaşmanız gerekiyor. Önceden? Ekran görüntüleri. İz ID’lerini kopyala-yapıştır. Her zamanki karmaşa.

Aspire 13.2, şunları yapabileceğiniz uygun bir Logları ve telemetriyi yönet iletişim kutusu ekliyor:

Tüm telemetriyi temizleme (yeniden üretim denemesinden önce kullanışlı)
Seçili telemetriyi standart OTLP/JSON formatında ZIP dosyasına dışa aktarma
Bu ZIP’i daha sonra herhangi bir Aspire dashboard’una yeniden içe aktarma

Son kısım öldürücü özellik. Bir hatayı yeniden üretirsiniz, telemetriyi dışa aktarırsınız, iş öğenize eklersiniz ve ekip arkadaşınız tam olarak gördüğünüzü görmek için kendi dashboard’una içe aktarabilir. Artık “kendi makinende yeniden üretebilir misin?” yok.

Bireysel izler, span’lar ve loglar da bağlam menülerinde “JSON Dışa Aktar” seçeneği kazanıyor. Tek bir izi paylaşmanız mı gerekiyor? Sağ tıklayın, JSON kopyalayın, PR açıklamanıza yapıştırın. Tamam.

Telemetri API’si gerçek oyun değiştirici

En çok bu konuya heyecanlıyım. Dashboard artık telemetri verilerini programatik olarak sorgulamak için /api/telemetry altında bir HTTP API sunuyor. Kullanılabilir endpoint’ler:

GET /api/telemetry/resources — telemetrisi olan kaynakları listele
GET /api/telemetry/spans — filtrelerle span’ları sorgula
GET /api/telemetry/logs — filtrelerle logları sorgula
GET /api/telemetry/traces — izleri listele
GET /api/telemetry/traces/{traceId} — belirli bir iz için tüm span’ları getir

Her şey OTLP JSON formatında dönüyor. Bu, yeni aspire agent mcp ve aspire otel CLI komutlarını besliyor, ama gerçek anlam daha büyük: artık uygulamanızın telemetrisini doğrudan sorgulayan araçlar, scriptler ve AI agent entegrasyonları oluşturabilirsiniz.

Hata ayıklarken gerçek dağıtık izlerinize bakabilen bir AI kodlama agentı hayal edin. Bu artık hayali değil — bu API’nin mümkün kıldığı şey tam olarak bu.

GenAI telemetri pratikleşiyor

Semantic Kernel veya Microsoft.Extensions.AI ile AI destekli uygulamalar geliştiriyorsanız, geliştirilmiş GenAI telemetri görselleştiricisini takdir edeceksiniz. Aspire 13.2 şunları ekliyor:

Markdown olarak render edilen AI araç açıklamaları
AI iz erişimini hızlandırmak için izler sayfasında özel GenAI butonu
Kesik veya standart olmayan GenAI JSON için daha iyi hata yönetimi
Araç tanımları arasında tıkla-vurgula navigasyonu

Blog yazısı, VS Code Copilot chat, Copilot CLI ve OpenCode’un tümünün OTEL_EXPORTER_OTLP_ENDPOINT yapılandırmasını desteklediğinden bahsediyor. Bunları Aspire dashboard’una yönlendirin ve AI agentlarınızın telemetri aracılığıyla gerçek zamanlı olarak nasıl düşündüğünü izleyebilirsiniz. Bu, başka hiçbir yerde bulamayacağınız bir hata ayıklama deneyimidir.

Sonuç

Aspire 13.2, dashboard’u “güzel bir hata ayıklama arayüzü"nden “programlanabilir bir gözlemlenebilirlik platformu"na taşıyor. Dışa aktarma/içe aktarma iş akışı tek başına dağıtık hata ayıklamada gerçek zaman kazandırıyor; telemetri API’si ise AI destekli tanılama kapısını açıyor.

Zaten Aspire kullanıyorsanız, yükseltin. Kullanmıyorsanız — bu, aspire.dev’e göz atmak ve tüm meseleyi anlamak için iyi bir neden.

azd Artık AI Ajanlarınızı Yerel Ortamda Çalıştırıp Hata Ayıklamanıza İzin Veriyor — Mart 2026'daki Değişiklikler

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Bir ayda yedi sürüm. Azure Developer CLI (azd) ekibinin Mart 2026’da yaptığı bu ve başlık özelliği benim beklediğim şey: AI ajanları için yerel çalıştırma ve hata ayıklama döngüsü.

PC Chan tam özeti yayımladı ve orada pek çok şey olsa da, AI destekli uygulamalar geliştiren .NET geliştiricileri için gerçekten önem taşıyan şeyleri özetleyeyim.

AI ajanlarını dağıtmadan çalıştırın ve hata ayıklayın

En büyük yenilik bu. Yeni azure.ai.agents uzantısı, AI ajanları için düzgün bir iç döngü deneyimi sunan bir dizi komut ekliyor:

azd ai agent run — ajanı yerel olarak başlatır
azd ai agent invoke — ona mesaj gönderir (yerel veya dağıtılmış)
azd ai agent show — container durumunu ve sağlığını gösterir
azd ai agent monitor — container loglarını gerçek zamanlı akıtır

Bundan önce, bir AI ajanını test etmek her değişiklik yaptığınızda Microsoft Foundry’e dağıtmak anlamına geliyordu. Artık yerel olarak yineleyebilir, ajanın davranışını test edebilir ve yalnızca hazır olduğunuzda dağıtabilirsiniz. Microsoft Agent Framework veya Semantic Kernel ile ajan geliştiriyorsanız, bu günlük iş akışınızı değiştiriyor.

invoke komutu hem yerel hem de dağıtılmış ajanlara karşı çalışıyor; bu, ajanın nerede çalıştığından bağımsız olarak aynı test iş akışını kullanabileceğiniz anlamına geliyor. Bu tür bir ayrıntı, iki ayrı test betiği setini sürdürmek zorunda kalmaktan sizi kurtarıyor.

GitHub Copilot azd projenizi iskelet oluşturuyor

azd init artık “GitHub Copilot ile Kur (Önizleme)” seçeneği sunuyor. Proje yapınız hakkındaki prompt’lara manuel olarak yanıt vermek yerine, bir Copilot ajanı yapılandırmayı sizin için iskelet oluşturuyor. Herhangi bir şeyi değiştirmeden önce kirli çalışma dizinini kontrol ediyor ve MCP sunucusu araç iznini önceden istiyor.

Bir komut başarısız olduğunda, azd artık AI destekli sorun giderme sunuyor: bir kategori seçin (açıkla, rehberlik, sorun gider veya atla), ajanın bir düzeltme önermesine izin verin ve yeniden deneyin — hepsi terminali terk etmeden. Karmaşık altyapı kurulumları için bu gerçek anlamda zaman kazandırıyor.

Container App Jobs ve dağıtım iyileştirmeleri

Dikkat çekmeye değer birkaç dağıtım özelliği:

Container App Jobs: azd artık mevcut host: containerapp yapılandırması aracılığıyla Microsoft.App/jobs dağıtıyor. Bicep şablonunuz hedefin Container App mı yoksa Job mu olduğunu belirliyor — ekstra kurulum gerekmez.
Yapılandırılabilir dağıtım zaman aşımları: azd deploy üzerinde yeni --timeout bayrağı ve azure.yaml‘da deployTimeout alanı. Varsayılan 1200 saniyelik sınırı artık tahmin etmek zorunda değilsiniz.
Uzak derleme yedeklemesi: Uzak ACR derlemesi başarısız olduğunda, azd otomatik olarak yerel Docker/Podman derlemesine geri düşüyor.
Yerel ön uçuş doğrulama: Bicep parametreleri, Azure’a bir gidiş-dönüş yapmadan eksik parametreleri yakalamak için dağıtımdan önce yerel olarak doğrulanıyor.

Geliştirici deneyimi iyileştirmeleri

Toplanınca fark yaratan küçük iyileştirmeler:

JS/TS projeleri için otomatik pnpm/yarn algılama
Python paketleme için pyproject.toml desteği
Yerel şablon dizinleri — azd init --template artık çevrimdışı yineleme için dosya sistemi yollarını kabul ediyor
--no-prompt modunda daha iyi hata mesajları — eksik tüm değerler çözüm komutlarıyla birlikte bir kerede raporlanıyor
Derleme ortam değişkenleri tüm framework derleme alt süreçlerine enjekte ediliyor (.NET, Node.js, Java, Python)

Son madde ince ama önemli: .NET derlemeniz artık azd ortam değişkenlerine erişebilir; bu, ekstra betik yazmadan derleme zamanı yapılandırma enjeksiyonu yapabileceğiniz anlamına geliyor.

Özet

Yerel AI ajan hata ayıklama döngüsü bu sürümün yıldızı, ancak dağıtım iyileştirmeleri ve geliştirici deneyimi cilasının birikmesi azd‘yi her zamankinden daha olgun hissettiriyor. .NET uygulamalarını Azure’a — özellikle AI ajanlarını — dağıtıyorsanız, bu güncelleme kuruluma değer.

Her ayrıntı için tam sürüm notlarına bakın ya da azd kurulumu ile başlayın.

Azure DevOps Sonunda Herkesin Şikayet Ettiği Markdown Editörü UX'ini Düzeltiyor

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Azure Boards kullanıyorsanız, muhtemelen bunu yaşamışsınızdır: bir iş öğesi açıklamasını okuyorsunuz, belki kabul kriterlerini gözden geçiriyorsunuz ve yanlışlıkla çift tıklıyorsunuz. Bum — düzenleme modundasınız. Hiçbir şeyi düzenlemek istemiyordunuz. Sadece okuyordunuz.

Dan Hellem düzeltmeyi duyurdu, ve bu, küçük gibi görünse de günlük iş akışınızdan gerçek sürtüşmeyi kaldıran değişikliklerden biri.

Ne değişti

İş öğesi metin alanları için Markdown editörü artık varsayılan olarak önizleme modunda açılıyor. İçerikle okuyabilir ve etkileşime girebilirsiniz — bağlantıları takip etmek, biçimlendirmeyi gözden geçirmek — yanlışlıkla düzenleme moduna girme endişesi olmadan.

Gerçekten düzenlemek istediğinizde, alanın üstündeki düzenleme simgesine tıklarsınız. Bitirdiğinizde, açıkça önizleme moduna geri çıkarsınız.

Neden göründüğünden daha önemli

Bu konudaki topluluk geri bildirim dizisi uzundu. Çift tıklama-düzenleme davranışı Temmuz 2025’te Markdown editörüyle tanıtıldı ve şikayetler neredeyse hemen başladı.

Yayılım durumu

Bu zaten bir müşteri alt kümesine yayılıyor ve önümüzdeki iki ila üç hafta içinde herkese genişleyecek.

Bookmark Studio, Visual Studio Yer İşaretlerine Slot Tabanlı Gezinti ve Paylaşım Getiriyor

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio’daki yer işaretleri her zaman… idare ederdi. Bir tane koyarsınız, bir sonrakine geçersiniz, hangisinin ne olduğunu unutursunuz. Çalışırlar, ama hiçbir zaman güçlü diyebileceğiniz bir özellik olmadılar.

Mads Kristensen, eğer yer işaretlerini düzenli kullanıyorsanız muhtemelen karşılaştığınız boşlukları tam olarak dolduran deneysel bir uzantı olan Bookmark Studio’yu yayımladı.

Slot tabanlı gezinti

Temel yenilik şu: yer işaretleri artık 1–9 numaralı slotlara atanabilir ve doğrudan Alt+Shift+1 ile Alt+Shift+9 tuş kombinasyonlarıyla erişilebilir. Yeni yer işaretleri otomatik olarak bir sonraki boş slotu alır; dolayısıyla çoğu durumda herhangi bir yapılandırma gerektirmeden hızlı gezinti çalışır.

Bu basit görünüyor, ama yer işaretlerini “bir yerlerde bazı yer işaretlerim var” durumundan “Slot 3 API controller’ım, Slot 5 servis katmanı, Slot 7 test” haline getiriyor. Bu tür uzamsal bellek, odaklanılmış çalışma oturumlarında gezintiyi neredeyse anında yapıyor.

Yer İşareti Yöneticisi

Yeni bir araç penceresi, tüm yer işaretlerinizi tek bir yerde ad, dosya, konum, renk veya slota göre filtreleme seçeneğiyle gösteriyor. Herhangi bir yer işaretine atlamak için çift tıklayabilir ya da klavyeyle gezinebilirsiniz.

Eğer hiç beş-altı yer işaretinden fazlasına sahip olup hangisinin ne olduğunu takip edemediğiniz olduysa, bu tek başına uzantıyı kurmaya değer.

Etiketler, renkler ve klasörlerle organizasyon

Yer işaretlerine isteğe bağlı olarak etiket ve renk eklenebilir, klasörlere gruplandırılabilir. Bunların hiçbiri zorunlu değil — mevcut yer işareti iş akışınız çalışmaya devam eder. Ancak karmaşık bir sorunu hata ayıkladığınızda ya da tanıdık olmayan bir kod tabanını keşfettiğinizde, yer işaretlerinizi renklendirebilmek ve etiketleyebilmek yararlı bir bağlam katıyor.

Tüm meta veriler çözüm başına saklanır; dolayısıyla yer işareti organizasyonunuz oturumlar arasında kalıcı olur.

Dışa aktarma ve paylaşma

Bilmeden istediğim özellik bu. Bookmark Studio, yer işaretlerini düz metin, Markdown veya CSV olarak dışa aktarmanıza izin veriyor. Yani şunları yapabilirsiniz:

Pull request açıklamalarına yer işareti yollarını eklemek
İnceleme izlerini takım arkadaşlarıyla paylaşmak
Yer işareti kümelerini repolar veya dallar arasında taşımak

Yer işaretleri yalnızca kişisel bir gezinti aracı olmaktan çıkıp “işte bu kodun geçtiği yol” mesajını iletmenin bir yoluna dönüşüyor.

Kod hareketini izleyen yer işaretleri

Bookmark Studio, yer işaretlerini bağlandıkları metne göre takip eder; böylece düzenleme yaparken yanlış satırlara kaymazlar. Hiç bir hata ayıklama oturumunda yer işaretleri koyup bir yeniden yapılandırmanın ardından hepsinin yanlış satırlara işaret ettiğini gördüyseniz — bu durumu düzeltiyor.

Sonuç

Bookmark Studio hiçbir şeyi yeniden icat etmiyor. Yıllardır “yeterince iyi” olan bir özelliği alıp odaklanılmış geliştirme için gerçekten kullanışlı hale getiriyor. Slot gezintisi, Yer İşareti Yöneticisi ve dışa aktarma özellikleri öne çıkanlardır.

Visual Studio Marketplace‘dan indirin ve deneyin.

Visual Studio'nun Mart Güncellemesiyle Özel Copilot Agentları Oluşturabilirsiniz — find_symbol Aracı Gerçekten Büyük

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio bugüne kadarki en önemli Copilot güncellemesini aldı. Mark Downie Mart sürümünü duyurdu ve başlık özel agentlar — ama dürüstçe söylemek gerekirse, daha aşağılarda geçen find_symbol aracı iş akışınızı en çok değiştirecek özellik olabilir.

Gerçekte neler olduğunu açıklayayım.

Reponuzda özel Copilot agentları

Copilot’un ekibinizin kodlama standartlarını izlemesini, build pipeline’ınızı çalıştırmasını veya dahili belgelerinizi sorgulamasını ister misiniz? Artık tam olarak bunu oluşturabilirsiniz.

Özel agentlar, reponuzdaki .github/agents/ klasörüne bıraktığınız .agent.md dosyaları olarak tanımlanıyor. Her agent, çalışma alanı farkındalığına, kod anlayışına, araçlara, tercih ettiğiniz modele ve harici servislere MCP bağlantılarına tam erişim elde ediyor. Yerleşik agentların yanında agent seçicisinde görünüyorlar.

Bu, VS Code’un süredir desteklediği desenin aynısı — ve Visual Studio’nun yetişmesini görmek harika. VS Code için zaten agent oluşturmuş ekipler için .agent.md dosyalarınız her iki IDE’de de çalışmalı (ancak araç adları farklılık gösterebilir, bu yüzden test edin).

awesome-copilot reposunda başlangıç noktası olarak kullanabileceğiniz topluluk katkılı agent yapılandırmaları var.

Agent becerileri: yeniden kullanılabilir talimat paketleri

Beceriler, reponuzdaki .github/skills/ klasöründen veya profilinizdeki ~/.copilot/skills/ konumundan otomatik olarak alınıyor. Her beceri, Agent Skills spesifikasyonunu takip eden bir SKILL.md dosyası.

Becerileri, karıştırıp eşleştirebileceğiniz modüler uzmanlık alanları olarak düşünün. API kurallarınız için bir beceri, test desenleriniz için bir diğeri ve dağıtım iş akışınız için başka biri olabilir. Bir beceri etkinleştiğinde, uygulandığını bilmeniz için sohbette görünüyor.

VS Code’da beceri kullandıysanız Visual Studio’da da aynı şekilde çalışıyorlar.

find_symbol: agentlar için dile duyarlı navigasyon

İşler burada gerçekten ilginçleşiyor. Yeni find_symbol aracı, Copilot’un agent moduna gerçek dil servisi destekli sembol navigasyonu sağlıyor. Kodunuzu metin olarak aramak yerine agent şunları yapabiliyor:

Projeniz genelinde bir sembole yapılan tüm referansları bul
Tür bilgisine, bildirimlere ve kapsam meta verilerine eriş
Tam dil farkındalığıyla çağrı noktalarında gezin

Pratikte ne anlama geliyor: Copilot’tan bir metodu yeniden düzenlemesini veya çağrı noktaları genelinde parametre imzasını güncellemesini istediğinizde, kodunuzun yapısını gerçekten görebiliyor. Artık “agent metodu değiştirdi ama üç çağrı noktasını kaçırdı” durumu yok.

Desteklenen diller arasında C#, C++, Razor, TypeScript ve desteklenen LSP uzantısına sahip her şey yer alıyor. .NET geliştiricileri için bu büyük bir iyileştirme — derin tür hiyerarşileri ve arayüzlere sahip C# kod tabanları, sembol farkındalıklı navigasyondan büyük ölçüde yararlanıyor.

Copilot ile testleri profilleyin

Test Gezgini bağlam menüsünde artık bir Profile with Copilot komutu var. Bir test seçin, profile tıklayın ve Profiling Agent onu otomatik olarak çalıştırıp performansı analiz eder — uygulanabilir içgörüler sunmak için CPU kullanımı ve enstrümantasyon verilerini birleştirir.

Artık profil oluşturucu oturumlarını manuel olarak yapılandırmak, testi çalıştırmak, sonuçları dışa aktarmak ve bir flame graph okumaya çalışmak yok. Agent analizi yapıp neyin yavaş olduğunu ve neden olduğunu söylüyor. Şu anda yalnızca .NET, ki bu Visual Studio’nun derin .NET tanı entegrasyonu göz önüne alındığında mantıklı.

Canlı hata ayıklama sırasında performans ipuçları

Performans optimizasyonu artık sonrasında değil, hata ayıklarken gerçekleşiyor. Kod üzerinde adım adım ilerlerken Visual Studio satır içinde yürütme süresini ve performans sinyallerini gösteriyor. Yavaş bir satır mı gördünüz? Perf İpucu’na tıklayın ve Copilot’tan hemen orada optimizasyon önerileri isteyin.

Profiling Agent çalışma zamanı verilerini otomatik olarak yakalıyor — geçen süre, CPU kullanımı, bellek davranışı — ve Copilot bunu sıcak noktaları tespit etmek için kullanıyor. Bu, performans çalışmasını ertelediğiniz ayrı bir görev yerine hata ayıklama akışınızın bir parçası olarak tutuyor.

Solution Explorer’dan NuGet güvenlik açıklarını düzeltin

Bir NuGet paketinde güvenlik açığı tespit edildiğinde, artık doğrudan Solution Explorer’da Fix with GitHub Copilot bağlantısıyla bir bildirim görüyorsunuz. Tıklayın ve Copilot güvenlik açığını analiz eder, doğru paket güncellemelerini önerir ve uygular.

Bağımlılıkları güncel tutmakta zorlanan ekipler için (ki bu esasen herkes), “bir güvenlik açığı olduğunu biliyorum ama doğru güncelleme yolunu bulmak başlı başına bir proje” sürtünmesini ortadan kaldırıyor.

Sonuç

Özel agentlar ve beceriler başlık haberi, ancak find_symbol uyuyan dev — .NET kodunu yeniden düzenlerken Copilot’un ne kadar doğru olabileceğini temelden değiştiriyor. Canlı profil oluşturma entegrasyonu ve güvenlik açığı düzeltmeleriyle birleşince bu güncelleme, Visual Studio’nun AI özelliklerini demo hazır değil gerçekten pratik hissettiriyor.

Her şeyi denemek için Visual Studio 2026 Insiders‘ı indirin.

KubeCon Avrupa 2026: .NET Geliştiricilerinin Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Büyük bir duyuru yazısı yayımlandığında ve “harika, ama bu benim için ne değiştiriyor ki” diye düşünerek kaydırma yaptığınız o hissi bilirsiniz, değil mi? Ben her KubeCon sezonunda böyle hissediyorum.

Microsoft, KubeCon Avrupa 2026 tam özetini yayımladı — bizzat Brendan Burns tarafından yazıldı — ve dürüst olmak gerekirse? Burada gerçek bir içerik var. Yalnızca özellik onay kutuları değil, üretimdeki çalışma biçiminizi değiştiren türden operasyonel iyileştirmeler.

.NET geliştiricileri olarak bizim için gerçekten önemli olanları ele alayım.

Service Mesh Yükü Olmadan mTLS

Service mesh’ler hakkında şunu söylemek gerekir: herkes güvenlik garantilerini istiyor, kimse operasyonel yükü istemiyor. AKS nihayet bu boşluğu kapatıyor.

Azure Kubernetes Application Network, ağır sidecar’lı bir mesh dağıtmadan karşılıklı TLS, uygulama farkında yetkilendirme ve trafik telemetrisi sunuyor. Advanced Container Networking Services’deki Cilium mTLS ile birleşince, kimlik yönetimi için X.509 sertifikaları ve SPIRE kullanan şifreli pod-to-pod iletişimi elde ediyorsunuz.

Pratikte ne anlama geliyor: arka plan worker’larıyla konuşan ASP.NET Core API’leriniz, birbirini çağıran gRPC servisleriniz — sıfır uygulama kodu değişikliğiyle ağ düzeyinde şifreli ve kimlik doğrulamalı. Bu büyük bir şey.

ingress-nginx‘ten geçiş yapan ekipler için tam Kubernetes Gateway API desteğiyle Application Routing with Meshless Istio da mevcut. Sidecar yok. Standart tabanlı. Ve kademeli geçiş için ingress2gateway araçlarını gönderdiler.

Sonradan Düşünülmemiş GPU Gözlemlenebilirliği

.NET servislerinizin yanında AI çıkarımı çalıştırıyorsanız (ve dürüst olalım, kim başlamıyor?), GPU izleme kör noktasına çarpmış olabilirsiniz. Harika CPU/bellek dashboard’larınız olur ve ardından… manuel exporter bağlantıları olmadan GPU’lar için hiçbir şey.

AKS artık GPU metriklerini yönetilen Prometheus ve Grafana’ya yerel olarak sunuyor. Aynı yığın, aynı dashboard’lar, aynı uyarı pipeline’ı. Özel exporter yok, üçüncü taraf ajan yok.

Ağ tarafında, tek tıklamalı Azure Monitor deneyimiyle HTTP, gRPC ve Kafka trafiği için akış başına görünürlük eklediler. IP’ler, portlar, iş yükleri, akış yönü, politika kararları — hepsi yerleşik dashboard’larda.

Ve beni iki kez baktıran şu oldu: agentic container networking kümenizin ağ durumu hakkında doğal dil soruları sorabileceğiniz bir web UI ekliyor. “Pod X neden servis Y’ye ulaşamıyor?” → canlı telemetriden salt okunur tanılamalar. Gece 2’de gerçekten kullanışlı.

PhD Gerektirmeyen Kümeler Arası Ağ

Multi-cluster Kubernetes, tarihsel olarak “kendi ağ yapıştırıcınızı getirin” deneyimiydi. Azure Kubernetes Fleet Manager artık yönetilen Cilium cluster mesh üzerinden kümeler arası ağ sunuyor:

AKS kümeleri arasında birleşik bağlantı
Kümeler arası keşif için global servis kaydı
Merkezi olarak yönetilen, küme başına tekrarlanmayan konfigürasyon

Dayanıklılık veya uyumluluk için bölgeler arasında .NET mikro servisler çalıştırıyorsanız, bu çok sayıda kırılgan özel yapıştırıcının yerini alıyor. West Europe’daki A Servisi, tutarlı yönlendirme ve güvenlik politikalarıyla mesh üzerinden East US’deki B Servisini keşfedebilir ve çağırabilir.

Cesaret Gerektirmeyen Yükseltmeler

Dürüst olalım — üretimdeki Kubernetes yükseltmeleri streslidir. “Yükselt ve umut et” pek çok ekip için fiili strateji olmuştur ve kümelerin sürümlerin gerisinde kalmasının ana nedenidir.

İki yeni özellik bunu değiştiriyor:

Mavi-yeşil agent pool yükseltmeleri yeni konfigürasyonla paralel bir node pool oluşturur. Davranışı doğrulayın, trafiği kademeli olarak kaydırın ve temiz bir geri alma yolu tutun. Üretim node’larında artık yerinde mutasyon yok.

Agent pool rollback, bir yükseltme ters gittiğinde kümeyi yeniden oluşturmadan bir node pool’u önceki Kubernetes sürümüne ve node imajına döndürmenizi sağlar.

Birlikte ele alındığında, bunlar nihayet operatörlere yükseltme yaşam döngüsü üzerinde gerçek kontrol veriyor. .NET ekipleri için bu önemlidir çünkü platform hızı, yeni runtime’ları, güvenlik yamalarını ve ağ özelliklerini ne kadar hızlı benimseyebileceğinizi doğrudan belirler.

AI İş Yükleri Birinci Sınıf Kubernetes Vatandaşı Oluyor

Upstream açık kaynak çalışması da eşit derecede önemli. Dynamic Resource Allocation (DRA) Kubernetes 1.36’da GA’ya geçti, GPU planlamasını bir geçici çözüm yerine gerçek anlamda birinci sınıf bir özellik haline getirdi.

İzlemeye değer birkaç proje:

Proje	Ne Yapıyor
AI Runway	Çıkarım için ortak Kubernetes API’si — K8s bilmeden model dağıtın, HuggingFace keşfi ve maliyet tahminleriyle
HolmesGPT	Cloud-native için agentic sorun giderme — artık CNCF Sandbox projesi
Dalec	SBOM üretimiyle bildirimsel container imaj oluşturma — derleme aşamasında daha az CVE

Yön açık: .NET API’niz, Semantic Kernel orkestrasyon katmanınız ve çıkarım iş yüklerinizin hepsi tek tutarlı bir platform modelinde çalışmalı. Oraya doğru ilerliyoruz.

Bu Hafta Nereden Başlardım

Bu değişiklikleri ekibiniz için değerlendiriyorsanız, işte dürüst öncelik listem:

Önce gözlemlenebilirlik — üretim dışı bir kümede GPU metriklerini ve ağ akış günlüklerini etkinleştirin. Neyi kaçırdığınızı görün.
Mavi-yeşil yükseltmeleri deneyin — bir sonraki üretim kümesi yükseltmenizden önce rollback iş akışını test edin. Sürece güven inşa edin.
Kimlik farkında ağı pilot edin — bir dahili servis yolu seçin ve Cilium ile mTLS’i etkinleştirin. Yükü ölçün (spoiler: minimumdur).
Fleet Manager’ı değerlendirin — ikiden fazla küme çalıştırıyorsanız, kümeler arası ağ azaltılan özel yapıştırıcıyla kendini amorti eder.

Küçük deneyler, hızlı geri bildirim. Her zaman doğru hamle budur.

Son Söz

KubeCon duyuruları bunaltıcı olabiliyor, ancak bu grup gerçekten AKS’teki .NET ekipleri için iğneyi hareket ettiriyor. Mesh yükü olmadan daha iyi ağ güvenliği, gerçek GPU gözlemlenebilirliği, daha güvenli yükseltmeler ve daha güçlü AI altyapısı temelleri.

Halihazırda AKS’teyseniz, bu operasyonel temelinizi sıkılaştırmak için harika bir an. .NET iş yüklerini Kubernetes’e taşımayı planlıyorsanız — platform önemli ölçüde daha üretim hazır hale geldi.

SQL MCP Server, SSMS'de Copilot ve AI Agentlı Veritabanı Hub'ı: SQLCon 2026'dan Gerçekten Önemli Olanlar

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft, Atlanta’da FabCon ile birlikte SQLCon 2026’yı başlattı ve açılacak çok şey var. Orijinal duyuru, tasarruf planlarından kurumsal uyumluluk özelliklerine kadar her şeyi kapsıyor. Kurumsal fiyatlandırma slaytlarını atlayarak, Azure SQL ve AI ile bir şeyler geliştiren bir geliştirici olarak önemli olanlara odaklanacağım.

SQL MCP Server genel önizlemede

Bu, benim için manşet. Azure SQL Database Hyperscale artık, Model Context Protocol kullanarak SQL verilerinizi AI agentlarına ve Copilot’lara güvenli biçimde bağlamanıza olanak tanıyan genel önizlemede bir SQL MCP Server‘a sahip.

MCP dalgasını takip ediyorsanız — ve dürüst olmak gerekirse, şu anda bunu kaçırmak zor — bu büyük bir gelişme. AI agentlarınıza veritabanından bağlam sağlamak için özel veri pipeline’ları oluşturmak yerine, SQL verilerini doğrudan sergilemek için standart bir protokol elde ediyorsunuz. Agentlarınız canlı veritabanı bilgilerini sorgulayabilir, üzerinde akıl yürütebilir ve harekete geçebilir.

Semantic Kernel veya Microsoft Agent Framework ile AI agentları geliştiriyoruz için bu, temiz bir entegrasyon yolu açıyor. Agentınızın envanteri kontrol etmesi mi gerekiyor? Müşteri kaydına bakması mı? Bir siparişi doğrulaması mı? MCP, her senaryo için özel veri-getirme kodu yazmadan bunu yapmanın yapılandırılmış bir yolunu sunar.

SSMS 22’de GitHub Copilot artık GA’da

SQL Server Management Studio’da zaman geçiriyorsanız — ve dürüst olalım, çoğumuz hâlâ geçiriyoruz — GitHub Copilot artık SSMS 22’de genel kullanım için hazır. VS Code ve Visual Studio’da zaten kullandığınız Copilot deneyiminin aynısı, ama T-SQL için.

Buradaki pratik değer açık: sorgu yazma, saklı yordam yeniden düzenleme, performans sorunlarını giderme ve yönetim görevleri için sohbet tabanlı yardım. Kavram olarak devrimci bir şey yok, ama SSMS’in içinde olması, veritabanı işleriniz için AI yardımı almak üzere başka bir editöre geçmenize gerek kalmadığı anlamına gelir.

Vektör indeksler ciddi bir yükseltme aldı

Azure SQL Database artık tam ekleme, güncelleme ve silme desteğiyle daha hızlı, daha yetenekli vektör indekslerine sahip. Bu, vektör verilerinizin gerçek zamanlı güncel kalması anlamına gelir — toplu yeniden indeksleme gerekmez.

İşte yenilikler:

Daha küçük indeks boyutları için fazla doğruluk kaybetmeden quantization (niceleme)
Daha hassas sonuçlar için iterative filtering (yinelemeli filtreleme)
Öngörülebilir performans için daha sıkı sorgu optimize edici entegrasyonu

Azure SQL’i vektör deposu olarak kullanarak RAG (Retrieval-Augmented Generation) yapıyorsanız, bu iyileştirmeler doğrudan işe yarar. Vektörlerinizi aynı veritabanındaki ilişkisel verilerle birlikte tutabilirsiniz; bu, ayrı bir vektör veritabanı çalıştırmaya kıyasla mimarinizi önemli ölçüde basitleştirir.

Aynı vektör geliştirmeleri Fabric’teki SQL veritabanında da mevcut; çünkü her ikisi de aynı SQL motoru üzerinde çalışıyor.

Fabric’te Database Hub: ajanlı yönetim

Bu daha ileriye dönük ama ilginç. Microsoft, Azure SQL, Cosmos DB, PostgreSQL, MySQL ve Arc üzerinden SQL Server genelinde tek bir cam panel sunan Microsoft Fabric’te Database Hub‘ı (erken erişim) duyurdu.

İlginç taraf, yalnızca birleşik görünüm değil — yönetimin ajanlı yaklaşımı. AI agentlar veritabanı altyapınızı sürekli izler, nelerin değiştiğini öne çıkarır, neden önemli olduğunu açıklar ve ne yapılması gerektiğini önerir. Agentın ön çalışmayı yaptığı ve siz kararları aldığınız bir human-in-the-loop modelidir.

Ondan fazla veritabanını yöneten ekipler için bu, operasyonel gürültüyü gerçekten azaltabilir. Portaller arasında atlayıp metrikleri manuel olarak kontrol etmek yerine, agent sinyali size getirir.

.NET geliştiricileri için ne anlama geliyor

Tüm bu duyuruları birbirine bağlayan ip açık: Microsoft, veritabanı yığınının her katmanına AI agentları yerleştiriyor. Bir hile olarak değil, pratik bir araç katmanı olarak.

Azure SQL tarafından desteklenen .NET uygulamaları geliştiriyorsanız, gerçekten yapacaklarım şunlar:

AI agentları geliştiriyorsanız SQL MCP Server’ı deneyin. Agentlarınıza özel bağlantı kodu olmadan veritabanı erişimi vermenin en temiz yolu.
Henüz yapmadıysanız SSMS’de Copilot’u etkinleştirin — günlük SQL çalışması için ücretsiz üretkenlik kazanımı.
RAG yapıyorsanız ve şu anda ayrı bir vektör deposu çalıştırıyorsanız vektör indekslerine bakın. Azure SQL’de birleştirmek, yönetilecek bir servis daha az demek.

Sonuç

Tam duyuruda daha fazlası var — tasarruf planları, geçiş asistanları, uyumluluk özellikleri — ancak geliştirici hikayesi MCP Server’da, vektör iyileştirmelerinde ve ajanlı yönetim katmanında. Bunlar, bütçenizi değil, oluşturduğunuz şeyleri değiştiren parçalar.

Tam tablo için Shireesh Thota’nın tam duyurusuna göz atın; yeni yönetim deneyimini denemek istiyorsanız Database Hub erken erişimine kaydolun.

.NET Geliştiricilerinin VS Code 1.112'de Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 yayınlandı ve dürüstçe söylemek gerekirse? .NET dünyasında gününüzü geçiriyorsanız bu sürüm farklı bir his veriyor. Resmi sürüm notlarında pek çok şey var, ama sizi biraz kaydırmadan kurtarayım ve gerçekten bizim için önemli olanlara odaklanayım.

Copilot CLI çok daha kullanışlı hale geldi

Bu sürümün büyük teması agent özerkliği — Copilot’a her adımı siz denetlemeden işini yapması için daha fazla alan tanıma.

Mesaj yönlendirme ve sıralama

Copilot CLI bir görevin ortasındayken bir şeyi söylemeyi unuttuğunuzu fark ettiğiniz o anı bilirsiniz. Önce beklemeniz gerekiyordu. Artık bir istek hâlâ çalışırken mesaj gönderebilirsiniz — ya mevcut yanıtı yönlendirmek ya da takip talimatlarını sıraya almak için.

Bu, Copilot’un bir proje kurduğunu izlerken “ah, buna MassTransit de eklemeliyim” dediğiniz uzun dotnet iskele görevleri için çok önemli.

İzin seviyeleri

En çok heyecanlandığım bu. Copilot CLI oturumları artık üç izin seviyesini destekliyor:

Default Permissions — araçların çalışmadan önce onay istediği olağan akış
Bypass Approvals — her şeyi otomatik onaylar ve hatalarda yeniden dener
Autopilot — tamamen özerk: araçları onaylar, kendi sorularını yanıtlar ve görev tamamlanana kadar devam eder

Entity Framework ile migrasyonlar, Docker kurulumu ve yeni bir ASP.NET Core API’si oluşturuyorsanız — Autopilot modu demek istediğinizi tanımlayıp kahve almaya gidebilirsiniz demek. Gerisini halledecek.

Autopilot’u chat.autopilot.enabled ayarıyla etkinleştirebilirsiniz.

Devretmeden önce değişiklikleri önizleyin

Copilot CLI’a bir görev devrettiğinizde bir worktree oluşturur. Daha önce, teslim edilmemiş değişiklikleriniz varsa nelerin etkileneceğini görmek için Source Control’ü kontrol etmeniz gerekiyordu. Artık Chat görünümü, kopyalamak, taşımak veya yoksaymak isteyip istemediğinize karar vermeden önce bekleyen değişiklikleri doğrudan orada gösteriyor.

Küçük bir şey, ama “dur, ne hazırlamıştım?” anından kurtarıyor.

VS Code’dan çıkmadan web uygulamalarını hata ayıklayın

Entegre tarayıcı artık tam hata ayıklamayı destekliyor. Kesme noktaları koyabilir, kod üzerinde adım adım ilerleyebilir ve değişkenleri inceleyebilirsiniz — hepsi VS Code içinde. Artık Edge DevTools’a geçiş yok.

Yeni bir editor-browser hata ayıklama türü var ve mevcut msedge veya chrome başlatma yapılandırmalarınız varsa, geçiş launch.json‘daki type alanını değiştirmek kadar basit:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor geliştiricileri için bu oyun değiştirici. Terminalde zaten dotnet watch çalıştırıyorsunuz — artık hata ayıklamanız da aynı pencerede kalıyor.

Tarayıcı aynı zamanda bağımsız yakınlaştırma seviyeleri (sonunda!), düzgün sağ tıklama bağlam menüleri aldı ve yakınlaştırma web sitesi başına hatırlanıyor.

MCP sunucu korumalı alanı

Bu, düşündüğünüzden daha önemli. MCP sunucuları kullanıyorsanız — belki Azure kaynaklarınız veya veritabanı sorguları için özel bir tane kurduysanız — bunlar VS Code sürecinizle aynı izinlerle çalışıyordu. Yani dosya sisteminize, ağınıza, her şeye tam erişim.

Artık onları korumalı alana alabilirsiniz. mcp.json dosyanızda:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Korumalı alandaki bir sunucu sahip olmadığı bir şeye erişim gerektirdiğinde, VS Code izin vermeniz için sizi uyarıyor. “Kimse garip bir şey yapmasın” yaklaşımından çok daha iyi.

Monorepo özelleştirme keşfi

Bir monorepo’da çalışıyorsanız (ve dürüstçe söylemek gerekirse, pek çok kurumsal .NET çözümü buna dönüşüyor), bu gerçek bir sorun noktasını çözüyor.

Daha önce, reponuzun bir alt klasörünü açtığınızda VS Code, depo kökünüzdeki copilot-instructions.md, AGENTS.md veya özel becerileri bulamıyordu. Artık chat.useCustomizationsInParentRepositories ayarıyla .git köküne kadar yukarı çıkıp her şeyi buluyor.

Bu, ekibinizin tüm monorepo projelerine herkesin kök klasörü açmasına gerek kalmadan agent talimatlarını, prompt dosyalarını ve özel araçları paylaşabilmesi anlamına geliyor.

Agent hata ayıklama için /troubleshoot

Özel talimatlar veya beceriler ayarlayıp neden alınmadığını hiç merak ettiniz mi? Yeni /troubleshoot becerisi agent hata ayıklama günlüklerini okuyup ne olduğunu söylüyor — hangi araçların kullanıldığı veya atlandığı, neden talimatların yüklenmediği ve yavaş yanıtlara neyin yol açtığı.

Bunu şununla etkinleştirin:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Ardından sohbette /troubleshoot neden özel beceri yüklenmiyor? yazın.

Bu hata ayıklama günlüklerini artık dışa ve içe aktarabilirsiniz; bir şey beklendiği gibi çalışmadığında ekibinizle paylaşmak için harika.

Resim ve ikili dosya desteği

Agentlar artık diskten resim dosyalarını ve ikili dosyaları doğrudan okuyabiliyor. İkili dosyalar hexdump formatında sunuluyor ve resim çıktıları (entegre tarayıcıdan alınan ekran görüntüleri gibi) bir carousel görünümünde gösteriliyor.

.NET geliştiricileri için düşünün: bir UI hatasının ekran görüntüsünü sohbete yapıştırın ve agent neyin yanlış olduğunu anlasın, ya da Blazor bileşeni render çıktısını analiz ettirin.

Otomatik sembol referansları

Küçük bir yaşam kalitesi iyileştirmesi: bir sembol adını (bir sınıf, metot vb.) kopyalayıp sohbete yapıştırdığınızda VS Code artık otomatik olarak #sym:İsim referansına dönüştürüyor. Bu, agent’a manuel olarak eklemek zorunda kalmadan bu sembol hakkında tam bağlam sağlıyor.

Bunun yerine düz metin istiyorsanız Ctrl+Shift+V kullanın.

Eklentiler artık etkinleştirilebilir/devre dışı bırakılabilir

Daha önce bir MCP sunucusunu veya eklentiyi devre dışı bırakmak kaldırmak anlamına geliyordu. Artık hem genel hem de çalışma alanı başına açıp kapatabilirsiniz. Extensions görünümünde veya Customizations görünümünde sağ tıklayın ve işiniz bitti.

npm ve pypi’den eklentiler artık otomatik güncellenebilir; ancak güncellemeler makinenizde yeni kod çalıştırmak anlamına geldiğinden önce onay isteyecekler.

Sonuç

VS Code 1.112, agent deneyimini açıkça ileriye taşıyor — daha fazla özerklik, daha iyi hata ayıklama, daha sıkı güvenlik. .NET geliştiricileri için entegre tarayıcı hata ayıklama ve Copilot CLI iyileştirmeleri öne çıkan özellikler.

Bir .NET projesi için tam Copilot CLI oturumu Autopilot modunda henüz denemediyseniz bu sürüm başlamak için iyi bir zaman. Sadece izinlerinizi ayarlamayı ve bırakıp gidermeyi unutmayın.

VS Code 1.112’yi indirin veya Help > Check for Updates aracılığıyla VS Code içinden güncelleyin.

Azure DevOps MCP Server Microsoft Foundry'ye Geldi: AI Agent'larınız İçin Ne Anlama Geliyor

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) son dönemde çok konuşuluyor. AI agent ekosistemine dikkat ettiyseniz, MCP server’ların her yerde belirdiğini fark etmişsinizdir — agent’lara standart bir protokol üzerinden harici araçlar ve servislerle etkileşim kurma yeteneği kazandırıyorlar.

Artık Azure DevOps MCP Server Microsoft Foundry’de mevcut ve bu, pratik olasılıklar üzerine düşündüren entegrasyonlardan biri.

Aslında ne oluyor

Microsoft, Azure DevOps MCP Server’ı genel önizleme olarak zaten yayınlamıştı — bu MCP server’ın kendisi. Yeni olan şey ise Foundry entegrasyonu. Artık Azure DevOps MCP Server’ı araç kataloğundan doğrudan Foundry agent’larınıza ekleyebilirsiniz.

Foundry’ye henüz aşina olmayanlar için: Microsoft’un AI destekli uygulama ve agent’ları ölçekli şekilde oluşturma ve yönetme için birleşik platformu. Model erişimi, orkestrasyon, değerlendirme, dağıtım — hepsi tek bir yerde.

Kurulum

Kurulum şaşırtıcı derecede basit:

Foundry agent’ınızda Add Tools > Catalog bölümüne gidin
“Azure DevOps” arayın
Azure DevOps MCP Server (önizleme) seçin ve Create tıklayın
Organizasyon adınızı girin ve bağlanın

Hepsi bu. Agent’ınız artık Azure DevOps araçlarına erişebilir.

Agent’ınızın nelere erişeceğini kontrol etme

Takdir ettiğim kısım şu: ya hep ya hiç yaklaşımına mahkum değilsiniz. Agent’ınıza hangi araçların sunulacağını belirtebilirsiniz. Yalnızca iş öğelerini okusun ama pipeline’lara dokunmasın istiyorsanız bunu yapılandırabilirsiniz. En az ayrıcalık ilkesi, AI agent’larınıza uygulanmış hali.

Bu, birinin “sürümle ilgili yardım et” demesi üzerine agent’ın kazara bir dağıtım pipeline’ını tetiklemesini istemediğiniz kurumsal senaryolarda önem taşıyor.

Bu .NET ekipleri için neden ilginç

Pratikte neleri mümkün kıldığını düşünün:

Sprint planlama asistanları — iş öğelerini çekebilen, hız verilerini analiz edebilen ve sprint kapasitesi önerebilen agent’lar
Kod inceleme botları — repolarınızı ve bağlantılı iş öğelerinizi gerçekten okuyabildikleri için PR bağlamınızı anlayan agent’lar
Olay müdahalesi — iş öğesi oluşturabilen, son dağıtımları sorgulayabilen ve hataları son değişikliklerle ilişkilendirebilen agent’lar
Geliştirici onboarding’i — “Ne üzerinde çalışmalıyım?” sorusuna gerçek proje verileriyle desteklenmiş gerçek bir yanıt

CI/CD pipeline’ları ve proje yönetimi için Azure DevOps’u zaten kullanan .NET ekipleri için, bir AI agent’ının bu sistemlerle doğrudan etkileşim kurabilmesi, yararlı otomasyona doğru önemli bir adım (sıradan chatbot-as-a-service değil).

Daha geniş MCP resmi

Bu, daha geniş bir trendin parçası: MCP server’lar, AI agent’larının dış dünyayla etkileşim kurmasının standart yolu haline geliyor. GitHub, Azure DevOps, veritabanları, SaaS API’leri için MCP server’lar görüyoruz — ve Foundry, tüm bu bağlantıların bir araya geldiği merkez haline geliyor.

.NET ekosisteminde agent geliştiriyorsanız MCP’ye dikkat etmeye değer. Protokol standartlaşmış, araç kitleri olgunlaşıyor ve Foundry entegrasyonu, server bağlantılarını manuel olarak kurmak zorunda kalmadan erişilebilir hale getiriyor.

Sonuç

Foundry’deki Azure DevOps MCP Server önizleme aşamasında, bu yüzden gelişmeye devam etmesini bekleyin. Ancak temel iş akışı sağlam: bağlanın, araç erişimini yapılandırın ve agent’larınızın DevOps verilerinizle çalışmasına izin verin. Zaten Foundry ekosistemindeyseniz, birkaç tıklama uzaktasınız. Bir deneyin ve hangi iş akışlarını oluşturabileceğinizi görün.

Adım adım kurulum ve daha fazla ayrıntı için tam duyuruya göz atın.

Dizüstü Bilgisayardan Üretime: İki Komutla AI Agent'larını Microsoft Foundry'ye Dağıtma

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

“Makinemde çalışıyor” ile “dağıtıldı ve trafik sunuyor” arasındaki o boşluğu bilirsiniz? AI agent’ları için bu boşluk acı verici derecede geniş oldu. Kaynak sağlamanız, modelleri dağıtmanız, kimliği bağlamanız, izlemeyi kurmanız gerekiyor — ve bütün bunlar herhangi biri agent’ınızı çağırabilmeden önce.

Azure Developer CLI bunu iki komutluk bir iş haline getirdi.

Yeni `azd ai agent` iş akışı

Bunun gerçekte nasıl göründüğünü anlatalım. Bir AI agent projeniz var — diyelim ki bir otel danışman agent’ı. Yerel olarak çalışıyor. Microsoft Foundry üzerinde çalışmasını istiyorsunuz.

azd ai agent init
azd up

Hepsi bu. İki komut. azd ai agent init, reponuzda altyapı-kod olarak iskele oluşturur ve azd up her şeyi Azure’da sağlayıp agent’ınızı yayımlar. Foundry portalında agent’ınıza doğrudan bir bağlantı alırsınız.

Arka planda ne oluyor

init komutu reponuzda gerçek, incelenebilir Bicep şablonları oluşturuyor:

Bir Foundry Kaynağı (üst düzey kapsayıcı)
Bir Foundry Projesi (agent’ınızın bulunduğu yer)
Model dağıtımı yapılandırması (GPT-4o vb.)
Uygun RBAC rol atamalarıyla Yönetilen kimlik
Servis haritası için azure.yaml
Agent meta verileri ve ortam değişkenleriyle agent.yaml

İşte kilit nokta: bunların hepsi size ait. Reponuzda sürümlendirilmiş Bicep. İnceleyebilir, özelleştirebilir ve agent kodunuzun yanı sıra commit edebilirsiniz. Sihirli kara kutular yok.

Geliştirme döngüsü

Gerçekten beğendiğim şey yerel geliştirme hikayesi. Agent mantığını geliştirirken, her prompt değişikliğinde yeniden dağıtmak istemezsiniz:

azd ai agent run

Bu, agent’ınızı yerel olarak başlatır. Bunu test promptları göndermek için azd ai agent invoke ile eşleştirin, sıkı bir geri bildirim döngüsü elde edersiniz. Kodu düzenleyin, yeniden başlatın, çağırın, tekrarlayın.

invoke komutu yönlendirme konusunda da akıllı — yerel bir agent çalışırken otomatik olarak onu hedefler. Çalışmıyorken uzak endpoint’e isabet eder.

Gerçek zamanlı izleme

Bu beni ikna eden özellik. Agent’ınız dağıtıldığında:

azd ai agent monitor --follow

Agent’ınızdan geçen her istek ve yanıt gerçek zamanlı olarak terminalinize akıyor. Üretim sorunlarını hata ayıklamak için bu paha biçilmez. Log analitiğini karıştırmak yok, metriklerin toplanmasını beklemek yok — şu an ne olduğunu görüyorsunuz.

Tam komut seti

İşte hızlı referans:

Komut	Ne yapıyor
`azd ai agent init`	IaC ile bir Foundry agent projesi iskele oluşturur
`azd up`	Azure kaynaklarını sağlar ve agent’ı dağıtır
`azd ai agent invoke`	Uzak veya yerel agent’a prompt gönderir
`azd ai agent run`	Geliştirme için agent’ı yerel olarak çalıştırır
`azd ai agent monitor`	Yayımlanan agent’dan gerçek zamanlı logları akıtır
`azd ai agent show`	Agent sağlığını ve durumunu kontrol eder
`azd down`	Tüm Azure kaynaklarını temizler

.NET geliştiricileri için neden önemli

Duyuruda örnek Python tabanlı olsa da, altyapı hikayesi dilden bağımsız. .NET agent’ınız aynı Bicep iskeleleme, aynı yönetilen kimlik kurulumu, aynı izleme pipeline’ı alıyor. .NET Aspire uygulamalarınız veya Azure dağıtımları için zaten azd kullanıyorsanız, bu mevcut iş akışınıza tam oturuyor.

AI agent’ları için dağıtım boşluğu, ekosistemdeki en büyük sürtüşme noktalarından biri oldu. Çalışan bir prototipi uygun kimlik, ağ ve izlemeyle bir üretim endpoint’ine götürmek bir haftalık DevOps çalışması gerektirmemeli. Artık iki komut ve birkaç dakika gerektiriyor.

Sonuç

azd ai agent şu an mevcut. AI agent’larınızı dağıtmayı erteliyorsanız çünkü altyapı kurulumu çok fazla iş gibi geliyordu, bunu bir deneyin. Ön uç sohbet uygulaması entegrasyonu dahil adım adım tam kılavuz için tam anlatıma göz atın.

Foundry Agent Service GA'ya Geçti: .NET Agent Geliştiricileri İçin Gerçekten Önemli Olan Nedir?

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Kabul edelim — bir AI agent prototipi oluşturmak kolay kısım. Zor olan ise sonrasındaki her şey: uygun ağ izolasyonuyla üretime almak, gerçekten anlamlı değerlendirmeler yapmak, uyumluluk gereksinimlerini karşılamak ve gece 2’de her şeyin çökmemesini sağlamak.

Foundry Agent Service az önce GA’ya geçti ve bu sürüm tam da bu “sonrasındaki her şey” boşluğuna odaklanıyor.

Responses API Üzerine İnşa Edildi

İşte manşet haber: yeni nesil Foundry Agent Service, OpenAI Responses API üzerine kurulu. Eğer bu wire protokolüyle zaten geliştirme yapıyorsanız, Foundry’ye geçiş minimal kod değişikliği gerektiriyor. Kazandıklarınız: kurumsal güvenlik, özel ağ desteği, Entra RBAC, tam izleme ve değerlendirme — mevcut agent mantığınızın üstüne.

Mimari kasıtlı olarak açık tasarlanmış. Tek bir model sağlayıcısına veya tek bir orkestrasyon framework’üne bağlı değilsiniz. Planlama için DeepSeek, üretim için OpenAI, orkestrasyon için LangGraph kullanabilirsiniz — runtime tutarlılık katmanını halleder.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Özel Ağ Desteği: Kurumsal Engel Kaldırıldı

Bu, kurumsal benimsemeyi engelleyen sorunu ortadan kaldıran özelliktir. Foundry artık BYO VNet ile uçtan uca tam özel ağ desteği sunuyor:

Genel çıkış yok — agent trafiği hiçbir zaman genel internete çıkmıyor
Container/alt ağ enjeksiyonu yerel iletişim için ağınıza entegre ediliyor
Araç bağlantısı dahil — MCP server’lar, Azure AI Search, Fabric data agent’ları hepsi özel yollar üzerinden çalışıyor

Son nokta kritik. Yalnızca çıkarım çağrıları değil, her araç çağrısı ve her veri alma işlemi de ağ sınırınızın içinde kalıyor. Dışarıya yönlendirmeyi yasaklayan veri sınıflandırma politikaları altında çalışan ekipler için işte bu eksik olan parçaydı.

Doğru Yapılmış MCP Kimlik Doğrulaması

MCP server bağlantıları artık tüm auth pattern yelpazesini destekliyor:

Auth Yöntemi	Ne Zaman Kullanılır
Key tabanlı	Kurum geneli dahili araçlar için basit paylaşımlı erişim
Entra Agent Identity	Servisten servise; agent kendisi olarak kimlik doğrular
Entra Managed Identity	Proje bazında izolasyon; kimlik bilgisi yönetimi yok
OAuth Identity Passthrough	Kullanıcı delegeli erişim; agent kullanıcılar adına hareket eder

OAuth Identity Passthrough ilginç olan. Kullanıcıların bir agent’a kişisel verilerine — OneDrive’larına, Salesforce organizasyonlarına, kullanıcı kapsamlı bir SaaS API’sine — erişim vermesi gerektiğinde, agent standart OAuth akışlarıyla onlar adına hareket eder. Herkesi temsil etmeye çalışan paylaşımlı bir sistem kimliği yok.

Voice Live: Tesisatla Uğraşmadan Konuşmadan Konuşmaya

Bir agent’a ses eklemek eskiden STT, LLM ve TTS’i bir araya getirmek anlamına geliyordu — üç servis, üç gecikme adımı, üç faturalama yüzeyi, hepsi elle senkronize. Voice Live bunu tek bir yönetilen API’ye indirgiyor:

Semantik ses aktivitesi ve konuşma sonu algılama (anlamı anlıyor, sadece sessizliği değil)
Sunucu taraflı gürültü bastırma ve yankı giderme
Araya girme desteği (kullanıcılar yanıt ortasında sözü kesebilir)

Ses etkileşimleri, metinle aynı agent runtime’ından geçiyor. Aynı değerlendiriciler, aynı izler, aynı maliyet görünürlüğü. Müşteri desteği, saha hizmeti veya erişilebilirlik senaryoları için bu, daha önce özel bir ses pipeline’ı gerektiren şeyin yerini alıyor.

Değerlendirmeler: Onay Kutusundan Sürekli İzlemeye

Foundry’nin üretim kalitesi konusunda ciddiye geldiği yer burası. Değerlendirme sistemi artık üç katmana sahip:

Hazır değerlendiriciler — tutarlılık, alaka, temellendirilme, erişim kalitesi, güvenlik. Bir veri kümesine veya canlı trafiğe bağlayın, puanları geri alın.
Özel değerlendiriciler — kendi iş mantığınızı, ton standartlarınızı ve alana özgü uyumluluk kurallarınızı kodlayın.
Sürekli değerlendirme — Foundry canlı üretim trafiğini örnekliyor, değerlendirici paketinizi çalıştırıyor ve sonuçları dashboard’lar aracılığıyla sunuyor. Temellendirilme düştüğünde veya güvenlik eşikleri aşıldığında Azure Monitor uyarıları ayarlayın.

Her şey Azure Monitor Application Insights’a yayımlanıyor. Agent kalitesi, altyapı sağlığı, maliyet ve uygulama telemetrisi — hepsi tek bir yerde.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Barındırılan Agent’lar İçin Altı Yeni Bölge

Barındırılan agent’lar artık East US, North Central US, Sweden Central, Southeast Asia, Japan East ve daha fazlasında kullanılabilir. Bu, veri yerleşim gereksinimleri için ve agent’ınız veri kaynaklarına yakın çalıştığında gecikmeyi azaltmak için önemlidir.

.NET Geliştiricileri İçin Neden Önemli?

GA duyurusundaki kod örnekleri Python öncelikli olsa da, altta yatan altyapı dilden bağımsız — ve azure-ai-projects için .NET SDK aynı pattern’leri takip ediyor. Responses API, değerlendirme framework’ü, özel ağ desteği, MCP auth — bunların hepsi .NET’ten erişilebilir.

AI agent’larının “harika demo” aşamasından “bunu işte gerçekten gönderebilirim” aşamasına geçmesini bekliyorsanız, bu GA sürümü sinyaldir. Özel ağ desteği, uygun auth, sürekli değerlendirme ve üretim izleme — işte eksik olan parçalar bunlardı.

Son Söz

Foundry Agent Service şu anda kullanılabilir. SDK’yı kurun, portal’ı açın ve geliştirmeye başlayın. Hızlı başlangıç kılavuzu sıfırdan çalışan bir agent’a dakikalar içinde ulaştırıyor.

Tüm kod örnekleriyle birlikte tam teknik derinlemesine bakış için GA duyurusunu inceleyin.

Microsoft Agent Framework'te Arka Plan Yanıtları: Zaman Aşımı Kaygısına Son

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

o3 veya GPT-5.2 gibi akıl yürütme modelleriyle bir şeyler geliştirdiyseniz, o acıyı biliyorsunuzdur. Agent’ınız karmaşık bir görev üzerinde düşünmeye başlıyor, istemci beklemeye devam ediyor ve “bu tamam” ile “çöktü mü acaba?” arasında bir yerde bağlantınız zaman aşımına uğruyor. Tüm o emek? Gitti.

Microsoft Agent Framework yeni arka plan yanıtlarını yayınladı — ve dürüst olmak gerekirse bu, ilk günden beri var olması gereken özelliklerden biri.

Engelleyen çağrıların sorunu

Geleneksel istek-yanıt kalıbında, agent işini bitirene kadar istemciniz bekler. Hızlı görevler için bu sorunsuz çalışır. Ama bir akıl yürütme modelinden derin araştırma, çok adımlı analiz veya 20 sayfalık rapor oluşturması istediğinizde? Gerçek zamanlı dakikalar söz konusu. Bu pencerede:

HTTP bağlantıları zaman aşımına uğrayabilir
Ağ kesintileri tüm işlemi mahvedebilir
Kullanıcınız bir şeylerin olup olmadığını merak ederek dönen bir simgeye bakmak zorunda kalır

Arka plan yanıtları bunu tersine çeviriyor.

Continuation token’lar nasıl çalışır

Engellemek yerine, agent görevini başlatırsınız ve geriye bir continuation token alırsınız. Bunu bir tamirhanedeki teslimat fişi gibi düşünün — tezgahın önünde beklemezsiniz, hazır olduğunda gelirsiniz.

Akış basit:

AllowBackgroundResponses = true ile isteğinizi gönderin
Agent arka plan işlemeyi destekliyorsa bir continuation token alırsınız
Token null döndürene kadar kendi zamanlamanızda sorgulama yapın — bu, sonucun hazır olduğu anlamına gelir

.NET versiyonu şöyle:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Tamamlanana kadar sorgula
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Agent hemen tamamlarsa (basit görevler, arka plan işleme gerektirmeyen modeller), continuation token döndürülmez. Kodunuz sadece çalışır — özel bir işlem gerekmez.

Devam ettirme özellikli streaming: asıl sihir

Sorgulama, fırlat-unut senaryoları için uygun, ama gerçek zamanlı ilerleme izlemek istediğinizde ne olur? Arka plan yanıtları aynı zamanda yerleşik devam ettirme özelliğiyle streaming’i de destekliyor.

Her streaming güncellemesi kendi continuation token’ını taşıyor. Bağlantınız streaming ortasında kesilirse, tam kaldığınız yerden devam ediyorsunuz:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Ağ kesintisini simüle et
}

// Tam kaldığımız yerden devam et
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent, istemcinizde ne olursa olsun sunucu tarafında işlemeye devam ediyor. Bu, retry mantığı veya circuit breaker yazmadan yerleşik hata toleransı demek.

Bunu gerçekten ne zaman kullanmalısınız

Her agent çağrısının arka plan yanıtlarına ihtiyacı yok. Hızlı tamamlamalar için gereksiz yere karmaşıklık ekliyor olursunuz. Ama bunların parlattığı durumlar şunlar:

Karmaşık akıl yürütme görevleri — çok adımlı analiz, derin araştırma, bir akıl yürütme modelinin gerçekten düşünmesi gereken her şey
Uzun içerik üretimi — ayrıntılı raporlar, çok bölümlü belgeler, kapsamlı analizler
Güvenilmez ağlar — mobil istemciler, edge dağıtımlar, kararsız kurumsal VPN’ler
Asenkron UX kalıpları — görevi gönder, başka bir şey yap, sonuçlar için geri gel

Kurumsal uygulamalar geliştiren .NET geliştiricileri olarak bizim için özellikle son madde ilginç. Kullanıcının karmaşık bir rapor talep ettiği bir Blazor uygulaması düşünün — agent görevini başlatırsınız, ilerleme göstergesi gösterirsiniz ve kullanıcının çalışmaya devam etmesine izin verirsiniz. WebSocket karmaşası yok, özel kuyruk altyapısı yok, sadece bir token ve bir sorgulama döngüsü.

Sonuç

Arka plan yanıtları Microsoft Agent Framework üzerinden şu anda hem .NET hem de Python’da mevcut. Basit soru-cevabın ötesinde herhangi bir şey yapan agent’lar geliştiriyorsanız, bunu araç kutunuza eklemeye değer. Continuation token kalıbi, gerçek bir üretim sorununu çözerken işleri basit tutuyor.

Tam API referansı ve daha fazla örnek için belgelere bakın.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog

.NET 10 Ubuntu 26.04 LTS ile Geliyor — Neler Yeni

.NET 10’u İki Komutla Yükle

Konteynerler: -noble yerine -resolute

Native AOT: 3ms Başlatma, 1,4MB İkili

.NET 8 veya 9’a İhtiyacın Var mı?

Agent Framework'te CodeAct: Ajanınızın Gecikmesini Yarıya Nasıl İndirirsiniz

CodeAct Nedir?

Güvenlik: Hyperlight Mikro-VM’leri

Minimum Kurulum

CodeAct Ne Zaman Kullanılır (Ne Zaman Kullanılmaz)

Şimdi Deneyin

Ajanınız Şeyleri Nerede Hatırlıyor? Sohbet Geçmişi Depolama için Pratik Rehber

İki temel desen

Agent Framework bunu nasıl soyutlar

Sağlayıcı hızlı referans

Nasıl seçilir

Azure MCP Server Artık .mcpb — Herhangi Bir Runtime Olmadan Yükle

MCP Bundle Nedir?

Nasıl Kurulur

Başlamak için

GPT-5.5 Burada ve Azure Foundry'e Geliyor — .NET Geliştiricilerinin Bilmesi Gerekenler

GPT-5 Evrimi

Gerçekte ne değişti

Fiyatlandırma

Foundry Neden Önemli

VS Code 1.118: Copilot CLI Oturum Adları, Model Rozetleri ve TypeScript 7.0 Nightly Alıyor

Copilot CLI: Oturumlara Gerçek Adlar Geliyor

Klavye Kısayollarıyla Hızlı Oturum Değiştirme

Sohbette Model Rozetleri

Copilot CLI’da Otomatik Model Seçimi

TypeScript 7.0 Nightly Katılımı

Foundry Toolboxes: Tüm Ajan Araçları için Tek Bir Endpoint

Toolbox nedir?

Dört sütun (bugün ikisi mevcut)

Pratik örnek

Foundry Agents’a bağımlılık yok

Neden şimdi önemli?

Sonuç

Python, TypeScript ve .NET ile azd Hook Yazma: Shell Script'lere Veda

Hook nedir?

Algılama nasıl çalışır

Dile göre önemli ayrıntılar

Python

JavaScript ve TypeScript

.NET

Executor’a özgü yapılandırma

.NET geliştiricileri için önemi

Sonuç

Windows App Dev CLI v0.3: Terminalden F5 Hata Ayıklama ve Ajanlar için UI Otomasyonu

winapp run: Her yerden F5

Yeni NuGet Paketi: Paketlenmiş uygulamalar için dotnet run

winapp ui: Komut satırından UI Otomasyonu

Diğer yenilikler

Nasıl edinilir

azd + GitHub Copilot: Yapay Zeka Destekli Proje Kurulumu ve Akıllı Hata Çözümü

azd init Sırasında Copilot ile Kurulum

Gerçekte Ne Yapar

Copilot ile Hata Giderme

Varsayılan Davranışı Ayarlama

Sonuç

Node.js için C# ile .NET Native AOT Kullanarak Yerel Eklenti Yazma

Temel fikir

Proje kurulumu

Giriş noktasını dışa aktarma

TypeScript’ten çağırma

Sonuç

VS Code 1.117: Agentlar Artık Kendi Git Dallarını Alıyor ve Ben Bunun İçin Buradayım

Autopilot modu artık tercihinizi hatırlıyor

Agent oturumları için worktree ve git izolasyonu

Alt-agentlar ve agent ekipleri

Agentlar girdi gönderdiğinde terminal çıktısı otomatik dahil ediliyor

macOS’ta Agents uygulaması kendi kendini güncelliyor

Bilmeye değer küçük şeyler

Sonuç

Azure'daki AI Deneyimleriniz Para Yakıyor — İşte Bunu Düzeltmenin Yolu

AI iş yükleri neden farklı hissettiriyor

Yönetim ile optimizasyon — farkı bilin

Gerçekten işe yarayan şeyler

Sonuç

Konteynerler: `-noble` yerine `-resolute`