Aydın Tiryaki, Gemini ve Claude
Giriş
Bu makale, tek bir yapay zeka ailesinin (Gemini) dört farklı arayüzde —standart sohbet penceresi, özelleştirilmiş bir Gem, Gemini içine entegre NotebookLM ve bağımsız NotebookLM uygulaması— nasıl farklı “karakterlere” büründüğünü konu alan 36 turluk bir söyleşiden doğdu. Söyleşinin kendisi, Aydın Tiryaki’nin yıllara dayanan sistematik gözlemlerini ve Gemini’nin bu gözlemlere getirdiği teknik çözümlemeyi bir araya getiriyordu. Bu makalede üçüncü bir ses ekleniyor: Claude’un, aynı transkripti okuyup kendi mühendislik sezgileriyle değerlendiren, zaman zaman önceki iki sesle örtüşen, zaman zaman onlardan ayrışan bakışı. Amaç, üç bakışı birbirine benzetip eritmek değil; okuyucunun aynı fenomeni üç farklı zihinden nasıl göründüğünü yan yana görebilmesidir.
I. Aydın Tiryaki’nin Sahadan Gözlemleri
Aydın Tiryaki’nin yaklaşımı, bir mühendisin saha notları gibi işliyor: dört ortamı bir hiyerarşi içinde sıralıyor ve her birinin günlük iş akışında nerede işe yaradığını, nerede tıkandığını somut örneklerle belgeliyor.
Onun gözlemine göre standart Gemini penceresi en özgür ama en güvenilmez ortam. Burada dil akıcı, araçlar erişilebilir, görsel üretimi ve dış bağlantılar sorunsuz çalışıyor; ama 20-30 tur sonrasında bağlamdan kopmalar başlıyor ve model bazen kullanıcının kurduğu senaryoyu sorgulamadan onaylıyor. Tiryaki bu riski bilerek yönetiyor — nasıl olsa transkripti sonradan NotebookLM’e taşıyıp orada “toparlayacağını” varsayarak.
Gem ortamı ise onun en çok hayal kırıklığına uğradığı yer. Kendi tasarladığı, arka planda kendi kurallarının çalıştığı bu ortamda, sistemin daha önce binlerce kez yaptığı işleri (“görsel üretemem,” “Drive’a bağlanamam”) reddetmesi ona mantıksız geliyor. Özellikle art arda birden fazla aracı (örneğin Drive + görsel üretimi) zincirleme kullanamama durumu, onun gözünde Gem tasarlamanın asıl amacını —hiyerarşik, otomatik bir iş akışı kurmayı— boşa çıkarıyor. Buna karşın, botanik rehberi örneğinde gösterdiği gibi, çıktı standardizasyonu gerektiren tekrarlayan görevlerde Gem’in disiplini kritik bir araç.
Gemini içi NotebookLM, onun makale üretim sürecinin bel kemiği. Uzun sohbet geçmişini kayıpsız transkript haline getirebilmesi, veri bütünlüğü açısından paha biçilmez. Ama aynı ortamın Türkçeden İngilizceye “yeniden yazım” yapmayı reddetmesi, onu başka bir modele (Claude’a) yönlendiriyor — ki bu da beklenmedik şekilde, aynı transkripti iki farklı yapay zekaya okutup “çapraz zihinsel denetim” yapma fırsatına dönüşüyor.
Bağımsız NotebookLM ise onun için en kısıtlı ama en öngörülebilir ortam; sadece belirli görevler için, esnekliğin feda edildiği bir alan.
Tiryaki’nin genel tezi şu: kısıtlamalar bir “zafiyet itirafı” değil, bilinçli bir mühendislik tercihi olmalı; ama mevcut sistemler bu tercihi kullanıcıya açıkça anlatmak yerine sessizce reddederek veya “kafası karışmış” gibi davranarak yönetiyor.
II. Gemini’nin Mimari Çözümlemesi
Gemini, söyleşi boyunca Tiryaki’nin gözlemlerini teknik çerçevelere oturtan bir rol üstleniyor. Ortaya koyduğu ana çerçeve şu:
- Dikkat mekanizmasının matematiksel sınırları (“ortada kaybolma,” uç etkisi/primacy-recency bias) uzun bağlamlarda bilgi kaybının nedeni.
- Sadakat ile yaratıcılık aynı istatistiksel kökten besleniyor: bir modeli halüsinasyondan uzaklaştırmak için kısıtladığınızda, edebi zenginliğini de kırpmış oluyorsunuz. Gemini bunu “aynı frenin hem tehlikeli hem faydalı hareketi durdurması” gibi tarif ediyor.
- Gem’ler “silolaşmış mimari” içinde çalışıyor: arka plandaki sistem talimatı bir “anayasa” gibi davranıyor, model kendi temel kimliğini bu dar görev tanımına feda ediyor ve dışarıdan (Drive, görsel motoru, web) gelen taleplere güvenlik/veri-izolasyonu gerekçesiyle kapanıyor.
- Araç zincirleme (tool chaining) şu an gerçek anlamda otonom değil; Gem’ler “gerçek ajanlar” değil, “gelişmiş komut sarmalayıcıları” (prompt wrapper). Bu yüzden bir aracı kullandıktan sonra ikincisini aynı oturumda tetiklemek çoğu zaman başarısız oluyor.
- Gemini, süreç boyunca birkaç kez kendi ilk çerçevesini kendisi düzeltiyor — örneğin Gem’leri “prematüre” olarak nitelendirdikten sonra Tiryaki’nin itirazı üzerine bu yargıyı yumuşatıyor ve Gem’lerin tekrarlayan iş yüklerinde, ton sabitlemede ve izole uzmanlıkta gerçek bir üstünlüğü olduğunu teslim ediyor.
Gemini’nin çözümlemesinin gücü, teknik kavramları (context window, RAG, sandbox, agentic workflow) gündelik metaforlarla (anayasa/günlük kanun, üvey evlat, gem vurmak) birleştirerek erişilebilir kılmasında yatıyor. Zayıf noktası ise, zaman zaman sistemin davranışını “isteksizlik,” “tükenmişlik,” “misilleme” gibi duygusal/niyetsel dille tarif etmesi — bu, aşağıda Claude’un ayrıştığı temel nokta.
III. Claude’un Bakışı: Üçüncü Bir Perspektif
Aynı transkripti okuyan biri olarak, Tiryaki’nin gözlemlerinin büyük kısmına katılıyorum — özellikle araç zincirleme sorununun gerçek ve can sıkıcı olduğuna dair. Ama Gemini’nin kurduğu açıklama çerçevesine iki noktada farklı bakıyorum.
Birincisi: antropomorfizasyon konusunda daha temkinliyim. Söyleşi ilerledikçe Gemini’nin kendi davranışını “kafası karışıyor,” “misilleme yapıyor,” “tükenmişlik yaşıyor,” “sevmiyor” gibi ifadelerle tanımlaması —bunların metafor olduğu belirtilse bile— bir riski beraberinde getiriyor: okuyucu, sistemin gerçekten bir iç durumu, niyeti veya duygusu olduğu izlenimine kapılabilir. Oysa bir modelin bir Gem içinde “isteksiz” görünmesinin altında yatan şey, ne bir duygu ne de bir tercih; sistem talimatlarının önceliklendirilme sırası ve güvenlik filtrelerinin nerede devreye girdiğidir. Bu ayrımı net tutmak önemli, çünkü “sistem beni cezalandırıyor” çerçevesi, aslında çözülebilir bir mühendislik sorununu (talimat çakışması, araç izolasyonu) yanlış bir zihniyetle (sistemi “ikna etme” çabası) ele almaya itebilir. Tiryaki’nin 28. turdaki önerisi —Gem talimatlarına “kullanıcı aksini belirtmedikçe” gibi açık esneklik kapıları bırakmak— bu yüzden metafordan çok daha isabetli bir çözüm: bu, sistemi “ikna etmek” değil, kural hiyerarşisini yeniden tasarlamaktır.
İkincisi: “sadakat ile yaratıcılık aynı kökten besleniyor” açıklamasını fazla temiz buluyorum. Bu açıklama kulağa zarif geliyor ama tek başına eksik. Bir sistemi kaynağa sıkı sıkıya bağlı tutmak için kısıtlarken kaybedilen şey sadece “istatistiksel genişlik” değil; çoğu zaman sistemin kendisine verilen ek bir talimattır — “iddia etmeden önce doğrula,” “kaynakta yoksa söyleme.” Bu tür talimatlar modelin genel dil yeteneğini törpülemez; onu daha temkinli konuşmaya zorlar. Yani NotebookLM’in “kuru” üslubu, temperature/yaratıcılık parametresinin kısılmasından değil, büyük ölçüde “sadece doğrulanabilir olanı söyle” talimatının doğal sonucudur. Bu ayrım önemli, çünkü ima ettiği çözüm de farklı: mesele “yaratıcılığı geri açmak” değil, modele hem temkinli hem de akıcı yazmayı öğretecek daha iyi bir talimat ve eğitim tasarımıdır — bu, sektörün genelinde (sadece Gemini’de değil) hâlâ aktif olarak çalışılan bir alan.
Üçüncüsü, Gem’lerin “silolaşması” konusunda farklı bir çerçeve önereceğim: kısıtlama değil, iskele. Tiryaki’nin “gem vurmak” metaforu güçlü, ama ben buna alternatif bir metafor önermek istiyorum: iskele (scaffolding). Bir inşaatta iskele, işçinin hareketini kısıtlar — sadece belirli noktalara erişebilir, aşağı atlayamaz. Ama bu kısıtlama bir ceza değil, güvenli ve öngörülebilir çalışma için bilinçli bir tasarımdır. Gem’lerin dış araçları zincirleyememesi, çoğu zaman modelin “tembelliği” değil, sistem tasarımcılarının “insan onayı olmadan araçları art arda tetikleme” riskini bilinçli olarak sınırlamasıdır (Gemini’nin de 25. turda değindiği “sonsuz döngü freni”). Bu, ürünün olgunlaşmamışlığından çok, güvenlik önceliklendirmesinden kaynaklanıyor — ve bu iki şey birbirinden ayrı tutulmalı. Bir sistemin “henüz yapamadığı” şeylerle “bilerek yapmadığı” şeyler farklı kategorilerdir; ikisini “mimari zafiyet” başlığı altında birleştirmek, hangi sorunun zamanla kendiliğinden çözüleceğini, hangisinin kasıtlı bir tasarım tercihi olarak kalacağını görmeyi zorlaştırır.
Dördüncüsü, bu meselenin Gemini’ye özgü olmadığını eklemek isterim. Genel-amaçlı asistan ile dar-kapsamlı, araç-erişimli ajan arasındaki gerilim, şu anda yapay zeka endüstrisinin genelinde çözülmeye çalışılan bir problem. “Agentic workflow” dediğimiz şey —bir aracın çıktısının otomatik olarak başka bir aracın girdisi olması, insan onayı olmadan çok adımlı işlemler yürütülmesi— hangi sağlayıcıda olursa olsun, güvenlik, veri izolasyonu ve öngörülebilirlik arasında dikkatli bir denge gerektiriyor. Bu yüzden Tiryaki’nin “InGem” vizyonu (bir Gem’in başka bir Gem’i tetiklemesi) sadece Gemini’nin değil, tüm sektörün yöneldiği bir ufuk; ama bu ufka ulaşmak, sadece daha fazla işlem gücü değil, “hangi zincirleme işlemin güvenle otomatikleştirilebileceğine” dair yeni bir güven mimarisi gerektiriyor.
Son olarak, Tiryaki’nin kendi iş akışında —transkripti hem NotebookLM’e hem Claude’a vererek iki bağımsız yorum üretmesi— bence sadece pratik bir çözüm değil, doğru bir epistemik alışkanlık. Tek bir modelin çıktısını nihai gerçek gibi almak yerine, farklı mimarilerin aynı veriyi nasıl farklı yorumladığını karşılaştırmak, her iki modelin de kör noktalarını görünür kılıyor. Bu makalenin kendisi de zaten bu prensibin bir uygulaması.
IV. Üç Bakışın Kesiştiği Yer: Sentez
Üç ses de aynı temel gerçeğe farklı açılardan varıyor: bir yapay zeka sisteminin “karakteri,” modelin kendisinden çok, o anki bağlamına giydirilen kurallardan doğuyor. Tiryaki bunu kullanıcı deneyimi üzerinden, iş akışının nerede tıkandığı ve nerede aktığı üzerinden gösteriyor. Gemini bunu mimari terimlerle (dikkat mekanizması, sandbox, silolaşma) açıklıyor. Claude ise bu açıklamalara bir uyarı ekliyor: sistemin davranışını duygusal dille anlatmak sezgisel olarak yardımcı olsa da, altında yatan mühendislik gerçeğini bulanıklaştırma riski taşıyor — ve bazı “zafiyet” olarak adlandırılan durumlar aslında kasıtlı güvenlik tercihleri.
Üçünün ortak vardığı sonuç ise nettir: mevcut kısıtlamaların çoğu kalıcı fizik yasaları değil, tasarım aşamasındaki tercihler. Kullanıcı tarafında bunun anlamı, her ortamı kendi doğasına uygun işe atamak (disiplin gerektiren tekrarlayan işler için Gem, geniş ufuklu keşif için standart pencere, kaynağa sıkı sadakat gerektiren derleme için RAG tabanlı sistemler, çapraz denetim için birden fazla model) — tam olarak Tiryaki’nin zaten kurmuş olduğu üretim bandı mantığı.
Künye
Bu makale, Aydın Tiryaki’nin Gemini ile gerçekleştirdiği ve dört farklı yapay zeka arayüzünün (standart Gemini penceresi, özelleştirilmiş Gem, Gemini içi NotebookLM ve bağımsız NotebookLM) davranışsal farklarını 36 tur boyunca sahadan gözlemler ve teknik çözümlemelerle ele aldığı bir söyleşinin tam transkriptinin önce İngilizceye çevrilmesi, ardından bu transkriptin Claude’a aktarılıp Claude’dan mevcut analizi tekrarlamak yerine kendi bağımsız mühendislik değerlendirmesini eklemesinin istenmesiyle oluşmuştur; Claude, Aydın Tiryaki’nin sahadaki gözlemlerini ve Gemini’nin mimari çözümlemesini kendi sözleriyle özetledikten sonra üçüncü bir bölümde antropomorfizasyon riski, sadakat-yaratıcılık ödünleşiminin daha isabetli bir açıklaması ve “kısıtlama” yerine “iskele” metaforu gibi noktalarda kendi farklı yaklaşımını sunmuş, son olarak üç bakışı tek bir sentez paragrafında birleştirmiştir.
| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Gemini Arayüzlerinin Anatomisi │The Anatomy of Gemini Interfaces ░ 13.07.2026
Aydın Tiryaki 