Savunmacı Veri Tasarımı: WordPress’in AI Ajanları Doktrini

Ajan çağının en ilginç yanı bence ajanların ne yapabildiği değil, neyi kırmasına izin verdiğimiz. Özerk bir süreç bir izin kapısı, bir REST uç noktası ve doğal dilde bir istem aldığında, sabahın üçünde bir kategori ağacını “temizlemek isteyen” bir müşteri asistanı yüzünden silinmesini ne engelliyor?

Uzun süredir cevabımız “umut, bir de yedek” oldu. Matt Mullenweg’in bu sabah Make/Core üzerinde yayımladığı Defensive Data Design yazısı, bu cevabı bir doktrin olarak yazıya dökmenin ilk ciddi denemesi. Kısa, iddialı ve WordPress 7.1 Beta’nın son iki haftasında Make/Core’a düşen Abilities API ile JSON Schema çalışmalarıyla neredeyse fazla iyi örtüşüyor.

Bu sabah iki kez okudum. Bir kez, üç “devrimci” içerik platformunun sessizce yok olduğunu izlerken 2005’ten kalma bir kurulumun hâlâ temiz güncellenebildiğini gören bir WordPress emektarı olarak. Bir kez de staging’de “son yirmi WooCommerce siparişini listele” diyebildiğim bir iç ajanı olan biri olarak. Sonuç aynı: bu, ajansların monitörün üstüne asması gereken yazı.

Aslında ne yeni

Defensive Data Design yazısı bir birleştirme önerisi ya da dev note değil. Matt’in “ajan-güdümlü gelecek” için ortaya koyduğu tasarım ilkeleri, ana damarı güvenli varsayılanlar. İlkeler, kendi cümleleriyle:

• “Çöp kutusuna atmak kolay olmalı; silmek çok zor olmalı.”
• “Taslak önermek kolay olmalı; dünyaya yayımlamak zor olmalı.”
• Değişiklikler mümkün olduğunca geri alınabilir ve görünür olmalı.
• Veri görselleştirmesi anlaşılırlığı artırmalı, gizlememeli.
• Hata mesajları sohbet diliyle yazılmalı; kişinin arama motoruna veya yapay zekâya yapıştırabilmesi için panoya kopyala düğmesiyle.
• Hatalar “ne” olduğunu değil “neden” olduğunu anlatmalı.
• Çöküş kibar olmalı ve olası zararı en aza indirmeli.
• Her şeyi — ağ, biçim, yapı — güvenilmez ve hatta düşmanca kabul et.
• Görünür bilgiyi en yüksek tut; gereksiz tıklamayı azalt.
• Sade, açık, doğal bir dil kullan; biraz da karakter olsun.

Zamanlamayı çarpıcı yapan şey, geçen hafta Make/Core’a düşen tesisat. Abilities API yaşam döngüsü süzgeçleri çekirdeğe bir yetenek çağrısını kısa devre yaptırma, girdiyi normalize etme, izni geçersiz kılma ve sonucu yeniden şekillendirme kancalarını verdi. JSON Schema hazırlama işlevi, sunucunun elindeki şema ile istemcinin gördüğü şema arasına temiz bir sınır çekti — PHP geri çağırmaları AI aracı tanımına asla sızmıyor. 3 Ağustos’ta ise Joe Dolson sessizce wp_get_tooltip() ve wp_get_toggletip() işlevlerini ekledi — “bu ikona tıkla”yı “widget’ı yukarı taşımak için bu ikona tıkla”ya çeviren küçük, sıradan işlevler, yani Matt’in savunduğu düz-dil görünürlüğün ta kendisi.

Tablo şu: Salı günü doktrin, bir hafta önce süzgeçler, ondan bir hafta önce şema güvenliği, dün ipucu işlevleri. WordPress 7.1 19 Ağustos 2026’da geliyor, RC1 ise yarın. Önce ilkel yapılar geldi, sonra felsefe geldi; projemizde alışılmadık biçimde ikisi birbirine uyuyor.

WordPress / WooCommerce’çular için neden önemli

“Kolay-zor” ikilisi işin tamamı. WordPress çöp kutusu, revizyon geçmişi ve taslak/yayımla ayrımıyla bu takası on beş yıldır sessizce yapıyor zaten. Matt’in yaptığı, buna bir isim vermek ve katkıcılara “aynı asimetriyi bir yapay zekâ ajanının dokunabildiği her yüzeye uygula” demek. “Bu siparişi iptal et” ile “iade et ve kalıcı sil” aynı zorlukta olmamalı. Sürtünme insanlar için değil; bir hatayı kimse fark etmeden on bin kere tekrarlayabilen makineler için orada.

Bir WooCommerce ajansı için eşleştirme neredeyse birebir. Müşterilerin geçip sonra geri döndüğü her barındırmalı ticaret platformunda iki türlü yıkıcı eylemi tek düğmeye dikmişlerdi. WordPress’te seçim sana kalıyor. Süresi dolan kuponlar, silinen değil. Otuz günlük geri sayımla iptal kovasına giden siparişler. Silinmeden önce yerinde anonimleşen müşteri hesapları. Bunların hiçbiri yeni yetenek değil. Yeni olan şu doktrin: core/read-orders ya da özel bir store/refund-order yeteneği bağladığında, kolay yol geri alınabilir olan, zor yol yıkıcı olan olmalı — bilerek.

Diğer güçlü ilke ise “her şey düşman” olanı. Kıdemli bir WordPress geliştiricisi zaten zaman aşımına uğrayan bir ağa, umulmadık biçimde bir kancayı süzen bir eklentiye karşı savunmacı yazıyor. Bu tavrı bir MCP istemcisinden gelen argümanlara ya da geçerli görünen bir ürün ID’sini uyduran bir sohbet modeline uzatmak, aynı disiplini yeni bir kaynağa yöneltmek. WordPress’in en eski alışkanlıkları — giren veriyi temizle, çıkanı kaç, işlem öncesi yetki kontrol et — ajan yüzeyine çeviri gerektirmeden geçiyor.

Yerinde olsam (ya da olmasam) ne yapardım

On ilkeyi çıktı al. Duvara as. Pazarlama posteri olarak değil, kod incelemesi kontrol listesi olarak. Ekibinden biri “ajan için ürünü doğrudan silen” bir yetenek kaydettiğinde, liste hakemin ilk sorusunu söylüyor: önce yumuşak silme yolu var mı ve ajan varsayılan olarak onu mu alıyor, sert silme ikinci ve açık bir izin mi gerektiriyor?

Somut olarak, staging’de ajan yüzeyi olan her WordPress veya WooCommerce mülkü için bu hafta üç iş. Bir: her özel yeteneği çöp-silme merceğinden geçir. Yalnızca yıkabiliyorsa — geri alma yok, çöp kovası yok, taslak muadili yok — RC1 yarın gelmeden ikiye böl. wp_ability_permission_result süzgeci, “ajan yumuşak yolu her zaman çağırabilir; sert yolu ise yalnızca son beş dakikada bir insan onayladıysa çağırabilir” demenin tam dikişi. O süzgeci mu-plugin içine, siteyle birlikte sürümlenmiş halde yaz.

İki: yetenek hata dizelerini Matt’in tarif ettiği gibi yeniden yaz. “4821 numaralı sipariş iade edilemez çünkü 2026-07-30 tarihinde tam iade almış” mesajı, modelin döngüden çıkıp hatayı bir insana iletebileceği bir cümle. “Error: ORDER_STATE_INVALID (code 42)” ise modelin üç kez daha deneyip sonunda kendinden emin bir şekilde yalan söyleyeceği tür. Bir öğleden sonra hata işleme kodunda gezinti; listedeki en yüksek kaldıraçlı değişiklik.

Üç: “savunmacı tasarım ayarlarını yapılandıran UI ekliyor” diyen bir eklenti kurma. Doktrinin özü, varsayılanların güvenlik olması; birileri ayar ekranından bunu kapatabildiği anda, ekrana kilit koymayı unutan için güvenlik biter. Kod incelemesine ve mu-plugin’e koy, seçeneğe değil. Bu denetimi de bugün açılan WooCommerce 11.0 yükseltme penceresinin üstüne yığma — aynı üretim mülkünde aynı öğleden sonrada iki hareketli parça, hangisinin bozduğunu daraltmakla geçen bir cumartesi demek.

Her WordPress sürüm döngüsünün, projenin felsefesiyle tesisatının aynı fikirde olduğu bir an vardır. Bu, o anlardan biri. 19 Ağustos’taki 7.1 GA duyuru yazılarını alacak; Defensive Data Design ise altındaki dipnot — 7.1’in üzerine kurduğun yeteneklerin bir pazar gecesi çalışır bırakabileceğin türden olup olmayacağını belirleyen not.