LLM'ler yazılım mühendisliği kariyerimi aşındırıyor ve ne yapacağımı bilmiyorum

• LLM tabanlı geliştirme araçları, tasarım dokümanı yazımından uygulama planına, kod yazımından hata ayıklamaya kadar sürece dahil oluyor ve 10 yılda biriktirilen ödeme ve finans backend uzmanlığının ayırt ediciliğini zayıflatıyor
• Finans ve ödeme alanındaki alan bilgisi, PCI uyumluluğu, çift taraflı muhasebe defterleri, escrow, mutabakat, ödeme yaşam döngüsü, banka transferi idempotency'si gibi deneyimlere dayanan bir rekabet avantajıydı; ancak modelin sistem yapısındaki bağlantıları yakalayabilmesi ilk şoku yarattı
• Claude Code, Codex, MCP, DataDog MCP gibi araçlarla hata ayıklama otomasyonu genişlerken, yalnızca stack trace ve Sentry bağlamıyla bazı hatalar çözülebiliyor; ardından dağıtık sistem hatalarının %90'ı tek seferde ele alınabilir hale geliyor
• Geriye kalan iki eksen olan kod kalitesi ve mimari de “taste” düzeyine indirgeniyor; insanlar için okunması kolay A ve B sınıfı kod tabanları yerine, LLM'lerin çalıştırabildiği C ve D sınıfı kod tabanlarını kabul eden bir akışa giriliyor
• Uzun vadeli istihdam edilebilirliği korumak için uzmanlığın LLM'lerin kolayca iyi yapamadığı alanlara taşınması gerekiyor; ancak araştırma rolüne geçiş, yaşanılan ülke, yoğun başvuru rekabeti, aile koşulları ve RSI olasılığı nedeniyle kısıtlı

---

Kariyer geçmişi

• 10 yıllık profesyonel deneyime sahip bir yazılım mühendisi; hata ayıklamanın daha kolay olması nedeniyle web frontend ile başlayıp daha sonra backend tarafına geçmiş
• Tesadüfen finans, muhasebe (bookkeeping) ve ödeme işleme alanında yazılım geliştirme rolü üstlenmiş; Product Manager ve diğer paydaşlarla yakın ve dürüst ilişkiler içinde yüksek özerklik yaşamış
• PCI uyumluluğu (PCI compliance), çift taraflı muhasebe defterleri (double-entry ledgers), escrow, mutabakat (reconciliation), ödeme yaşam döngüsü (payment lifecycles), banka transferi idempotency'si (bank transfer idempotency) gibi alan bilgisini biriktirmiş
• Alan uzmanı olma kariyer stratejisi, alan uzmanlarına talebin artma işaretleri gösterdiği bir sahada uzmanlığı farklılaştırmak için net bir tercihti

Çökmeye başlayan ilk sütun: alan bilgisi

• Geçen yıl finans alanındaki bir şirkete geçmiş; önceki şirketlerde ödeme ve finans unsurları güçlüydü ama hiçbiri yalnızca finans odaklı değildi
• Yeni şirket yapay zekayı tamamen benimsedi; ilk günden ChatGPT ve Claude Enterprise hesapları sağladı ve araştırma, keşif, kodlama için AI kullanımını teşvik etti
  • Ancak üretime girecek her satır kodun doğrudan gözden geçirilmesi ve sorumluluğunun alınması gerekiyordu
• İlk proje, dağınık bir legacy çevrimiçi ödeme sisteminin yeniden ele alınmasıydı ve geçmişte benzer sistemler kurmuş olması nedeniyle bu işe verildi
• Kodlamadan önce yazılan Design Docs, hem mühendisler hem de Product Manager'lar tarafından okunabilir olmalıydı; teknik derinlikten çok mimari bakış açısı gerektiren dokümanlardı
• İlk Design Docs'ları AI'dan çok sınırlı destek alarak yazdı; o dönemde LLM'leri “stochastic parrots” olarak görüyordu ama artık bu görüşü sürdürmüyor
• Yöneticisinden gelen geri bildirim, kodu iyi hızda çıkardığı ama Design Docs yazımının fazla uzun sürdüğü ve daha fazla AI kullanması gerektiği yönündeydi
• O zamanki modeller bugünkü kadar iyi değildi, ama yazma ve karar verme hızını artırmak için yeterince etkiliydi
• Yıllar içinde biriktirdiği implementation trade-off'ları, acquiring'in nasıl çalıştığı ve çift ücretlendirmeyi önlemek için idempotency'yi nasıl yapılandırdığına dair bilginin değer kaybettiğini ilk kez o anda hissetti
  • Model hâlâ yönlendirme gerektiriyordu ama sistemin nasıl yapılandırılması gerektiğine dair bağlantıları kurabiliyordu; bu da genelde yıllarca pratik deneyim sonrasında zihinde şekillenen en zor kısımdı
• Web'de çok sayıda açıklayıcı yazı, teknik dokümantasyon ve alanlara teknik araçların nasıl uygulandığını anlatan blog yazıları bulunduğundan, modelin bunları eğitim verisi olarak içine alabileceğini düşündü
• İnsanların öne çıkmaya devam edeceği alanın hata ayıklama olacağı umudu sürüyordu; prod ortamındaki race condition'lar ve dağıtık sistem hata ayıklama deneyimi, uzun vadeli istihdam edilebilirliğin temeli gibi görünüyordu

Çökmeye başlayan ikinci sütun: hata ayıklama ve dağıtık sistemler

• LLM'ler doküman yazımı ve uygulama planı desteğinde ustalaştıktan sonra kod yazımında da iyi hale geldi; 2025'in ikinci yarısındaki Claude Code heyecanı ve Codex'in çıkışıyla bu akım büyüdü
• Ondan önce de günlük olarak unit test yazmak için LLM kullanıyordu ama tüm implementasyonu teslim edecek kadar güvenmiyordu
• Kod yazımına daha fazla AI dahil etmek doğal bir sonraki adımdı ve kodlama kadar production deploy ile kullanıcı memnuniyetini de sevdiği için bu kabul edilebilir bir takastı
• LLM'ler kod yazmada iyi hale gelmişti, ancak modelin ya da insanların bıraktığı karmaşayı hata ayıklayamıyordu; bu yüzden robotları yönlendirmekten daha büyük bir rolü olduğu düşünülüyordu
• MCP, ajan tabanlı workflow'lar ve Claude 4.5'in gelişiyle hata ayıklama ekseni de sarsılmaya başladı
• Claude 4.5, yalnızca stack trace ve biraz bağlamla hataların yaklaşık %60'ını çözebiliyordu; çoğu durumda Sentry MCP'nin etkin olduğu bir Sentry linki yeterliydi
  • Bazen makul görünen ama tamamen yanlış çözümler de üretiyordu
• Bu noktada makineye duyduğu kuşkuyu bıraktı; geçmişte tüm gününü alacak bir hatayı Claude Code'un tek seferde çözdüğünü gördü
• Sonrasında 4.6, 4.7, GPT 5.5, Opus 4.8 ve DataDog MCP ile birlikte CLI, dağıtık sistem hatalarını tek seferde çözebilir hale geldi
  • Geçmişte çözemediği hatalar, iki gün tam zamanlı uğraş gerektirecek hatalar, hatta dağıtık gözlemlenebilirliği zayıf dağıtık sistem hataları bile buna dahil
  • Tuhaf race condition'lar, beklenmeyen corner case'ler, üçüncü taraf entegrasyon sorunları, dokümante edilmemiş API edge case'leri gibi hataların %90'ı tek seferde çözülebiliyor
• Hâlâ kodu gözden geçirip robotları yönlendirecek birine ihtiyaç olduğu için işi sürüyor, ancak artık paket bir mühendis haline geldiğini düşünüyor
• Finans ve ödeme alan uzmanlığı, hata ayıklama sezgisi ve dağıtık sistem bilgisi; artık başka kıdemli mühendislerin LLM'leri yönlendirmek için prompt'a dökebileceği bilgiye dönüşmüş durumda
• Genelistlerle uzmanların ikisinin de rolü olduğunu söyleyen eski anlayışın aksine, pazar herkesi geneliste dönüştüren bir yöne gidiyor
  • Herkes genelist olursa ve talep buna yetişmezse genelistlerin fiyatı düşer; üstelik talep zaten azalıyor

Henüz çökmemiş üçüncü sütun: kod kalitesi ve mimari

• Geriye kalan sütun kod kalitesi ve yazılım mimarisi; ancak bugün bu alan da “taste” denilerek küçümseniyor
• Kariyeri boyunca refactoring'i sevdi, iyi koda önem verdi ve sprint içinde buna zaman ayırabilmek için pazarlık yaptı
• DDD, Hexagonal, Clean Architecture gibi konularda trade-off'ları ve kod tabanı yapısını tartışmayı sevdi
• Ajanlar, kod tabanını düzenli tutmak konusunda çok zayıf araçlar
  • Yönlendirilmediklerinde circular dependency sorunları hızla ortaya çıkıyor
  • Yinelenen kod ekliyorlar, gereksiz yorumlar koyuyorlar, pure function'larla side effect'leri karıştırıyorlar ve SOLID ilkelerini görmezden geliyorlar
• Bu beceri, insanların istihdam edilebilirliğini koruyacak alan olmalıydı; ancak sektör bunu “taste” kelimesine indirgedi ve kod organizasyonunun öneminin daha düşük olduğu bir dünyaya gidiyor
• İnsanların rolü, circular dependency graph'ına sahip spaghetti kod tabanlarını önlemek için ajanları yönlendirmek olarak kalıyor
• Bir şeyi düzeltmeye çalışınca kırılan F sınıfı kod tabanları istenmiyor, ama C ya da D sınıfı artık kabul edilebilir görülüyor
• Artık A ya da B sınıfı kod tabanlarına ihtiyaç duyulmamasının nedeni, kod tabanlarının insanlar okusun diye değil, LLM'ler işlesin diye kuruluyor olması
• Kaynak kod artık insanlar yerine makineler tarafından okunmak üzere yazılıyorsa, doğrudan makineyi hedef almak da mümkün hale geliyor
• Kod kalitesi ve mimari bilgisi de değer kaybediyor; kitap okumaya, gerçek pratik yapmaya, mühendislerle tartışmaya ve ADR yazmaya harcanan zaman boşa gidiyormuş gibi hissettiriyor

Peki şimdi ne yapmalı

• Şimdilik, en azından mevcut şirkette, işini koruyacağını düşünüyor; ancak uzun vadeli görünüm belirsiz
• Uzun vadede, 10 yıl ve uzmanlık öncesi deneyim de sayılırsa daha da uzun sürede öğrendiği şeylerin değeri giderek düşüyor
• Son uzmanlık sütunu bile “taste” düzeyine indirgenmiş durumda
• Yaklaşık 8 ay önce mevcut şirkette, şirketin açıklamasına göre AI ile ilgisiz bir işten çıkarma dalgası yaşandı ve işten çıkarılan çok yetenekli eski ekip arkadaşları hâlâ iş arıyor
  • Bu kişilerin çoğu da aynı sorunla karşı karşıya: alan uzmanlığı artık tek başına farklılaştırıcı değil
• Şirket şimdi bazı rolleri yeniden işe alıyor, ancak alan aşinalığı artık güçlü bir ayırt edici unsur sayılmıyor
  • Eskiden ilanlar “Software Engineer - Area” biçimindeydi; şimdi yalnızca “Software Engineer” yazılıyor ve takım ataması teklif kabulünden sonra yapılıyor
• Derin alan deneyimi edinme fırsatı bulamamış yetenekli mühendislere daha iyi iş fırsatları doğuran bir değişim yaşanıyor
• Öte yandan, hayatı boyunca alan bilgisi biriktirmiş yetenekli mühendisler de artık aynı kulvarda rekabet ediyor
• Uzun vadeli istihdam edilebilirliği korumanın tek yolu, alan uzmanlığını LLM'lerin kolayca iyi yapamadığı alanlara taşımak gibi görünüyor
• Üniversiteye dönüp matematik, istatistik ve ileri düzey Machine Learning öğrenerek frontier lab araştırma rollerine başvurmayı da düşünüyor
  • Yaşadığı ülkede frontier lab yok ve var olan az sayıdaki araştırma laboratuvarına yoğun başvuru var
  • Aile koşulları nedeniyle başka bir ülkeye taşınmak zor
  • Taşınmanın mümkün olacağı zamana kadar RSI'ın (özyinelemeli öz geliştirme) araştırmacıları gereksiz hale getirme ihtimali de var
• Hatta ahşap işçiliği hobisini mesleğe dönüştürmeyi düşünecek kadar çıkmazda hissettiğini söylüyor

[GN⁺]

Hacker News görüşleri

• Ne diyorsun? Bütün gün LLM yönlendiriyorum ama finansal ürünlerin sorumluluğunu üstlenmeyi asla kabul etmem
  İlk sütun hâlâ ayakta. Yazar kendi etkisinin farkında olmayabilir ama geri çevrilmiş PR’ların kanıtına bakılırsa, benim derinlemesine bildiğim alanın dışına çıktığımda ajanların saçmalayıp saçmalamadığını artık ayırt edemediğimi biliyorum. Yazarın sözünü ettiği, dağıtık sistemlere erişimi bile olan en üst düzey ajanlarımız da sık sık yanılıyor, dar bir bakış açısına sahip ve sürekli aptalca şeyler yapıyor. Sonunda işleri yeniden rayına oturtan şey ekipteki mühendislerin uzmanlığı oluyor

  • Kimliğimi ifşa etmemek için geçici bir hesapla yazıyorum. Düzenlemeye tabi ürünler geliştiren bir FinTech’te çalışıyorum ve Mythos erişimim var
    Mythos, kod tabanımızın bir bölümünün belirli bir düzenlemeyi ihlal ettiğine yüksek bir özgüvenle karar verdi ve mevcut şekilde çalıştırılırsa ciddi risk oluşturacağını söyledi. Ama bu doğru değildi; düzenleyici gereklilikleri halüsinasyonla uydurmuştu. Bunu anlayabildik çünkü ilgili kod zaten insan bir hukuk danışmanı tarafından incelenmişti. Üstelik bunun şu anda kullanılabilen en ileri model olduğu söyleniyor. Kod yazma yardımında üretken yapay zekayı yoğun kullanıyoruz ama orta vadede bile bu tür araçlara güvenip gerçekten mevzuata uyumlu finansal ürünler inşa edemezsiniz. Bu tam anlamıyla delilik olur. Birçok FinTech şirketinin hız kazanmak için ajanlar kullandığı doğru, ancak insanlar gerçekten derinlemesine incelemeden bunu ürün yayını için kullanmak devasa bir riski üstlenmek demek
  • “Ekipteki mühendislerin uzmanlığı işleri yeniden rayına oturtuyor” deniyor ama meslektaşlarımın benden daha uzman olmadığından nasıl emin olabilirim?
    LLM’lerden önce çoğu şirkette çok iyi mühendislerle ortalama mühendislerin birlikte çalışabileceği bir alan vardı. LLM’lerden sonra ise yalnızca “en iyi” mühendisler hayatta kalabilecek. Çünkü artık ortalama mühendislere ihtiyaç yok. HN’nin yapısı gereği bu yazıyı okuyan mühendislerin çoğu kendisinin şirketi/şehri/ülkesi ölçeğinde ilk %10–5 içinde olduğunu düşünüyor ve bu yüzden LLM benimsenmesinden etkilenecek “ortalama” mühendislerden olmadığını varsayacaktır. İstatistiksel olarak bakınca büyük olasılıkla yanılıyorlar. Sonunda bu bir ego meselesi. Büyük ihtimalle bir rockstar değilsin ve LLM sonunda senin işini elinden alabilir. Her zamanki gibi kazananlar yalnızca şirketler ve yöneticiler olacak; çoğumuz zincirin en sonunda olduğumuz için zararı biz göreceğiz
  • Karmaşık gereksinimleri olan PR’larda ilk PR’ye kadar geçen sürenin çok kısaldığını, ama sonrasında gözden geçirenle geliştirici arasında pinpon başladığını görüyorum
    Benim durumumda geliştirici bazı kısımları vibe coding ile yaptı ve gereksinimleri ya da kendi kodunu derinlemesine anlamadığı için düzeltmek adına birçok tekrar gerekti. Buna insani bir sorun diyebilirsiniz ama benim gördüğüm net etki şu: Karmaşık vakalarda eskiden olan “makul derecede uzun PR yazma süresi + makul derecede uzun inceleme süresi”, “çok kısa PR yazma süresi + daha uzun inceleme süresi”ne dönüşmüş gibi. Bu durumda gerçekten bir kazanç olup olmadığını bilmiyorum. Bazen işlevsel olarak doğru olan kod bile gereğinden fazla ara fonksiyon içerdiği için aşırı ayrıntılı oluyor ve bunun gelecekteki incelemeleri etkileyeceğini düşünüyorum
  • Ne yazık ki yazılımla ilgili sektörlerin genelinde LLM/kod üretimi benimseniyor. Bankalar, FinTech’ler, sigorta şirketleri; hepsi böyle
    Ben de aynı kaygıları taşıyorum ama sık sık “teslimat hızı ve ROI buna değiyor, o yüzden dert etme” denerek geçiştiriliyor ya da üstü örtülüyor
  • “Bütün gün LLM yönlendiriyorum ama finansal ürünlerin sorumluluğunu üstlenmeyi kabul etmem” sözünün belli bir işverende ne kadar daha geçerli kalacağını bilmiyorum
    Benim kişisel olarak temas ettiğim tüm FinTech şirketlerinde geçen yıldan beri geliştiriciler için bir tür AI hesabı vardı. Jane Street gibi yerlerde bile çalışanlar blog yazıları yayımlayıp çoğunlukla ajanları yönlendirdiklerini söylüyor. Sence senin şirketin buna daha ne kadar dayanabilir?

• “Yapay zeka X’i %80~100 doğrulukla yapamıyor, o yüzden mesleğimiz güvende” diyen çok yorum görüyorum
  Aşırı karamsar gelmek istemem ama modeller hızla iyileşiyor. Yaklaşık 3 yıl önce bugünkü durumu anlatıp “model tek bir prompt’la yaklaşık 30 dakikada baştan sona bir MVP uygulaması yapıyor” denseydi bilim kurgu gibi gelirdi. Modellerin şu anda yaşadığı halüsinasyon oranını düşürme, kurallara uyumu garanti etme, temiz bir kod tabanı koruma gibi engellerin çözümü de uzak görünmüyor. Belirli bilgileri getirme işi de birden fazla MCP sunucusu/RAG ile zaten kısmen mümkün. Yazılım mühendisliğinin geleceği konusunda endişeliyim. Bu kusurlar çözülünce meslek nereye oturacak? Yapay zeka modeline iş devreden bir role mi? Ne yazık ki bu, yılların uzmanlığını gerektirmediği için iki ucu keskin bir kılıç. Yapay zeka çıktısını gözden geçirmek mi? Anlamadığın her satırı açıklamasını isteyebilirsin. İnsan hesaplayıcıların dijital bilgisayarlarla yer değiştirmesi gibi, daha büyük bir işten çıkarma dalgası daha göreceğimizi düşünüyorum. Karmaşık matematik hesaplarını kafadan yapmak eğlenceli bir meydan okuma olabilir ama bilgisayardan çok daha yavaş ve daha hatalıdır. Aynı şekilde elle kod yazmak da eğlenceli bir “meydan okuma” gibi görünecek ve yapay zeka modern hesap makinesi gibi algılanacak

  • Bu kısa klibi mutlaka izlemeni öneririm
    https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
  • Modellerin hızla iyileştiği ve 3 yıl önce bugünkü durumun bilim kurgu gibi duyulacağı sözü tamamen doğru
    Birçok şey ciddi biçimde gelişmeye devam edecek. Yine de teknolojinin yarattığı ani karmaşanın yakın tarihine bakınca tekrarlayan bir örüntü var. Çığ ya da ani sel gibi, bu tür hızlı değişimler çoğu zaman belirli bir teknolojideki bir veya daha fazla önemli atılımla başlar. İlk değişim hızı hızlı ve serttir ama kolay kazanımlar toplandıkça ve yeni alanda yeni engellerle sürtünmelerle karşılaşıldıkça giderek yavaşlar. Böyle dönemlerin başında, son dönemdeki sıra dışı değişim oranını olduğu gibi geleceğe uzatmanın öngörü gücü düşüktür. Ani ve aşırı patlamalar uzun vadeli trend çizgisine geri dönme eğilimindedir. Mevcut LLM karmaşasının, 2010 sonrası araştırmaların 2017’deki Transformer makalesi ile birikmesi ve bunun etrafında araştırmaları hızla tetiklemesinden kaynaklandığı söylenebilir. O halde şu anda LLM’lerin hızlı patlama evresinin orta ya da geç safhasında olabiliriz. Tüm LLM uygulamalarını yukarı çeken temel ve geniş kapsamlı atılımların hızı açıkça yavaşladı; son dönemde etkisi büyük keşiflerin çoğu belirli alanlara yönelik ölçekleme, optimizasyon, ince ayar ve ürünleştirme tarafında. Bu, yarın Transformer ölçeğinde başka bir atılım olmayacağı anlamına gelmiyor ama tarihsel olarak kara kuğular sürü halinde dolaşmaz
  • Neden bunun geliştirici işten çıkarmalarında duracağını düşünüyorsun? Yazılım şirketleri iş yürütmeyi LLM sağlayıcılarına bağımlı hale getirirse, şirket içi ürünlerden SaaS’a kadar dünya çapında bu şirketlerin büyük çaplı çöküşünü görebileceğimizi düşünüyorum
    Müşteriler bugün olduğu gibi yazılım araçları satın almak yerine, ihtiyaç duydukları tüm yazılımı ya kendi içlerinde geliştirir ya da prompt engineering danışmanlarıyla yaptırabilir. Çok farklı bir dünya olabilir
  • Yapay zekanın %100’e ulaştığı ana dair teorin ne? PM’ler ve iş analistleri tüm yazılımı mı yapacak?
    Yoksa dünya çapında sadece 700 kadar tek kişilik girişim mi olacak ve geri kalan herkes işsiz mi kalacak? Matrix mi bu?
  • Modellerin o kadar iyiye gittiğini düşünüyorsan bu biraz hezeyana yakın
    Claude 3.5 çıktığından beri üretkenliğim o kadar da artmadı. Tüm LLM’lere sınırsız erişimim var ama çoğu çöp ve tasarruf ettirdiğinden fazlasını yaptırıyor. Bu araçtan fayda sağlayan tek kişiler, düşük kaliteli çıktıları hızlıca üretip duranlar. Katılmıyorsan sen de o kişilerden birisin

• Kariyer yolum, yazarınkine şaşırtıcı derecede benziyor. İşin garibi, yazarın çöken ilk sütun olarak gördüğü kısım şu anda en sağlam görüneni.
  LLM’ler işimizin özgün yapısında sürekli başarısız oluyor. Bölgesel vergi yasaları, muhasebe süreçlerinin ayrıntıları, bizim defter sistemi uygulamamızın kendine has özellikleri gibi konularda. Refactoring, diller arası dönüştürme ve mevcut koddaki hataları izleme konusunda harikalar, ama bizim alan bilgisini yineleyip genişletirken her zaman ince ama önemli yanlışları oluyor. Belki de çalıştığım şirketler, hendek oluşturmak için bilerek karmaşık alanlarla uğraştığından böyledir. Kopyasını çıkaracak bir kitabın dünyada olmadığı ve know-how’ın içeride kaldığı için ayakta duran şirketler bunlar. Ayrıca bir yöneticinin tasarım dokümanlarını AI ile hızlıca üretmeyi teşvik ettiği bir FinTech, para işi yapmak için fazla dikkatsiz görünüyor. Özellikle küçük işlemler çok büyük hacimlerde gerçekleştiğinde, milyonlar düzeyinde tutarın yanlış dağıtılması çok kolay. Böyle hatalarla uğraşmak gerçekten zor. Mantığı düzeltmek sadece ilk adım; sonrasında değiştirilemez veritabanındaki yanlış hesaplanmış verileri düzeltmeniz, düzenleyici süreçleri ve müşteri iletişimini yönetmeniz gerekir. Düzeltmeler, yeni özelliklerin ve gözlemlenebilirliğin hesaba katması gereken bir tuzağa dönüşür. Mesela “2 Şubat verisindeki sıçramanın X olayı yüzünden olduğunu unutma” gibi.

  • Gerçekten daha önce hiç yapılmamış bir şey inşa ederken, mimari kararları LLM’ye bırakamazsınız.
    Birden fazla fizik simülasyonu tabanlı ürün geliştiriyorum; tamamen birinci ilkelere dayanıyorlar. Ama bunu aktif araştırma, düşünme ve doğrulama olmadan LLM’ye bırakırsanız, yüzlerce basamak mertebesinde daha yavaş çalışan hesaplama kodu üretirken saçma sapan alternatif yollar ve kestirmeler ekliyor; sonuçta da işe yaramaz bir hesaplama ortaya çıkıyor. Bu muhtemelen vakaların %95’inde oluyor. Gözetim çok önemli ve mimari düşünce hâlâ dış kaynak olarak verilemiyor. Dış kaynak olarak verilebilen şey yalnızca uygulama.
  • Bölgesel vergi yasaları, muhasebe süreçleri ve defter sistemi uygulamasının kendine has özellikleri alan uzmanlığıdır; bunun için mutlaka bir yazılım mühendisi gerekmez.
    Elbette kıdemli yazılım mühendisleri çoğu zaman bu konularda uzmandır, ama bu şart değildir. Geleneksel olarak, bir mühendisin işin yaklaşık %90’ını iş uzmanına sormadan halledebilmesi, sürtünmesiz üretim için faydalıydı; ama tam da o “gelenek”in sona erdiği, asıl yazının ana noktası. Yeni dünyada kıdemli mühendisin işi, bu alan uzmanlığına bizzat sahip olmak değil; ajanın buna sahip olmasını ya da bunu edinmesini sağlamak ve bunun doğrulanabilir biçimde doğru olduğundan emin olmaktır. İleri düzey iş alanı uzmanlığının kendisini güvende tutacağını düşünen kıdemli mühendisler, dönüşüm geçirmemiş junior’lar kadar yakında çıkmaz bir yola girecek.
  • Claude ya da GPT-5’e yaygın kullanım senaryoları için bir akış diyagramını bile tutarlı biçimde iyi yaptırmayı başaramıyorum. Alan özelindeki içeriklerden hiç söz etmiyorum bile.
    Derin bir kelime dağarcığına sahip olduğu için, gerçekte bildiğinden daha fazlasını biliyormuş gibi geliyor. Kod yazmakta ve görünür hataları debug etmekte çok iyi, ama bunda yarı yarıya test düzeneği etkili.
  • Ürün özellikleriyle bu özelliklerin yansıtması gereken düzenlemeleri, LLM ile ortak bir anlayışta buluşturmayı sağlayan teknikler faydalı olabilir.
    Temel fikir, dokümanları LLM’ye vermek ve LLM’nin çok sayıda soru sorarak belirsizlikleri ve yanlış anlaşılma ihtimallerini gidermesidir. Skills’e bir göz atmanızı öneririm. Gerçekten yardımcı oluyor. https://www.youtube.com/watch?v=6BB6exR8Zd8
  • Bizim şirket de karmaşık düzenlemelerle ve alana özgü sistem uygulamalarıyla çok uğraşıyor; eskiden AI burada zorlanıyordu.
    Sorunu iyi düzenlenmiş claude.md/agents.md dosyalarıyla çözebildik. Buna ek olarak supermemory.ai’yi de entegre ettik; böylece yeni alınan kararlar, her yeni oturum başladığında AI ajanı tarafından her zaman hatırlanıyor.

• Steve Jobs’un meşhur “fikirler ucuzdur” sözünü hep hatırlarım
  Her şey icrada bitiyor ve en ileri seviye LLM’ler icra sorununu çözerse, o zaman fikirler bolluğa açılan kapı haline geliyor. Ama bolluğun kendisi, tek başına “elde tutma gücünü” garanti etmez. Sık sık gözden kaçan şey, insanların o işte kalmaya yönelik iradesi ve gerçekten önemsemesidir. Birçok insan bir şeyi üretmeyi, sürdürmeyi ve sahiplenmeyi isteyecek ya da bunu önemseyecek kadar bağlı değildir. V1’i daha hızlı çıkarabilirsiniz, ama onu sürdürüp emek vermeye devam edebilir misiniz? Buna iyi bir örnek AI müzik aracı Suno’da görülebilir. Artık oldukça iyi sonuçlar üretiyor. Birçok insan kendi küçük dünyasını kurup biraz oynuyor, sonra hızla sıkılıp gidiyor; geriye sadece az sayıdaki üretken yaratıcı kalıyor ve onlar bunu “iş gibi” bir ortama çeviriyor. Yetki devri ve icranın ölçeğiyle ekonomisi değişmiş olabilir, ama hâlâ hesaba katılması gereken çok şey var

  • Suno’yu biraz kullandım ama “gerçekten iyi sonuçlar veriyor” sözüne katılmıyorum
    Müzik birikimi sınırlı biri olarak bile böyle hissediyorum; müzisyenler muhtemelen çok daha eleştirel olacaktır. İlk birkaç denemede etkileyici geliyor ve melodiler akılda kalıyor. Eskiden arka planda tuhaf duyulan şeyler vardı ama çoğu düzeltilmiş. Ama onlarca parçadan sonra hepsi birbirine benzemeye başlıyor. Her şey genel geçer, şarkılar bir hikâye anlatmıyor ve kurumsal reklamlarda çalan müzik hissi veriyor. Prompt’ları daha hassas yazmak da pek işe yaramadı; parçayı ilginç kılacak detayların çoğunu görmezden geliyor. En ilginç sonuçlar ise ancak sistemi adeta bug gibi raydan çıkardığımda ortaya çıktı. Birbirinden çok farklı iki türü karıştırmasını istediğimde, daha önce duyduğumu hatırlamadığım kadar tekinsiz bir sonuç verdi. Ama bunun üstüne daha fazla çalışmak hep zor oluyor; sürekli tekrar genel sonuçlara dönmeye çalışıyor ve ayrıntılı talimatları yok sayıyor. Suno remiks yapabiliyor. Bu da koda benziyor. LLM’ler, zaten çalışan bir şeyi başka bir dilde çalışır hale getiren port etme işinde çok iyiler. Ama elinizde sadece bir fikir varsa, özgün kısımda tökezliyorlar. LLM’in fikri düzgün uygulamasını sağlamak için o kadar çok yönerge vermek gerekiyor ki, doğal dilin muğlaklığıyla boğuşurken fiilen kodu kendiniz yazmaya yaklaşmış oluyorsunuz
  • En ileri seviye LLM’ler icra sorununu “çözmüyor”
    Yeterince zorlar ve gerçekten çalışan kod alabileceğiniz bir sistem kurarsanız, icra sorununu çözebilirsiniz. Ama bunun adı zaten mühendislik. Şu an varsayılan durumda mühendisliğin yerini alabilmekten çok uzaktalar. Belki 3 yıl sonra mümkün olur. Çünkü çok hızlı ilerliyorlar. Ama bugün çıkıp “bana daha iyi bir Rust derleyicisi yap” deyip arkana yaslanarak sonucu bekleyemezsin
  • Suno iyi bir örnek. Bir sürü şarkı sözü yazdım ve Suno ile “prodüksiyonunu” yaptım, ama istediğim sesi elde etmek için onlarca hatta yüzlerce remiks/cover/uzatma düzeltmesi yapmak ya da editörde uzun zaman harcamak gerekti
    Ortaya çıkan parçaları seviyorum ve kendi çalma listemde dinlerim, ama Suno algoritmasında büyük bir karşılık bulmadılar. Başka yerlerde de pek tanıtmadım; paylaştığımda da gelen şey birkaç beğeniden ibaretti. Buna hayal kırıklığı demiyorum. Çünkü müziği kendim için yaptım, paylaşmak sadece yan etkisiydi. Buradan çıkardığım sonuç şu: İnsanların benim yaptığım şeyle ilgilenmesini ve ondan keyif almasını sağlamak için çok emek gerekiyor. Pazarlamanız gerekiyor, insanların önüne getirmeniz gerekiyor, dikkatlerini çekmeniz gerekiyor. Ayrıca bunun video, hikâye, persona ya da belli bir atmosfer gibi şeylerle bağlantılı olması ve onlara hoşlanmaları için bir sebep vermesi gerektiğine de eminim. Bir şeyin “tutması” için bunların hepsini aynı kitleye tekrar tekrar sunmanız ve onların buna alışmasını sağlamanız gerekiyor. Bu yüzden süreklilik gerekiyor ve satmaya çalıştığınız şeye gerçekten içtenlikle önem vermeniz gerekiyor. İnsanlar bağlanmadan önce benim önce bağlı kalmam gerekiyor
  • https://x.com/chamath/status/2033385903520129161
    https://en.wikipedia.org/wiki/Sturgeon%27s_law
    Sturgeon yasası, “her şeyin %90’ı çöptür” der. Bu özdeyiş, Amerikalı bilimkurgu yazarı ve eleştirmeni Theodore Sturgeon tarafından türün değerini savunurken ortaya atılmıştır. Sturgeon’a göre hangi alan olursa olsun, üretilen işlerin büyük çoğunluğu düşük kalitelidir; dolayısıyla yalnızca bilimkurguya özgü bir aşağılık durumu yoktur
  • AI müzik araçları hakkında biraz daha açıklama yapabilir misin?
    Benim izlenimim, bunların tek seferde üretim yapan araçlar gibi kullanıldığı yönünde. Müzikten çok anlamıyorum ama sanatçılar için ara aşamalar, track ayrıştırma, enstrüman özelleştirme gibi bilmediğim birçok unsur gerekir gibi geliyor. Bunlar yoksa profesyonel üretimde kullanılması zor olur diye düşünüyorum

• Bu yazıya tamamen katılmıyorum. Vibe coder denen biri, orta düzeyde karmaşıklığa sahip bir sistemi tasarlayıp geliştirirken ve hayata geçirirken her şeyi patlatmadan ilerleyemez
  Claude gibi uygulamaları gerçekten iyi kullanmanın büyük kısmı, bilgisayar bilimi kavramlarına dair kavramsal anlayış ve deneyimden geliyor. Vibe coder’da bunlar asla yoktur. Olsaydı zaten vibe coder olmazdı

• “Ne yapacağımı bilmiyorum” diyorsan, dalgayı sürmen yeterli
  Web siteleri/web uygulamaları dalgayken de onu sürdük. Ben yazılım sektörüne internetten önce girdim ve o zamandan beri sürekli at değiştiriyorum. Yeni teknoloji öğrenmek için asla çok yaşlı değilsin. Yeni dalgalar, yeni iş ve çalışan türleri yaratır. Onlardan biri olman yeterli. Canavarın sırtına bin ve aracı ustalıkla kullan. Aynı oyunun yeniden gelmiş hali bu

  • Katılıyorum
    Sürekli talep gören bir beceri varsa, o da yeni işleri, yeni süreçleri, yeni insanları, kısacası her şeyi zihninde yapılandırabilme yeteneğidir. Ben prototip makinisti olarak çalışırken bu yeteneği keskin bir araç gibi anlamayı ve geliştirmeyi öğrendim. Aşina olmayanlar için söyleyeyim, prototip makinisti; her hafta kısa takvimler içinde zor parçaları üretmek için gerekeni yapan kişidir. Metal, plastik, ne varsa uğraşır. Süreçlere, takım tezgâhlarına ve malzemelere hızla alışmada ustalaşırsın. Bunu bir süre yaptıktan sonra yeni bilgiyi çok hızlı özümseyebilir, işi çoğu insandan çok daha hızlı ve doğru anlayabilir hale gelirsin. Herkes başlayabilir. Merak duyup bir şeyler yapman yeterli. Sonra daha fazlasını yap. Yaptıklarını paylaş ve başkalarının istediği şeyleri üret
  • Genel olarak toplum daha sarsıntılı hissettiriyor ama özünde aynı şarkı ve dans yeniden tekrar ediyor
    90’larda ve 00’larda “nesne yönelimli programlama her şeyi değiştirecek” dalgası vardı. Daha önce yüzlerce kez başarıyla yaptığımız işleri artık nesne yönelimli yapıyorduk. Uçakla ilgili kod mu yazıyorsun? Üniversitede gerçekten, uçağın her işini yapan her şeye kadir bir uçak nesnesi satın alman gerektiği anlatılmıştı. Peki nesne yönelimli yaklaşım her derde deva değil miydi? Kod üretimi, Ruby on Rails’i çalıştır bakalım. 2 saniyede web sitesi yapıyor. Kod üretimi her yerdeydi. Sonra işler tuhaf yönlere gitti ve TDD geldi. TDD yapmıyorsan hapse atılman gereken kadar kötü bir mühendissin diyen gerçek konuşmalar gördüm. Hayır, çözüm TDD değil BDD’ymiş. Lean, hayır Agile, hayır küçük harfli agile, ama başlangıçta buydu, yok hayır Scrum, yok XML, dur o önceki 10 yıldı, sonra JSON ve en sonunda SAFe. Şimdi de “bu chatbotu gördün mü?” deniyor. Her tekrar, dikkat edersen iyi şeyler getirir. Ama beraberinde bolca abartı ve kaygı da getirir. Deneyip öğrenmek yeterli. Benim için değişmeyen tek şey şu oldu: neredeyse herkes, hayali gerçekleştiğinde ortaya çıkacak sonucu dikkatle düşünmektense ölmeyi tercih ediyor. Bu doğru kaldığı sürece insanlar, kendi yerlerine abartılmış moda ejderhasına binecek birilerine para ödemeye devam edecek
  • “Aracı ustalıkla kullan” diyorsun ama bu araçların değer önerisi zaten inşa edilecek bir beceri ya da ustalık olmaması
    Bütünüyle düşük kaliteli çıktı fabrikası akışı, pardon, “AI native” akışı şöyle işliyor. “Vay, chatbotu kandırıp hiç anlamadığım bir şeyi yaptırdım. İşimi ne kadar da iyi yapıyorum!” Bir şey üretmenin katılım ödülü gibi. Başka bir şey üretiyor, ben de pek anlamadan payeyi alıyorum. Harcadığım çabanın bileşik getirisi yok. Çıkarılmış bir ders yok. Biriken bir anlayış yok. Gelecekteki yeniliklere dönüşecek bir içgörü yok. Farklılaşma yok. Sadece akıl uyuşturacak kadar boşluğa bağırıyorsun; sonra slot makinesi “yeterince iyi görünüyor” denebilecek düşük kaliteli bir karışım kusunca ertesi gün aynısını tekrar ediyorsun. Oyun buysa ben yokum. Başkaları bundan keyif alıyorsa ne âlâ ama burada bir ustalık olduğunu düşünmek yanılsama. Bu araçla “başarılı” olmanın tek koşulu, önemsemeyi bırakıp teslim olmak

• Daha önce de paylaşmıştım ama yeniden paylaşmaya değer
  LLM kullanımında çok agresif bir şirkette DevOps işi yapıyorum. Aşamalar kabaca şöyleydi: LLM’e “bir sürü şey” yaptırmak, daha fazlasını yaptırmak, birden çok ajan çalıştırmak, sonra tekrar tek ajana dönüp ona araçlar yaptırmak ve en sonunda hem insanların hem de LLM’lerin kullanabileceği deterministik araçlara gitmek. Sebebi şu. Hem dağıtımda hem testte deterministik araçlar ikili cevap verir ve tekrarlanabilirdir. Bir arıza olduğunda, insanın çalıştırabileceği araçlara her zaman geri dönebilirsin. Daha hızlıdır. Basit betikler 30 saniyenin altında çalışırken, “makul görünen saçmalık” hep 2-3 dakika sürüyor gibiydi. Sonunda yine bu yazıya geri dönüyorsun. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 Yani mesele şu: “işlerin listesini yap, her işin betiğini yaz, betikleri fonksiyonlar olarak birleştir ve fonksiyonlar sistem olsun.” Şunu da ekleyeyim: LLM’i istediği gibi bırakırsan memnuniyetle kod yazar. Testler ekleyip testlerin çalıştığını doğrulayabilirsin. Eskiden de insan yazdığı kod için bunu yapıyordun zaten. Kodu da okuyabilirsin. Kodu okuyunca, çalışan kod üretirken aynı zamanda tamamen çılgınca şeyler yapabildiğini görüyorsun. İnsanlar da yapıyor ama o ayrı mesele. Sonuçta ortaya çıkan sistemin mantıklı olup olmadığını yine de kontrol etmen gerekiyor. Daha basit söylersek, kodlama ölmüş olabilir ama yazılım mühendisliği gayet canlı ve sapasağlam koşuyor

  • Doğru yaklaşım bu
    Büyük LLM’lere her şeyi yaptırabilirsin. Mümkün ve gerçekten de yapılıyor. Ama inanılmaz pahalıya mal oluyor ve uzun sürüyor. Onun yerine AI ile araçlar geliştirip sürecin mümkün olduğunca çok adımını deterministik şekilde işletir, sonra AI’nin bu araçları kullanmasını sağlarsan sistem çok daha hızlı ve ucuza çalışır. Üstelik sonunda pahalı bulut AI’sını bırakıp küçük/orta ölçekli yerel modellerle de çalıştırabilirsin

• Yazarın gelecek tasviri doğruysa, yetkin yazılım mühendisleri güvende olacaktır
  Alan bilgisi, iyi mühendislik ilkelerinin nasıl uygulanacağını öğrenmekten çok daha hızlı öğrenilebilir. Asıl rekabet avantajı alan bilgisi olan bir mühendis, mühendisliğin kendisinde o kadar da üstün olmayabilir. Yine de biriktirdiği alan bilgisi gerektiren sektörün başka kısımlarında iş bulabilir

  • Bir hafta önceki tam başlıkta, alan uzmanlığının her zaman asıl hendek olduğu söylenmişti: https://news.ycombinator.com/item?id=48340411
  • Alan bilgisinin iyi mühendislik ilkelerinden çok daha hızlı öğrenilebileceği iddiasının genel olarak doğru olduğundan emin değilim
    Kolay elde edilebilen alan bilgisi diye kibirlenen iyi yazılım mühendisleri, sayısız ERP sistemini mahvetti. BT'nin çok büyük bir kısmı, kelimenin tam anlamıyla iş kurallarını sisteme yerleştirmekten ibaret
  • Kısmen katılmıyorum. Büyük çerçevedeki alan bilgisi hızlı öğrenilebilir, ancak bunu karmaşıklığı hesaba katan incelikli bir kavrayışla rafine etmek, özellikle kendine özgü organizasyonlarda, çoğu zaman “yazılım geliştirme şirketi” olarak görülmeyen yerlerde, yıllardan on yıllara kadar sürebilir
    Buna rağmen iyi yazılım mühendisliği pratiklerini izlemeyen “uzman” yazılım geliştiriciler hâlâ görüyorum ve kodlarını inceliyorum. Asıl rekabet avantajı alan bilgisi olan mühendislerin mühendislikte çok iyi olmayabileceği iddiası, alan bilgisi olmayan mühendisler için de aynı ölçüde geçerli. En azından benim deneyimimde böyle. Belki biz şanssızdık
  • Değerli alan bilgisinin geliştirilmesi ve edinilmesi zor, riskli, pahalı ve yavaş bir süreçtir
    Çünkü değerli alan bilgisi, dünkü değil bugünün ve yarının bilgisidir. Alan bilgisinin önemli olduğu alanlarda bu bilgi mühendislikle derinden iç içedir. Jeff Dean'e Unreal Engine'i sıfırdan geliştirme görevi vermezsiniz. Yine de alan bilgisi uzmanlarının tam olarak içselleştirmediği ya da yeterince uygulamadığı birçok yazılım mühendisliği ilkesi vardır. Alan bilgisi değerli olduğu sürece bu durum da sürecektir. Çünkü yazılım mühendisliği de başka bir alandır
  • Alan bilgisini daha hızlı mı öğrenebilirsiniz? Ben aksi görüşteyim
    Metodoloji, uzmanlık bilgisini edinmekten çok daha hızlı geliştirilebilir. İlki yaklaşım meselesidir; bu yüzden zorunlu kılınabilir ve hızla yukarı çekilebilir. İkincisi ise kişinin öğrenme eğilimine, kapasitesine ve o anki müsait zamanına bağlıdır; makul destekten fazlasıyla zorlanamaz. Ayrıca birikimli bir yapısı vardır, bu yüzden erken öğrenme eğrisi çok daha diktir

• Claude Code ve Opus 4.7 kullanıyorum; ürettikleri kod yanlış olmaktan çok fazla yazılma eğiliminde
  Belirli bir özelliği düşünüp bunu koda en uygun şekilde yerleştirme biçimi hâlâ değerli. Claude çoğu zaman yığının bir katmanını, örneğin sunum katmanını seçip her şeyi oraya itiyor. Birkaç hafta sonra aynı veriye başka bir yerde de ihtiyaç duyulursa, Claude hizmet katmanındaki kodu yeniden kullanamıyor ve bir tür “nakil” yapıyor. İnsan dikkat etmezse kod miktarı ikiye katlanıyor ve mantık yineleniyor. Claude gibi yapay zeka araçlarının bu konuda yakında daha iyi olacağını sanmıyorum. Çalıştığım yerde zaten maliyeti kısmak için Opus 4.7 kullanımını azaltmamız yönünde baskı var. Birisi “basit hata düzeltmeleri” için daha küçük modeller kullanalım dedi. Bazen işe yarayabilir, ama gerçekte bunun önceden basit bir hata düzeltmesi olduğunu ne kadar sık anlayabilirsiniz? Maliyet arttıkça bu araçla “tüm kodu” yazma isteğinin azalacağını düşünüyorum. İnsanlar daha ucuz ve daha az etkili modellere geçerse, o kodu incelemeyelim yönündeki baskı da büyük olasılıkla ortadan kalkar. Sonunda nereye varacağını göreceğiz ama yazarın korktuğu kadar dramatik şekilde değişmeyebilir

  • AI'ın çok fazla kod yazdığı eleştirisine katılıyorum
    AI'a üretim kodu satır sayısını yarıya indirmesini ve yeniden kullanılabilecek başka kütüphaneler olup olmadığına bakmasını söylemek bile şaşırtıcı derecede etkili. Yinelenen kısımları bulup çıkartan bir refactoring botu da yapılabilir gibi görünüyor. Şu an varsayılan olarak yok ama imkânsız olduğu da açık değil
  • Ben de kodun gereğinden fazla büyümesi sorununu görüyorum
    Ama açık soru şu: fazla kod gerçekten bir sorun mu? Bu araçlar artık hayatın bir parçası. Sorunları daha hızlı çözüyor veya debug etmeyi hızlandırıyor ve yazılımda daha az bug oluyorsa, bu fazla kod değil, tam olması gereken satır sayısı olabilir
  • Kısa süre önce kod tabanında fooBar() ve fooBarExtended() adlı iki fonksiyonun bulunduğu bir durum yaşadım
    İkincisi, mevcut sorun için gerekli ek parametrelere ve işlevselliğe sahipti. Ama Claude, o fonksiyonu çağırmak yerine ilk fonksiyona aynı genişletme parametrelerini eklemeye devam etti. Bunu yapmamasını söyledikten sonra bile daha sonra yine aynı öneriyi sundu ve bazen gerçekten sinir bozucu oluyor

• Sektörün geleceğini nasıl görürseniz görün, zanaat marangozlukta zanaat yazılımdan daha büyük mesleki başarı bulmanın zor olduğunu düşünüyorum

  • Özel mobilya/dolap pazarı zaten epey zor; marangozluk da programcılar arasında fazla yaygın bir hobi, dolayısıyla önemli bir kısmımız bu alana girerse pazar kısa sürede ciddi biçimde arz fazlasına düşer
    Bana yaptığım mobilyaları satmayı denemem söylendiğinde cevabım hep aynı oluyor. Hobiyi mesleğe çevirme hatasını bir kez yaptım, aynı hatayı tekrar yapmayı düşünmüyorum. En azından yazılım hâlâ oldukça iyi para ödüyor
  • Marangozluğu ne olarak gördüğünüze bağlı
    Birlikte çalıştığım kişilerden biri deck, bahçe, karavan, depo ve çit gibi şeyler yapıyor ve gerçekten çok iyi kazanıyor. Gerçi adil olmak gerekirse adam inanılmaz derecede yetenekli
  • El oyması, benzersiz şekilli kapıları olan tarihi bir evim var
    Kapı kasası çürüdüğü için bir marangozcuya yerine yenisini yapması için 4 bin dolar ödedim. Kapının kendisini değiştirmek ise rahatlıkla 25 bin dolara mal olur. El oyması kapıların çok olduğu büyük bir tarihi bölgeye taşınırsanız gayet iyi para kazanabilirsiniz
  • Pazarın çok küçük bir kısmı, muhtemelen %1'den bile azı, hâlâ el yapımı ürünlere para ödemeye istekli. Tam modern ama retro bir havası varsa bonus bile olur. Örneğin steampunk klavyeler gibi
    Ama el yapımı yazılıma para ödemek isteyen pazar oranı tam olarak %0
  • layoffs.fyi'ye bak. Yakında işten çıkarılma ihtimalin yüksek. Yarın olmasa bile AI biraz daha iyileşene kadar birkaç yıl ver yeter. Bu aşağı yönlü tek yönlü bir yol
    Çözüm marangozluk değil, çiftçilik. Bir arazi edinip kendi yiyeceğini yetiştirmen gerekiyor. Ekonomiye hiç katılmamak, hayatta kalmanın tek yolu