brick by brick'e hoş geldiniz!

Bültenin 28. sayısından selamlar!

Ne zamana kadar benlesin, henüz ona karar vermedim, buralara kolay gelmedim...

Her gün yeni bir tool, her saat yeni bir "game changer", her LinkedIn postu "Bunu kullanmayan tasarımcılar işsiz kalacak" diye başlıyor. Bir bakmışsın 12 farklı platforma abonesin, ama hangisini neden aldığını sen de hatırlamıyorsun.

Let's be real: Tasarımda öğrenme hiç bitmiyor.

Ama yıllardır değişmeyen bir gerçek de var: En değerli öğrenmeler çoğu zaman bir araçtan değil, aynı işi yapan insanlarla aynı ortamı paylaşmaktan geliyor.

Tam da bu yüzden partnerleri arasında yer aldığımız Deneyim Tasarımı Zirvesi 2026'yı paylaşmadan geçemeyiz.

29 Eylül'de gerçekleşecek zirvede müşteri deneyiminden UX'e, erişilebilirlikten yapay zeka ve hikâyeleştirmeye kadar birçok konu konuşulacak. Aralarında Userspots Founder & brick institute Co-Founder'ı Mustafa Dalcı'nın da bulunduğu 15'ten fazla konuşmacı sahnede olacak.

Geçtiğimiz yıl 4,78 memnuniyet puanı ve +87 NPS alan zirve, bu yıl da deneyim tasarımı profesyonellerini aynı çatı altında buluşturuyor. Kısacası; yeni tool'lar yine çıkar, ama iyi sohbetler, yeni bağlantılar ve ilham veren konuşmaların alternatifi pek olmuyor.

Takviminizde 29 Eylül hâlâ boşsa, bence değerlendirmeye değer.

14 Ağustos'a kadar erken kayıt fırsatını da kaçırma. Detaylar için web sitesine göz atabilirsiniz.

Artık konu AI olunca tool'lardan bahsetmek bile eskidi. There is a new sheriff in town: ✨Skill'ler✨

Peki konuşulduğu kadar var mı yoksa bu da sadece geçici bi hype mı? Okuyalım...

Tasarımcı Skill'leri

Geçen hafta X'te feed'i kaydırırken tuhaf bir şey fark ettik.

Aynı gün içinde, birbirinden bağımsız beş ayrı hesap "50 CLAUDE SKILLS THAT ARE ACTUALLY USEFUL" başlıklı bir liste paylaşmış. Beşi de aynı liste. Aynı sıra, aynı açıklamalar, aynı yazım hataları. Kimse denemiş falan değil, sadece kopyalamışlar.

O an "eh yeter be" dedik ve konuyu ciddi ciddi araştırmaya karar verdik.

Çünkü Brick olarak skill'ler konusunda uzun süredir aynı yerde duruyoruz: overrated. Herkesin bir listesi var, kimsenin ölçümü yok. Ama araştırmaya girince beklemediğimiz bir şey çıktı — konum hâlâ doğru, ama gerekçeleri değişmiş.

Bu yazıda skill'lerin neden hâlâ abartıldığını, buna rağmen son altı ayda gerçekten neyin olgunlaştığını ve bir tasarımcının bugün hangilerini kurcalamasının mantıklı olduğunu anlatacağız.

Önce Kötü Haber: Skill'lerin Yarısı Ölü Doğuyor

Bu sefer sadece hisler değil, sayı var elimizde...

Temmuz'da yayımlanan bir akademik çalışma, 18.463 registry skill'ini ve 5.876 GitHub repo'sundaki 23.199 kişisel skill'i inceledi. Aralarındaki 3.709 yeniden kullanım bağlantısını takip ettiler. Yani birinin skill'ini alıp kendi klasörüne kopyalayan insanların ne yaptığına baktılar.

Çıkan tablo şu:

• Kopyalanan skill'lerin %53'ü hiçbir zaman güncellenmiyor
• %40,2'si, orijinalinde sonradan çıkan düzeltmeleri hiç almıyor
• Skill'lerin %63'ü ajanın insanla nasıl konuşacağını kurguluyor — ama benimseyenlerin sadece %1–2'si o kısma dokunuyor
• Ekleme/çıkarma oranı 6,1'e 1. Yani skill'ler sürekli şişiyor, kimse budamıyor

Çalışmanın kendi cümlesi çok net: "Adoption largely behaves as a one-time copy." Kopyalıyorsun, klasöre atıyorsun, unutuyorsun.

​

Bir daha açıp yüzüne bakmayacağımız skill dosyalarını copy paste'lerken bizim min keyif

Burada ufak bir araya girelim, çünkü asıl mesele burada. Bir README'yi güncellemezsen kimse ölmez, insan okur ve "bu eskimiş" der. Ama skill'i makine okuyor ve o eski talimatı güvenle çalıştırıyor. Hata düzeltme mekanizması yok. Jakob Nielsen buna "skill rot" adını taktı, bize kalırsa tam yerine oturmuş bir isim.

Bir de güvenlik tarafı var. 31.132 topluluk skill'i tarandığında%26,1'inde en az bir sömürülebilir açık bulunmuş — prompt injection, veri sızdırma, yetki yükseltme. Her dört skill'den biri. (GitHub'dan indirip klasöre attığın o şeyin ne yaptığını okudun mu peki? Biz de hep okumuyoruz, itiraf edelim.)

Üstüne UX Planet'te temmuz ortasında çıkan yazının başlığı zaten her şeyi söylüyor: "20 popüler Claude Code skill'ini test ettim. Çoğu işe yaramazdı."

Peki Neden Hâlâ Konuşuyoruz?

Çünkü aynı araştırmanın içinde ters yöne bakan bir bulgu daha var ve bize kalırsa asıl haber o.

​Küratörlü skill'ler, 84 görevde ajanın başarı oranını ortalama %16,2 artırıyor. Buna karşılık modelin kendi yazdığı skill'ler hiçbir konfigürasyonda tutarlı bir fayda göstermiyor.

Cümleyi bir daha okuyalım: skill'ler işe yarıyor. İnsanların kurduğu şeylerin çoğu skill değil.

Aynı araştırmadan iki pratik not daha:

• Düz bir skill listesi 80'i geçince bozuluyor. Benzer açıklamalı skill'ler birbirine karışıyor, ajan hangisini çağıracağını şaşırıyor.
• Geniş kapsamlı skill kötü, dar kapsamlı skill iyi. 2–3 modüllük odaklı skill'ler daha iyi çalışıyor.

Yani "50 skill kurdum" bir başarı değil, bir semptom.

İşte Tam Burada: Altı Ayda Ne Değişti?

Bir teknolojinin oyuncak olmaktan çıkıp üretime girdiğini nereden anlarsın? Bana kalırsa dört işaret var: paket yöneticisi çıkar, güvenlik taraması çıkar, akademik literatür oluşur, kurumsal vaka yayımlanır.

Skill'lerde dördü de çıktı. Hem de altı ay içinde.

Paket yöneticisi geldi — arkasında da Vercel var.skills.sh, kendini "npm for agent skills" diye tanıtıyor. npx skills add komutu 76 farklı ajanı destekliyor: Claude Code, Cursor, Codex hepsi içinde. Bu şu demek — skill artık tek bir ürüne kilitli değil, taşınabilir bir şey. Bir tanesini kur, aracını değiştirdiğinde yanında gelsin.

Güvenlik katmanı kuruldu. NVIDIA, SkillSpector adında açık kaynak bir tarayıcı çıkardı; skill'leri statik analizle tarıyor, SARIF raporu üretiyor, CI'ına policy gate olarak bağlanıyor. Bir teknolojiye güvenlik tarayıcısı yazılıyorsa o teknoloji artık hobi değil.

Kurumsal yönetim tarafı da başladı. localskills.sh gibi araçlar ekip ve şirket ölçeğinde skill + MCP yönetimi yapıyor. "Herkes kendi klasörüne kopyalasın" dönemi kapanıyor.

Tasarım Tarafında Asıl Haber: DESIGN.md

Buraya kadar genel resimdi. Hadi tasarımcı tarafına gelelim, çünkü orada daha net bir şey oldu.

Bir konvansiyon oluştu: DESIGN.md. Tek bir düz metin dosyası, içinde hem makinenin okuyacağı design token'lar hem de insanın okuyacağı gerekçe var. CLAUDE.md kod tarafında ne yapıyorsa, DESIGN.md görsel kimlik tarafında onu yapıyor.

Konvansiyonun kaynağı Google Stitch'in yayımladığı bir spec. Etrafında biriken şeyler ise fikir aşamasını geçtiğini gösteriyor: 101 bin yıldızlı bir hazır DESIGN.md koleksiyonu, Apple'dan Stripe'a 300+ gerçek sitenin tasarım sistemini analiz edip DESIGN.md'ye çeviren bir katalog (getdesign.md), 2.000+ AI-okunabilir tasarım sistemi sunan bir başkası (Refero).

Kurumsal vaka da geldi ve sıcak — 3 Ağustos'ta, yani bu bülteni yazmamıza üç gün kala.

​LINE Yahoo'nun tasarım ekibi, şirket içi tasarım sistemlerini "AI-Ready" yapma sürecini yazdı. Birleşme sonrası LINE ve Yahoo sistemlerini LEAN UI adı altında birleştirmişler, sonra üç katmana ayırmışlar: değişmez kalite standartları, AI'ın anlayabileceği tanımlar, teslim mekanizmaları. Kullandıkları araçlar Figma Code Connect, MCP, Agent Skills ve DESIGN.md. React/Vue tarafında markup mühendisliği eforunda %80 azalma bildiriyorlar.

Burada dürüst olalım: o %80 ekibin kendi beyanı, bağımsız bir ölçüm değil. Bir de yazıda çok hoşumuza giden bir detay var — DESIGN.md ve MCP'yi bilinçli olarak "değiştirilebilir teslim mekanizması" diye çerçeveliyorlar, bağlandıkları bir standart olarak değil. Sahici bir duruş.

Peki Bir Tasarımcı Bugün Neyi Kurcalasın?

Hepsini tek tek GitHub'dan doğruladık, yıldız sayıları ağustos başı itibarıyla.

Skill ​Impeccable (Paul Bakaus)​ ​ui-ux-pro-max​ ​Taste Skill​ ​Emil (Emil Kowalski)​ ​Layers (Jamie Mill)​

​Ne yapıyor​ Kodlama ajanına arayüz iyileştirme dili veriyor. 23 komut, 59 deterministik "anti-slop" kuralı 84 UI stili, 192 palet, 74 font eşleşmesi, 161 sektör kuralı AI arayüzünün klişeleşmesini engelliyor — mor gradient, üç kart yan yana, o bildiğin şeyler Animasyon incelemesi ve animasyon sözlüğü. Sonner ve Vaul'un yazarından Ürün tasarımı karar çerçevesi, yedi katman: yüzey → etkileşim → kavramsal model → strateji

★ ~50k 112,6k 70,1k 25,1k 281

Son satırı özellikle bıraktık. Layers'ın çerçevesi gerçekten iyi — tasarım kararlarını yüzeyden gözlemlenen davranışa kadar yedi katmana ayırıyor, MIT lisanslı, tek komutla kuruluyor. Ama 281 yıldız ve 9 commit. Yani ortada iyi bir fikir var, henüz bir araç yok.

Tekrar söylüyoruz bunu çünkü tam da bu yazının konusu: yıldız sayısı kaliteyi göstermiyor ama kullanımı gösteriyor. İkisini karıştırmayalım.

Bir de şunu ekleyelim — X'te dolaşan "Impeccable 92 bin yıldız" iddiası şişirilmiş, gerçek rakam 50 bin bandında. Kontrol etmeden aktarmayalım.

Impeccable'ın Kurucusundan Bir Cümle

Paul Bakaus'un Latent Space'te söylediği bir şey var, bu araştırmada okuduğumuz en iyi cümleydi:

Anlatmak istediği şu: ajana "daha cesur yap" dediğinde neon efekt veya cam yüzey ekliyor, çünkü "cesur" onun için boş bir kelime. Impeccable ise cesareti hiyerarşiye, ölçeğe ve kararlı tipografiye çeviriyor. Skill kurmak prompt yazmak değil, tanım yazmak.

Bakaus'un ürünü için söylediği cümle de bizim AI tavrımıza birebir oturuyor: "There is no auto, and there will be no auto."

Brick Tarafında Biz Ne Yapıyoruz?

Biz de kurduk. Bültenin "Kısa..Kısa.." bölümü için bir skill'imiz var, marka tonuna göre içerik düzenleyen bir tanesi var, carousel üreten bir tanesi var. Yani bu yazıyı dışarıdan bakarak yazmıyoruz.

​

Biz de birileriyiz...

Öğrendiğimiz de araştırmanın söylediğiyle aynı: işe yarayan skill, gerçek bir iş akışından çıkarılan skill. Bizimkiler ortalıktan indirilmiş şeyler değil, aylardır elle yaptığımız işlerin donmuş hali. Bir işi üçüncü kez aynı şekilde yaptığımızda skill'e dönüştürüyoruz. Öncesinde değil.

İkinci öğrendiğimiz de şu: skill kurmak bir kereye mahsus iş değil. Araştırmadaki %53 rakamı boşuna çıkmamış — biz de güncellemeyi unutuyoruz, sonra çıktı bozuluyor, sonra "neden bunu yaptı ya" diye bakıyoruz. (Sonra dosyayı açıp altı ay önceki kendi talimatımızı okuyoruz ve suçlu belli oluyor :))

Bitirmeden;

Skill'ler hâlâ overrated. Bunu değiştirmiyoruz.

Ama şimdilik bulduğumuz çıkış noktası şu: abartılan şey skill'in kendisi değil, sayısı. 50 skill kurmak seni hızlandırmıyor; gerçek işinden çıkardığın 3 tanesi hızlandırıyor. Araştırma da tam olarak bunu söylüyor — küratörlü olan %16 kazandırıyor, gerisi gürültü.

Altyapı olgunlaştı, bu net. Paket yöneticisi var, güvenlik taraması var, tasarım tarafında bir konvansiyon oturuyor. Yani artık "denemeye değmez" diyemeyiz. Ama "listeye bak, hepsini kur" da diyemeyiz.

Bu arada, skill yazmak için kimsenin listesini beklemene gerek yok. Bu hafta üçüncü kez aynı şekilde yaptığın bir iş var mı? Bir e-postayı hep aynı sırayla mı yazıyorsun, bir tasarımı hep aynı kriterlere göre mi gözden geçiriyorsun? İşte skill orada. Yaptığın adımları, verdiğin kararları ve "şunu asla yapma" dediğin şeyleri düz bir dosyaya yaz — süslemeye çalışma, kendi kendine anlatır gibi yaz. İlk hâli berbat olacak, normal; iki üç kullanımda oturuyor. Kendi işinden çıkardığın en kaba skill, indirdiğin en iyi skill'den bile daha çok işine yarıyor.

Peki diyelim doğru skill'leri bulduk. Sıradaki soru daha zor: Bütün bunlar gerçekten işe yarıyor mu?

Çünkü hissetmek başka, ölçmek başka.

2. yazımız da tam bunun hakkında.

AI ile Kodlamanın ROI'si

Bu aralar müşteri ziyaretlerinde masaya en çok gelen soru bu oldu: ekibe AI araçlarını aldık, peki gerçekten hızlandık mı?

Neredeyse herkes aynı yerde takılıyor. Araçlar dağıtılmış, bütçe onaylanmış, ekip memnun. Ama kimse tek bir rakam veremiyor.

Sonra geçtiğimiz haftalarda gündemi tararken bir araştırmaya denk geldik ve ekipte bir süre kimse konuşmadı.

​METR adında bir araştırma kuruluşu, 16 deneyimli açık kaynak geliştiricisini alıyor. Kendi repo'ları, kendi bildikleri kod tabanı, uydurma değil gerçek issue'lar. Bir kısmında AI kullanmalarına izin veriliyor, bir kısmında verilmiyor. Ekran kayıtları alınıyor, süre tutuluyor.

Deney öncesi geliştiricilere soruyorlar: AI sizi ne kadar hızlandırır? Cevap ortalama %24.

​Çıkan sonuç: AI'lı grup işleri %19 daha yavaş bitiriyor.​

Asıl can alıcı kısım burada da değil. Deneyden sonra aynı kişilere tekrar soruluyor — süreyi yaşamış, işi bizzat yapmış insanlar. Cevap yine aynı: "AI bizi %20 hızlandırdı."

Yani yavaşladıklarını fark bile etmemişler. ​​​​

Bu yazıda ekibinin AI ile gerçekten hızlanıp hızlanmadığını nasıl ölçeceğini anlatacağım. Kimin ne yaptığına, hangi rakamların işe yaradığına ve nerelerde kendimizi kandırdığımıza bakacağız.

Peki Bu Neden Bizim Konumuz?

Çünkü o ziyaretlerdeki cevap hep aynı: "ekip çok memnun."

Memnuniyet güzel bir şey, ama ay sonunda gelen faturaları ödemiye yetmiyor. METR'in deneyi tam olarak bunun neden yetmediğini gösteriyor — memnuniyet ölçtüğün şeyin ta kendisi olduğunda, yanlış yönü bile fark edemiyorsun.

Burada ufak bir araya girelim: METR'in çalışması 2025 başında, o günün araçlarıyla yapıldı. Araçlar değişti, bugün sonuç farklı çıkabilir. Ama dayanıklı olan kısım şu ve o değişmedi — algı, ölçüm değildir. Ekibin ne hissettiğiyle ekibin ne yaptığı iki ayrı veri, ikisini birbirinin yerine koyamıyoruz.

Önümüzdeki dönemde bu soruyu soran çok daha fazla ekip olacak. Bugün ölçmeye başlamayan, sorulduğunda cevapsız kalacak.

Önce Kötü Haber: Tek Bir "AI Verimlilik" Sayısı Yok

"AI ekibi %30 hızlandırır" cümlesi bize hiçbir şey söylemiyor. Kimin, hangi işte olduğunu söylemiyorsan aslında bir şey söylememiş oluyorsun.

Stanford'dan Yegor Denisov-Blanch yaklaşık 100 bin geliştiricinin verisini analiz etti. (Yayımlanmış bir makale değil, konferans sunumu — o yüzden kesin rakam yerine aralık veriyoruz.)

• Sıfırdan proje + basit iş: %30–40 kazanç
• Sıfırdan proje + karmaşık iş: %10–15
• Mevcut kod tabanı + basit iş: %15–20
• Mevcut kod tabanı + karmaşık iş: %0–10, bazı ekiplerde net negatif

Deneyim seviyesi de aynı şekilde ayrışıyor. Microsoft, Accenture ve bir Fortune 100 şirketinde toplam 4.867 geliştiriciyle yapılan kontrollü deneylerde ortalama kazanç %26 çıkmış. Microsoft kolunun kırılımına bakınca tablo netleşiyor: junior'lar %21–40, senior'lar %7–16.

Yani AI en çok, ekibinde en az deneyimli olanı hızlandırıyor. Kulağa iyi haber gibi geliyor. Birazdan neden tam olarak öyle olmadığına geleceğim.

Hızın Faturasını Kim Ödüyor?

​Faros AI iki yıl boyunca 22 bin geliştiricinin, 4 binden fazla takımın telemetrisini izlemiş. Aynı organizasyonların en düşük ve en yüksek AI kullanım dönemlerini karşılaştırmışlar.

İyileşen tarafı beklendiği gibi: task throughput (birim zamanda biten iş sayısı) %33,7 artmış, PR merge oranı (ana dala birleşen kod değişikliği) %16,2, geliştirici başına tamamlanan epic (büyük iş paketi) sayısı %66.

Diğer tarafta ne olduğuna bakalım:

• Geliştirici başına hata (bug): +%54
• Aylık kesinti ve olay (incident) sayısı: +%57,9
• İnceleme görmeden merge edilen PR: +%31,3
• Code churn, yani silinip yeniden yazılan kod: +%861

Ama asıl mesele şurada. Bir kod değişikliğinin ilk incelemeyi görmesi %156 daha uzun sürüyor. İncelemede geçen süre ise %441 uzamış.

Faros bunu "senior engineer tax" — senior mühendis vergisi — diye adlandırıyor ve bize göre çok yerinde bir isim. AI kod yazmayı ucuzlattı, kod okumayı ucuzlatmadı. Darboğaz klavyeden çıkıp inceleme kuyruğuna taşındı, orayı da senior'ların zamanı ödüyor.

​Google'ın 2025 DORA raporu da aynı yere çıkıyor. Yaklaşık 5.000 kişilik ankette AI kullanımı ile delivery throughput (teslimat hızı) arasında pozitif, delivery stability (teslimatın kararlılığı, yani bozulmadan gitmesi) arasında negatif korelasyon var. Raporun tezi net: AI bir amplifikatör. İyi çalışan ekibi daha iyi, kötü çalışan ekibi daha kötü yapıyor.

Peki Ne Ölçeceğiz?

Hadi işin pratik tarafına gelelim. Bu bölümün ekran görüntüsünü alıp ekibinle paylaşabilirsin, gerisi detay.

Bir — Her hız metriğinin yanına bir karşı ağırlık koy.Tek başına hız ölçmek, sistemi kırılmaya doğru optimize etmek demek oluyor.

Ölçtüğün PR throughput — birim zamanda giden kod değişikliği Cycle time — bir işin başlamasıyla bitmesi arasındaki süre Deploy sıklığı — canlıya çıkma sıklığı Anketle ölçülen kazanılan saat

Yanına koyacağın Escaped defect rate — canlıya kaçan hata oranı İlk incelemeye kadar geçen süre + incelemede geçen süre MTTR — bir arızadan toparlanma süresi AI harcaması → net kazanç

İki — Baseline'ı, yani başlangıç ölçümünü, araçları dağıtmadan önce al. Telemetriyi geriye dönük çıkarabilirsin, algıyı çıkaramazsın. "Eskiden ne hissediyordunuz" diye soramıyoruz. Bir haftalık iş, kaçırırsan bir daha şansın olmuyor.

Üç — Toplam sayıya değil, kırılıma bak. En az üç segment: yeni proje / mevcut kod, junior / senior, ekip bazında. Stanford verisinde üst çeyrek ile alt çeyrek arasındaki fark zamanla dört katına çıkmış. Tek bir kurumsal ortalama bunu tamamen gizliyor.

Dört — Beklentini gerçeğe göre kur.400'den fazla organizasyonun 14 aylık verisinde medyan PR throughput artışı %7,76. Araç satıcılarının söylediği 3–10x değil. Maliyet tarafı da net: 2026'da geliştirici başına aylık toplam 200–600 dolar bandında. %30 bekliyorsan gerçek bir başarıyı bile başarısızlık diye okuyorsun.

Ölçerken Düştüğümüz Üç Tuzak

Tokenmaxxing.Gergely Orosz'un aktardığı bir vaka var: bir şirket toplu işten çıkarmanın (layoff) hemen ardından verimlilik metriği olarak "AI destekli PR yüzdesi" ve "haftalık PR sayısı" belirliyor. Sonuç tahmin edilebilir — insanlar sırada olmamak için metrik şişiriyor. Aynı dönemde üç ayrı büyük şirketten geliştiriciler token kullanımının ölçüldüğünü yazmış. Bir metrik hedefe dönüştüğü anda ölçüm olmaktan çıkıyor.

Bireysel ölçüm. Ekip seviyesinde topla, kişi seviyesinde asla. Ve neden ölçtüğünü açıkça anlat. Bunu atlarsan yukarıdaki tuzağa kendi elinle giriyorsun.

Öğrenmeyi hesaba katmamak.Anthropic'in şubatta yayımladığı kontrollü deneyde 52 çoğunlukla junior geliştirici, AI ile veya AI'sız bir Python kütüphanesi öğrendi. Sonrasındaki kavrama testinde AI'lı grup 17 puan düşük skor aldı, %50'ye karşı %67. En büyük fark hata ayıklama (debugging) sorularında çıkmış. Hız avantajı ise istatistiksel olarak anlamlı bile değil.

Kritik nüans şu: AI'ı anlamak için kullananlar, yani soru sorup açıklama isteyenler bilgiyi çok daha iyi tutmuş. Fark araçta değil, kullanım biçiminde.

Tekrar söylüyoruz bunu çünkü kolayca atlanıyor: junior'ını en çok hızlandıran araç, aynı zamanda onun senior olmasını en çok geciktiren araç olabiliyor. MIT'den Michael Caosun ve Sinan Aral'ın "Artırım Tuzağı" makalesi tam da bunu modelliyor — yönetici beceri erozyonunu bilse bile, kısa vadeli kazanç yeterince cazipse AI'ı yoğun kullanmayı rasyonel olarak seçebiliyor. Uzun vadede toplam verimlilik düşüyor.

Bunu ölçmüyorsan iki yıl sonra fark ediyorsun.

Türkiye Tarafında Ne Var?

Açık konuşalım: bu bültende saydığımız rakamların hiçbiri Türkiye'den gelmiyor.

​Booking.com'un, Dropbox'ın, Google'ın nasıl ölçtüğünü biliyoruz. Türkiye'de ekibine token bütçesi ayıran kaç şirket bunun karşılığını ölçüyor — bilmiyoruz. Tahminlerimiz var ama verimiz yok.

Bu bir sitem değil, bir davet. Ekibinde bu ölçümü yapıyorsan, başlangıç ölçümünü aldıysan, hız metriğinin karşısına bir kalite metriği koyduysan — hatta ölçüp "işe yaramıyor" sonucuna vardıysan — bu maile yanıt yaz. Türkiye'den gerçek bir veri seti, burada listelediğimiz her rapordan daha kıymetli olur.

Bitirmeden;

Bu bülteni hazırlarken fark ettiğimiz bir şeyi de söylemeden geçmemek lazım. Ölçümü konuşan neredeyse herkes — DX, Faros, Jellyfish — aynı zamanda ölçüm platformu satıyor. Verileri gerçek, metodolojileri açık, biz de kullandık. Yine de bunu bilerek okumak gerekiyor.

İlginç istisna Anthropic'in çalışması. Kendi ürününün öğrenmeyi zorlaştırdığını gösteren bir sonucu yayımlamışlar. Bir satıcının kendi aleyhine veri yayımlaması, o veriyi diğerlerinden daha sahici kılıyor bizce.

AI konusunda tavrımız değişmedi: ne hype ne ret. Deneyeceğiz, ölçeceğiz, bize uyuyor mu göreceğiz.

Şimdilik bulduğumuz çıkış noktası şu: en zor kısım hızı ölçmek değil, hızın işe yarayıp yaramadığını ölçmek. Daha çok kod göndermek daha çok değer üretmek anlamına gelmiyor. Ölçüm sistemine en az bir tane iş sonucu metriği koy — AI'ın taklit edemediği tek metrik o.

Ve bunun için token'a değil, iki haftalık disipline ihtiyacın var.

Sen ekibinde bunu nasıl ölçüyorsun, hiç ölçüyor musun — gerçekten merak ediyoruz. Yanıtlayıp yazarsan, tecrübenden faydalanmayı çok isteriz. Bir sonraki sayıda konuşalım.

Kısa Kısa...

AI

Agent'i workflow'un ortasına koy: Saf agent de saf workflow da tek başına yetmiyor. Bu yazı, agent'i yalnızca esnekliğe ihtiyaç duyulan aşamalara gömen hibrit bir mimari öneriyor. Güvenilirliği workflow'dan, uyum yeteneğini agent'ten alıyorsun. Production'da AI çalıştıran herkes için pratik bir yaklaşım. 🧱

Coding agent'lar gerçek işte kaç puan alıyor? Supabase, evals adında açık kaynak bir benchmark çıkardı. Claude Code, Codex ve OpenCode'u schema kurma, Edge Function debug'lama, RLS policy düzeltme gibi gerçek görevlerde ölçüyor. Hangi agent'ın nerede iyi olduğunu tahmin etmek yerine artık test edebiliyorsun. 👌

Şirketin dağınık bilgisini LLM'e nasıl bağlarsın? Demo'da çalışan RAG ile production'da çalışan "company brain" arasında ciddi bir mühendislik farkı var. Bu yazı, dağınık kurum bilgisini LLM'in gerçekten kullanabileceği bir context layer'a çevirmenin pratik yollarını anlatıyor. Proof-of-concept'ten öteye geçmek isteyenlere. 💡

AI faturan düşmüyor, artıyor: Superhuman'ın FinOps lideri Josh Collier, frontier model fiyatlarının ilk düşüşten sonra ikiye katlandığını anlatıyor. Sohbette tek bir workflow'un maliyetini aylık 400 bin dolardan 80 bine indiren mimari değişiklikler var. AI maliyetini ciddiye almaya başladığın an bu konuşma işine yarar. 🤔

Ürün Yönetimi

Bir CPO, "keşke product management diye bir şey olmasaydı" diyor: Whatnot'ın CPO'su Tom Verrilli, Lenny'ye takım yapısı, IC işi ve AI'ın PM rolünü nasıl değiştirdiği üzerine çarpıcı bir söyleşi veriyor. Provokatif başlığın arkasında, product ekiplerini nasıl kurduğuna dair sağlam bir düşünce var. 🧱

"Product sense" tam olarak ne demek? Herkesin bahsettiği ama kimsenin net tanımlamadığı o yeteneği NN/G somutlaştırmış: deneyerek öğrenilen kalıplardan hangi ürün kararının tutacağını tahmin edebilmek ve o kalıpların ne zaman geçerli olduğunu bilmek. İyi haber, öğrenilebilir bir şey. 👌

AI PM ile normal PM arasındaki gerçek fark: İkisi de aynı işi yapıyor: kullanıcı problemini çözmek. Ama bu yazıya göre AI PM; olasılıksal çıktılarla, eval'lerle, prompt'larla, veri kalitesiyle ve hallucination yönetimiyle uğraşmak zorunda. Kod yazmadan bu role geçmek isteyen PM'ler için pratik bir yol haritası var. 🚀

Herkes hedefini tutuyor ama şirket kaybediyor: Tanıdık geldi mi? Bu yazı, takımların tek tek target'ını tutup şirketin yine de başarısız olduğu o klasik tuzağı ele alıyor. Silolar arasına düşen, kimsenin ölçmediği problemleri görmek için "ecosystem thinking" öneriyor. Metriğe değil bütüne bakmak. 💡

Tasarım

AI, tasarım kurallarını değiştiriyor: Jakob Nielsen'in son UX derlemesinde AI için değişen tasarım rehberlerinden AI anxiety'ye, glanceable monitoring'den toggle switch'lere kadar geniş bir gündem var. Alanın nabzını tutan, haftalık okuma listene katabileceğin bir derleme. 🧱

Markanın görsel kimliği tek bir dosyada: AGENTS.md'yi duyduysan mantığı tanıdık gelecek. DESIGN.md, bir ürünün görsel kimliğini, design token'larını ve marka kurallarını hem insanların hem AI agent'ların okuyabileceği tek bir standart dosyada topluyor. Agent'ların tasarım sistemine gireceği bir dünyada akıllıca bir fikir. 👌

Her friction kötü değil: Changi Havalimanı gibi sürtünmesiz deneyimler harika, ama bu yazı AI çağında her şeyi pürüzsüz yapmanın da bir tuzağı olduğunu savunuyor. Bazen tasarım "unutulur" olmalı, bazen de anlamlı bir deneyim için stratejik friction gerekiyor. Ne zaman hangisi, işin sırrı orada. 🤔

Her şey tek bir chat box'a sığınca tasarım ne olacak? AI, onlarca ekranı tek bir sohbet kutusuna indiriyor. Bu yazı, Jakob's law'u (kullanıcılar zamanının çoğunu senin ürününde değil başka ürünlerde geçirir) bu yeni dünyada nasıl uygularsın diye soruyor. Arayüzler eriyip chat'e dönüşürken tanıdıklık hâlâ önemli mi? 🧱

Yaklaşan Brick Institute Eğitimleri

Bülteni bitirirken bu ay yaklaşan eğitimlerimizi bir göz atmanız için şöyle özetliyoruz:

Sertifika Programları

Ürün Yönetimi Eğitimleri

15 Eylül - 1 Ekim - Yazılım Geçmişi Olmayanlar için Yazılım - Tech Lead & Product Engineer Mustafa Biçer ile yazılımın kapısını aralayın! "Yazılım dünyası bana çok uzak" diyenler için teknik ekiplerle konuşabilmenin, API'lerden database'lere jargonu çözmenin ve teknik kararların mantığını anlamanın sistematik yolu.

Tasarım Eğitimleri

15 Eylül - 8 Ekim - Baştan Sona Uygulamalı Figma Eğitimi - Digital Product Designer Ramazan Güler ile Figma'da ustalaşın! Sıfırdan ileri seviyeye, component'lerden auto-layout'a, prototype'lardan developer handoff'a kadar her şeyi pratikte öğreniyoruz.

15 Eylül - 8 Ekim - Yapay Zeka Destekli UX Araştırma Eğitimi - UX Researcher İlayda Sena Topçu ve Mustafa Terzioğlu ile AI ile araştırma süper gücü! Kullanıcı görüşmelerinden anket analizine, persona oluşturmadan insight çıkarmaya yapay zeka destekli UX araştırma yöntemlerini öğreniyoruz.

15 Eylül - 27 Ekim - Advanced UX Eğitimi - Senior UX Designer Burç Taluğ ile UX uzmanlığında bir sonraki seviye! Temel bilgilerin ötesine geçip karmaşık tasarım problemlerine ileri seviye çözümler üretmeyi, araştırma yöntemlerini derinlemesine uygulamayı öğreniyoruz.

Sektörün en deneyimli isimleriyle, teoriden sıkılmadan pratik odaklı öğrenme garantisi!

👋 Tasarım ve ürün dünyasında gelişme bitmez. Ancak bu haftalık bizden bu kadar diyelim! İki hafta sonra yeni sayıyla gelene kadar okuyun, paylaşın ve kendinize iyi bakın!