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

• Yazılım mühendisliğinde LLM’lere aşırı bağımlılık, kısa vadede hızı artırsa da eleştirel düşünme ve problem çözme becerilerini zayıflatabilir
• Hatalı çıktılardan daha büyük risk, kusurlu prompt’ları olduğu gibi kabul etmek ve bunun sonucunda teknik borcun ve kullanıcı yetkinliği kaybının hızla birikmesidir
• LLM’ler mevcut bağlam penceresinin ötesinde program teorisini hatırlayıp içselleştiremediği için, tasarım ve bakım için gerekli ortak zihinsel model insan mühendislerin alanı olarak kalır
• Karmaşıklık bakım sürecinde sürekli artar ve metin düzeyinde çalışan token tahminleyicileri olan LLM’ler gereksiz ya da tuhaf değişikliklerle program entropisini büyütebilir
• AI bir araç olarak kullanılabilir, ancak koltuk değneği gibi ona yaslanılmamalıdır; 2019’da da değerli olan temel mühendislik yetkinliklerine ve derin düşünmeye yatırım sürmelidir

---

LLM bağımlılığının yarattığı mühendislik riskleri

• LLM’leri “arkadaş” gibi adlandıran yaklaşım, gerçek bir yoldaştan çok kullanıcıya fayda sağladığını ima eden örtülü bir ifadedir
• Bu bakış açısındaki mühendisler çoğunlukla hızı önceliklendirir ya da hızı öncelemeleri için baskı görür
• LLM’ler çok miktarda kodu hızlıca üretebilir, ancak kullanımlarına uzun vadeli riskler eşlik eder

Kod üretiminde ortaya çıkan beş risk

• Çıktı riski

  • LLM’ler derlenmeyen kod gibi açıkça yanlış sonuçlar üretebilir
  • Daha tehlikeli olan durum, mantık hataları gibi daha ince ve tespit edilmesi zor yanlış sonuçlardır
  • Prompt’u yazan kişinin sonucu değerlendirecek yetkinliği yoksa risk büyür
  • Buna örnek olarak bir proje yöneticisinin kaynak kod istemesi verilir

• Girdi riski

  • LLM’ler yönlendirici sorulara, yanlış varsayımlara ya da eksik bağlama sahip prompt’lara itiraz etmez
  • Örneğin “C#’ta thread-safe bir liste implementasyonu ver” isteğine 200 satırlık makul görünen bir kod çıkabilir; oysa gerçek soru “Bu kodu thread-safe hale getirmek için ne yapmalıyım?” olabilir
  • Bu durumda yanıt, System.Collections.Concurrent kullanan tek satırlık bir kod olabilir
  • LLM, kendisinden istenmediği için XY Problem örneğini fark etmez

• Gelecekte hız kaybı

  • LLM’ler bir kod tabanının kalitesini çok hızlı biçimde düşürebilir
  • Güçlü koruyucu önlemler yoksa, LLM tarafından üretilen kod dışarıdan düzgün görünse de içeride hijyenden uzak ve işlevsiz bir alana dönüşebilir
  • Bu, genel teknik borç tartışmalarından daha acil bir sorun olarak ele alınır

• Kullanıcının çocuklaştırılması

  • Düşünmeyi ve problem çözmeyi LLM’lere devreden bireylerde ve organizasyonlarda yetenekler körelebilir
  • Kıdemli mühendisler, verimli mücadele yoluyla öğrenme fırsatını kaybederek problem çözme ve eleştirel düşünme becerilerinde zayıflama yaşayabilir
  • Junior mühendisler ise bu becerileri en baştan geliştiremeyebilir ve sonrasında geleceğin junior’larına mentorluk yapmakta zorlanabilir
  • ThoughtWorks Technology Radar Volume 32, AI kaynaklı özgüvenin bazen eleştirel düşünme pahasına geldiğini ele alır
  • Coding as Craft: Going Back to the Old Gym, kodlamayı bir zanaat olarak koruyan bilinçli AI iş birliğini vurgular
  • Thoughts on Thinking, LLM’lerin tamamlanmış düşünceler verebildiğini ama kişinin kendi başına geliştirdiği entelektüel büyümeyi sağlayamadığını savunur

• Keyif kaybı

  • Pek çok geliştirici, AI kullanımının akış halini ve üretmenin keyfini ellerinden aldığını bildiriyor
  • AI tarafından üretilen kod, okunması ve değiştirilmesi eziyetli bir koda dönüşebilir
  • İlgili yazı olarak The Hidden Cost of AI Coding bağlantısı verilir

LLM’lerin yerine geçemediği iki yetkinlik

• Yetkin mühendislerin AI yüzünden gereksiz hale geleceği yönündeki kaygıya karşı, LLM’lerin sağlayamadığı programlama becerileri iki başlıkta toplanır
• Bu yetkinlikler program teorisi ve program entropisidir

Program teorisi: Kod, programın kendisi değildir

• Peter Naur’un Programming as Theory Building makalesi, programlamayı bir probleme dair içgörü ya da teori oluşturma faaliyeti olarak görür
• Naur’un bakış açısında program, kaynak kod değil; paylaşılan zihinsel bir yapı, yani teori veya tasarımdır
• Kod bu tasarımdan türese de asıl değerli çıktı koddan çok tasarımın kendisindedir

• İki takım düşünce deneyi

  • Aynı yetkinlikteki iki takım A ve B, birbirleriyle iletişim kurmadan ayrı odalarda bulunur
  • A takımı terminal tabanlı bir satranç oyunu gibi bir program yazar, B takımı ise bekler ya da gerçekten satranç oynar
  • A takımı bitirdikten sonra kaynak kod B takımına verilir ve her iki takımın da sanal satranç oyuncusu gibi bir özellik eklemesi gerekir
  • Daha iyi çözümü üretmesi beklenen takım A’dır
  • Çünkü A takımının, az önce yaptığı programa dair taze bir zihinsel modeli vardır
  • B takımında ise böyle bir model yoktur
  • Programlar ilk üretimden sonra sürekli değiştirildiği için, yalnızca kaynak koda sahip olup tasarıma dair içselleştirilmiş bir anlayış olmadan değişiklik yapmak pahalıya mal olur
  • Bu, büyük bir mevcut kod tabanına ilk kez girildiğinde üretkenliğin neredeyse sıfıra yakın olup, kişi kafasında program teorisini kurdukça üretkenliğin artması deneyimiyle bağlantılıdır

• LLM’ler ve program teorisi

  • Günümüz LLM’leri bağlam penceresinin ötesini hatırlayamadığı için teoriye, tasarıma ve zihinsel yapılara hakim olamaz
  • Program teorisini edinip koruyabilen varlık insandır

Program entropisi: Karmaşıklığı azaltma ya da ona direnme becerisi

• Karmaşıklık, programlamanın karşısındaki temel kuvvettir ve entropiyle ilişkilidir
• Fred Brooks’un The Mythical Man-Month kitabı, program inşasını entropiyi azaltma süreci; bakımı ise entropiyi artırma süreci olarak görür
• Brooks’un bakış açısından, ilk inşadan sonra programda yapılan değişiklikler kaynak kodu kaçınılmaz olarak daha karmaşık hale getirir
• Ancak tasarımla uyumlu değişiklikler, karmaşıklık artış hızını yavaşlatabilir

• LLM’ler ve program entropisi

  • LLM’ler birer token tahminleyicisidir ve yalnızca metin düzeyinde çalışır
  • LLM’ler fikirler, diyagramlar ya da gereksinim tanımları gibi kavramsal düzeyde akıl yürütemez
  • Büyük kod parçalarını LLM’lere veren herkes, onların gereksiz ve tuhaf değişiklikler uygulama eğilimini görebilir
  • Konuşma uzadıkça sonuçlar daha da sapabilir
  • Kodun karmaşıklığını azaltma ya da karmaşıklığa direnme yeteneği insanlarda bulunur

Mühendislikte AI kullanma biçimi

• Eğer AI’ın mühendislik kariyerini bir üst seviyeye taşıyacağını umduysanız, bunun tersi de gerçekleşebilir
• LLM’ler yetersizliği hızlandırabilir, ancak insan mühendisliğinin yerini alamaz
• AI’ın iş dünyasındaki çekiciliği, mühendisliği metalaştırarak maliyetleri düşürmesinde yatar
• Ancak yurtdışı mühendislik yeteneğinden yararlanmanın karma sonuçlar doğurması gibi, LLM’ler de sınırlamalar ve riskler taşır
• AI hype cycle eninde sonunda zirveye ulaşabilir
• Bugün AI’ı aşırı kullanan şirketler, uzun vadeli maliyetleri üstlenmek zorunda kalacak ve yön değiştirebilir ya da ortadan kaybolabilir
• Mühendislikte insanın uzun vadeli değer önerisi değişmez
  • Dünya hâlâ teknik yetkinliğe ve derin düşünmeye ihtiyaç duyuyor
  • Bu yetkinlikler için hâlâ ödeme yapacak
• AI kalıcı olacak, ancak bir araç olarak kullanılmalı; koltuk değneği gibi ona bağımlı olunmamalıdır
• 2019’da da değerli görülen temel mühendislik yetkinliklerine yatırım yapmaya devam edilmelidir

[GN⁺]

Hacker News görüşleri

• Yapay zeka ile kodlama tartışması bazen yazılım mühendisi ile veri bilimci/makine öğrenimi mühendisi arasındaki farkı yansıtıyor gibi geliyor.
  İkisi de belirsiz gereksinimlerle ve yakalaması zor hatalarla uğraşıyor; ancak genel olarak yazılım mühendisleri her zaman belirli bir şekilde davranması gereken yazılımlar geliştirir ve yeniden üretilebilirlik, testler ve olgun araçlar önemlidir.
  Buna karşılık makine öğrenimi mühendisleri doğası gereği olasılıksal modellerle çalışır; testler de belirli bir çıktıyı verip vermediğinden çok “vakaların %90’ında doğru çıktı” gibi değerlendirme metrikleri etrafında şekillenir.
  Bu yüzden her zaman güvenilir olmayan yapay zekayla çalışma zihniyeti makine öğrenimi tarafına daha doğal gelir ve kodlama yardımcılarını “%80 doğru, zahmeti azaltıyor; kalan %20’yi de ben yakalarım” gibi değerlendirirler.

  • Benim deneyimime göre de bu yarı yarıya doğru. Gerçek sistemlerde makine öğrenimini iyi kullanan çok başarılı yazılım mühendisleri var; öte yandan, alan uzmanlarının kurduğu ve iyi anlaşılmış sistemlerin makine öğrenimiyle değiştirileceğine inanan insanlar da var.
    Amazon’da çalışırken, klasik bir yaklaşımı olmayan gerçek problemlere makine öğrenimi tabanlı çözümlerin çoğu zaman iyi oturduğunu gördüm. Örneğin ızgara harita tabanlı hareket tahmini ya da görüntü/ızgara harita sınıflandırması, mevcut kestirim ve kontrol işlem hatlarına iyi entegre edilip faydalı oluyordu.
    Buna karşılık bir startup’ta, duran bir düzlemin yönünü zaman içinde tahmin etme probleminde öğrenme tabanlı yaklaşımdan şüphe ettiğim için alt düzey bir yönetici tarafından sürekli azarlandım. Ekip haritalama ya da filtrelemenin temellerini bilmiyor ve “daha fazla veri koyarsak çözülür” diye varsayıyordu; bunun sonucunda tüm araç kontrol işlem hattı, yanıp sönen ve zıplayan rastgele dönüş tahminleriyle besleniyordu.
    Bu uçurum gerçekten büyük ve mülakatlarda bunu daha iyi ayırt etmenin bir yolu olsa keşke.
  • Şu anki havada, makine öğrenimi mühendisleri kendi düşünme biçimlerini ona uymayan başka organizasyonlara dayatma gücü kazanmış gibi görünüyor.
    Bir keresinde şirketin kıdemli mimarının bir toplantıdan sonra şikâyet ettiğini duymuştum: Şirketimizin ürünlerinde kesinlik ve doğruluk her zaman büyük bir satış argümanıydı, ama başka bir ofisteki makine öğrenimi ekibi bunu anlamıyor ve %80–90 doğruluğun müşteriler için yeterli olduğunu düşünüyordu.
    Bu bana pandemik bir hastalıkta %1 ölüm oranının küçük mü büyük mü olduğu tartışmasını hatırlatıyor. 1 en küçük tam sayıdır, ama 300 milyon kişinin %1’i 3 milyon kişidir.
  • Burada sözü edilen şey deterministik davranış ile olasılıksal davranış arasındaki fark ve bazı tartışmalar bu açıklamayla örtüşüyor.
    Ama bence bu yazı yalnızca bundan ibaret değil. Yazı, yazılım mühendisliği yapan insanların meta düzeydeki kaygılarını ve yapay zekanın buna nasıl uyduğunu ele alıyor; “program entropisi”nden söz ederken de bence can alıcı noktayı yakalıyor.
    Bir yazılım ürünü geliştirmenin büyük kısmı entropi yönetimidir. Kod ve insan sayısını artırırken makul bir ilerleme hızını korumak, herkesin parçaların nasıl birbirine oturduğunu ve yeni parçaların nasıl ekleneceğini anlamasını sağlamak gerekir. Bir gün yapay zeka bunu kolaylaştırabilir; ama şu anda çoğu zaman entropiyi daha da kötüleştiriyor.
  • %90 doğru yanıtın kesinlikle yeterli olmadığı çok fazla kullanım durumu var.
    Çıkarı olan insanlar “hayır, öyle değil; yapay zeka hemen her şeyde kullanılabilir” diye ikna etmeye çalışmasaydı bu büyük bir sorun olmazdı.
    Bu varsayım, mantıkla çürütülmesi bile zor olacak kadar saçma; şimdiye kadar ise dev yatırımları çekmek ve kâr odaklı iş gücü optimizasyonunu ambalajlamak için inanç temelli bir anlatı olarak son derece başarılı oldu.
  • Yazılım mühendisleri de sürekli olasılık kullanır. Bir race condition’ı yapısal olarak düzeltmek mi yoksa etki alanını küçültmek mi gerektiği, veritabanı çağrılarının p99’unun ne olacağı, A/B testleri vb. bunların hepsi olasılıksal yargılardır.

• Yazının öncülüne ve somut argümanlarının çoğuna güçlü biçimde katılıyorum; ama günlük kullanımda LLM’lerden yararlanırken olumlu yanlarını da görüyorum. Not olarak, yazılım sektöründe yaklaşık 30 yıldır çalışıyorum.
  Yapay zeka tarafından üretilen kodla uğraşınca kod okursunuz. Geliştirme, sıfırdan yaratma yolculuğundan çok bir dizi kod incelemesine benzemeye başlar; solo geliştiriciler için de normalde daha çok ekip içinde öğrenilen sorumlulukları taklit ederek edinme avantajı sağlar.
  Ayrıca LLM ile çalışmak, geliştiricinin problemi açık ve iyi yapılandırılmış katmanlar hâlinde anlaması gerektiğini hızla ortaya koyar. Büyük bir şeyi tek seferde yaptırmaya kalkarsanız genellikle ayağınıza sıkarsınız; bu yüzden tasarım perspektifinden yaklaşmak, ayrıntılı spesifikasyon yazmak ve parça parça uygulamak, kavramsal blokların sınırlarını ve arayüzlerini belirlemeye yardımcı olur.
  LLM, junior geliştiricilerin senior role doğru büyümesine yardımcı olan güçlü bir hızlandırıcı olarak görülebilir. Doğru yönlendirmeyle, daha deneyimli insanların zamanla öğrendiği derslerin ilerleyişini görünür kılar. Her şeyin karanlık olduğunu düşünmüyorum; yapay zeka geliştiricilerin yerini de almayacak. Şu an çok yıkıcı, ama sonunda diğer araçların arasında bir yere yerleşecek gibi geliyor.

  • Dengeli bakış açısına katılıyorum. Yazdığından daha az kod okuyan bir geliştiricinin yanlış yaptığını düşünüyorum. Kod okumak, bir yazılım mühendisinin gelişiminin merkezindedir.
    LLM yardımıyla üretilen kodu incelemek, daha sıradan kod okumak anlamına geliyor olabilir; ama yine de öğrenildiğini düşünüyorum. LLM tarafından üretilmiş çok kod okudum ve sık sık aşina olmadığım deyimler ya da bilmediğim kütüphane çağrıları öğrendim.
    Senior geliştiriciler için de LLM daha güçlü bir hızlandırıcıdır. Neyin var olduğunu ve neyi denemeye gerek olmadığını bildikleri için daha iyi prompt yazabilirler.
  • Bunun bir kod incelemeleri dizisine dönüşmesinden ziyade, birinin prototiplemeyi sizin yerinize yapması gibi hissettiriyor. Boş sayfa problemini çözmek için iyi; ama aynen inceleyip commit edilecek bir şey değil.
  • Scott Kilmer tarzı söylersek sorun şu: Şirketlerin boyundan yukarısı ölü. Şirketlerin vardığı sonuç, yapay zekanın junior’lara yardımcı olduğu değil; junior işe almayıp senior’lardan yapay zeka yardımıyla sihirli bir 10 kat üretkenlik beklemek oluyor. Hatta senior’lar bile yapay zeka yüzünden işten çıkarılıyor.
    Son haberlere bakınca bile Big Tech’te, orta ölçekli teknoloji şirketlerinde ve küçük teknoloji şirketlerinde işten çıkarmaların sürdüğünü görüyoruz.

• 3D baskının tüm üretimin yerini alacağı söylenen zamanı hatırlıyor musunuz?
  Yapay zeka, tekillikten çok bu duyguya daha yakın

  • İyi bir benzetme. 3D baskı havalı ve çok kullanışlı bir teknoloji; gerçekten dünyayı değiştirdi. Ama enjeksiyon kalıplama hâlâ varlığını sürdürüyor
  • Tekilliğe götürmeyebilir ama akademide ödev verme, notlandırma ve ders notları açısından yapay zeka iyi ya da kötü muazzam bir etki yarattı
    LLM'lerin bir şeyleri iyileştirmesinden çok sistemsel kusurları ortaya çıkardığı da söylenebilir, ama etkinin kendisi açık. İki yıl önce standart olan onlarca ders akışı artık çalışmıyor
    Özellikle çevrimiçi ve uzaktan eğitimin tamamı buna dahil; ironik biçimde, birçok üniversitenin Covid sonrasında tam da bu alana yatırım yapmaya başladığı sırada ChatGPT çıktı. Bu, dünya genelindeki yükseköğretim ve ortaöğretim alanlarının tamamı ölçeğinde bir etki
  • Kolayca yapılabilecek bir şaka ama epey yanlış. 3D baskı birçok sektörde dev bir atılımdı ve mevcut durumu kökten değiştirdi
    Havacılık ve uzay iyi bir örnek. SpaceX'in ve bu alandaki genç startup'ların yaptığı birçok şey 3D baskı parçalar olmadan mümkün olmazdı. Nozul, yanma odası, turbopompa gibi parçalar sık sık basılıyor
  • Bitcoin'in bankaların yerini alacağı sözüne de benziyor. Sonunda bankalar Bitcoin tabanlı finansal araçlar satmaya başladı
  • Açıkçası o günleri hatırlamıyorum. Belki de o abartı döngüsü benim zamanımdan önceydi
    Yine de bu karşılaştırma adil görünmüyor. Makine mühendisliği yaptığım dönemde 3D baskı, daha hızlı ve ucuz prototip üretip hata yapmama imkân vererek mühendislik becerilerimi aksine geliştirdi
    Tüm üretimin yerini almadı ama tasarımda önemli bir rol oynuyor ve kullanıcının becerilerini köreltmedi

• LLM'ler kod yazmada şaşırtıcı derecede iyi, ama o kodu sahiplenip sürdürmede berbat
  Anlamadan kabul ettiğiniz her satır ödünç alınmış bir anlayıştır ve bakım aşamasında yüksek faizle geri ödenir. Bedava hız gibi hissettirir ama gerçekte yıllık yaklaşık %40 faiz işleyen teknik borca daha yakındır
  Topluluk olarak yapay zekayla yazmayı otomatikleştirip düşünmeyi otomatikleştirmemenin yolunu bulmalıyız

  • “Ödünç alınmış anlayış” olabilmesi için LLM'nin, insan mühendislere uyguladığımız anlamdaki anlayışla yazdığı şeyi gerçekten anlaması gerekir
    Ama öyle değil ve çalışma biçimi gereği de öyle olamaz
    Bu yüzden LLM'den gelen ve anlamadan kabul edilen her satır aslında var olmayan bir anlayıştır. O sadece olasılıksal bir modelin ürettiği bir kod satırıdır; kod tabanının bağlamını, sistemi ve tasarımı gerçekten anlayabilen bir varlık tarafından görülene kadar anlaşılmamış durumdadır. Şu anda böyle bir varlık olarak bilinen tek şey insandır
  • İşe bağlı olarak, kod yazmanın kendisinde de berbat olabilir
  • Çok iyi bir benzetme. Bu faiz oranı TDD ve yalıtılmış alt sistemlerin boyutunu küçültmeyle epey azaltılabilir gibi görünüyor. Sonunda mikroservislere benzemeye başlayabilir
    Geleneksel geliştirmede ikisini de pek sevmem ama mevcut LLM'ler ikisini de daha kolay ve kullanışlı kılıyor
    Ayrıca “üç kuralı” bileşenler arasında fiilen geçerliliğini yitiriyor. Kod etkisi ya yerel kalmalı ya da çok sağlam bir temel kütüphanenin parçası olmalı. Aradaki örnekler refaktörleme karmaşıklığını patlatıyor

• “LLM’ler yönlendirici promptlara itiraz etmez” şeklindeki girdi riski şimdiye kadar en büyük sıkıntı oldu
  Daha da sinir bozucu olan, benim belirli bir yöne yönlendirdiğimin farkında bile olmayabilecek olmam. LLM’lerin çalışma biçimini düşününce mantıklı geliyor ama muğlak yazılmış tek bir kelime bile sonucu kötü bir yöne kaydırabiliyor; istediğimin tersine gidip yanlış bir tavşan deliğine düşürebiliyor
  Farkına vardığımda, zar zor işleyen, gelişigüzel birbirine eklenmiş bir kod çamurunun ortasında oluyorum. İnsan dili çok muğlak ve belirsiz; bu da başta kesinliğe izin veren kurallı biçimsel dilleri icat etmiş olmamıza neredeyse denk
  Kişisel olarak yapay zeka araçları yüzünden becerilerimin hızla köreldiğini de hissettim. Bir ara tembellikten küçük her işte yapay zekaya başvuruyordum; ama bir adım geri çekilip bakınca, pek de zaman kazanmadığımı, aksine onlarca/yüzlerce satır kod okuyup yapay zekanın nasıl yanıldığını düşünüp düzeltirken çok daha çabuk tükendiğimi gördüm
  Ölçmedim ama genel olarak yapay zeka araçlarıyla kazandığım zamandan çok daha fazlasını boşa harcadığımı düşünüyorum
  Asıl sorun, yapay zekanın birçok işte gerçekten faydalı olması; ama onu kullananların iki gruba ayrılması. Bir taraf, küçük hataların hızla biriktiği karmaşık işlerde kullanıyor; diğer taraf ise çoğunlukla yönetici tipi kişiler: Anlamadıkları 200 satır kodun döküldüğünü görüp zar zor çalışan bir TODO uygulaması seviyesindeki şeyi “MVP” sanıyor ve “bunu yapabildiğine göre senin işini de kolayca yapabilir” diye düşünüyor
  “Yanlış kullanmışsın” ya da “model hatalıydı” gibi alışılmış cevapları verecekseniz, bu araçlarla ilgili deneyim bağlamım için önce eski yorumumu https://news.ycombinator.com/item?id=44055448 okumanızı isterim

  • Şimdiye kadarki deneyimime göre, problem çözme yöntemine dair farklı bir bakış açısı edinmeme yardımcı oluyor ve sonunda işi yine ben yapıyorum. Ya da çok somut talimat verip görece küçük bir sorun verdiğimde kod yazıyor; ben de kod incelemesi yapıp kendi standartlarıma göre düzeltiyorum
    Yani yapay zeka benim asistanım; ama kaliteli ve bakımı yapılabilir bir çıktı üretme sorumluluğu bende
    Ancak genel kamu perspektifinden bakarsak basit bir hesap makinesini düşünmek yeterli. Hesap makineleri insanların zihinden hesap yapma becerisini bozdu. Yapay zeka da yazma ve iletişim becerileri, problem çözme becerisi vb. için bunu yapacak
  • Muğlak tek bir kelimenin sonucu kötü bir yöne kaydırdığı hissinin yalnızca bana ait olmamasına sevindim
    Modeller, prompt akışının bir yerindeki belirli anahtar kelimelere takılıp geleneksel mantığı bırakıyor ve asıl problemi de düzgün çözemeyen daha dar bir yola itiyor gibi. Sonuçta insan tarafındaki hayal kırıklığı ve mutsuzluk artıyor
    Becerilerimin körelmesini önlemek için, yapay zekayı yalnızca normalde StackOverflow aramasıyla çözeceğim küçük ve net işlerde kullanmaya çalışıyorum. “X’i nasıl yaparım?” diye aramak yerine modele aynı soruyu soruyor, cevabı doğru cevap olarak değil, problem çözme rehberi olarak kullanıyorum
  • “Yapay zeka yapabilir” noktasından “o2.7 modelini RAG ekli bir IDE’de kullanıp promptta yöntemi de söylemiş olsaydın yapabilirdi” noktasına kalelerin taşındığı hissine fazlasıyla katılıyorum. Bir noktadan sonra, çabaya göre değeri kodu kendim yazmaktan daha düşük oluyor
    Yine de bugün yapay zekanın kolaylaştırdığı işler var. Örneğin “bu sayfaya benzer yap ama y yerine x verisini kullan” gibi kullanılacak bir örnek varsa, çoğu zaman doküman aramaktan daha hızlı oluyor. Halüsinasyon görebileceği kaydı var ama zamanla iyileşme olasılığı da yüksek
    Görmek istediğim iyileşme, genel olarak daha doğru olmasının yanında, her seferinde söylemeye gerek kalmadan en basit çözümü araması. ChatGPT, Claude vb.’yi serbest bıraktığınızda en büyük dezavantajı hızla bir sürü çöp üretmeleri ve “bunu daha sonra ele almak çok karmaşık hale gelecek” diye durmamaları. Orijinal metin, yalnızca genel tasarımı anlayan insanın entropiye direnebileceğini savunuyor; bu kısmın sonsuza kadar iyileşmeyeceğini söyleyemem ama şu anda en büyük sorun gibi geliyor
  • Bu tür “beklenmedik yönlendirmeden” kaçınmak istediğimde LLM’den önce “her turda 5 tane olmak üzere 3 tur netleştirme sorusu sor” demesini istiyorum
    İlk turda genelde modelin yaptığı temel varsayımlar ortaya çıkıyor; oradan itibaren daraltıp netleştirebiliyorsunuz
    Birçok deneme yaptığınızı anlatan eski yorumu okuyunca LLM deneyiminizin benimkinden çok daha geniş göründü. Yine de bu tekniği görmediğim için, birilerine yardımcı olur diye bırakıyorum
  • İnsanlarda da benzer önyargılar var. Sadece LLM’lerin önyargılarını test etmek insanlara kıyasla çok daha kolay olduğu için LLM önyargılarının daha çok farkındayız

• “Fikirleri, diyagramları, gereksinim şartnamelerini akıl yürüterek çıkaramaz”, “karmaşıklığı azaltabilecek tek şey insandır” gibi sözler, ilginç bir kavramın arkasına açıkça yanlış ayrıntı iddialarının eklendiği durumlara benziyor
  Bu çok kolay yapılabilir. Daha basit kod istemek yeterli. Ben ikinci bir görüş almak için sık kullanıyorum ve iyi sonuç alıyorum
  Modele soru sormazsanız ne karmaşık cevap ne de basit cevap alırsınız. Varsayılan seçenek olarak soru sormak da bir tercihtir; LLM kavramının doğasında olan bir şey değildir
  Kod ile fikirler/diyagramlar arasında dönüşüm yapmak için de iyi kullanıyorum. İnsanların her gün pratikte çürüttüğü güçlü iddiaları neden ortaya attığını anlamıyorum

  • “LLM’ler kavramlarla akıl yürütemez” meme’inin artık ortadan kalkmış olması gerektiğini düşünüyorum. LLM’ler kelimenin tam anlamıyla kavramların somutlaşmış hâlidir ve akıl yürütme sırasında belirli kavramları tanımlayıp bastırma ya da güçlendirme yöntemleri de dahil olmak üzere çeşitli biçimlerde deneysel olarak gösterilmiştir
    Yazı yüzeyde doğru görünüyor ama yakından bakınca ayakta kalamayan tuhaf bir mantığı da tekrarlıyor. Naur meselesi artık bir meme oldu ve gerçek dünyada içgörü gibi tekrarlanıyor; fakat yazılım mühendisliğinin başka bir temel ve pratik kuralını unutuyor: önemsiz olmayan bir program, kısa sürede tek bir kişinin tüm teorisini zihninde tutabilme kapasitesini aşar
    Biz neredeyse hiçbir zaman düzgün bir program teorisine sahip olarak çalışmayız. Programlama dilleri, teknikleri, metodolojileri ve araçları, insanların kodun çoğunu anlamadan daha iyi çalışabilmesini sağlayacak yönde gelişti
    Bu açıdan insanlar da LLM’lerle aynı sınırları paylaşıyor; sadece başka bir bakış açısı elde etmek için bir sonraki akıl yürütme döngüsüne izin verilmesini beklemek zorunda olmadığımızdan bunu daha iyi yönetiyoruz
  • Junior mühendislerin kodunu incelerken sürekli karşıma çıkan büyük sorun, kod kalitesinin kendisinden çok çözüm yönü oluyor. LLM modelinin “neden bunu bu şekilde yapmaya çalışıyorsun?” diye karşı soru sorup soramayacağından emin değilim. Meşhur StackOverflow tarzı cevaplar gibi
  • Kodu diyagrama çevirme işini manuel mi yapıyorsunuz, yoksa otomasyon aracı mı var merak ediyorum. İkincisini arıyorum

• Google Maps veya Apple Maps gibi harita teknolojilerine de benzer bir mantığın uygulanabileceğini düşünüyorum. İddia şu: Bu araçları kullanmak fiziksel dünyada gezinme becerisini, yön duygusunu ve coğrafi sezgiyi köreltiyor.
  Aslında tamamen yanlış değil. Bugün insanlar Google Maps gibi bir dayanak olmadan yol bulmakta çoğu zaman zorlanıyor ve fiziksel dünyayla ilişkimiz de birçok açıdan değişti.
  Ama eskiden de birçok insan yol bulmada özellikle iyi değildi. Özellikle yabancı bir bölgede A noktasından B noktasına güvenli ve istikrarlı biçimde gitme konusundaki ortalama beceri kesinlikle çok yükseldi.
  Ayrıca coğrafya ve yol bulma konusunda doğuştan yetenekli az sayıda kişinin becerileri Google Maps gibi araçlarla ikame edilmedi, tamamlandı.
  Yapay zekanın da daha büyük ölçekte benzer şekilde sonuçlanacağını düşünüyorum. Elbette ödünleşimler var ve bazı beceri ve yetenekler azalacak; ama çok daha fazla insan daha önce yapamadığı şeyleri yapabilir hale gelecek, az sayıda kişi de yaptığı işi daha iyi yapacak.

  • Sorun şu ki harita yazılımı güvenilir ve özünde rastgele sayı üreteci gibi sonuçlar vermiyor. Hesap makinesine güvendiğimiz gibi çıktısına dayanabiliyoruz.
    Elbette her zaman değil. Tüm dünyayı haritalamak, sayısız istisna ve uç durum içeren çok karmaşık bir iş. Ama LLM çıktısıyla karşılaştırınca arada büyük fark var. Sıcaklığı 0’a ayarlayıp aynı prompt’u birkaç kez yeniden üretseniz bile çıktı ciddi biçimde değişiyor.
    Ayrıca LLM’ler çok daha geniş bir kavram alanını kapsadığı için insanlar, gerçekten yapmamaları gereken birçok durumda kendi akıllarının yerine bunu kullanacak. Sadece haritalarda bile Google Maps yol dedi diye göle arabayla giren insanlar var; LLM çıktısına körü körüne güvenip kendi düşüncesinin yerine koyduğunda neler olacağını hayal bile edemiyorum.
  • Kişisel deneyimimde bunun tam tersi oldu. Harita yazılımı sayesinde istediğim yöne yürüyebiliyor, gerektiğinde rotamı güvenle düzeltebiliyorum; bir kez yürüdüğüm yolu da daha iyi hatırlıyorum.
  • Güvenilirlik farkı o kadar büyük ki benzetme uygun değil.
    Yaşadığım yerde Google Maps, taksi şoförlerinden vakaların %90’ında daha iyi.
    Yapay zeka ise o işi birkaç gündür yapan birinden bile daha iyi değil.
  • Yabancı bir bölgede A’dan B’ye güvenli ve istikrarlı gitme konusundaki ortalama becerinin ciddi biçimde arttığına dair kanıt var mı?

• Gerçekçi bakarsak çalışanların %70’i işi o kadar baştan savma yapıyor ki yapay zeka çoğu zaman onlar kadar, hatta daha iyi yapabiliyor.
  Asıl zorluk şu: İşi baştan savma yapanlar yapay zeka kullansa da hâlâ işe yaramaz kalıyor; geri kalanlar ise yapay zekayla birlikte öğrenip gelişiyor.

  • Epey benmerkezci bir anlatı. Kendinin %30’un içinde olduğunu mu varsayıyor?
  • İşini yapay zekaya dış kaynak olarak verenler, yalnızca bir bilgisayar programının işlerini daha iyi yapabileceğini kanıtlamakla kalmıyor; aynı zamanda bunun yolunu da döşeyip kovulmayı istemiş oluyorlar.
  • Büyük şirketlerde bu doğru ve şimdiye kadar okuduğum yapay zekayla kodlama görüşleri arasında belki de en iyisi.
    Tam otonom sürüş de benzer. FSD, berbat, sarhoş ya da mesaj yazan insan sürücülerden daha iyi; yollarda da böyle sürücüler çok.

• Yazarın “[Yapay zeka] kavramsal düzeyde çalışamaz” hissini nereden edindiğini merak ediyorum.
  Son dönem LLM’lerin tekrar tekrar gösterdiği şey, örneğin bağlama göre bir dildeki kavramları başka bir dile doğru çevirmek gibi, açıkça kavramsal düzeyde çalışabildikleri.
  Kavramları insanlar gibi “anlamadıkları” ayrı bir mesele. Acıyı deneyimlemedikleri için acıyı “anlamıyor” olabilirler; ama insanlar da doğrudan deneyimlemedikleri şeyler hakkında durmadan konuşuyor. Bunun uygun olup olmadığı başka bir konu.

  • LLM, kavramların vekili olarak verilen ölçülü bir yapıya sahip token uzayında çalışır. Bu uzayda bir noktadan “dog” token’ının etrafında kümelenmiş noktalara doğru yürüyebilirsiniz.
    Bu, ilişkilendirme gibi kavramın bazı özelliklerine dair zayıf bir modeldir. Örneğin “dog”, “cat” ile ilişkilidir. Ama bileşimsellik, içlem ya da karşıolgusal koşullu ifadelerde terimlerin üstlendiği rol gibi şeyleri modellemez.
    Ancak soru eğitim verisine benziyorsa, görünürdeki kavramsal yetenek kaba kuvvetle elde edilebilir. Birisi “Köpekler Mars’ta oynarsa mutlu olur mu?” gibi bir soru veya yeterince benzer bir soru kümesi sormuşsa, “dog”u “literal gerçek” kümesiyle ve zaten bilinen bazı karşıolgusal kümelerin etrafına yerleştirebilirsiniz.
    Bunun gerçek zihinsel yetenekten farkını görmek için, keyfi derinlikte kavram birleşimlerinin sonsuz olduğunu ve sonsuz sayıda karşıolgusaldan oluşabileceğini düşünmek yeterli. Temel yapı taşlarına ve hayal gücüne sahip bir çocuk bu sonsuz çeşitliliği değerlendirebilir.
    Bu yüzden LLM’ler, gerekli “kavramsal iş”in çok iyi belgelenmiş ve yeterince istikrarlı olduğu dar alanlarda, özellikle de yazılım mühendisliğinde en çok kullanılıyor.
  • Uç örnek olarak, doğrudan deneyim olmasa bile afantazi, sinestezi, renk körlüğü gibi şeylerden söz edip kavramlarını anlayabiliriz.

• 90s.dev’i yapay zekasız bir topluluğa dönüştürmem gerektiği fikri giderek güçleniyor. Yazılımı iyi yazmanın kadim becerilerine odaklanan ve bu becerileri geliştirmiş herkesi memnuniyetle karşılayan bir yer olsun isterim.
  Başlamak için ne gerekir? Forum mu? E-posta listesi mi? hackernoon gibi birçok yazarın blogunu bir araya getiren bir yöntem mi?
  İlgilenenler için geçici bir e-posta listesini https://github.com/sdegutis/90s.dev/issues/2 adresinde oluşturdum; bu konuyla ilgili e-postaları almak için abone olabilir veya yorum bırakabilirsiniz.

  • Abonelik ya da yorum mu? Bu benim hedef pazarıma uygun. Ama “abonelik” kelimesi kadar insanın bir şey yapma isteğini kıran pek az şey var.
    Forumlar LLM’ler ve botlar yüzünden bozuldu, dolayısıyla o seçenek elendi. Böyle bir şeyin işlemesi için yalnızca davetle girilebilir olması ve her davet edenin kendi davet ağacından sorumlu tutulması gerekir.
    Topluluk, erişim hakkını kaybetmenin iyi davranışı teşvik edeceği kadar iyi olmalı. İnternetteki belirli topluluklarda bu yöntem çok iyi çalışıyor.
  • O dönemin klasik forumlarını çalıştıran harika OG forum yazılımı kullanılabilir. Şık bir retro tarzda olursa iyi olurdu.