Alan uzmanlığı her zaman gerçek hendekti

• Yazılımın zor kısmı kod yazmaktan çok maaş bordrosu, ulaşım gibi gerçek dünya kurallarını anlayıp bir alan modeli kurmaktı; kod ise bu anlayışın ürünüydü
• Ajan tabanlı yapay zeka, alanı anlamadan da yazılım üretimini mümkün kılıyor ve darboğazı “yapılabilir mi”den “doğru olup olmadığına karar verilebilir mi”ye taşıyor
• Lojistik planlamacıları, klinik kodlayıcılar, sigorta aktüerleri gibi alan uzmanları kod bilmeden de çıktının hukuk, faturalama ve operasyon kurallarına uyup uymadığını ayırt edebilir
• Genel amaçlı mühendisler mimariyi ve güvenilirliği doğrulayabilir, ancak klinik kodlama gibi doğru cevabın alan bilgisine sıkı sıkıya bağlı olduğu yerlerde kulağa makul gelen hataları kaçırabilir
• En değerli yetkinlik, üretilen kodun sağlamlığını ve çıktının doğruluğunu birlikte doğrulayabilen muhakeme gücüdür; bu yüzden kıdemli mühendisler için alan uzmanlığına yatırım daha önemli hale geliyor

---

Yazılımın darboğazı implementasyondan doğrulamaya kayıyor

• Yazılım yazmanın zor kısmı kodu girmek değil, önce zihinde bir alan modeli kurmaktı
  • Bordro sistemlerinde hacizler, vergi öncesi kesintiler ve ücret değişikliği maaş döneminin ortasına geldiğinde bunun nasıl ele alınacağı yer alır
  • Ulaşım uygulamalarında GTFS akışları, trip ile route arasındaki fark ve bir otobüsün neden “zamanında” görünse bile yine de yanlış olabileceği yansıtılır
  • Kod, bu anlayışın aktarılmış haliydi; asıl iş ise bu anlayışı edinmekti
• Ajan tabanlı yapay zeka, alan bilgisi ile yazılım üretimi arasındaki bağı zayıflatıyor
  • Artık alan modelini bizzat kurmadan da yazılım üretmek mümkün
  • Yazılım mesleklerinin tamamının dayandığı varsayım sarsılıyor
• Geçen yılın bakış açısında olduğu gibi, bu araçların muhakeme gücü yüksek kıdemli geliştiricileri güçlendirdiği açıklaması doğru ama yeterli değil
  • Daha somut değişim, darboğazın “yapabilir miyiz”den “doğru olup olmadığına karar verebilir miyiz”e kaymış olması

Ajan tabanlı araçları iyi kullanan kişiler

• Alan uzmanları kod bilmeden de doğru cevabı ayırt edebilir

  • Lojistik planlamacıları, klinik kodlayıcılar, sigorta aktüerleri gibi kişiler stack trace okuyamayabilir ve hash map ile list arasındaki farkı açıklayamayabilir
  • Ama ajanın oluşturduğu bir planlamaya baktıklarında hangi sürücünün yasal olarak o vardiyada çalışamayacağını hemen anlayabilirler
  • Belirli kod kombinasyonlarıyla yapılan bir sigorta talebinin ödenmeyeceğini de görebilirler
  • Çünkü bu insanlar 10 yılını girişler ve çıktılar arasında geçirmiştir; verilen bir giriş için doğru çıktının ne olduğunu bilirler
  • Ajanın onlara sunduğu şey eksik olan kod üretme kapasitesidir; onların ajana getirdiği şey ise ajanda olmayan **doğruluk ölçütü (ground truth)**dür

• Genel amaçlı mühendisler iyi yapılmış yazılım ile doğru yazılımı ayırt edemeyebilir

  • Güçlü bir genel amaçlı mühendis mimariyi, güvenilirliği, testleri ve sistemin gece 2’de çökmesini nasıl engelleyeceğini bilir
  • Ancak klinik kodlama gibi alanlarda, makul görünen ama yanlış olan cevap ile doğru cevabı ayırt edemeyebilir
  • Ajan, derlenen ve mühendisin düşündüğü testlerden geçen ama ince ve pahalı faturalama kuralı hataları üreten bir şey ortaya koyabilir
  • Mühendis yazılımın iyi inşa edilip edilmediğini doğrulayabilir, ancak doğruluk bütünüyle zihninde olmayan bir alan tarafından tanımlanıyorsa isabeti doğrulamak zordur

• Ajanlardan önce mühendisler için avantajlı bir öğrenme yolu vardı

  • Mühendisler uzmanların peşine takılıp, spesifikasyonları okuyup, üretim ortamında hatalar yaparak alanı yavaş yavaş öğrenebilirdi
  • Birçok alanda bu süreç kariyer basamağının temeliydi
  • Alan uzmanları için bunun simetrik bir yolu yoktu
  • Güvenilir yazılım üretmeyi öğrenmek yıllar alırdı ve bu onların fiilen geçmesinin zor olduğu bir yoldu

• Ajan tabanlı araçlar yalnızca tek taraflı yolu yıktı

  • Mühendislerin avantajı olan alan modelini çalışan koda çevirme becerisi ucuzladı
  • Alan uzmanlarının avantajı olan neyin doğru olduğunu bilme becerisi ise ucuzlamadı
  • Bu beceri yalnızca prompt yazarak edinilemez; maaş hesaplamasını binlerce kez doğru yapmış birinin örtük bilgisini taşıyan bir skill file yok

• En değerli kişi, her iki katmanda da doğrulama yapabilen kişidir

  • Üretilen kodun sağlam olup olmadığını da, o kodun verdiği cevabın doğru olup olmadığını da bilen kişi en önemli hale geliyor
  • “Sürücü 11 saati aşamaz” testini yazabilmesinin nedeni kuralı bilmesidir
  • O testin başlı başına anlamlı olup olmadığını değerlendirebilmesinin nedeni de neyi test ettiğini bilmesidir
  • Ajan, aktarma işini yapar; insan ise hem kod hem alan katmanında muhakeme yürütür
  • Kıdemli mühendisler için önemli yatırım, gerçek alanın derin ve doğrulanmış bir modelini edinmektir
  • Net fikirleri temiz koda dönüştürme gibi mekanik becerinin değeri ciddi biçimde düştü
  • Hâlâ kıt olan şey, gerçek sektörler, araçlar, düzenleyici çerçeveler ve fiziksel süreçler hakkında derin anlayıştır
  • Programlama dili ya da framework öğrenir gibi bir alan seçip onu öğrenmek gerekir
  • Ajanların ikame edemeyeceği ve değeri bugün en çok artan şey alan uzmanlığıdır

[GN⁺]

Hacker News görüşleri

• Bireysel düzeyde AI'ı nasıl kullanmamız gerektiğini kimsenin bilmediğini kabul etmek için daha ne kadar uzun nutuk dinlememiz gerekecek bilmiyorum
  Önce iyi bir geliştirici olup AI kullanmayı öğrenmenin yeterli olduğu söylendi, sonra mimari tasarım becerisi dendi, ardından her şeyi zevkin belirlediği söylendi, şimdi de sadece alan uzmanlarının önemli olduğu söyleniyor
  AI'ın gelişimi veya duraklaması istikrarlı ve öngörülebilir bir duruma gelene kadar bu tür yorumlar anlamsız olmaya devam edecek ve büyük olasılıkla çoğu yanlış çıkacak

  • Giderek daha da pekişen düşüncem şu: AI araçları yazılım geliştirmeyi daha zor hale getiriyor
    Mümkün olan şeylerin çıtasını ciddi biçimde yükselttikleri için daha zor hale geliyor. Bireysel geliştiriciler artık çok daha zor projeleri üstlenebiliyor ve sonuçta kısıt her zaman zamandı; AI ise verilen süre içinde daha fazla iş yapmaya yardımcı oluyor
    Ama o sürede yapılabilecek işin kendisi artık çok daha zor. Çok daha fazla şeyi anlaman gerekiyor ve AI öncesindeki alışıldık güvenli alanın çok daha dışına çıkman gerekiyor
    Eskiden alışık olmadığın bir sistem alanı olduğu ya da yeni bir kütüphane öğrenmen gerektiği için bir kod tabanını refactor etmek veya küçük bir özelliği yayına hazırlamak için birkaç gün harcamak kabul edilebilirdi
    Kodlama ajanları sayesinde o öğrenme eğrisini çok daha hızlı tırmanabiliyorsun, ama yine de kendin tırmanmak zorundasın. Üstelik üzerine gelen bilgi miktarı da çok daha fazla
    Teknik olmayan vibe coder'ların işini elinden alacağından endişe ediyorsan, doğru tepki onlardan çok daha iyi yazılım üretmek olmalı. Bunun için daha fazla beceri, daha büyük hedefler ve daha fazla deneyim gerekiyor; kolay değil
  • LLM, cephaneliğe eklenen bir araçtan ibaret. Her şeye kadir değil ve diğer araçlar gibi dikkatle kullanılmalı
    Şimdiye kadar en uygun bulduğum benzetme, modern akülü matkap/vidalama aleti ile tornavida ya da el matkabı gibi eski ekipmanların karşılaştırılması
    Eski ekipmanlara kıyasla çok kısa sürede şaşırtıcı sonuçlar üretebilir
    Örneğin "Normalde tüm gün sürecek bir zemin sabitleme işini 1 saatte bitirdim, arada da birkaç kez sigara molası verdim" gibi çarpıcı hikâyeler mümkün oluyor. Çivi tabancası kullansaydın belki iş yarı sürede biterdi, ama sonra o zemini kolayca sökmek zor olurdu ve maliyet de yaklaşık iki katına çıkabilirdi
    On-premise LLM'leri de birkaç tane kullanıyorum ve başka modellere de erişimim var; bu yüzden bir gün bu benzetmeyi marka farklarına kadar genişleteceğim gibi geliyor
    Ama bunun yeni bir iş bulacağıma işaret ettiğini sanmıyorum. Akülü matkap/vidalama aleti bir marangoz ya da saha işçisi değildir; insan olmadan bir işe yaramaz
  • 20 yıl önceki nesne yönelimli abartıyı hatırlıyor musunuz? GoF kitabını şöyle bir karıştırıp neden kullandığını bile bilmeden herkesin pattern yağdırdığı kodları hâlâ bizim kod tabanından temizliyoruz
    20 yıl sonra da Claude ile birlikte yazılmış çöpleri temizliyor olacağız diye düşünüyorum
    https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
  • AI'dan önce de alan uzmanı olmanın, üstün bir yazılım geliştiricisi olmaktan daha değerli olduğu durumlar vardı
    2018'de hiç kodlama deneyimi olmayan birinin, sadece belirli bir niş pazarı iyi bildiği için bir ay kod yazıp gayet iyi para kazandıran bir araç yaptığını görmüştüm
    Kodun bir kısmını göstermişti; benim ilk programım kadar berbattı ama gerçek bir problemi çözüyordu
  • Bu bana seyircilerin ya da sıradan insanların profesyonel sporları değerlendirme biçimini hatırlatıyor
    Mesela "Sporda iyi olmak için kusursuz simetri gerekir ve bu, fetal gelişim istikrarıyla güçlü biçimde ilişkilidir. Simetri ne kadar yüksekse gelişim o kadar kusursuzdur" derler
    Sonra birkaç yıl sonra Bruce Lee'nin bir bacağının diğerinden belirgin şekilde kısa olduğu, Usain Bolt'un da benzer türde asimetrik bir gelişime sahip olduğu ortaya çıkar
    Bunun üzerine bunların istisna olduğunu söyleyip ilk iddialarını genel kural bozulmamış gibi tersyüz ederek savunurlar
    Sadece ilginç bir şey yap; belki tutar

• Kısa süre önce vibe coding ile neredeyse tamamlanmış bir uygulamayı inceledim. Sahibi, neredeyse yayına hazır olduğunu ve sadece hızlı bir kontrolden geçmesi gerektiğini söyledi
  Baktığımda veritabanı tasarımı berbattı. Bazı özellikler çalışıyordu, bazıları çalışmıyordu. Eksik parçaları ve neden bozulduğunu anlattım. Asıl yazıdaki kişi gibi o da bir alan uzmanıydı
  Sadece geçen ay milyarlarca token harcamıştı ve araçlar hızla gelişiyor. Ama bir alan uzmanına AI vermek, yazılım mühendislerine artık ihtiyaç kalmadığı anlamına gelmiyor
  Alan uzmanı AI ile yazılım üretebilir, yazılım mühendisi de AI ile alan bilgisini öğrenebilir. İkisi farklı uzmanlıklar getirir

  • Benim yöneldiğim yerin sonunda platform mühendisliğine daha yakın olduğunu düşünüyorum
    Alan uzmanları kodlama ajanlarını kullanmaya başladığında onları güvenle koruyacak guardrail'ler, doğrulama sistemleri, prompt kütüphaneleri, ajan ve manuel review süreçleri oluşturmak söz konusu oluyor
    Biraz iç kullanıma dönük T2/T3 müşteri desteği ya da destek mühendisliği gibi. Günlük sorunları doğrudan %100 çözmekten çok, riskli noktaları ve tuhaf edge case'leri yakalayıp tüm ayarların doğru olduğundan emin olma rolü
    Elbette birçok cross-cutting concern ile de ilgileniyorsun
  • Benim deneyimim de benzer. LLM'ler başka alanları keşfetmeyi kolaylaştırıyor ama seni o alanın ustası yapmıyor. Hâlâ uzman alan bilgisine ihtiyaç var
    Yine de yeni fikirleri hızlıca denemek ve derinleşmek için harika bir araç. Merakın varsa müthiş bir öğrenme hızlandırıcısı da olabilir
  • "Sadece geçen ay milyarlarca token harcadı" kısmını pek anlayamıyorum
    Bütün gün Claude Code (Opus 4.6, maksimum efor ayarı) kullanıyorum ama bunun nasıl mümkün olduğunu anlayamıyorum. Bu kullanımın gerçekten karşılığını verip vermediğini de merak ediyorum
    Büyük ihtimalle ben bir şeyi kaçırıyorum ama gerçekten bunun nasıl olduğunu anlamıyorum
  • Alan uzmanlığı, tutarlı bir QA zihniyetiyle birleşirse yazılım mühendisinin yerini alabilir; ama tutarlı QA zihniyeti nadirdir

• Kısa süre önce yaşadığım çok iyi bir örnek var
  Bir balıkçılık gezisindeydim ve üzerinde çalıştığım ücretsiz uygulamanın (https://oceanconnect.ca) işine yarayıp yaramayacağını görmek için kaptana bakmak isteyip istemediğini sordum
  İnsanların denizde okyanus verilerini nasıl kullandığını pek bilmiyorum. Ne bilmek istediklerini ya da neden istediklerini de pek bilmiyorum. İnsanların verileri nasıl kullandığına ve bizim verilerle neler yapabileceğimize dair öyle çok soru ve bilgi geldi ki hiç hazırlıklı değildim; o bakış açısını kazanmak gerçekten harika ve çok ilginçti
  Bu bana, modelin soyutladığı sistemle aynı şey olmadığını ve modeli geliştirmeye dair bilginin, onu kullanmaya dair bilgiyle neredeyse ilgisiz olduğunu yeniden hatırlattı
  Bu kişinin su üstünde hava durumu verilerini nasıl kullandığı konusunda muazzam bir bilgisi vardı. Bir bakıma veriyi benden daha iyi biliyordu ve bunu fark etmese ya da bunun dijital temsilini anlamasa bile, sadece programlama yapabilse kendisi gibi insanlar için çok daha iyi faydalı bir uygulama yapabilirdi
  Böyle insanların önüne bir LLM koyup fikirlerini ekrana dökebilmelerini sağlarsanız gerçekten müthiş şeyler üretebilirler diye düşündüm. Bir gün finansman bulabilirsem her gün denize çıkan insanlarla röportaj yapıp ürünü onların geri bildirimleriyle şekillendirmek isterim. Bu alan bilgisi çok özel; karmaşık alanlarda onlarca yıl yaşamış insanlar asla tahmin edemeyeceğiniz şeyler biliyor

• Bu yazıda tarif edilen yazılım generalisti de bir alan uzmanlığına sahip. O alan da yazılım
  Şu anda çok iyi bir generalist yazılım mühendisiyseniz, AI'dan kaçmak için rastgele bir alana atlamazsınız. Yazılım sizin alanınızdır ve bu alan genişleyip dönüşürken onun içinde kalmaya devam edersiniz

  • Evet. Üstelik artık AI diye yeni bir süper güç de var; onunla neredeyse her alana dalıp uzmanlığı hızla artırabilirsiniz. Bence yazının yönü tam tersine dönmüş durumda

• Belki de iyi haber şu: Batı'nın en iyi spreadsheet ustası muhasebecisi bile doğrulama yapabilmek için sonunda bir miktar programlama deneyimine ihtiyaç duyuyor
  LLM'ye “bu kod ne yapıyor ve Y olduğunda her zaman X oluyor mu?” diye sorabilirsiniz, ama bu sadece doğrulama problemini başka bir doğrulama probleminin içine yerleştirmek olur

• En başından beri asıl mesele kod değildi
  Son 5 yıldır venture capital ve private equity için yazılım geliştiriyorum; bu yazı bana gerçekten çok dokundu. Kod yazmak işimin açık ara en kolay kısmı, zor olan kısım ise şirket müşterilerinin gerçekten neye ihtiyaç duyduğunu anlamak için gereken finans mühendisliği ve ince bağlam
  Şaka yollu olarak, mümkün olsa kıdemli bir fon muhasebecisini işe alıp ona programlama öğretmek istediğimizi söyleriz. Sorun, böyle insanların neredeyse hiç olmaması. Mühendislere de fon muhasebesinin ayrıntılarını, bunu yazılıma dökebilecek kadar iyi öğretmek zor

  • Yalnızca alan uzmanlığı olup teknik beceri olmadığında, bir noktadan sonra en iyi ihtimalle devasa bir teknik borç çıkıyor
    Aslında kariyerimin yaklaşık yarısı, “bir ticket ya da epic'i kapatacak kadar alan bilgisi var ama sonunda bir sürü teknik borç bırakmış” işleri temizlemekle geçti
    Örneğin alan bilgisi olsa bile insanlar hata yapıyor, daha iyi yöntemleri bilmiyor, geri bildirimi uygulamıyor ya da daha kötüsü kodlama ajanının yazdıklarını tekrar kontrol etmiyor; bu yüzden PR'ları çok dikkatli incelemek zorunda kaldım
    “Teknik olarak doğru ama o kadar kötü yazılmış ki timeout'a giriyor ya da manager/DBA bağırmaya başlıyor” türü şeyleri refactor etmek de sık yaptığım işlerdendi
    Gerçekten iyi bir yazılım mühendisi, alanı öğrenme yeteneğine ve isteğine sahiptir; ama öğrenebileceği bir yol da olmalı. Bunu mümkün kılan şirketler, ekipler ve iş arkadaşları gördüm; bir de bunun önemli olduğunu söyleyip sonunda sadece JIRA'dan ve toplantılarda IT dışı ekiplerin ağzından kaçırdığı şeylerden anlam çıkarmanızı bekleyen yerler gördüm
    Bence son 5 yıldaki büyük paradigma değişimi şu: şirketlerin çoğu insanlardan sınırlarına kadar çalışmalarını bekliyor ve tam da bu yüzden önemli konuşmalar için alan bırakmayarak ters etki yaratıyor
    Kültür büyük bir değişken. En azından yanınızdakiyle kısa bir konuşma yapabildiğiniz ya da kolayca toplantı ayarlayabildiğiniz yerler vardı; bir de düzgünce tartışmak için zaman istemenin neredeyse change.org kampanyası başlatmayı gerektirdiği yerler vardı
    Yine de ana fikir doğru. Sonuçta gereksinimler koddan daha önemli. Tüm gereksinimler karşılanmış, ekip tasarım kararlarını onaylamışken bile, uygulama boyunca ortada olmayan birinin geri dönüp yazılış biçimini beğenmemesi yüzünden özelliğin geciktiği yerler gördüm
    Sonra bir bakıyorsunuz “batch process” %numberOfRecord%*10 tane insert yapıyor, kötü tasarlanmış veri modeli yüzünden ek sorgular da atıyor ve SQL upsert'ü yapılabilecek en yanlış şekilde gerçekleştiriyor. Yani önce DB'den çekip sonra yoksa insert edilecek kayıtlar listesine ekliyor. Sonra da veri katmanındaki sorgu desenlerini yeniden düşünmek yerine, “performans iyileştirmesi” adı altında giderek daha şüpheli işler yapmaya devam ediyorlar. Kariyerimde bunu bir kereden fazla gördüm

• AI'ya nasıl karşılık verileceğine dair gibi görünen bu çok genel yazıları her okuduğumda, yazılım sektörünün inşaat sektörüne benzediğini düşünüyorum
  Asla tam olarak düzenli değil, hiçbir zaman bütünüyle optimize edilmez ve kaçınılmaz olarak hep özelleştirilmiş kalır. Çünkü zevklerin, bağlamın ve yerelliğin aşırı farklı olduğu bir gerçekliğe uyum sağlamak zorundadır
  Arada bir iyi araçlar ya da yeni hammaddeler ortaya çıkabilir

• Yazılımın gerçek hendeğinin, hem sistemler hem de alan tarafında geniş çaplı bilgi ya da deneyim gerektirmemesinde yattığını düşünmüştüm
  Zevki ve ağ etkilerini kopyalamak ise çok daha zor. Nitekim vibe coding'den önce bile, bol yetenek ve kaynağa sahip VC destekli startup'ların pazarda kalıcı yer edinmesi nadirdi
  Bu yüzden 20'li yaşlardaki biri bile birçok alandaki uzmanlarla rekabet edebiliyordu. Şu anki tepkinin, diğer olgun sektörlerde sık gördüğümüz “sektörde X yıl deneyim” insanlarının ortaya çıkışından kaynaklandığını düşünüyorum

• Analist olarak çalışıyorum ve grubumuzda güçlü teknik yetkinliğe, yani yazılım mühendisliği becerisine sahip analistlerin oranı yaklaşık %20; geri kalanı ise geleneksel analistler veya alan uzmanları
  Son 1 yılda, teknik olmayan analistlerin geliştirme kısmında AI modellerini kullanarak iç araç geliştirme verimliliğini artırdığını gördüm
  Eskiden neredeyse her şey Tableau ile geliştiriliyordu. Geliştirici olmayan birinin çalışan bir araç üretmesinin en erişilebilir yolu buydu
  Daha birkaç gün önce grubumuzdaki bir analist üzerinde çalıştığı bir aracı sundu; temelde bir Tableau raporunu daha esnek bir uygulamaya taşımıştı

  • Grubumuz Tableau'yu yavaş yavaş kendi yaptığımız araçlarla değiştiriyor ve performans artışı muazzam
    Bu BI şirketleri büyük sıkıntıya girecek gibi görünüyor. Özellikle histogram gibi basit bir şeyi bile çizmeyi neredeyse imkânsız hale getiren Tableau gibi şirketler için bu daha da geçerli bence

• Arkadaşım bir elektrik mühendisi ve kısa süre önce FIDE satranç reytingi 2000 barajını geçti. 30 yıldır satranç oynuyor ve lisede satranç kulübü bile kurmuştu. Üniversitede mikrodenetleyicilerle uğraşırken biraz programlama öğrenmişliği var
  Ben ise bilgisayar bilimi diploması olan, daha çok altyapı/yönetim işlerine bakan bir genel iş çözücüyüm ve 30 yıldır hobi olarak programlama yapıyorum. Lichess reytingim en iyi günümde bile 1000
  Bir satranç botu yarışması yaptık. Açık kitaptı; yapay zekayla programlamak serbestti ve açılış kitabı, oyun sonu tabloları gibi ne varsa kullanabildiğin serbest bir mücadeleydi. Ben onu ezip geçtim ama gerçek tahtada oynanan satrançta 20 yılda onu sadece iki kez yenebildim
  O gerçek hayatta rastgele oyuncuların %99'unu yener, ben ise muhtemelen ancak %20 kadarını yenebilirim
  Tam olarak ne demek istediğimden emin değilim ama artık alan bilgisinin her şey olmayabileceği hissine kapılıyorum. Ya da belki de alanın kendisi değişmiştir

  • Yapay zekanın bakış açısından bazı alanlar sığdır, satranç gibi; bazı alanlar ise derindir diye yorumlamak en temkinli yaklaşım gibi görünüyor
  • Gerçekten satranç oynayabilme becerisinin, birkaç basit ilkenin ötesinde verimli bir oyun ağacı arama algoritması yazabilmekle ne ilgisi olduğunu bilmiyorum
    Ona bir programlama düellosu teklif etmiş oldun ve çok daha deneyimli programcı olan sen kazandın. Yapay zeka kullanmak serbest olsa bile burada belirleyici olanın senin alan bilgin olduğunu düşünüyorum