AI: Hızlandırılmış Yetersizlik

• Yazılım mühendisliğinde LLM'lere aşırı bağımlılık, yetersizliği hızla teşvik eder
• LLM'lerin eleştirel düşünme ve problem çözme becerilerinin yerini alamayan sınırları vardır
• LLM kullanımı; hatalı çıktı, hatalı girdi, kod kalitesinde düşüş, geliştirici becerilerinde gerileme, üretme zevkinin kaybı gibi çeşitli riskler taşır
• LLM'ler, program teorisi ve program entropisi gibi özsel geliştirme yetkinliklerini sağlayamaz
• Uzun vadede teknik yetkinlik ve derin düşünme becerisi her zamankinden daha önemlidir

---

Giriş

2022'nin sonunda kamuoyunun ilgisini çeken AI ve LLM'lerin ortaya çıkışından sonra birçok tartışma devam etti.
Deneyimli bir yazılım mühendisi olarak, LLM'lerde gözlemlediği iki temel sorunu anlatıyor.

"LLM benim arkadaşım" bakış açısı

LLM'yi en iyi araç olarak gören mühendisler, hızı en öncelikli değer haline getirir.
LLM ile hızla çok fazla kod üretilebilir, ancak bu durum uzun vadeli riskler barındırır.

LLM kullanımının riskleri

• Hatalı çıktı riski: LLM'ler açıkça yanlış kodlar (derlenemeyen) ve ince hatalar içeren kodlar (mantık hataları vb.) üretir.
  • Değerlendirme yetkinliği olmayan kişiler kaynak kod istediğinde uygun olmayan yanıt alma olasılığı yüksektir
• Hatalı girdi riski: LLM'ler hatalı varsayımları veya bağlamı eksik prompt'ları eleştirmez.
  • Doğru soruyu ayırt edemez ve XY problemiyle de (kök nedeni saptayamama) empati kuramaz
• Gelecekte geliştirme hızının düşmesi: LLM benimsenmesi teknik borcu hızla artırır ve içeride dağınık, bakımı zor bir kod tabanına dönüşür
• Kullanıcının körelmesi riski: Problem çözme ve düşünme becerilerinin gelişme fırsatı ortadan kalktıkça geliştirici yeteneklerinin gerilemesi hızlanır.
  • Kıdemli geliştiriciler daha derin problem çözme deneyimi edinemez, junior geliştiriciler ise hiç beceri geliştiremez hale gelir
• Üretmenin sevincinin kaybı: LLM tabanlı kod yazımı akış (flow) durumunu ve üretme sevincini elinden alır; AI'ın yazdığı kodu okuyup değiştirmek ise çoğu zaman sancılıdır

"AI yüzünden işimi kaybeder miyim?" kaygısı

Bunun olasılığı oldukça düşüktür.
LLM'lerin yerine koyamayacağı iki geliştirme yetkinliği vardır: program teorisi ve program entropisi.

Program teorisi

• Peter Naur'un savunduğu gibi, "programlama, tasarım teorisi inşa etme etkinliğidir".
  • Kaynak kod asıl çıktı değildir; kolektif anlayış (teori) daha önemlidir
  • Aynı yetkinlikte iki takıma aynı problem verilip yalnızca kod teslim edildiğinde, kodu bizzat yazan ekip yeni özellik eklemeyi çok daha etkili şekilde yapabilir
  • Alışılmadık bir kod tabanında üretkenlik düşüktür; içsel tasarım teorisi anlaşıldıkça üretkenlik giderek artar

LLM'ler ve program teorisi

• LLM'ler yalnızca bağlam içi belleğe sahip olduğundan, gerçek bir program teorisini ya da derin tasarımı içselleştiremez.
  • Gerçekte kodlamanın özünü oluşturan şey (tasarım ve teori inşası) yalnızca insanlar tarafından edinilir

Program entropisi

• Fred Brooks, karmaşıklığı (entropiyi) programlamanın temel zorluğu olarak tanımlamıştır.
  • Program bakımı karmaşıklığı artırır; en iyi uygulamalar bile sistemi geri döndürülemez biçimde yaşlandırır

LLM'ler ve program entropisi

• LLM'ler yalnızca metin düzeyinde token tahmini yapar; fikirler, tasarım planları ve gereksinimler düzeyinde anlamsal düşünme gerçekleştiremez.
  • Uzun konuşmalar veya büyük kod parçalarıyla uğraştıkça gereksiz ya da tuhaf değişiklikleri tekrar tekrar üretip yalnızca karmaşıklığı artırır
  • Karmaşıklığı azaltmak ya da ona direnmek ancak insanların yapabileceği bir iştir

Sonuç

İki öncünün içgörülerine dayanarak yazılım tasarımının ve karmaşıklığın doğası yeniden teyit ediliyor.
AI'ın geliştirici kariyerini iyileştireceğini umuyorsanız, tersine yetersizliğin hızlanması riskine dikkat etmelisiniz.
Zengin deneyime ve olgun becerilere sahip bir geliştirici olarak, LLM'lerin insan mühendislerin yerini alamayacağını kabul etmek gerekir.
AI benimsemesinin iş tarafındaki cazibesi maliyet düşürmektir; ancak gerçekte yeni riskler doğurur ve aşırı kullanımda uzun vadeli ek maliyetler ile kurumsal riskler birikir.
Teknik yetkinlik ve derin düşünme becerisinin önemi uzun vadede değişmez; AI araç olarak kullanılmalı ve 2019'da da önemli olan özsel yetkinliklere yatırım yapılmaya devam edilmelidir

Sonraki yazı duyurusu

Bir sonraki yazıda her bir risk için somut çözüm yolları ele alınacak.

Kaynakça

• Leading Question: https://en.wikipedia.org/wiki/Leading_question
• The XY Problem: https://en.wikipedia.org/wiki/XY_problem
• ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
• Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
• Thoughts on Thinking: https://dcurt.is/thinking
• The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
• "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
• Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
• Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
• Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle

[GN⁺]

Hacker News görüşleri

• Bazen AI ile kodlama tartışmalarının yazılım mühendisleri ile veri bilimciler/makine öğrenimi mühendisleri arasındaki farkı yansıttığını hissettiren deneyimler paylaşılıyor
  Yazılım mühendislerinden her zaman öngörülebilir ve testleri geçen yazılım üretmeleri beklenir; araçlar da çok daha gelişmiştir
  Buna karşılık makine öğrenimi mühendisleri için olasılıksal modellerle çalışmak günlük hayatın doğal parçasıdır ve testler de çoğu zaman belirli çıktılardan çok metrik odaklı değerlendirmelere dayanır
  Bu yüzden AI'nın her zaman güvenilir olmamasına daha alışıklardır
  Kodlama asistanlarına da, %80 doğru verse kalan %20'yi benim yakalamam yeter yaklaşımıyla bakılır
• Benim deneyimimde de yaklaşık yarısı benzerdi
  Amazon'da çalışırken klasik yaklaşımı olmayan sorunlarda ML tabanlı çözümler çok faydalı olmuştu
  Ama bir startup'ta, temel filtreleme ya da eşleme mantığını anlamadan sadece öğrenme tabanlı yaklaşımda ısrar edilince, duran bir uçağın duruş tahmininde tekrar tekrar saçma sonuçlar üretildi
  ML ile SW mühendisliği arasındaki bu uçurum çok belirgin; keşke bunu işe alım sürecinde daha iyi ortaya çıkaracak bir yol olsa
• Şu anki atmosferde MLE zihniyetinin başka gruplara da zorla uygulandığı hissi var
  Doğruluk ve kesinliğin kritik olduğu ürünler satan bir şirkette, ML tarafındaki ekiplerin %80~90 yeter dediğini ve buna karşı bir mimarın duyduğu rahatsızlığı gördüm
  Pandemide %1 ölüm oranı tartışmalarında olduğu gibi, küçük yüzdelerin bile büyük etkileri olabileceğini hatırlatıyor
• Deterministic davranış ile probabilistic davranış arasındaki farktan söz ediliyor
  Bu yazı, AI ile yazılım mühendisliği üzerine üst düzey bir kaygıya, yani program entropisinin yönetimine odaklanıyor
  Entropi yönetimi yazılım ürünü inşa etmenin çok büyük bir parçası; AI bir gün bunu kolaylaştırabilir ama bugün çoğu zaman entropiyi daha da kötüleştiriyor
• Şu anda AI'ya, özellikle ML'ye odaklı bir yüksek lisans yaparken SWE olarak yeni kaslar geliştiriyorum
  MLE'yi SWE'nin daha geniş perspektifi içinde görüyorum; sağlam pipeline kurma, model entegrasyonu, dağıtım gibi bütünsel bir anlayış gerekiyor
  Ancak çoğu saf MLE mezununda SWE bakışı eksik; bilgisayarsal sezgi olmadan sadece ML'i anlayan çok kişi var
  Gerçek anlamda full-stack olmak için düşük seviyeli sistemleri, mimariyi, dağıtımı ve MLE'yi birlikte anlamak şart
  Ama piyasadaki işe alımlar çoğunlukla ya SWE ya da MLE doktorası arıyor; bunların hepsini bilen bana bir ödül teklif edilse fena olmaz
• Yazılım mühendisleri de aslında sık sık olasılıksal düşünme kullanıyor
  Örneğin race condition'ları yeniden tasarlarken, DB çağrılarının p99'unu tahmin ederken ya da A/B testlerinde
• Genel olarak makalenin iddiasına katılıyorum ama LLM kullanırken ortaya çıkan bazı olumlu değişimler de gördüm
  30 yıllık deneyime sahip kıdemli bir geliştirici olarak, AI tarafından üretilen kodu okumak zorunda olmak, geliştirme sürecinin kod inceleme merkezli bir akışa kaydığı anlamına geliyor
  Bu, bireysel geliştiriciler için bile ekip düzeyinde sorumluluk duygusu ve kod okuma deneyimi kazanmaya yardımcı oluyor
  Ayrıca LLM'i düzgün kullanmak için problemin katmanlı yapısını anlama yeteneği şart
  Bölüm bölüm ayrıntılı tasarlayıp uygulatmak, doğal olarak arayüzleri ve sınırları tanımlamaya da yardımcı oluyor
  LLM, junior'ın senior'a dönüşme hızını artıran bir katalizör; deneyimli geliştiricilerin öğrenme sürecini deneyimlemeye yardımcı oluyor
  AI geliştiricilerin yerini almayacak; sonunda bir araç olarak işin içine işleyecek
  • Her zaman, yazdığım koddan daha fazlasını okumam gerektiğini düşünüyorum
    LLM tarafından üretilen kod monoton olabilir ama bu da bir öğrenme fırsatı
    LLM üretimi kod sayesinde birçok yeni kalıp/deyim ve kütüphane çağrısı öğrendim
    Senior'lar daha iyi prompt verebildiği için LLM onlar için daha güçlü bir katalizöre dönüşüyor
  • AI, kodu en azından prototip seviyesinde oluşturup kopyala-yapıştır yapmak için çok iyi ama inceleme ve commit aşamasını üstlenemez
  • Şirket açısından bakıldığında AI, junior'lara yardım etmekten çok junior işe alımını ortadan kaldırmak ve senior'lardan AI ile 10 kat üretkenlik istemek için bahane oluyor
    Big Tech, Mid Tech, Small Tech fark etmeksizin işten çıkarmalar sürüyor
• AI tartışmasını, eskiden 3D printing'in tüm üretimi değiştirip değiştirmeyeceğine dair düşüncelere benzetenler var
  İddiaya göre AI, singularity'den çok buna benzer gerçekçi değişimlere daha yakın
  • 3D printing gerçekten harika ve yenilikçi bir teknoloji ama injection molding hâlâ yerinde duruyor
  • 3D printing singularity getirmedi ama üniversite eğitimi gibi bilgi emeği alanlarında AI zaten büyük etki yaratıyor
    Eskiden doğal kabul edilen ders/ödev/sınıf düzenlerinin LLM'lerin ortaya çıkışıyla dünya çapında hızla değiştiği anlatılıyor
  • 3D printing, havacılık, uzay ve başka birçok sektörde çok büyük değişim ve yenilik getirdi
    SpaceX olmasaydı pratikte mümkün olmayacak pek çok alan vardı
  • Bu, Bitcoin'in bankaların yerini alacağı beklentisine de benziyor
    Sonunda bankalar Bitcoin tabanlı finansal ürünler satar hale geldi
  • 3D printing ile AI tamamen farklı büyüme eğrilerine sahip
    3D printing mevcut üretimin yerine geçen bir şey olarak görülmüyor; daha çok prototip/mockup/PoC aracı olarak kalıyor
• LLM'ler kod yazmada çok iyi olabilir ama 'sorumluluk' taşıyan özne olamaz
  Anlamadan kabul edilen kod, sonradan bakım sırasında büyük bedel, yani teknik borç doğurur
  Sanki bedava hız kazanılmış gibi görünür ama gerçekte %40 yıllık faizle teknik borç birikir
  AI sadece yazmayı otomatikleştirmeli; düşünme işi insanda kalmalı
  • LLM gerçekten 'anlamadığı' için, gerçek comprehension ancak insan kod tabanının bağlamını ve sistemi anladığında ortaya çıkar
  • Testing ve izole alt sistemler kurma (tdd, mikroservisler vb.) ile faiz oranını, yani teknik borcu azaltma önerisi var
    Bazılarına göre geleneksel geliştirmede gereksiz görülen tdd ve mikroservisler, LLM çağında daha değerli hale geliyor
  • Göreve bağlı olarak AI bazen kod yazmada bile çok kötü olabiliyor
• En büyük acı noktası input risk olmuştu diyen bir deneyim var
  Prompt'taki küçük bir belirsizlik bile sonucu tamamen raydan çıkarabiliyor ve bunu fark ettiğinizde sonradan toparlamak zor oluyor
  İnsan dilindeki belirsizlik yüzünden zaten sonunda açık biçimsel diller doğdu
  Kişisel olarak AI araçlarını kullandıkça becerilerimin hızla köreldiğini hissettim; hatta bazı durumlarda daha fazla zaman ve enerji harcadım
  AI faydalı ama bir tarafta karmaşık problemler içinde küçük hataların biriktiğini görenler, diğer tarafta sadece sonuca bakıp rol değişimi oldu diyen yöneticiler/teknik olmayanlar var gibi görünüyor
  [Ayrıntılı deneyim: önceki yorum]
  • AI'yı yardımcı olarak kullanmak ve kalite/bakım sorumluluğunu doğrudan kendinizde tutmak öneriliyor
    Hesap makineleri insanların zihinden hesap becerisini zayıflattığı gibi, AI da yazma, iletişim ve problem çözme becerilerini zayıflatabilir
  • Belirsiz kelime girişlerinin LLM'de mantıksız sonuçlara yol açtığı deneyimler paylaşılıyor
    Bu yüzden LLM'i sadece küçük ve net görevlerde, StackOverflow'da aranacak türden sorunlarda kullanıyorlar
    Yanıtları mutlak doğru olarak değil, yol gösterici olarak görüyorlar
  • AI bazı sorunları daha hızlı çözse de gereğinden fazla karmaşık hâle getirdiği sorunları çözemiyor
    İnsanın bütün tasarım planını anlama kapasitesi, entropiye direnmenin çekirdeği
  • Sık kullandığı yöntem şu: önce LLM'e "3 tur boyunca, her seferinde 5 tane net soru sor" demek
    Bu sayede konu ve bağlam daha berrak hâle geliyor
    Bu küçük ipucunun başkalarına da faydalı olmasını umuyor
  • Bu hype dönemi geçtikten sonra, kalite kontrolün öneminin yeniden keşfedileceğine dair bir his var
    Örnek: eski Coke vs Pepsi savaşı
• LLM'lerin fikirleri, diyagramları ve spesifikasyonları kavramsal olarak ele almadığı iddiasına katılmak zor diyenler de var
  LLM'e "daha sade kod ver" gibi tasarım niyetini içeren sorular sorulursa oldukça iyi bir ikinci görüş alınabildiği söyleniyor
  Soru sormazsanız zaten cevap da gelmez; varsayılan ayarlar da bizim seçimimiz olduğundan bunun temel teknolojiyle ilgili bir itiraz olmadığı düşünülüyor
  • LLM'lerin kavramsal iş yapabildiği pek çok biçimde ampirik olarak zaten gösterildi deniyor
    Gerçekte hiç kimse dev bir programın tamamını zihninde tutamaz; araçlar ve diller de çoğunlukla kısmi anlayış üzerine gelişti
    LLM'ler de aynı sınırı paylaştığı için bu çerçevede insanla benzer sınırlara sahip
  • Junior kod incelemesinde, kodun kalitesinden çok yön sorunu gördüğünü söyleyenler var
    LLM'in o yönelim için "neden bunu böyle yapıyorsun" diye sormakta zorlanması eksiklik olarak görülüyor
  • Kod→diyagram dönüşümünü otomatik yapan araçlar kullanılıp kullanılmadığı, yoksa bunun elle mi yapıldığı soruluyor
• Google/Apple Maps gibi harita yazılımlarının insanın yol bulma becerisini körelttiği iddiasına benzetenler var
  Bir yanıyla doğru olsa da çoğu insan zaten baştan iyi yön bulamıyordu; harita teknolojisi sayesinde A→B gitme becerisi ortalama olarak arttı deniyor
  Az sayıdaki yetenekli kişi için bile teknoloji, onların becerisini ortadan kaldırmaktan çok destekliyor
  AI da daha büyük ölçekte benzer bir değişim getirecek; bazı beceriler zayıflayacak ya da kaybolacak ama kazanımlar da olacak
  • Haritalar güvenilirlik açısından LLM'lerle kıyaslanamaz
    Haritalar neredeyse her zaman beklenen değeri verirken, LLM'ler aynı prompt'ta bile farklı sonuç verdiği için güven vermiyor
    İnsanlar harita yüzünden göle de düşebiliyor ama LLM'e körü körüne güvenmek daha büyük sorunlara yol açabilir
  • Kişisel olarak harita yazılımı kullanmanın uzamsal hafızaya daha çok yardımcı olduğunu düşünüyorum
    İstediğim kadar dolaşıp gerektiği anda rotayı açabildiğim için deneyimim aslında güçleniyor
  • Google Maps, taksi şoförlerinden %90'dan fazla daha doğru
    AI ise bazen o alanda birkaç gün geçirmiş sıradan bir insandan bile daha kötü
  • 'Ortalama beceri artışı' iddiasını destekleyen kanıt olup olmadığı sorgulanıyor
• Yazarın '[AI] kavramsal düzeyde çalışamaz' iddiasına katılmayanlar da var
  Son dönem LLM'lerin açıkça kavramsal düzeyde çalışabildiği, örneğin kavram çevirisi/uygulaması yapabildiği söyleniyor
  Hatta insanın kişisel olarak deneyimlemediği kavramları bile anladığı iddia ediliyor
  • LLM'ler kavramları token kümeleri üzerinden modelliyor
    Örneğin 'dog' çevresinde ilişkili kelimeler toplanıyor
    Ama kombinasyonları, niyeti ve karşıolgusal mantığı modelleyemiyorlar
    Eğitim verisine benzeyen sorularda güçlüler
    Yazılım mühendisliği gibi kavramsallaştırmanın iyi tanımlandığı alanlarda işe yarıyorlar
  • İnsanların da doğrudan deneyimlemediği kavramları anlayabildiğine dair ek örnekler veriliyor
• Gerçekte çalışanların %70'i işini zaten savsaklıyor; bazen AI daha iyi bile olabilir diyenler var
  Sonuçta işini ciddiye almayan kişi AI kullansa da değişmez; gerçekten öğrenenler ise AI ile birlikte gelişir
  • Kişinin kendisini o %30'luk iyi kesime koymasının benmerkezci bir anlatı olduğu eleştiriliyor
  • AI ile işi savsaklamaya çalışanlar aslında işten çıkarılma riskini artırıyor
    AI işi daha iyi yapıyorsa, sadece işin sahibini değiştirmek için gerekçe yaratılmış olur
  • Büyük şirketler açısından bunun en gerçekçi yorum olduğu söyleniyor
    FSD de uzman olmayan sıradan sürücülere kıyasla çok daha iyi
• Son dönemde 90s.dev'i AI dışı bir topluluk, yazılım zanaatkârlığına ayrılmış bir alan olarak yeniden kurma ihtiyacı hissedildiği paylaşılıyor
  Forum, mailing list, çok yazarlı blog gibi formatlar düşünülüyor
  Geçici mailing list
  • Herkesin katılabildiği yapıdan ziyade, davet tabanlı ve referans güven ağacı yapısının daha sürdürülebilir topluluklar için uygun olduğu düşünülüyor
    Bunun bazı topluluklarda zaten başarılı örnekleri olduğu söyleniyor
  • O dönemin klasik forum yazılımlarını retro tasarımla kullanmak da iyi bir fikir olarak görülüyor