Bir modelin web tasarımına katkısını değerlendirirken iki şeye bakarım: verdiğim briefi ne kadar doğru anlıyor ve revizyon sırasında seçtiğimiz tasarım kararını koruyabiliyor mu? İlk ekranda etkileyici görünen bir çıktı, çalışan bir sayfaya dönüşmüyorsa işin önemli kısmı hâlâ önümüzde duruyor. Sonnet 5.5’i de bu açıdan okumak gerekir. Kodlama ve görsel yorumlama sonuçları, hangi işleri denemeye değer bulacağımızı gösteren bir başlangıç olabilir.
Anthropic, Claude Sonnet 5.5’i 28 Eylül 2026’da duyurdu. Sonnet ürün sayfası, günlük kodlama ve belge işleri için daha hızlı bir Sonnet sunuyor. Aşağıdaki performans verileri yayımlanmış raporlardan, proje önerileri ise benim tasarım yaklaşımımdan geliyor. Bu yazı için modele ücretli test yaptırılmadı. Kaynakların kontrol tarihi 30 Eylül 2026.
Sonnet 5.5 bir tasarım işinde ne üretebilir?
Model belgesi, metin ve görsel girdiden metin çıktısı üretildiğini belirtiyor. API kimliği `claude-sonnet-5-5`; bağlam kapasitesi 1 milyon, standart çıktı sınırı 128 bin token. Bu rakamlar, modele ne kadar bilgi verilebildiğini anlatır. Projeyi daha uzun bir istemle başlatmanın otomatik olarak daha iyi sonuç vereceğini söylemez.
Bir hizmet sayfasının ekran görüntüsünü verip başlık, açıklama ve iletişim butonu arasındaki ilişkiyi inceletebilirsiniz. Üç farklı metin yaklaşımı isteyebilir veya mevcut bileşene uygun HTML ve CSS taslağı hazırlatabilirsiniz. SVG kodu da bu metin çıktısının bir parçasıdır; görseli tarayıcı oluşturur. Fotoğraf üretimi veya bitmiş reklam filmi teslimi için farklı bir üretim akışı gerekir.
Ben bu ayrımı briefte de açık tutardım. “Referanstaki düzeni incele ve mevcut tipografiye uygun bir öneri yaz” ile “aynı tasarımı çalışır biçimde uygula” aynı teslim talebi değildir. İlkinde değerlendirme, ikincisinde bağlantılar, mobil görünüm ve uygulamanın davranışı da kapsamın içindedir. Model seçimini bu teslim farkından sonra yapmak daha anlamlı olur.
Resmî performans raporu: Altı testte karşılaştırma
Anthropic’in performans tablosundan seçilen sonuçlar aşağıda. Yüzde ile verilen sonuçları, puan ile verilen iş değerlendirmelerinden ayrı okuyun.
| Değerlendirme | Sonnet 5 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | %10,3 | %70,6 | %66,4 |
| CursorBench 4.0 | %34,1 | %55,5 | %57,8 |
| Chartography, araçsız | %15,6 | %61,6 | %64,4 |
| GDPval-AA v2.1, puan | 1449 | 1844 | 1846 |
| AA-Briefcase v1.1, puan | 1359 | 1811 | 1822 |
| OSWorld 2.1, kısmi | %57,0 | %80,1 | %81,8 |
Terminal-Bench satırındaki Opus sonucu Xhigh ayarında. İş değerlendirmelerindeki Sonnet sonucu, sonradan düzeltilen bir yapılandırılmış çıktı hatasını içeren ön sürümden. Kaynak tablosu farklı çalışma ayarlarını tek özet halinde sunuyor; bunlar eşit bütçeli proje testleri değil. Raporun yöntem ve dipnotları.
Ben bu tabloyu bir satın alma kararı olarak değil, deneme sırasını belirlemek için kullanırdım. Kodla çalışacağım projede önce düzeltmenin kapsamını koruyup korumadığını kontrol ederim. Görsel incelemede ise ekrandaki metni doğru okuması ve önerisini gerçekten görünen unsurlara dayandırması önemli. Bunları aynı puanda birleştirmek, farklı ihtiyaçları görünmez hale getirir.
Kodlama ve görsel okuma grafikleri nasıl okunmalı?
Grafiklerin amacı sürümler arasındaki farkı okunabilir hale getirmek. Üç testin çubuklarını toplayıp genel bir başarı yüzdesi çıkaramayız. Ayrıca bir kodlama değerlendirmesi, hazırlanan landing page’in markaya uygunluğunu veya müşterinin tasarımı beğeneceğini ölçmez. Sayfanın ana mesajı, tipografisi ve kullanıcı yolculuğu için kendi kabul ölçütlerimizi yazmamız gerekir.
Görsel okuma tarafında da aynı dikkat geçerli. Bir kampanya raporundaki grafik ile bir ürün sayfasındaki buton hiyerarşisi farklı bağlamlar taşır. Ben ekran incelemesinde modelin önerisini üç soruyla kontrol ederdim: Hangi unsuru gördü, buradan hangi yoruma ulaştı ve önerdiği değişiklik hangi kullanıcı sorununu çözüyor? Bu bağlantı kurulmadığında doğru görünen bir yorumun uygulamaya katkısı sınırlı kalabilir.
Belge ve uzun iş akışlarında sonuçlar
Bir tasarım ekibinde belge üretiminin değeri, hazırlanmış dosyanın karar vermeyi kolaylaştırmasıyla ortaya çıkar. Örneğin bir web projesi için sayfa listesi, içerik sorumluları ve teslim kapsamını bir araya getiren bir doküman isteyebilirsiniz. Ben önce kaynak briefteki kararların korunmasına bakardım. Modelin boş alanları tahminle doldurması, düzenli görünen bir belgede yanlış taahhütler yaratabilir.
Grafikte birbirine yakın duran iki puan, iki modelin bütün işlerde aynı davranacağı anlamına gelmez. Bir marka sunumunda görsel yönü korumak, başka bir görevde ise karmaşık bir teknik kararı tartışmak gerekir. Bunları tek örnekle değerlendirmek yerine aynı brief üzerinde farklı teslim türlerini denemek daha kullanışlı bir karşılaştırma sağlar.
Hız ve maliyet: Aynı rakam farklı şeyi anlatabilir
Anthropic, Sonnet 5’e göre çıktı üretiminin yüzde 30 hızlandığını ve kendi testlerinde görev maliyetinin yüzde 30’a kadar düştüğünü bildiriyor. Token birim fiyatı aynı. Hız ve maliyet açıklaması.
Bu ayrım bütçe planında önemli. Daha hızlı çıktı almak, kullanıcının ilk yanıtı aynı oranda daha erken göreceğini veya projenin aynı oranda erken biteceğini söylemez. Araç beklemeleri, revizyonlar ve insan kontrolü toplam sürenin parçalarıdır. Ben denemede ilk üretimi ve son kabulü ayrı kaydederdim. Böylece akışın hangi aşamasında zaman kazanıldığını görürüz.
Resmî API fiyatı, milyon token başına girişte 2 dolar ve çıkışta 10 dolar. Önbelleksiz 100 bin giriş ve 10 bin çıkış tokenı için hesap 0,20 + 0,10 = 0,30 dolar olur. Bu örnek araç ücretlerini içermez; bir abonelik bedeli veya ölçtüğümüz proje faturası değildir.
Tasarım ve web için üç somut deneme
İlk denemeyi tek bir hizmet sayfasının giriş bölümünde yapardım. Mevcut tipografi, ana renk, hedef kullanıcı ve çağrı butonu belirli olsun. Modelden aynı sırayla üç başlık ve açıklama alternatifi isteyin. Karşılaştırma sorusu, hangisinin daha süslü olduğu değil, hizmeti hangisinin daha açık anlattığı olsun. Seçilen yönü revizyonlarda sabit tutmak değerlendirmeyi kolaylaştırır.
İkinci görev, mevcut bir ürün kartının mobil ekran görüntüsü olabilir. Görsel, fiyat, ürün adı ve ana aksiyon arasındaki ilişkiyi yorumlatın. Öneriyi uygulamadan önce ekranda gerçekten bulunan bilgilere dayandığını kontrol edin. Uzun bir ürün adı veya eksik görsel gibi durumları ayrıca gösterin; iyi görünen tek bir örnek, bileşenin bütün içeriklerde çalıştığını kanıtlamaz.
Üçüncü görevde küçük bir arayüz düzeltmesi seçin. Örneğin dar ekranda taşan bir bölümün mevcut bileşen yapısıyla düzeltilmesini isteyin. Kabul ölçütü yalnız taşmanın bitmesi olmasın: geniş ekran düzeni, bağlantılar ve klavye kullanımı da kontrol edilsin. Bu kapsam, modelin gereken değişikliği yapıp yapmadığını ve ilgisiz yerleri değiştirip değiştirmediğini görmemizi sağlar.
Kendi denemenizin raporunda ne bulunmalı?
Briefi, kullanılan modeli, çalışma ayarını ve beklenen çıktıyı kaydedin. Sonra tamamlanma süresini, revizyon sayısını, tüketimi ve kabul kararını aynı görev için izleyin. “Güzel göründü” yerine neyin çalıştığını yazın: başlık hizmeti anlatıyor, buton doğru sayfaya gidiyor veya kart mobilde taşmıyor. Bu notlar bir sonraki denemede karşılaştırılabilir bir kayıt oluşturur.
Başarısız örneği de saklayın. Eksik bağlam yüzünden yanlış bir öneri geldiyse, briefi değiştirip tekrar deneyin; iki sonucu aynı koşulmuş gibi sunmayın. Birkaç görevde başarı görmek de bütün projeyi modele devretmek için yeterli gerekçe değildir. Hangi işi hızlandırdığını ve hangi aşamada insan kararı gerektiğini ayırabilmek, küçük bir ekip için daha değerli bir sonuçtur.
Örneğin ürün kartı denemesinde aynı ekranı, aynı içerikleri ve aynı değişiklik talebini kullanın. Bir modelden yalnız metni kısaltmasını, diğerinden bütün kartı yeniden tasarlamasını isterseniz sonuçlar farklı işi anlatır. Revizyonu da kayda ekleyin: ilk öneri kabul edilmediğinde hangi bilgi verildi ve ikinci turda ne düzeldi? Böylece başarılı sonucun ilk yanıttan mı, daha açık bir brieften mi geldiğini ayırt edebiliriz.
İyi görünen prototipin teslim kontrolü
Bir web sayfası taslağında yalnız ekran görüntüsüne bakarak teslim kararı vermem. İletişim butonunun doğru yere gitmesi, uzun başlığın kartı bozmaması ve mobilde metnin okunabilmesi de işin içinde. Modelin önerdiği bir görselin ölçülerini veya kullanılacak dosyanın boyutunu kontrol etmek, uygulama aşamasındaki küçük ama etkili kararlardan biridir. Performans raporundaki yüksek puan bu kontrolleri bizim yerimize yapmaz.
Ben prototipi üç içerikle denemeyi tercih ederdim: kısa ve normal bir metin, uzun bir başlık, bir de henüz görseli hazırlanmamış bir kayıt. Aynı sayfanın farklı durumlarda nasıl davrandığını görmek, tasarımın yalnız sunum için mi yoksa gerçek içerik için mi kurulduğunu ortaya çıkarır. Geri bildirimde de görünen sorunu açık yazarım: “Dar ekranda başlık butona taşıyor” gibi. Bu ifade, “mobilde daha güzel olsun” talebine göre uygulanacak değişikliği daha net tarif eder.
Son kabulde onaylanmış metni, tasarım yönünü ve çalışan sayfayı birlikte değerlendiririz. Sonnet’in katkısını da bu teslim üzerinden konuşmak isterim: hangi öneri kullanıldı, hangisi revize edildi ve insanın yeniden yapması gereken bölüm neydi? Böyle bir kayıt, sonraki proje için model seçimini daha somut hale getirir.
Mevcut uygulamaya geçişte kontrol edilecekler
Yenilikler belgesi, önceki modelde kullanılan bazı ayarların hata verdiğini açıklıyor. `thinking.type: disabled` yerine `between_tools` yalnız low, medium ve high seviyelerinde kullanılabiliyor; zorunlu araç seçimi desteklenmiyor. Kullanıcıya ilerleme gösteren uygulamalarda yanıt bloklarının okunma biçimi de kontrol edilmeli.
Ben geçişi önce ayrı bir deneme ortamında, bir metin görevi ve bir araç kullanan görevle sınardım. İstek başarılı olsa bile beklenen arayüz davranışı kaybolabilir. Yanıt akışını ve hata durumlarını mevcut ekranla birlikte değerlendirmek gerekir. Geçiş kılavuzu, kullanılacak ayarları mevcut entegrasyonla karşılaştırmak için başlangıç noktasıdır.
Projede karar vermek için sonraki adım
Sonnet 5.5’in raporları, hangi işlere bakacağımızı belirlememize yardım ediyor. Benim başlangıcım yine tek bir sayfa, açık bir brief ve tanımlı teslim ölçütleri olurdu. İlk üretimi, revizyonu ve çalışan sonucu birlikte değerlendirince modelin katkısı daha görünür hale gelir. Yaratıcı yön ve teslim kararı da bu sürecin parçası olarak kalır.
Bir hizmet sitesinde aynı yaklaşımı kurmak için önce mesajı ve kullanıcı yolculuğunu netleştirmek gerekir. Web tasarım ve yazılım hizmetinin kapsamında bu kararları arayüz ve uygulama planıyla birlikte ele alıyorum. Araç seçimini de projenin ihtiyacına ve beklenen teslimine göre yapmak, hem tasarım yönünü hem çalışma kapsamını anlaşılır tutar.