Yazar: @atilayberber
Birkaç ay önce “AI, Power BI geliştiricisinin yerini alır mı?” sorusu konferans aralarında yarı şaka sorulurdu. Eylül 2026’dan sonra bu soru artık şaka değil. Microsoft, FabCon Barcelona’da Power BI Agentic Experiences‘ı genel kullanıma (GA) açtı. Yani bir yapay zekâ ajanına gereksinim dokümanı, hatta istediğiniz raporun bir ekran görüntüsünü veriyorsunuz; ajan semantic model’i inceliyor, DAX ölçülerini yazıyor, rapor sayfalarını kuruyor, Power BI Desktop’ta yeniden yüklüyor, ekran görüntüsü alıp kendi işini kontrol ediyor ve gerekirse düzeltiyor.
Bu yazıda neyin gerçekten değiştiğini, neyin abartıldığını ve BI geliştiricisi olarak benim bu tabloyu nasıl okuduğumu anlatıyorum. Baştan söyleyeyim: Bu bir “korkmayın, hiçbir şey değişmiyor” yazısı değil.
Kısaca: Bu yazıda neler var?
- Power BI Agentic Experiences tam olarak nedir, hangi parçalardan oluşur?
- Ajan bugün neyi gerçekten yapabiliyor, neyi yapamıyor?
- İki kamp: “Analistin yerini almaz” ile “Uzmanların yerini bugün alabilir”
- Benim görüşüm: Ortadan kalkan iş, ortadan kalkmayan rol
- BI geliştiricisinin 2027’de öne çıkacak beş becerisi
- Ekipler için pratik bir başlangıç planı
Power BI Agentic Experiences nedir?
Önce önemli bir ayrım: Bu, Power BI’da açıp kapattığınız bir özellik değil. Microsoft Learn’deki tanıma göre Power BI Agentic, kodlama ajanlarına (GitHub Copilot, Claude Code, Cursor gibi) kurduğunuz bir beceri (skill) ve araç paketi. Ajanın kendisi sizin kullandığınız ajan; Microsoft ona Power BI’ı “öğreten” talimatları ve Power BI’a “dokunan” araçları veriyor.
Paket iki katmandan oluşuyor:
| Katman | Ne işe yarar? | Örnekler |
|---|---|---|
| Skills (beceriler) | Ajana ne yapacağını anlatan talimat klasörleri | semantic-model-authoring (model, ölçü, ilişki, refresh, DAX performansı), powerbi-report-cli (PBIR rapor tanımı oluşturma, doğrulama, yayınlama) |
| Tools (araçlar) | Ajanın işi yapmasını sağlayan bağlantılar | Power BI Authoring MCP server, Power BI Desktop Bridge |
Authoring MCP server’ı daha önce ayrı bir rehberde detaylı anlatmıştım. Yeni olan parça Desktop Bridge: Power BI Desktop’ın içinde çalışan yerel bir sunucu. Ajan onunla açık Desktop’ı yeniden yükleyebiliyor ve ekran görüntüsü alarak oluşturduğu raporu “gözüyle” kontrol edebiliyor. Bu, ajanın kör çalışmasını bitiren parça.
Kurulum adımlarını burada tekrar etmeyeceğim; üç kurulum yolunu da Authoring MCP rehberinde adım adım anlattım.
Bir not: Microsoft genel deneyimi GA olarak duyurdu, ama bazı alt bileşenler (ör. bazı skill’ler ve barındırılan Authoring MCP server) hâlâ önizlemede. Yerel Authoring MCP server ise GA.
Bu arada sessiz ama önemli bir değişiklik daha oldu: PBIR artık varsayılan rapor formatı. PBIR-Legacy bir raporu düzenleyip kaydettiğinizde otomatik olarak PBIR’a dönüşüyor. Raporların metin tabanlı, Git’e konabilen ve ajanların okuyup yazabildiği bir formata geçmesi, bu ajan döneminin altyapısı.
Ajan bugün neyi gerçekten yapabiliyor?
James Serra’nın Barcelona özetindeki örnek akış şöyle: Ajana bir gereksinim dokümanı veya hedef rapor düzeninin ekran görüntüsünü veriyorsunuz ve bir satış dashboard’u kurmasını istiyorsunuz. Ajan:
- Semantic model’i inceliyor (tablolar, ilişkiler, mevcut ölçüler).
- Gerekli DAX ölçülerini oluşturuyor veya düzeltiyor.
- Rapor sayfalarını ve görselleri kuruyor, biçimlendirme uyguluyor.
- Rapor tanımını doğruluyor.
- Desktop’ta değişiklikleri yeniden yüklüyor, ekran görüntüsü alıyor.
- Sonuca bakıp yineliyor.
Bu akışta öne çıkan tablo şu: Ajan, tekrarlayan ve iyi tanımlanmış işlerde gerçekten hızlı. “Bu modele YTD, geçen yıl ve değişim yüzdesi ölçülerini ekle, her birine açıklama yaz, Zaman Zekâsı klasörüne koy” gibi bir iş saniyeler sürüyor. Bir rapor sayfasının iskeletini çıkarmak da öyle.
Ama “iyi tanımlanmış” kelimesinin altını çizmek lazım. Ajan, verilen tanım kadar iyi. “Satış” ölçüsünün KDV dahil mi hariç mi olduğunu, iadelerin nereden düşüldüğünü, hangi mağazaların karşılaştırmaya girmediğini bilmiyorsa, çok hızlı ve çok emin bir şekilde yanlış bir rapor üretiyor.
İki kamp
Bu konuda toplulukta iki net kamp var ve ikisinin de haklı olduğu noktalar var.
Kamp 1: “Analistin yerini almaz, çıtayı yükseltir”
Pragmatic Works gibi eğitim tarafındaki kaynakların genel tezi bu: Copilot ve ajanlar analistin yerini almıyor; analistin geliştirmesi gereken becerilerin çıtasını yükseltiyor. Modeli doğru şekillendiren kişi olmadan Copilot, tahmin yürüten “acemi bir analist” gibi davranıyor.
Topluluk forumlarında Microsoft tarafından verilen cevaplar da benzer: Copilot’un bugünkü odağı veri keşfi, rapor oluşturma ve semantic model ile etkileşim. Büyük, ağır özelleştirilmiş bir modelin derin mimari incelemesini yapmak, şimdilik ayrı bir uzmanlık işi.
Kamp 2: “Bazı uzmanların yerini bugün alıyor”
Öbür tarafta ise ilginç bir sinyal var: Mart 2026’da bir Microsoft çalışanının Tech Community’de yayımladığı yazının başlığı, Microsoft 365 Copilot’un Power BI optimizasyon uzmanlarının yerini bugün alabileceğini iddia ediyordu. Yazı, Copilot ile semantic model’i, Power Query’yi ve rapor hızını iyileştirmek için kullanılabilecek prompt’ları paylaşıyordu.
Başlık kışkırtıcı, ama altındaki tespit ciddiye alınmalı: “Şu modeli incele, kullanılmayan sütunları, yanlış veri tiplerini ve pahalı DAX kalıplarını listele” türü işler, yıllarca danışmanların saatlik ücretle yaptığı işlerdi. Bu işlerin bir kısmı artık bir prompt uzaklığında.
Benim görüşüm: Ortadan kalkan iş, ortadan kalkmayan rol
Bence iki kamp da aynı fili farklı yerinden tutuyor. Ayrımı şöyle yapıyorum:
Ortadan kalkan şey bir iş türü: Görsel hizalamak, aynı ölçünün on varyasyonunu yazmak, standart bir rapor şablonunu her yeni proje için baştan kurmak, temel performans kontrol listesini elle uygulamak. Bu işler ya tamamen ajana geçecek ya da işin küçük bir parçasına dönüşecek. Eğer bir BI geliştiricisinin haftasının çoğu bu işlerle geçiyorsa, bu yazıyı okurken rahatsız olması normal.
Ortadan kalkmayan şey bir rol: İş kuralını tanımlayan, “doğru rakam hangisi?” sorusunun sahibi olan, ajanın ürettiğini doğrulayan ve sonuçtan sorumlu olan kişi. Serra da özetini benzer bir yerden bağlıyor: Teknik uzmanlık kritik olmaya devam ediyor ama uzmanlığın uygulandığı yer değişiyor; her satırı yazmaktan, mimariyi tasarlamaya, istenen sonucu tanımlamaya, sınırları koymaya ve AI’ın ürettiğini doğrulamaya kayıyor.
Bunu bir perakende örneğiyle somutlaştırayım. Bir market zincirinde “benzer mağaza satış büyümesi” (like-for-like) raporu isteniyor. Ajan bunu bir saatte kurar. Ama şu soruların cevabı modelde yoksa, ajan onları kendisi uydurur:
- Yeni açılan bir mağaza kaç ay sonra karşılaştırmaya dahil olur?
- Tadilat için iki hafta kapalı kalan mağaza ne olacak?
- Bayram kayması (bayramın bir yıl Nisan’da, ertesi yıl Mart’ta olması) nasıl dengelenecek?
Bu sorular DAX sorusu değil, iş sorusu. Ve bu soruların cevabını bilen, belgeleyen ve modele işleyen kişi, ajan çağında daha da değerli hale geliyor. Çünkü artık o tanım bir kişinin kafasında kalırsa, ajan her seferinde farklı bir varsayımla çalışıyor.
BI geliştiricisinin 2027’de öne çıkacak beş becerisi
- Tanımlama (specification): “Bana bir satış raporu yap” değil; kapsamı, iş kurallarını, kabul kriterlerini yazabilmek. Ajan için yazılan iyi bir gereksinim dokümanı, artık kodun kendisi kadar değerli.
- Semantic model tasarımı: Ajanlar ve Copilot raporlarınızı değil, modelinizi okuyor. Adlandırma, açıklamalar, ilişkiler ve ölçü tanımları, AI’ın ne kadar doğru çalışacağını belirliyor. Bu konuyu Copilot kötü veri modelini kurtarmaz yazısında ayrıca ele aldım.
- Doğrulama: Ajanın ürettiği ölçüyü bilinen bir rakamla karşılaştırmak, kenar durumları test etmek. “Çalışıyor” ile “doğru” arasındaki farkı yakalayan kişi olmak.
- Geliştirme disiplini: PBIP/PBIR, Git, kod incelemesi, dağıtım hatları. Ajan değişiklik yapacaksa, o değişikliğin incelenebilir ve geri alınabilir olması gerekiyor.
- Ürün düşüncesi: Serra’nın sorduğu soru burada kritik: “Bu bir rapor mu olmalı, bir uygulama mı?” Fabric Apps yazısında tartıştığımız gibi, karar artık “raporu nasıl kurarım?” sorusundan “kullanıcıya hangi deneyim lazım?” sorusuna kayıyor.
Ekipler için pratik başlangıç planı
- Küçük ve tekrarlayan bir işle başlayın: Ölçü açıklamalarını yazdırmak, standart zaman zekâsı ölçülerini eklemek, bir sayfanın iskeletini çıkarmak.
- Önce PBIP + Git: Ajanın yaptığı her değişikliği bir commit olarak görün. İnsan incelemesi olmadan üretime giden ajan değişikliği olmasın.
- Doğrulama veri seti hazırlayın: Bilinen dönemler için bilinen rakamlar. Ajanın ürettiği her ölçü bu rakamlarla test edilsin.
- İş kurallarını yazıya dökün: Ajana verilecek talimatların ve model açıklamalarının kaynağı bu doküman olsun.
- Ölçün: Ajanla yapılan işlerde harcanan süreyi ve düzeltme oranını takip edin. “Hızlandı” hissi ile “hızlandı” gerçeği bazen farklı çıkar.
Sonuç
Power BI raporlarını yapay zekâ ajanlarının kurması artık bir demo değil, GA bir deneyim. Bu, BI geliştiricisinin sonu değil; ama BI geliştiricisinin haftasının nasıl geçtiğinin sonu olabilir. Görsel hizalayan, ölçü kopyalayan geliştiricinin yerini, iş kuralını tanımlayan, modeli tasarlayan ve ajanı denetleyen geliştirici alacak.
Benim cevabım net: Sırada BI geliştiricisi yok. Sırada, BI geliştiriciliğinin yalnızca araç kullanmaktan ibaret olduğunu düşünen yaklaşım var.
Peki sizce? Ekibinizde ajanla rapor kuran biri oldu mu, sonuç üretime gidecek kalitede miydi? Yorumlarda ya da LinkedIn’de tartışalım.
Kaynaklar
- Power BI agentic development overview (Microsoft Learn)
- Power BI Desktop Bridge overview (Microsoft Learn)
- Announcements from FabCon Barcelona 2026 (James Serra)
- Microsoft 365 Copilot can replace Power BI optimization experts today (Tech Community)
- Chat With Your Data – What Is It? (Pragmatic Works)
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.