- 15 yıllık deneyime sahip yazılım mühendisi Alberto Fortin, LLM'lerin (büyük dil modelleri) benimsenmesi konusunda büyük beklentilere sahipti, ancak gerçek prodüksiyon ortamında çeşitli sınırlamalarla karşılaştı
- Go ve ClickHouse tabanlı altyapıyı yeniden kurma sürecinde yapay zekanın artılarını ve eksilerini doğrudan gördü ve modeller gelişse de temel sorunların yeterince çözülmediğini hissetti
- Üretkenlik artışıyla ilgili bir yanılsama olduğunu, gerçekte ise hata ve beklenmedik sorunların daha da arttığını vurguluyor
- LLM'leri bir yardımcı (assistant) olarak görmek, temel tasarım ve kararların geliştirici tarafından verilmesi gerektiği dersini öne çıkarıyor
- "Yapay zeka devrim niteliğinde ama henüz kusursuz değil; bu yüzden dengeli kullanım ve soğukkanlı bir gerçeklik algısı gerekiyor"
Alberto Fortin'in LLM deneyimi ve değerlendirmesi
- 15 yıllık deneyime sahip yazılım mühendisi Alberto Fortin, LLM'leri geliştirme iş akışına aktif biçimde dahil ederken büyük bir heyecan duydu
- Go ve ClickHouse kullanarak altyapıyı yeniden kurma sürecinde çeşitli zorluklar ve sınırlarla karşılaşınca, yapay zeka ile gerçek geliştirme pratiği arasındaki fark üzerine bir blog yazısı kaleme aldı
- Daha sonra yaptığı ek analizlerle Claude Opus 4 gibi en yeni modellerin bu sorunları çözüp çözmediğini doğrulama çalışması yürüttü
- Alberto'nun deneyimi, pratik çalışma ortamında LLM kullanımını değerlendiren mühendislere somut dersler sunuyor; aracın hangi noktalarda değer ürettiği ve sınırlarının nerede başladığı konusunda gerçekçi bir bakış sağlıyor
Alberto'nun LLM deneyimine dair önemli alıntıları
> "Bunun sadece yanlış çalışma ya da bir özelliğin hiç çalışmaması sorunu olmamasına gerçekten şaşırdım. Önümüzdeki birkaç yıl boyunca bu kodun bakımını yapacak geliştirici olarak, kodun yeterince temiz olması gerekiyor."
> "Sorun sanki hemen çözülecekmiş gibi görünüyor ama sonunda yine yeni bir hata çıkıyor ve onu çözmek de tekrar yaklaşık 2 hafta daha sürüyor; bu deneyim tekrar tekrar yaşandı."
> "Hata çıktısını LLM'e verdiğinizde yeni bir cevap üretiyor ama sık sık bir şeyi gereksiz yere karmaşık hale getiriyor ya da başka bir kısmı bozuyor."
LLM'lere yönelik aşırı beklentilerin farkına varmak
> "İlk otomatik tamamlama gibi küçük özellikleri ilk kullandığımızda, tüm geliştiriciler şaşırıyor. Sanki düşüncemi okuyormuş gibi geliyor; bu da beklentilerin şişmesine yol açıyor."
> "Geliştirme üretkenliğinin 10 kat artabileceği hissine kapılıyorsunuz ama gerçekte bu ölçüde bir beklentiye fazla hızlı girme eğilimi var."
Roller ve beklentileri yeniden tanımlamak
> "En büyük fark, rol algısındaki değişimdi. Ben mimar ve kıdemli geliştiriciyim, LLM ise yalnızca yardımcım. Planı ben yapıyorum, LLM ise destekleyici rol üstleniyor."
> "Güveni kaybettikten sonra artık ona önemli özellikleri emanet etmiyorum. Yalnızca refactoring gibi küçük ölçekli işlerde kullanıyorum."
> "Hataları doğrudan kendim düzeltmeye başladım. Kod tabanını tamamen anlıyorsanız, sorunu bizzat çözmek çok daha hızlı ve verimli oluyor."
LLM'lere bakışın değişimi ve öneriler
> "Kıdemli bir geliştirici olarak LLM kullanımının bana iyi uymamasının benim yetersizliğim anlamına gelmediğini kendime kabul ettim. Mevcut çalışma yöntemimi koruyup yapay zekayı yardımcı olarak kullanmak asıl önemli nokta."
> "Teknolojik ilerlemeyle bir seviye ileri gidildiği doğru, ancak henüz bir sonraki aşamaya ulaşılmış değil. Karar verme ve mimari hâlâ insanın sorumluluğunda olmalı."
> "Yapay zeka devrimi etkileyici ama şu anda dengeli ve gerçekçi beklentilere ihtiyaç var."
2 yorum
> https://tr.news.hada.io/topic?id=20955
Hacker News görüşü
HN'de çok fazla zaman geçirdiğimi düşünmemin nedeni, neredeyse tüm yazı ve yorumlarda aynı şeylerin tekrarlandığını görmem. LLM'ler ilgi çekici ama üretilen kod karmaşık, sahiplik hissi vermiyor ve doğrudan yazdığın kod gibi tüm yapısı zihninde canlanmadığı için yönetmesi zor oluyor deniyor. Kısa ömürlü, bakım yapılmayacak script'lerde işe yarayabilir ama büyük projelerde sorun çıkarıyor. Öte yandan birden çok LLM ajanını kullanıp farklı işleri dağıtıp birleştiren iş akışlarının harika olduğunu söyleyen insanlar da var, ama gerçek kod göstermeden sadece övünüyorlarmış gibi geliyor
Bence bu özet asıl noktayı gerçekten iyi yakalıyor. LLM'ler geliştirme hızını inanılmaz artırıyor ama tüm kodu tamamen anlamadığım için, ne zaman hangi bölümde sorun çıktığını kavramak zorlaşıyor. Sonuçta yeni katılmış bir geliştiricinin kendi projesine alışmaya çalışması gibi hissettiriyor. Bu yüzden kodu sık sık commit ediyorum ve düzenli aralıklarla LLM'den kodu yeniden açıklamasını istiyorum. Bu süreçte LLM kendi hatalarını da sık sık buluyor. Özellikle veri analizi gibi kapsamı dar işlerde yeterince kontrolü elde tutarak hızlı ilerlemek mümkün. Buna karşılık büyük bir codebase'de LLM'i doğru kullanacak yetenek ve alışkanlıklar yoksa işler kolayca dağılabiliyor. Prompt yazma, context yönetimi, hız ayarı, iş organizasyonu ve LLM çıktısını doğru biçimde review etme gibi beceriler mutlaka öğrenilmeli. Bunu henüz kimse resmi olarak öğretmediği için herkes deneme yanılmayla öğreniyor. Yine de bir kez tadını alınca eskiye dönmek zor. Çünkü can sıkıcı ya da tekrarlı işleri LLM'e bırakabiliyorsun. 20 yıldan uzun süredir geliştirme yapıyorum, eskisi kadar sabırlı da değilim; ayrıca nasıl hayata geçirileceğini tam bilmediğim fikirleri LLM'e verince çok daha verimli çalışabiliyorum
Programlamayı bir "teori inşa etme" süreci olarak görme yaklaşımını seviyorum. Programming as Theory Building bakılabilir. Yapay zeka kullanımının kendisine karşı değilim. Ama üretilen kodun sonuçlarıyla ilgili sorumluluğu bırakıp gitme tavrını desteklemiyorum. grep gibi araçları kullanırken olduğu gibi, araçla elde edilen sonuçların da sorumluluğunu almak gerekir; ancak o zaman anlamlı olur. Üretilen kod için bu daha da geçerli, birkaç disclaimer ile geçiştirilecek bir konu değil
Yapay zeka yazılarından yorulma hissine katılıyorum. Görüşlerin bölünmüş olması da gerçek. Yine de gerçekten kodlarını paylaşan örnekler var. Flask/Jinja2/Sentry'nin yaratıcısı Armin Ronacher, YouTube'da iş akışı videosu ve kendi yaptığı AI kütüphanesinin tanıtımını paylaştı; ben de açık kaynak projelerimin yaklaşık %50 ila %80'ini AI ile yapıyorum. cijene-api bakılabilir
Kullanıcı kitlesinin çan eğrisi gibi dağıldığını hissediyorum. Bir tarafta, LLM çok fazla kodu kendi üslubuyla üretiyor ve bu yüzden kullanıcının zihnine bağlam oturmuyor, kişi eziliyor. Öte tarafta ise normalde tek başına hayata geçiremeyeceği şeyleri LLM sayesinde yapabilir hâle gelen kullanıcılar var. Bir başka tarafta da, aslında tek başına yavaş yavaş yapabilecek ama LLM'i adeta bir junior geliştirici ordusu gibi kullanıp yalnızca genel algoritmik seviyeyi akılda tutarak çok daha büyük projeleri hızla kuran kullanıcılar bulunuyor
25'ten fazla geliştiricinin aynı anda katkı verdiği büyük bir codebase'de çalışmaktan çok da farklı gelmiyor. Benim organizasyonumda 160 mühendis frontend ve mid-tier üzerinde çalışıyor; sürekli sahiplik hissi olmayan kodu eşelemek zorunda kalıyoruz ve git blame'de 3 yıl önceki dış kaynak geliştiricinin adını görmek olağan bir şey. LLM küçük ölçekte iyi, orta ölçekte uyumsuz, büyük projelerde ise küçük modüller için tekrar işe yarar gibi görünüyor
LLM hedeflerime ulaşmamda çok yardımcı oluyor ama doğrudan programlama becerimin kendisini zayıflatıyor gibi hissettiriyor. Biraz steroid gibi: kaslar hızlı büyüyor ama yan etkileri fazla ve bıraktığın anda bir anda çökme riski var. Şirketler sağlık yerine hızlı sonuca baktığı için bu durum daha da kötüleşiyor. Bu yüzden şimdi ölçülü ve kontrollü kullanmaya başladım
LLM yüzünden birçok geliştirici "Simple Made Easy"'de vurgulanan dersi unutmuş gibi geliyor. LLM'in ürettiği kod, 'Ball of Mud' (karmaşık, refactor edilmesi ya da yönetilmesi zor, dağınık kod) üretmekte çok başarılı. Asıl güç, karmaşık sorunları küçük parçalara ayırmakta; her küçük bileşenin basit çalışmasını sağlamakta ve bu bileşenlerin etkileşimiyle karmaşıklığı inşa etmekte yatıyor. Her bileşen basit olursa anlamak, debug etmek ve performansı öngörmek kolaylaşır. LLM bu ilkeye gerçekten iyi uymaya başlarsa, o zaman gerçekten geliştiriciye ihtiyaç kalmayabilir
Aslında LLM'e istediğin yönü açıkça söyleyebilirsin. LLM'i faydalı bulanlarla bulmayanlar arasındaki fark, onun nerede güçlü nerede zayıf olduğunu anlayıp girdiye (prompt'a) göre çıktının kalitesinin değişeceğini öngörebilmekte yatıyor. Mesela ben karmaşık bir sorunu nasıl parçalayabileceğimi önce LLM'e sorup gözümden kaçan bir nokta var mı diye bakmayı, ardından somut implementasyonu ona bırakmayı seviyorum. Hiç yönlendirme yapmadan tüm büyük projeyi baştan sona üretmesini istemiyorum
'Ball of Mud' sorunu sadece kodda yaşanmıyor. İş yerimde de "AI'yi agresif biçimde benimseyelim" diyen liderler var ve deployment sistemiyle karmaşık operasyonları da AI'ye devretme fikrini gördüm. Sonuçta karmaşık bir sistemin üstüne bir karmaşık black box daha koyup, "black box'ı anlamak için yeni bir black box gerekiyor" mantığına varıyorlar; bana hiç mantıklı gelmiyor. Kurum içindeki zorlayıcı atmosfer yüzünden bazen sorun bende sanıyormuşum gibi hissettiriyorlar
LLM gerçekten kusursuz hâle gelirse gerçekten geliştiriciye ihtiyaç kalır mı diye düşünüyorum. Kimsenin 7/24 yazılım "üreten bir makine" çalışsın isteyeceğini sanmıyorum. Sonuçta yine problemleri parçalara ayıran, gerçekten ihtiyaç duyulan yazılımı bulup ortaya koyan insanlara ihtiyaç olacak. Bugün onlara yazılım geliştirici dediğimiz gibi
Ben de sonunda benzer bir sonuca vardım. LLM, tüm codebase'i bir otomatik tamamlama sistemi gibi doldurmak için pek iyi değil. Çünkü neyin nerede ne yaptığını zihnimde modelleme yeteneğim kayboluyor. Kişiselleştirilmiş bir StackOverflow gibi; anahtar kelimeleri açıklamak, bilmediğim kavramları özetlemek ve yön göstermek için kullanıp, gerçek implementasyon ve kararları kendim verdiğimde çok daha verimli oldu
Ben de aynı şekilde kullanıyorum ama cursor sürekli ısrarla kod değişikliği öneriyor. Codebase'in içeriğine dokunmadan sadece introspect etmesini sağlamanın bir yolu var mı merak ediyorum
Bende durum farklı. LLM'in önerdiği kodu her zaman dikkatle review edersem, neyin nerede olduğu ve nasıl etkileştiği konusunda oldukça net bir kavrayış elde edebiliyorum
Ben de kullanım sıklığını epey azaltıyorum. LLM yanıtlarının ciddi bir kısmı yanlıştı. Bu yüzden artık daha çok "hangi kılavuzda ya da dokümanda bakmam gerekir" diye soruyor, asıl içeriği kendim inceliyorum. Bu yöntem hem bilginin nerede olduğunu bulma becerisini geliştiriyor hem de arama motoru ve LLM bağımlılığını azaltıyor. LLM sadece bir araç ve doğruluk konusunda da çok güvenilir değil
Hiç değinilmeyen bir nokta daha var: LLM bazen üretkenliği düşürebiliyor. Makul görünen cevaplarla insanı yanlış bir yola sürüklediğinde ciddi zaman kaybı yaşatabiliyor. Genel toplamda çoğu zaman yardımcı oluyor ama "dayanak kontrolü" önemli; hatta bazı durumlarda doğrudan kendin yapmak gerçekten daha hızlı oluyor
LLM'in sınırları belirgin. Çok güçlü ama insanlar kadar yaratıcı sıçramalar yapmakta zorlanıyor. Örneğin, "Android'de 1000'in altındaki bir porta bind edemiyorum, peki web sunucusunu nasıl çalıştırırım?" sorusuna hem Claude hem Gemini yalnızca şu üç bariz çözümü verdi: 1) reverse proxy 2) root erişimi 3) port numarasını yükseltmek. Benim aradığım gerçek çözüm HTTPS RR kaydıydı (ilgili yazı). İkisi de bu spesifikasyonu biliyor ama duruma uygulayamıyor. Cevabı bulabilmek için bağlamı benim eklemem gerekti
Aslında LLM'in bunu önermemesi bana o kadar garip gelmiyor. Chrome'da bile resmi desteği olmayan yeni bir spesifikasyonu önermesini beklemek zor; ben de muhtemelen o kadarını düşünmezdim
Bunu ben de not aldım. Son zamanlarda LLM ile gerçekten sohbet ederken, ona biraz insan gibi tolerans göstermek stresi azaltıyor. Mesela cursor ile kod yazarken "burada bir şey eksik" dediğimde, aynı hatayı benim de yapabileceğim aklıma geliyor. LLM'i bir "kitap kulübü" ya da "film kulübü" partneri olarak kullanıp iki filmi tartıştırdığımda, karakterlerin durumunu yanlış anlattığı hatalar da oldu ama %100 doğru olmak zorunda olmadığını kabul edip insanlara gösterdiğimiz esnekliği gösterince sohbet çok daha akıcı oluyor. AI ile konuşurken de olumlu yaklaşmak iyi geliyor
SRV kaydını duymuştum ama neredeyse hiç kullanılmıyor gibi geliyordu; HTTPS RR'yi ise ilk kez duydum. Gerçek destek durumu da SRV'den daha iyi görünüyor
Bu, LLM'in klasik sorunu: ancak "doğru cevabı" sen söyleyince onu çözüm listesine ekliyor
Hedefleri ve kısıtları yeterince net tanımlarsan ChatGPT o3 bu çözümü önerebiliyor. Ama bunun yalnızca modern tarayıcılarda çalıştığını da doğru biçimde belirtiyor. Örnek
ChatGPT Enterprise sürümünü sık kullandıkça zaman içinde birkaç şey öğrendim. Büyük miktarda kod yüklemek yerine, oldukça bağımsız fonksiyonlar ya da küçük sınıflar düzeyinde çalışınca daha iyi sonuç veriyor. Kod üretimi ya da tamamlama taleplerinde yaklaşık %10'luk bir kısmı ek yönlendirmeyle düzeltilebiliyor ama kalite yine de düşük kalıyor; yaklaşık %25'lik bir kısmı ise ne kadar açıklarsan açıkla düzelmiyor. Böyle durumlarda hiç uğraşmadan görmezden gelip kendim çözüyorum. Buna karşılık yeni yazılmış kodu review etmekte oldukça işe yarıyor. Yorumların yarısı işe yaramaz, bir kısmı muğlak ama bazen gerçekten önemli bir bug ya da sorunu yakaladığı da oluyor. Aynı anda birden çok sayfa vermek yerine parçalara bölerek kullanmak daha iyi. HLSL shader ya da SIMD gibi niş alanlarda, eğitim verisi eksikliği nedeniyle neredeyse hiç yardımcı olamıyor. Genel olarak kod kalitesini artırıyor. Kodu küçük birimlere ayırıp doğruladıkça, fonksiyon/sınıf/modül gibi mimari parçalanma daha netleşiyor ve genel kalite yükseliyor
Uzun vadeli yazılım geliştirmede LLM'i bir "ileri seviye boilerplate üreticisi" gibi kullanmak bana en çekici gelen senaryo. Bakım düşünmeye gerek olmayan tek seferlik işlerde zaten iyi ama uzun soluklu geliştirmede de soyutlamakta zorlandığın tekrarlı kodlar için (örneğin test kodu) gerçekten çok yararlı. Başta itici gelmişti ama şimdi çok memnunum. Sıkıcı ve tekrarlı kısımlar, "prompt optimizasyonu" gibi eğlenceli yeni bir oyuna dönüştü ve üretkenliğim de ciddi biçimde arttı. Prompt yazmak ve kod review yapmak, sıradan işleri elle yapmaktan çok daha hızlı bitiyor. Böylece geriye sadece gerçekten kafa yormaya değer ilginç kısımlar kalıyor
Sonunda LLM'in yalnızca kodlamada değil, birçok işte "moda diyet" gibi bir olgu olduğunu fark ettim. Herkes hızlı ve kolay bir çözüm istiyor ama sonunda sihirli bir yol yok. Kolaylık her zaman bir trade-off getiriyor ve er ya da geç herkes bu gerçeği kabul ediyor