WooCommerce Abilities API: Mağaza Yapay Zekâ Ajanı Yerlisi Oluyor

🇬🇧 English: Read this in English →

Yirmi yıldır WordPress’in üzerine vuran dalgaları izliyorum ve hepsi geri çekiliyor. Sayfa kurucuları özel temaları gereksiz kılacaktı. Headless mimari yönetim panelini gereksiz kılacaktı. Şimdi de yapay zekâ ajanları, panelden geriye kalan ne varsa onu gereksiz kılacakmış. Her seferinde olduğu gibi platform, sessiz sedasız, bir sonraki dalganın üzerinde koşacağı zemini örüyor. Açık konuşayım, ben artık dalgaya değil, zemine bakıyorum.

WordPress 6.9 ile gelen Abilities API’sini yakından takip ediyorum, çünkü güvendiğim her kıdemli geliştirici aynı şeyi farklı kelimelerle söylüyor: ilginç olan sınır “bir büyük dil modeli paragraf yazabiliyor mu” değil, “büyük dil modeli pazartesi sabahı gerçek bir mağazada güvenle iş yapabiliyor mu” sınırıdır. Bu hafta WooCommerce, sektörümüz adına bu sorunun büyük kısmını cevaplayan bir hamle yaptı.

Bu, müşterilerime “Twitter’ı bırak, sürüm notlarını oku” dediğim anlardan biri.

Asıl yeni olan ne

1 Haziran 2026’da WooCommerce Geliştirici Blogu, Expanding Abilities across WooCommerce Extensions başlıklı yazıyı yayımladı. Bu yazı, 12 Mayıs’taki duyurunun devamı niteliğinde. 23 Haziran 2026 Salı günü çıkması planlanan WooCommerce 10.9, ürünler ve siparişler için yedi kanonik etki alanı yeteneği getiriyor: woocommerce/products-query, woocommerce/product-create, woocommerce/product-update, woocommerce/product-delete, woocommerce/orders-query, woocommerce/order-update-status ve woocommerce/order-add-note.

Yeni yazı daha iddialı bir adım atıyor: aynı yetenek deseni yedi etki alanında, yirmiden fazla resmi eklentiye yayılıyor — hediye kartları, ürün ekleri, satın alma kuralları, ürün kompozisyonu, öneriler, abonelikler, ödemeler, kargo, takip, pazarlama ve otomasyon. WooPayments 10.8.0 sonrası. Subscriptions 8.7.1 sonrası. AutomateWoo 6.3.1 sonrası. Gift Cards 2.7.3 sonrası. MailPoet 5.28.0 ile zaten yayında. Tarihler birleştirilmiş PR’lardan tahmin edilmiş; nihai kaynak her eklentinin kendi changelog’u. Ama yön net.

Bunların hiçbiri yeni boyaya çekilmiş REST sarmalayıcıları değil. WordPress Abilities API’sinin üzerinde duran ve resmi MCP Adapter üzerinden de ortaya çıkan bu yetenek deseni, her yeteneği taşımadan bağımsız bir sözleşme gibi ele alıyor: katı girdi ve çıktı şemaları, WooCommerce’e özgü enum’lar, WooCommerce’in mevcut izin modeli üzerinden çalışan permission callback’leri ve aynı yeteneğin REST, MCP, panel araçları, CLI iş akışları, otomasyon sistemleri ve “gelecekteki ajan yüzeyleri” üzerinden sunulmasını sağlayan üst veri. Sorgu yetenekleri readonly ve idempotent olarak işaretleniyor. Yazma yetenekleri, yıkıcı olup olmadıklarını açıkça beyan ediyor. Şema doğrulaması, çalıştırmadan önce bilinmeyen alanları ve desteklenmeyen enum değerlerini reddediyor.

Sade Türkçeyle: WooCommerce, “bu mağazada yapmana izin verilen şeyler”in makinece okunabilir, izin kontrollü bir menüsünü yayımlıyor. Claude, ChatGPT, kurum içi bir yardımcı pilot, bir CLI betiği, özel bir panel aracı — hangi yapay zekâ ajanı olursa olsun bu menüyü okuyup bir kalemi seçebiliyor. Kimsenin her biri için elle entegrasyon yazmasına gerek kalmıyor.

WordPress ve WooCommerce dünyası için neden önemli

İki yıldır gördüğüm her “WooCommerce için yapay zekâ” sunumu aynı tuzağa düştü. Biri REST API’yi bir sarmalayıcıyla kaplıyor, üstüne bir büyük dil modeli yapıştırıyor ve “ürün oluşturan” bir sohbet kutusu demosu yapıyor. Sonra gerçek bir satıcı denediğinde sarmalayıcının varyasyon fiyatlamasından haberinin olmadığını, modelin neşeyle kullanıcının yazma yetkisi olmayan alanlara yazdığını ve denetim kaydında işe yarar hiçbir şey olmadığını keşfediyoruz. Yetenekler tam da bu boşluğu kapatıyor. Yetenek sözleşmesinin sahibi eklenti yazarı, ajanı sonradan ekleyen kişi değil.

Bunun ajans müşterilerimiz için üç somut karşılığı var.

• İzinler artık senin sorunun değil. Bir yetenek izinleri WooCommerce’in kendi modeli üzerinden kontrol ettiğinde, yapay zekâ entegrasyonun yirmi yıllık yetenek tabanlı erişim denetimini bedavaya devralıyor. “Mağaza yöneticisi” ajanı yanlışlıkla bir site yöneticisinin kullanıcısını silemiyor.
• Halüsinasyonlar kapıda yakalanıyor. Geçersiz bir sipariş durumu, bilinmeyen bir ürün tipi ya da yanlış yazılmış bir vergi sınıfı geçirmeye çalışan bir model, hiçbir kod çalışmadan önce şema doğrulamasına çarpıyor. Bu, “ajan veritabanını bozdu” ile “ajan işe yarar bir hata mesajı aldı ve tekrar denedi” arasındaki fark.
• Tek entegrasyon, birden fazla yüzey. Bir Subscriptions panel akışını yetenek sözleşmesinin üzerine kurarsan, aynı kod yolu kurum içi CLI’na da, Claude Desktop için MCP sunucuna da, özel WP-Admin aracına da ve müşterinin ileride kuracağı her ajana da hizmet ediyor. İşte gerçek bir bütçeyi hak ettiren yeniden kullanım türü budur.

Yapay zekâya zerre kadar ilgi duymayanlar için de önemli. Yetenek kataloğu, üçüncü taraf bir eklentinin PHP tarafından neye izin verip neye vermediğini anlamak için tüm kaynağı okumak zorunda kaldıysan, WooCommerce eklentilerinin sahip olduğu en temiz işlevsel belgeyi de tesadüfen kazandırıyor.

Ajanı üretime almadan önce: kısa bir güven kontrolü

Şemanın girdiyi doğrulaması güzel, ama bir ajanın gerçek bir mağazada yazma yeteneklerine dokunmasına izin vermeden önce ben şu üç şeyi görmeden içim rahat etmez. Bunları bir demoda değil, canlıya benzeyen bir hazırlık ortamında dene.

• Denetim izi. Ajanın çağırdığı her yeteneğin kim, ne zaman, hangi girdiyle sorusuna cevap veren bir kaydı olmalı. “Bu siparişi kim iptal etti” sorusuna “yapay zekâ” demek yetmez; hangi oturum, hangi istem, hangi çağrı — hepsi izlenebilir olmalı.
• Yıkıcı yeteneklerde ikinci kapı. product-delete ve order-update-status gibi yıkıcı yetenekleri, salt okunur olanlarla aynı güven seviyesine koyma. Ben olsam yazma yeteneklerini bir onay adımının veya dar bir rolün arkasında tutar, ilk hafta sadece products-query ve orders-query ile yaşardım.
• Geri alma planı. Ajan yüz ürünü yanlış fiyatla güncellerse ne yapacaksın? Bu soruya bir cevabın yoksa, yazma yeteneklerini henüz açma. Şema seni kötü veriden korur; kötü karardan korumaz.

Bu konuda ne yapardım (ya da yapmazdım)

Bugün bir WooCommerce mağazası işletiyorsan hiçbir şeyi söküp atma. WooCommerce 10.9 henüz çıkmadı ve eklenti yayılımı aşamalı. Ama bu ay yapılmaya değer bir sıralama işi var.

• Minimum sürümleri sabitle. Yayılım, mağaza WordPress 6.9+ üzerinde çalışıyorsa işe yarıyor; WooCommerce 10.8’den itibaren WordPress 6.9 zorunlu hâle geliyor — bunu 10.8.0 sürüm notları teyit ediyor. Özel bir eklenti seni hâlâ 6.7’de tutuyorsa, o eklenti şu an yapay zekâ hazırlığının darboğazı.
• Eklenti yüzeyini denetle. Üretimde çalışan her ücretli WooCommerce eklentisinin bir listesini çıkar ve sağlayıcının resmi yetenek yayılım listesinde olup olmadığını kontrol et. Değilse, bu yenileme döneminde konuşulacak bir konu.
• Yapay zekâ iş akışları için artık özel REST sarmalayıcıları yazma. Bu çeyrek bir yapay zekâ entegrasyonuna başlıyorsan, derme çatma REST uç noktaları üzerine değil, doğrudan Abilities API ve MCP Adapter üzerine kur. Şimdi yaptığın iş bir daha çöpe gitmeyecek.
• Kapsam konusunda dürüst ol. Eklentilerin çoğunda önce salt okunur yetenekler iniyor. Gerçekten tehlikeli olanlar — yazma yetenekleri — çok daha temkinli geliyor ve bu doğru karar. Müşteriye temmuza kadar “mağazayı yöneten yapay zekâ” sözü verme.

Yapmayacağım şey: bu sözleşmenin üzerine inşa etmeyen üçüncü taraf bir “WooCommerce için yapay zekâ” SaaS aracına bir sonraki sprint’i yatırmazdım. Rakibin Claude’u ya da kurum içi bir ajanı doğrudan resmi yeteneklere bağladığı anda ekonomi değişiyor. Özel API’lerin etrafına sarılmış sarmalayıcılar, blok editörünü görmezden gelen sayfa kurucuları kadar eski moda görünmek üzere.

WordPress ve WooCommerce’in alışkanlık edindiği o sessiz, altyapısal hamle yine devrede ve hype dalgası yine kaçırıyor. Mesele “WordPress’e yapay zekâ eklendi” değil. WordPress, yapay zekânın güvenle hareket etmesine izin verilen zemin hâline geliyor; izinleri kontrol edilmiş, şemaları zorunlu kılınmış, hep sahip olduğu yönetişim katmanıyla birlikte. Ben olsam bu tarafa yatırırdım.