Coding Agent’lara İyi Ürün Tasarımı Nasıl Öğretilir?

Yapay zekâ kodlama ajanları (coding agent) artık dakikalar içinde çalışan arayüzler üretebiliyor. Ancak bu arayüzler ilk bakışta makul görünse de çoğu zaman tutarsız boşluklar, eksik boş ekran durumları, yer tutucu hata mesajları ve uyumsuz yazı boyutları barındırıyor.

Salesforce UX Mimarı Alan Weibel, 1 Ekim 2026’da yayımlanan yazısında sorunun kökünü şöyle tanımlıyor: Ajan, iyi tasarımın şeklini kopyalıyor ama arkasındaki nedenleri anlamıyor. Çünkü tasarım kararlarının gerekçesi kod tabanında değil; tasarımcıların zihninde, tasarım incelemelerinde ve Slack yazışmalarında duruyor.

Bu yazıda Salesforce’un bu bilgiyi ajanların kullanabileceği bir yapıya nasıl dönüştürdüğünü ve ajanların fikirden mühendisliğe hazır tasarıma kadar tüm süreci nasıl yürütebildiğini anlatıyoruz.

Tasarım Bilgisini Kod Gibi Yönetmek: Design Intelligence

Salesforce’un yaklaşımı iki katmandan oluşuyor. Design Intelligence, tasarım bilgisinin toplandığı katman. Üzerine kurulan Experience Operating System (XOS) ise bu bilgiyi kullanarak fikirleri üretime hazır tasarımlara dönüştüren süreç.

Design Intelligence dört bileşenden oluşuyor:

Skill’ler iki seviyede düzenleniyor. Evrensel skill’ler deneyim tasarlama, kalıp uygulama, Figma’da tasarım ve tasarım doğrulama gibi her üründe geçerli konuları kapsıyor. Platform skill’leri ise SLDS, Data 360, Tableau, Sales Cloud ve Slack gibi ürünlere özel kurallar içeriyor. Bu skill’ler Claude Code, Codex ve Copilot gibi Anthropic Skill standardını destekleyen araçlarda kullanılabiliyor.

Her tasarım talebi aynı değil. “Bir ekran oluştur”, “bu tasarımı incele” ve “boş ekran metnini yaz” farklı işler. Ajan önce talebin türünü ve hangi ürün için olduğunu belirliyor, ardından yalnızca ilgili rehberi yüklüyor. Kurallar çeliştiğinde ise şu öncelik sırası izleniyor:

1. Kullanıcının hedefi

2. Doğrulanmış araştırma bulguları

3. Kod deposundaki standartlar

4. Daha önce kabul edilmiş kararlar

5. Genel tasarım prensipleri

Ajan “neden”i bulabilmeli. Her rehber maddesinin sabit bir kimliği ve çapraz referansları var. Böylece ajanın verdiği her karar bir kaynağa dayandırılabiliyor. Yazının ifadesiyle: “Ajanın kaynağını gösteremediği bir kuralı, ajan eninde sonunda çiğner.”

Kaliteyi Güvenceye Almak: Muhakeme, Linter ve Testler

Salesforce, kalite kontrolünü işin doğasına göre ayırıyor. Zor tasarım kararları ajanın muhakemesine bırakılıyor. Mekanik kurallar ise otomatik araçlara devrediliyor.

• Linter’lar: “Rengi asla sabit kodlama” gibi kurallar, ajanın yorumuna bırakılmadan otomatik olarak denetleniyor. Token kullanılması gereken yerlerdeki sabit değerler, tek aktif tema kuralı ve zorunlu erişilebilirlik nitelikleri bu kapsamda. Salesforce, kod kaydedilmeden önce SLDS Linter’ı çalıştırıyor.

• Eval’lar (değerlendirme testleri): Her skill, aynı görev üzerinde rehberli ve rehbersiz olarak çalıştırılıp puanlanıyor. Ajanın ezber yapmadığından emin olmak için daha önce görmediği örnekler kullanılıyor.

• Sürekli öğrenme: Yeni bulgular önce yargılanmadan toplanıyor. Ardından insanlar bunun bir rehber maddesi, linter kuralı, örnek ya da test mi olacağına karar veriyor.

Erişilebilirlik bir kapı görevi görüyor. Tüm tasarımlar WCAG 2.2 AA standardını hedefliyor. Salesforce’un erişilebilirlik uzmanlarının yönettiği özel skill’ler ve tarayıcı testleri, ihlalleri tespit edip doğruluyor.

Dört katmanlı bilgi yapısı. Bilgi genelden özele dört katmanda düzenleniyor: Kullanılabilirlik ve erişilebilirlik gibi evrensel temeller, markadan bağımsız ortak kalıplar, ürün ailesine ait görsel dil ve son olarak tek bir ürüne özel marka ve bileşenler. Ajan ortak temeli her yerde uygularken ürüne özel kararlarda ilgili katmana başvuruyor.

XOS: Fikirden Mühendisliğe Hazır Tasarıma Yedi Aşama

Salesforce’un vizyonu, ajanların tasarımları yalnızca incelemesi değil, sıfırdan üretmesi. XOS bunu yedi aşamalı bir süreçle yapıyor. Sürece herhangi bir aşamadan girilebiliyor; eksik kalan önceki çıktılar sonradan tamamlanıyor.

1. Kabul: Bir fikir, brief, ürün gereksinim dokümanı, Figma dosyası ya da prototip; problem tanımına ve tasarım brief’ine dönüştürülüyor.

2. Araştırma: Çalışma, kullanıcılar ve problemle ilgili gerçek verilere dayandırılıyor. Salesforce’un araştırma ekibi bu aşama için özel skill’ler yönetiyor.

3. Çoklu ajanla tasarım: Ajanlar paralel çalışarak 10’a kadar farklı tasarım yönünü tıklanabilir prototip olarak üretiyor. Bu, insanların tek bir fikrin küçük varyasyonlarına takılma eğilimini kırıyor.

4. İnteraktif inceleme: Ekip, canlı prototip üzerinde noktasal yorumlar bırakıyor.

5. İterasyon: Her değişiklik, onu tetikleyen yoruma kadar izlenebiliyor.

6. Kullanıcı testi: Mühendislik ekibi devreye girmeden önce gerçek kullanıcılar ve 15 yıllık araştırmaya dayanan sentetik kullanıcı personalarıyla testler yapılıyor. Salesforce, sentetik personaların gerçek kullanıcı testinin yerini tutmadığını özellikle vurguluyor.

7. Teslim: Mühendislik ekibine eksiksiz bir paket iletiliyor.

Teslim paketi; yerleşim, durumlar ve klavye davranışını içeren teknik şartnameyi, tasarım token haritasını, erişilebilirlik notlarını, arayüz metinlerini, sürüm notlarını, hazır olma kontrol listesini, bileşen paketini, prototipi ve tüm karar geçmişini kapsıyor.

Salesforce bu süreci ekiplerin kararları aldığı yere de taşıyor. Geliştirilmekte olan bir Slack uygulaması, XOS iş akışını doğrudan bir Slack kanalında başlatıyor. Böylece ekipler problemi tanımlıyor, alternatif tasarımlar üretiyor ve bunları birlikte değerlendiriyor.

İşletmeniz İçin Çıkarımlar

Salesforce’un yaklaşımı yalnızca tasarım ekiplerini ilgilendirmiyor. Salesforce üzerinde Lightning bileşenleri, Experience Cloud siteleri ya da özel uygulamalar geliştiren her kurum için somut dersler içeriyor:

1. Kurumsal bilgiyi yazıya dökün. Marka kurallarınız, tasarım standartlarınız ve geçmiş kararlarınız kişilerin zihninde kaldıkça hiçbir yapay zekâ aracı bunları tutarlı biçimde uygulayamaz.

2. Mekanik kuralları otomatikleştirin. SLDS Linter gibi araçları geliştirme sürecine ekleyerek tasarım tutarlılığını ve erişilebilirliği kod kaydedilmeden önce güvenceye alın.

3. Erişilebilirliği en baştan zorunlu tutun. WCAG 2.2 AA uyumunu proje sonunda değil, her tasarımın geçmesi gereken bir kapı olarak konumlandırın.

4. Yapay zekâyı ölçün. Ajanların çıktılarını testlerle düzenli olarak puanlayın; rehberin gerçekten fark yaratıp yaratmadığını veriyle görün.

5. Alternatifleri artırın, kararı insana bırakın. Ajanların ürettiği çok sayıda tasarım yönü, ekiplerin daha geniş bir seçenek yelpazesini daha kısa sürede değerlendirmesini sağlıyor.

Makul Tasarımdan Savunulabilir Tasarıma

Coding agent’ların potansiyeli büyük, ancak bu potansiyel ancak doğru bilgiyle beslendiklerinde ortaya çıkıyor. Salesforce’un yaklaşımı açık bir yol gösteriyor: Tasarım bilgisini insanların zihninden çıkarıp ajanların kullanabileceği ortak bir kütüphaneye taşımak. Böylece ajanlar iyi tasarımın şeklini kopyalamayı bırakıp gerçeğini üretmeye başlıyor; her kararın kaynağı gösterilebiliyor ve her tasarım erişilebilirlik testinden geçiyor.

Kofana olarak Salesforce projelerinizde SLDS uyumlu, erişilebilir ve marka kimliğinize sadık arayüzler geliştiriyor, yapay zekâ destekli geliştirme süreçlerini ekiplerinize kazandırıyoruz. Bu dönüşümü kendi kurumunuzda nasıl hayata geçirebileceğinizi konuşmak için ekibimizle iletişime geçebilirsiniz.