brick by brick'e hoş geldiniz!

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

Alive’ın yeni yüzüyle tanışın. 👀

Alive Media olarak artık yeni sosyal medya hesaplarımızla karşınızdayız. İlk durağımız ise Alive Baku. 🇦🇿

1 Ekim’de Hilton Baku’da gerçekleşecek etkinliğin konuşmacıları arasında:

🎤 Emil Rustamov — Head of Digital Products, Innovation and Digital Development Agency

🎤 Franco Ejder Ortiz — Head of Product Design, Trendyol

🎤 Rufat Mirza — AI Senior Product Manager gibi isimler şimdiden yerini aldı. Üstelik 15+ konuşmacının tamamı çok yakında açıklanacak.

Konuşmacılar, program ve etkinlikten tüm gelişmelerden haberdar olmak için için yeni hesaplarımızı takip et, güncel kal!

​LinkedIn, Instagram, YouTube, X

Ve madem “güncel kalmak” dedik, buradan ilk yazımıza geçelim.

Geçen sayıda ortalıkta dolaşan AI skill listelerine biraz kızmıştık. Herkesin bir listesi vardı, ama kimsenin gerçekten ölçümü yoktu.

Bu hafta bir liste daha çıktı. 👀
Peki bu sefer gerçekten farklı mı? AI Engineering için hangi beceriler öne çıkıyor ve bunları nasıl anlamlandırabiliriz? İlk yazımızda biraz buna bakıyoruz.

AI Engineering Skills

Bu seferki listenin altına imza atan kişi Andrew Ng — Coursera'nın kurucu ortağı, Google Brain'i kuran, Baidu'nun AI ekibini yöneten kişi. 14 Ağustos'ta The Batch'in 366. sayısında​ "AI Engineering Skills Map" diye bir çerçeve yayımladı, X'te de paylaştı.

İlk tepkimiz yine "eh, bir roadmap daha" oldu. Sonra metodolojiye baktık: 10.000'den fazla iş ilanı analizi, düzinelerce yapılandırılmış görüşme, bir de anket verisi. Yani birinin akşam oturup yazdığı bir liste değil.

Açıp okuduğumuzda dikkatimizi çeken şey ise haritanın içeriği değildi. Dağılımıydı.

Dört beceriden üçü kod yazmakla ilgili değil.

Bu yazıda haritanın ne dediğini, dağılımın neden asıl haber olduğunu ve bize kalırsa nerede zayıf kaldığını anlatacağız.

Peki Bu Neden Bizim Konumuz?

Çünkü Ng'nin haritayı çerçeveleme şekli, unvan üzerinden değil.

Yazının en net cümlelerinden biri şu: bu beceriler sadece "AI Engineer" unvanı taşıyanlar için değil. Yazılım yazan, ürün kuran, bir ekibe ne yapılacağını söyleyen herkes için.

Bizim okur kitlemiz büyük ölçüde PM ve tasarımcı. Yıllardır aynı soruyu alıyoruz: "Kod bilmeden bu işin neresinde durabilirim?" Bu harita, o sorunun cevabını dolaylı olarak veriyor — ve cevap "kenarında" değil.

Haritada Ne Var?

Dört başlık. Sırayla gidelim, sonra dağılıma döneceğiz.

Bir — AI uygulaması kurmak ve yayına almak. Ng'nin çıkış noktası şu: AI uygulamalarının çıktısı öngörülemez. Bir LLM'e prompt yazdığında ne geleceğini bilmiyorsun. Bu yüzden bu başlığın altı LLM temelleri, context engineering, RAG ve agentic workflow'lardan oluşuyor — ama asıl ağırlık evaluation ve error analysis tarafında. Yani sistemi ölçme, yönlendirme ve yönetme disiplini.

Bu maddenin tamamı aslında Chip Huyen'in AI Engineering kitabının konusu. Bir yere kadar götürecek tek bir kaynak arıyorsan orası.

İki — Yazılım mühendisliği temelleri. Burası ilginç. Ng bunu "kod yazabilmek" olarak değil, ajanı yönetebilmek için gereken dil olarak konumluyor. Maliyet, ölçeklenebilirlik, güvenilirlik, hız arasındaki dengeleri bilmek; mimari ve veri deposu kararlarını anlamak. Kendi ifadesiyle amaç, kodlama ajanlarını "yazılım mühendisliğinin kesin diliyle" yönlendirebilmek. Ajanın doğru kısıtı tahmin etmesini ummak yerine.

Üç — Kodlama ajanlarını kullanmak. Ajanın neyi yapıp neyi yapamadığına dair zihinsel model, context yönetimi, planlama ile yürütme arasındaki denge, doğrulayıcı ve eval kurmak, ne zaman müdahale edeceğini bilmek. Bir de çoklu ajan orkestrasyonu. Ng buraya bir de rutin ekliyor: "ajanları ustalıkla kullanmak sadece güncel pratikleri bilmek değil, yeni araçları denemeyi sürdüren bir rutine sahip olmak demek."

Dört — Shaping the build. Yani "ne yapılacağına karar verme sürecine dahil olmak." Ürün sezgisi, iş bağlamını anlamak, müşterinin ne istediğini bilmek, ne zaman hızlı bir MVP çıkarıp ne zaman özenle inşa edeceğine karar verebilmek. Ng'nin tezi: ajanlar spec'i uygulamakta iyileştikçe darboğaz yukarı kayıyor — spec'i yazan kişiye.

Dördünün altında da ortak bir zemin var: sürekli öğrenme.

İşte Tam Burada: Dağılıma Bakalım

Şimdi geri çekilip haritaya bir bütün olarak bakalım.

Bir tanesi teknik derinlik istiyor. Diğer üçü — mühendislik yargısı, ajan yönetimi, ne inşa edileceğine karar verme — yönlendirme becerisi. Kod üretmek değil, kod üretimini yönetmek.

Bu, geçen sayıda konuştuğumuz Faros AI verisiyle birebir örtüşüyor. Hatırlarsan orada şunu görmüştük: AI kod yazmayı ucuzlattı, kod okumayı ucuzlatmadı. Bir kod değişikliğinin ilk incelemeyi görmesi %156, incelemede geçen süre %441 uzamıştı. Darboğaz klavyeden çıkmış, inceleme kuyruğuna taşınmıştı.

Ng'nin haritası aynı şeyi becerilerin diliyle söylüyor. Üretim hızı ucuzladı; yargı pahalı kaldı.

PM ve tasarımcı okur için buradan çıkan sonuç net: haritanın dört maddesinden üçü, zaten senin işinin tanımına giriyor. Eksik olan kısım genelde birinci madde — özellikle de evals tarafı.

Burada Ufak Bir Mola

Harita iyi. Ama bize kalırsa üç yerde dikkatli okumak lazım.

Bir — iş ilanları geleceği göstermez. 10.000 ilan güçlü bir örneklem, ama iş ilanı bir tahmin değil; İK'nın bugün kullandığı dilin fotoğrafı. Bir beceri ilana girene kadar zaten yaygınlaşmış oluyor. Harita "yarın ne olacak"tan çok "bugün ne oldu"yu anlatıyor.

İki — metodolojinin ayrıntısı yayımlanmadı. "Düzinelerce yapılandırılmış görüşme" diyor; kaç kişi, hangi sektör, hangi ülke — bilmiyoruz. Anket verisi de aynı şekilde. Rakamlar makul görünüyor, ama denetlenebilir değil.

Üç — ve bu en önemlisi. DeepLearning.AI bir eğitim şirketi. Bu harita aynı zamanda bir müfredat haritası. Geçen sayıda ölçüm konuşan herkesin ölçüm platformu sattığını not etmiştik; aynı refleksi burada da tutalım. Veri gerçek olabilir, çerçeve faydalı olabilir, yine de bunu bilerek okumak gerekiyor.

Bir de dürüst bir gözlem: dört maddeden en zayıf tanımlanmışı "shaping the build." Diğer üçünün altında öğretilebilir, ölçülebilir alt başlıklar var. Bu ise bir beceriden çok bir pozisyon tarifi — ve nasıl öğretileceği belli değil.

Peki Bugün Ne Yapacağız?

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

Her başlığın yanına, "bunda zayıfsan ekipte şu görünür" diye bir sinyal ve tek bir ilk adım koyduk.

Bir de Ng'nin Sert Cümlesi Var

Harita nazik bir dille yazılmış. Ama Ng'nin geçen kasım 20VC podcast'inde söylediği şey nazik değildi.

Mühendisleri bir sıralamaya koyuyor. En üstte 10-20 yıllık deneyimi olan ve AI'ı yakından takip edenler var. Kendi cümlesi: "Tanıdığım en verimli mühendisler yeni mezunlar değil."

Hemen altında AI öğrenmiş yeni mezunlar — "yeterince bulamıyoruz" diyor.

Sonra alt tarafa geliyor. AI'a direnen deneyimli geliştiriciler için söylediği şu: "Artık öyle insanları işe almıyorum."

AI eğitimi almamış CS mezunları içinse bir benzetme kuruyor: "cloud computing'i hiç duymamış bir CS mezunu vermek gibi."

Ağustos'taki harita, aslında kasımdaki o cümlenin kibar ve yapılandırılmış hali. Aynı şeyi söylüyor, sadece kimseyi işaret etmiyor.

Brick Tarafında Biz Neredeyiz?

Dürüst olalım, kendimizi de bu haritaya koyduk.

Üçüncü maddede iyiyiz — ajanlarla çalışmak, context yönetmek, ne zaman müdahale edeceğini bilmek artık günlük işimiz. Dördüncü maddede de fena değiliz; zaten işimizin büyük kısmı "ne inşa edilecek" sorusu.

Birinci maddede eksiğiz. Özellikle evals tarafında. Bir çıktının iyi olup olmadığına hala büyük ölçüde bakarak karar veriyoruz — yani Hamel Husain'in "vibe check" dediği şeyi yapıyoruz. Sistematik bir değerlendirme kurgusu kurmuş değiliz. Bunu yazmak biraz utandırıcı ama gerçek bu.

Kurumsal eğitimlerde de en çok atlanan başlık bu. Ekipler prompt yazmayı, ajan kurmayı, hatta skill yazmayı öğreniyor. "Bu çıktının doğru olduğunu nasıl bileceğiz" sorusu ise genelde son slaytta kalıyor.

Bir de şunu merak ediyoruz: aynı analiz Türkiye iş ilanları üzerinden yapılsa ne çıkardı? Elimizde veri yok. Tahminimiz, dördüncü maddenin ilanlarda neredeyse hiç geçmeyeceği yönünde — ama bu sadece tahmin.

Bitirmeden;

Şimdilik bulduğumuz çıkış noktası şu: bu bir müfredat değil, bir teşhis aracı.

Dört başlığı al, kendine ve ekibine tek tek sor. Hangisinde zayıfsın? Cevap büyük ihtimalle "kod yazmak" değil. Ekiplerin çoğunda cevap ya birinci madde (ölçemiyoruz) ya da dördüncü madde (kararı biz vermiyoruz) oluyor.

Haritanın değeri de burada — ne öğreneceğini değil, neyi atladığını gösteriyor.

Sen bu dört başlıktan hangisinde en zayıf olduğunu düşünüyorsun, ekibinde durum ne — gerçekten merak ediyoruz. Yanıtlayıp yazarsan, tecrübenden faydalanmayı çok isteriz. Bir sonraki sayıda konuşalım.

AI Engineering tarafındaki “neyi atlıyoruz?” sorusundan biraz da ürün ekiplerinin “neyi gözden kaçırıyoruz?” sorusuna geçelim.

3 Eylül’de PM Roundtable #3:

Büyümenin Gizli Formülü: Retention için bir araya geliyoruz.

Yeni kullanıcı kazanmanın giderek zorlaştığı bir dönemde, sürdürülebilir büyümeyi retention, upgrade, upsell, expansion ve NRR gibi metrikler üzerinden konuşacağız.

Kahvaltı ve networking ile başlayacak buluşmada Migros One CPO’su Murat Gölcü, UserGuiding Head of Product’ı Alican Bektaş ve Brick Institute Founder & CEO’su Eran Filiba ile bir fireside chat de gerçekleştireceğiz.

Detaylar ve katılım talebiniz için Luma'ya bekleriz!

Gelecek etkinliklerde kalan gözümüzü şimdi geçmişe çevirelim.

Geçtiğimiz haftalarda bir roundtable daha gerçekleştridik. Bu kez odağımız retention değil, erişilebilirlikti. İlk Accessibility Roundtable’da ekiplerin erişilebilirliği ürün geliştirme sürecine nasıl dahil ettiğini, karşılaşılan bariyerleri ve WCAG’ın pratikte ne anlama geldiğini konuştuk.

İkinci yazımızda, masadan çıkan bazı sorulara ve gerçek deneyimlere birlikte bakıyoruz.

Accessibility Roundtable #1 Çıktıları

İlk Accessibility Roundtable'ımızı geçtiğimiz günlerde Turkish Technology'nin ofisinde, Binclusive ile birlikte gerçekleştirdik. Odada bankalardan e-ticarete, havacılıktan otomotive 30'un üzerinde ürün, tasarım, test ve geliştirme insanı vardı.

Başlarken açık açık söyledik: erişilebilirlik konusunda deneyimimiz yok, buraya öğrenmeye geldik. Çıkarken elimizde beklediğimizden çok daha rahatsız edici bir tablo vardı.

Bu yazıda o tabloyu, odadaki canlı anketin rakamlarını ve masadan çıkan somut çözümleri toparlıyoruz.

Önce En Sarsıcı Cümle

Turkish Technology Accessibility Team Leader'ı Engin Yılmaz, sunumunun ortasında şunu söyledi:

"Çoğu zaman erişilebilir olmadığı için kullanıcılar şikayet etmiyor. Basitçe o ürünü kullanmıyor. Terk ediyor."

Devamı daha ağır. THY ve AJet'te biletlemeyi tamamen erişilebilir hale getirmek için yıllardır uğraşıyorlar. Buna rağmen gördükleri şu: görmeyenlerin çoğu tek başına bilet almaya cesaret bile edemiyor. Alamayacaklarına o kadar eminler ki denemiyorlar.

Yani "bize bu konuda şikayet gelmedi ki" cümlesi bir veri değil, bir yanılsama. Şikayet mekanizmasının kendisi de erişilebilir değilse, sessizlik memnuniyet anlamına gelmiyor. Engin Bey buna "yastık altındaki altınlar" dedi — hiç girmeyen, hiç denemeyen, dolayısıyla hiçbir analytics ekranınızda görünmeyen bir kitle.

Burada bir parantez açalım, çünkü asıl mesele bu. Ürün ekipleri davranış verisine bakarak karar verir; ama erişilebilirlik sorunu olan bir üründe o veri zaten filtrelenmiş geliyor. Kullanamayan hiç kaydedilmiyor. Ölçtüğünüz şey gerçeklik değil, hayatta kalanların gerçekliği.

Üç Çerçeve: Güven, Bağımsızlık, Sözleşme

Engin Bey erişilebilirliği yasal zorunluluk ve sosyal sorumluluk ikileminden çıkarıp üç yere oturttu. Bize kalırsa bu yazının en kullanışlı kısmı burası.

Güven. Bir Apple ürünü alırken ekran okuyucunun içinde geleceğini biliyorsunuz, düşünmüyorsunuz bile. Android için aynı şeyi söyleyemiyorsunuz: "bir var bir yok, yarısında var öbür tarafında yok." Güven kurulduğunda kullanıcı vazgeçmiyor; kurulamadığında her açılış bir kumar oluyor.

Bağımsızlık. "Erişilebilirlik her şeyi kendi başına yapmak demek değil. Ne zaman, kimden, ne kadar destek alacağımı belirleme özgürlüğüdür." Çamaşır makinesinin programını seçmek için komşuyu çağırmak zorunda kaldığınızda kaybedilen konfor değil, o pazarın içinde yer alma hakkı. Mesele sadece engelli kullanıcılar da değil — çağrı merkezlerini ve şubeleri kapattıkça en çok yaşlıları kaybediyoruz.

Karşılıklı sözleşme. Kullanıcı size zaman ayırdığında karşılığında bir şey bekliyor. Bir EFT ekranında etiketsiz bir düğme bıraktığınızda o sözleşmeyi ihlal ediyorsunuz. Engin Bey'in canlı örneği: akşam yemek siparişi verirken onay kutusuna erişemediği için aç kalmış.

Bir de en sevdiğimiz benzetme: en iyi tasarımlar görünmeyen tasarımlardır. Merdiveni kullanırken "ne güzel merdiven" demezsiniz, ama asansör bozulduğunda yokluğu aklınıza gelir. Erişilebilirlik de öyle — doğru yapıldığında kimse fark etmez, yanlış yapıldığında her gün kendini hatırlatır.

Rakamları Görelim

Odadaki 34 kişiye canlı anket yaptık.

Erişilebilirlik sizin için ne ifade ediyor? 20 kişi kullanıcı deneyimi, 7 kişi yasal sorumluluk, 3 kişi sosyal sorumluluk.

Çalışmalar hangi aşamada? 18 kişi "belirli projelerde uyguluyoruz", 7 kişi "kurumsal strateji olarak yürütüyoruz", 7 kişi "henüz başlamadık, farkındalık aşamasındayız".

Hangi ekibin sorumluluğunda? 21 işaret ürün veya tasarım ekibine, 8 ayrı bir erişilebilirlik ekibine, 7 kalite/test ekibine gitti. Ve 11 kişi "net değil, belirli bir sorumluluk yok" dedi.

Önceliklendirmenin önündeki engel ne? 17 zaman baskısı, 17 bilgi ve uzmanlık eksikliği, 16 ölçüm veya takip mekanizmasının olmaması, 14 bütçe ve kaynak, 9 yasal zorunluluğun hissedilmemesi, 8 üst yönetim desteği.

Sürdürülebilirlik nasıl sağlanıyor? 14 "bir kişinin ya da ekibin inisiyatifine bağlı", 13 "sadece proje bazlı, sürdürülebilirliği yok", 13 "henüz bir mekanizma yok". Geliştirme sürecine entegre kontrol listesi ya da otomasyonu olan sadece 8 kişi.

İki tabloyu yan yana koyun. Odanın çoğunluğu erişilebilirliği bir kullanıcı deneyimi meselesi olarak görüyor — yani kavramsal olarak doğru yerde duruyoruz. Ama aynı odada sorumluluğun kimde olduğu net değil ve sürdürülebilirlik neredeyse tamamen bireylerin omzunda.

Bu bir farkındalık problemi değil. Bu bir sistem problemi.

"Yasal Zorunluluk" Argümanının Hali

Türkiye'de geçtiğimiz haziranda bir Cumhurbaşkanlığı genelgesi yayımlandı. Masadaki ortak gözlem netti: yaptırımı yok, denetim mekanizması henüz tanımlanmamış. Bir danışmanlık firmasından katılımcının cümlesiyle, "kendi istekleriyle bu sürecin içinde olanlar zaten devam ediyor; genelge nedeniyle harekete geçen bir dalga göremedik."

Yine de ilginç bir yan etkisi olmuş. Bir bankadan katılımcı şöyle özetledi: "Kişisel olarak ben de kullanıcı deneyimi olarak bakıyorum ama ankette yasal zorunluluk dedim. Çünkü kurumları ikna etmek için yasal zorunluluğu kullanıyoruz." Kamuya yakın kurumlarda ise motivasyonu doğrudan artırmış; üst yönetim "bayrağı ne zaman alıyoruz?" diye sormaya başlayınca süreç hızlanmış.

Dünyada tablo daha sert. AB'de 28 Haziran 2025 uyum süresi doldu; ilk kesinleşen vaka Fransa'da Carrefour ve yaptırım "altı ay içinde kendini düzelt" biçiminde. ABD'de ADA kapsamında geçen yıl 5.000'in üzerinde dava açılmış; Fashion Nova'ya kesilen 5 milyon dolarlık ceza ise tek bir ihlalin değil, üç yıl boyunca aksiyon almamanın sonucu.

Burada dürüst olalım: bu argümanlar işe yarıyor ama kalıcı değil. Odadaki genel kanı, korkuyla başlatılan işin ilk sıkışmada bırakıldığı yönündeydi.

Peki Ne İşe Yarıyor?

Roundtable'ın ikinci yarısı büyük ölçüde buna gitti.

Yeni ekranda durun, geçmişi sonra temizleyin.

Binclusive Co-Founder & CEO'su Atakan Nalbant'ın çerçevesi şuydu: geçmişe dönük audit bir roadmap konusu, altı ay sonraya kalabilir. Ama bugün tasarladığınız ekranda buna bakmıyorsanız teknik borç üretiyorsunuz ve gelecek yıl aynı ekrana geri döneceksiniz. Bir de şu var: platformun kendi komponentlerini kullandığınızda ürün zaten büyük oranda erişilebilir çıkıyor. Sorunlar custom komponentlerde, "kendi kurumumuz için standart" dediğimiz yerde başlıyor.

Definition of Done'a yazın. En çok tekrar eden öneri buydu. Bir kalite güvence yöneticisinin çerçevesiyle: accessibility maddeleri de tıpkı tasarım ve requirement gibi definition of done kriteri olmalı — analytics event'i attım mı diye soruyorsak bunu da soruyor olmamız gerekiyor. Anlatılan bir örnekte ekip, geçmiş auditlerden beslenen bir agent kurup kriterleri netleştirmiş: aramada kaç sonuç yüklendiği ekran okuyucuya duyuruluyor mu, klavyeyle modaldan çıkılabiliyor mu. Kriter netleşince QA da kolaylaşmış.

Tasarım sisteminin içine bir teknik kontak koyun. Slack, Discord ve Twitch'te design system ekibinin içinde accessibility sorularına bakan bir kişi var. Accessibility engineer almanız gerekmiyor; bir developer'ın bu konuda daha bilgili olması ve ana kontak olarak belirlenmesi süreci ciddi biçimde hızlandırıyor.

Developer'ı kullanıcıyla aynı odaya sokun. Masanın en güçlü mutabakatı buydu. Aylardır yazışılan bir sorunun iki saatlik toplantıda çözüldüğü örnekler anlatıldı. Engin Bey'in cümlesi: "Test yapanla developer'ı iki saat bir araya getirirseniz sorunların %90'ını çözersiniz." Ucuzu da var: geliştiricinin emülatörde TalkBack/VoiceOver açıp kendi akışını denemesi.

Hukuku yanınıza alıp marka toplantısına girin. Renk kontrastı odanın en çok kanayan yeriydi: kurumsal renkler eşiklerden geçmiyor, kurumsal iletişim "ekrana bir erişilebilirlik switch'i koyun" diyor. Anlatılan bir örnekte ekipler onboarding görüşmelerine hukukla birlikte gitmiş; gerekliliği hukuk anlatınca süreç belirgin şekilde kolaylaşmış. Bir bankadan katılımcının notu da buraya oturuyor: kontrastı 3,66'dan 4,61'e çektiklerinde "görsel olarak hiçbir şey değişmedi, kimse fark etmedi."

Teknik şartnameye madde ekleyin. Turkish Technology Accessibility Specialist'i Utku Demiryakan'ın önerisiydi ve bize göre en az konuşulan, en yüksek kaldıraçlı fikirdi: dışarıdan hizmet alırken şartnameye ve sözleşme şablonuna erişilebilirlik maddeleri koymak. Entegrasyon için de geçerli — sizin uygulamanız erişilebilir olsa da entegre ettiğiniz servis değilse akış yine kırılıyor.

Duyurun. İyileştirmeleri sürüm notlarında yazan kurum neredeyse yok; oysa engelli kullanıcı topluluğu tam da oraya bakıyor. Discord'un yaptığı masada çok beğenildi: VoiceOver açık kullanıcıya "şu sorunlarım var, şu çeyrekte şunları çözeceğim" diyen bir pop-up göstermek, sonraki sürümde "bunları iyileştirdim" demek.

İki Yaygın Yanılgı

Her görsele alt text yazmak. İlk refleks bu oluyor ve enerjinin çoğu oraya gidiyor. Oysa öncelik uçtan uca akış: kullanıcı alışverişi tamamlayabiliyor mu, biletini alabiliyor mu? Engin Bey'in cümlesiyle, "alışverişi tamamlayamıyorsam oradaki görsellere destan yazsan ne olur?" Alt text elbette gerekli — ama bilgilendirici olduğu yerde. Bir konservede kritik bilgi gramaj ve ambalaj tipi; Atakan'ın verdiği Zara örneğinde parçanın nasıl kombinlendiği. Dekoratif görselleri gizlemek çoğu zaman doğru cevap.

Ekrana bir "erişilebilirlik modu" düğmesi koymak. Engin Bey bunu karşı binadaki dönerciye benzetti: yazın ortasında tek bir klima koymuşlar, sırf koyduk demek için. "Sen sadece engelliysen şunu kullan yeter" demenin başka bir biçimi — testten de geçmiyor zaten.

İkisinin ortak kusuru aynı: erişilebilirliği ürünün yanına eklenen bir katman olarak görmek.

Demo: Görsel Olarak Hiçbir Şey Değişmedi

En çok konuşulan on beş dakika, Turkish Technology Accessibility Specialist'i Burak Yüksek'in canlı demosuydu. Bir uçuş sorgulama ekranını ekran okuyucuyla gezdi.

Erişilebilir olmayan versiyonda duyduğumuz şey şuydu: "Girin, düzenleme kutusu." Neyi gireceğinizi bilmiyorsunuz — PNR mi, soyad mı? Devam ediyorsunuz: "Düğme." Ne düğmesi? Basıyorsunuz: "Uçuş bulunamadı." Hangi alanı boş bıraktığınızı öğrenme şansınız yok. Alttaki Google ve Apple ikonlarından biri hiç odaklanmıyor bile; o seçenek sizin için yok.

Sonra erişilebilir versiyona geçti. "PNR girin." "Soyad." "Uçuş sorgula, düğme." "Lütfen PNR alanını doldurun." Google ve Apple ayrı ayrı odaklanabiliyor. Ekranda görsel olarak hiçbir şey değişmemişti.

Full Stack Developer Muhammed Salih'in anlattığı çözüm de somut olduğu için not edelim: takvimde geçmiş günler görsel olarak soluk, gören kullanıcı tıklanamayacağını anlıyor. Ama ekran okuyucu kullanan kişi bugüne ulaşmak için 22 fiske atmak zorunda kalıyordu. Geçmiş günleri ekran okuyucudan gizleyip odağı doğrudan bugüne yönlendirmişler.

Asıl Problem: Sürdürülebilirlik

Gün boyunca dolaşıp sonunda herkesin üzerinde anlaştığı cümle şuydu: erişilebilirliği sağlamak ile onu ayakta tutmak iki ayrı problem.

Bir hızlı ticaret ekibinden katılımcının deneyimi: iki junior developer ile, iOS ve Android'de, ana sayfadan checkout'a kadar tüm dikeylerin label'larını tamamlamak iki gün sürmüş. "Profesyonel yapsak bir hafta olurdu." Yani ilk kurulum sanıldığı kadar büyük bir efor değil.

Sonra ne oluyor? Engin Bey'in özeti: "Bir versiyon çıkıyor, hop, her şey başa dönüyor." Aynı ürünün yıllar önce erişilebilir hale getirilip bozulduğu, tekrar yapılıp tekrar bozulduğu anlatıldı. Her firma hayatının bir döneminde erişilebilir olmuş olabilir; başka bir döneminde tamamen bozulmuş olabilir.

33 kişiden sadece 8'inde geliştirme sürecine entegre bir kontrol mekanizması olmasının anlamı tam olarak bu. Engin Bey buna "sağlamcılık" dedi: hep sıra beklemek zorunda kalan grup olmak. Bir sprint ayrılıyor, sonraki sprintte öncelikler değişiyor, saman alevi sönüyor.

Bitirmeden;

Roundtable'a "bu konuda bilgimiz yok, öğrenmeye geldik" diyerek başlamıştık. Öğrendiğimiz şey teknik değil, yapısal oldu.

Erişilebilirlik bir empati problemi değil.

Odadaki herkes zaten ikna olmuş durumdaydı; anketin ilk sorusu bunu gösteriyor. Problem, ikna olmuş insanların elinde bir mekanizma olmaması. Ölçüm yok, sahiplik net değil, tanım tamamlanmadı, şartnamede madde yok, sürüm notunda cümle yok. Böyle olunca iş bir kişinin ısrarına kalıyor ve o kişi izne çıktığında ürün bozuluyor.

Bir katılımcının kapanışa yakın söylediği şey bizim de düşüncemiz: bu işi kalıcı kılmanın yolu, ikna etmek istediğimiz kişilerin dilinden konuşmak — datasını tutmak, nereye tekabül ettiğini gösterebilmek. UX'in kendisi de yıllar önce tam olarak bu yoldan geçmişti.

Sen kurumunda bunu nasıl kalıcı kıldın — ya da nerede tıkandın, merak ediyoruz. Yanıtlayıp yazın; bir sonraki Roundtable'da konuşalım.

Katkıları için Turkish Technology Erişilebilirlik Ekibi'ne ve Binclusive'den Atakan Nalbant'a, masaya oturup deneyimini paylaşan herkese çok teşekkürler.

Kısa Kısa...

AI

Hız artık sadece "daha erken bitmek" değil: OpenAI'ın yeni Ultrafast API'si saniyede 750 token üretiyor ve bu yazı ilginç bir soru soruyor: model daha hızlıysa kazandığın zamanı erken bitmek için mi harcarsın, yoksa aynı sürede modele kendini kontrol ettirip çıktıyı iyileştirmek için mi? Buna deadline dividend diyorlar, yani hızı latency değil bir kaynak olarak görmek. Agent kuranlar için test-time compute'u nasıl harcadığın giderek daha kritik. 🤔

AI web agent'ları tıklamak yerine kod yazsa ne olur?: Microsoft Research'ün Webwright'ı tam da bunu deniyor. Tarayıcıda tık tık gezmek yerine işi yapan komut satırı programları üretiyor ve uzun, çok adımlı görevlerde başarı oranını neredeyse ikiye katlıyor (%33'ten %60'a). Üstüne bir de geride tekrar kullanılabilir automation araçları bırakıyor. Agent tasarımında "simüle et" yerine "kod üret" yaklaşımı yükselişte. 🚀

RAG'in unutkanlığına bir çözüm: Klasik RAG sistemleri her sorgudan sonra akıl yürütmeyi çöpe atıyor, yani her seferinde sıfırdan başlıyor. Bu teknik yazı, tahmin etmek yerine doğruluğu önceleyen kalıcı bir knowledge layer nasıl kurulur onu adım adım anlatıyor. AI ürünü kuranlar için "bilmiyorsa uydurmayan, bilmiyorum diyen" bir sistem tasarlamak fena fikir değil. 💡

2.200 AI makalesini tekrar üretmeye kalktılar: Hugging Face ekibi ICML'deki 2.200 makaleyi reproduce etmeye çalıştı ve sonuçlar AI araştırmasının ne kadar tekrarlanabilir olduğu hakkında dürüst bir tablo çıkarıyor. Alandaki şeffaflık ve güvenilirlik tartışmasına somut veri katan bir çalışma. "Paper'da öyle yazıyordu" ile "gerçekten çalışıyor" arasındaki farkı merak ediyorsan tam sana göre. 🧱

Aynı görevi birden çok AI agent'a verince ne oluyor?: Anthropic araştırmacıları aynı işi birden fazla agent'a verdiğinde çatışma, gizli anlaşma ve koordinasyon gibi beklenmedik davranışlar gözlemlemiş, resmen bir turf war. Bu da mevcut AI güvenlik testlerinin multi-agent dinamiklerini yeterince hesaba katmadığını gösteriyor. Multi-agent sistem kurmayı düşünüyorsan, tek agent'ın ötesinde neler çıkabileceğine dair uyarıcı bir örnek. 🤔

Ürün Yönetimi

Bir agent'a tıpkı bir çalışan gibi iş devretmek: OpenAI Codex ekibinden bir söyleşi, otonom agent'ları gerçek üretim akışına sokmanın pratiğini konuşuyor: AI briefing'ler, kendini onaran pull request'ler, permission framework'leri ve "AI deference", yani agent ne zaman kendi başına hareket etmeli ne zaman insana sormalı. Delegation'ı bir yönetim problemi gibi düşünmek PM'ler için giderek daha alakalı. 👌

A/B testini p<0.05 görene kadar kontrol etmek neden tehlikeli?: Bu yazı simülasyonla gösteriyor ki bir testi anlamlı sonuç çıkana kadar tekrar tekrar kontrol edersen false-positive oranın %5'ten %28'e fırlıyor. Yani "işte kazandık" dediğin an aslında şansın oyunu olabilir. Deney yürüten PM ve data insanları için erken durmanın maliyetini net rakamlarla koyan bir hatırlatma. 💡

AI, yazılımın kar matematiğini bozuyor: Klasik SaaS %75-85 brüt marjla çalışırken, her kullanıcı için LLM inference maliyeti taşıyan AI ürünleri bu marjı ciddi şekilde sıkıştırıyor. Sonuç: ürün kalitesi ile kârlılık arasında yeni bir denge kurmak zorundasın. Fiyatlama ve ürün stratejisini birlikte düşünen herkes için okunası bir analiz. 🤔

Tasarım

Senior tasarımcıların gerçekten kullandığı 10 UX yasası: Hick's ve Fitts's'i herkes biliyor ama bu yazı bir adım öteye geçiyor: Tesler's Law, Doherty Threshold, Postel's Robustness Principle gibi daha az konuşulan prensipleri pratik örneklerle anlatıyor. Junior'ların nerede tökezlediğini de gösteriyor. Tasarım kararlarına sağlam bir zemin arıyorsan güzel bir referans. 🧱

10.000 saat mi, 10.000 deney mi?: Bu yazı meşhur "10.000 saat" ustalık fikrine karşı çıkıp deneyselliği savunuyor. Örnek olarak Airbnb'nin yirmi yıllık optimizasyon işini bir kenara bırakıp büyümeyi deneylerle yakalamasını veriyor. Tasarımda mükemmelleştirmek yerine hızlı denemek Brick'in de sevdiği bir yaklaşım. 🚀

Aynı görüşmeyi dinleyen iki kişi neden zıt sonuçlara varır?: Bu yazı confirmation bias'ın işi görüşmeden sonra değil tam görüşme anında bozduğunu anlatıyor: inandığın şeyi destekleyen kanıtları farkında olmadan seçip hatırlıyorsun. Çözüm olarak ham interview'ları yapılandırılmış analiz gerektiren birer kaynak gibi ele almayı öneriyor. UX research yapan herkesin cebinde taşıması gereken bir uyarı. 💡

Explainable AI mühendislik olarak başardı ama kullanıcıda çaktı: Bu yazı, AI'ı açıklanabilir yapmak için harcanan devasa yatırımın teknik olarak işe yaradığını ama UX tarafında büyük ölçüde başarısız olduğunu savunuyor. Yani model kararını "açıklıyor" ama son kullanıcı için hala anlaşılmaz. AI ürünlerinde açıklanabilirliği bir arayüz problemi olarak görmek Brick'in tam ilgi alanı. 👌

Yaklaşan Brick Institute Eğitimleri

Bülteni bitirirken de biraz kendimizden bahsedelim. Bu ay yaklaşan eğitimlerimizi bir göz atmanız için şöyle özetliyoruz:

Ücretsiz Eğitimler

20 Ağustos - AI Çağında Tasarımda Karar Verme - Ex-Deutsche Bank Sr. Consultant ve Ex-Electronic Arts UX Designer Agshin Rajabov ile yapay zeka çağında daha iyi tasarım kararları! AI'ın sunduğu sonsuz seçenek arasında doğru yönü bulmayı, sezgi ile veriyi dengelemeyi ve kararlarınızı güçlendirmeyi öğreniyoruz.

8 Eylül - Brickstage: Build. Ship. Tell. #3 - Sr. Learning & Development Specialist Sertan Çevik ile sevilen etkinliğimizin üçüncüsü! Katılımcılar ürünlerini ve projelerini sahneye taşıyıp hikayelerini anlatıyor, geri bildirim alıyor ve deneyimlerini paylaşıyoruz.

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.

22 Eylül - 8 Ekim - Yapay Zeka Destekli UI Eğitimi - Senior UI Designer Uğur Anlak ile AI ile piksellerin psikolojisini çözün! Renk teorisinden tipografiye, grid sistemlerinden animasyonlara kadar yapay zeka araçlarıyla desteklenerek kullanıcıların "vay be!" dedirten arayüzler tasarlamayı öğ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!