- LLM kod üretim araçlarının sektörde coşkuyla benimsenmesine karşı, yazılım geliştirmede düşünmenin önemini vurgulayan bir yazı
- Otomatik üretilen kod deterministik değildir (non-deterministic) ve iç işleyişi opaktır; bu yüzden her seferinde aynı sonucu garanti eden mekanizasyondan özünde farklıdır
- LLM’ler mevcut düşük kaliteli kodları öğrenip aynı hataları tekrar eder ve bunu yeniden öğrenir; buna "human centipede epistemology" sorunu deniyor
- Kod üretimi ajanlara devredildiğinde, PR incelemelerinde paylaşılan bağlam ve sorumluluk zayıflar ve bu da yazılım kalitesini olumsuz etkiler
- LLM’ler prototipleme gibi sınırlı kullanım alanlarında faydalıdır; ancak geliştiricinin düşünme eyleminin kendisini dış kaynak kullanımıyla devretmesi risklidir ve anlamadan bakım yapmak mümkün değildir
LLM kod üretimine dair rahatsızlık
- Uzun süredir sektörün son eğilimlerini takip edip CSS ve JS’deki yeni özellikleri ekip arkadaşlarıyla paylaşmış biri olmasına rağmen, LLM tabanlı kod üretiminin hızla yayılmasıyla birlikte geri kalıyormuş gibi hissettiren bir kaygı yaşadığını anlatıyor
- Copilot ve Claude’u "spicy autocomplete" ve hata ayıklama yardımcı araçları olarak kullansa da, biraz karmaşık görevler verildiğinde ortaya çıkan sonuçların berbat olduğunu söylüyor
- Yeterli bağlam sağlamak gerekiyor; ama çok fazla bağlam verilirse sistem aşırı yükleniyor ve "Siz dağıtık sistemler uzmanısınız" gibi LLM’nin egosunu okşayan uzun prompt’lar yazmak gerekiyor
- Çoğu zaman prompt’u inceltmek için harcanan zamandan daha hızlısı kodu doğrudan yazmak oluyor
- Mühendislerin kodlama gibi keyifli bir işi bırakıp geriye sadece inceleme gibi sıkıcı bir işi bırakmak istemesine kuşkuyla yaklaşıyor
"Sanayi Devrimi’nin yeniden sahnelenmesi" iddiasına itiraz
- Sanayi Devrimi’nin iklim değişikliğine katkıda bulunması gibi, AI veri merkezlerinin devasa enerji tüketiminde de benzer bir örüntü görülüyor
- Tüm elektrik fosil yakıt temelli olmasa da, "karides İsa" görselleri üretmek gibi işler için muazzam kaynak israfı var
- Mekanizasyon ürünleri ucuzlatıp yaygınlaştırdı; ama aynı zamanda kalite düşüşüne yol açtı ve SHEIN’den bir fincan kahveden daha ucuza pantolon alınabilen bugünkü tabloya katkı sundu
- Bu durum nitelikli emeğin gerilemesi, fabrikaların düşük ücretli ülkelere taşınması ve işçi sömürüsüyle daha da kötüleşti
- Üretilen kod hızlı modaya benziyor: ilk bakışta iyi görünüyor, ama zamanla delik deşik oluyor; çoğu zaman başkalarının kodlarını izinsiz ödünç alıyor ve çevreye de zarar veriyor
- Temel fark şu: mekanizasyon her seferinde aynı sonucu üretir ve sorun çıktığında içine bakılabilirdi; LLM çıktısı ise deterministik değildir ve iç işleyişi opaktır
- Her seferinde farklı sonuç veren ve içine halüsinasyonlar (hallucination) karışan bir mekanizasyon süreci kullanışlı değildir
"Yeni bir soyutlama katmanı" iddiasına itiraz
- Java ya da Go kullanırken artık assembly öğrenmek zorunda olmamak doğru; çöp toplama ve bellek ayırma gibi işleri runtime üstleniyor
- Ancak sistem mimarisi, kritik yola etkisi, bakım yapılabilirlikle dağıtım hızı arasındaki ödünleşim, tarayıcı uyumluluğu, erişilebilirlik, güvenlik, performans gibi alanlar hâlâ geliştiricinin bizzat düşünmesi gereken konular
- LLM’lerin en büyük zararı verdiği nokta, mühendisin yazılım geliştirmek için gereken düşünmenin kendisini dışarıya devretmesi
- LLM’lerin muhakeme yeteneği olmadığı için, geliştirici de düşünmüyorsa ve LLM de düşünmüyorsa kimse düşünmüyor demektir
- Horizon skandalı örneği: Post Office yazılımındaki bir hata yüzünden masum çalışanlar hapse girdi ve 13 kişi intihar etti
- Yazılımda hesap verebilirlik (accountability) her zamankinden daha önemli
Düşük kaliteli kod asıl sorun
- İnsan geliştiriciler de erişilebilirliği zayıf, performansı düşük ve JavaScript’e aşırı bağımlı kodlar yazıyor
- LLM’ler bu düşük kaliteli kodlarla eğitim verisi olarak eğitiliyor (açık rıza olmadan) ve aynı hataları tekrar üretiyor
- LLM’nin ürettiği düşük kaliteli kodun yeniden başka bir LLM tarafından öğrenildiği döngüsel yapı, yani "human centipede epistemology"
- Yardımcı teknoloji kullanıcıları, kötü internet koşullarındaki kullanıcılar ve yüz tanıma yazılımlarındaki ırkçılığın mağdurları düşünüldüğünde, bugünkü yazılım kalitesi yeterli değil
- İnsan olarak öğrenip iyileştirmek yerine, hatalar düşünmeyen algoritmalara dış kaynakla devredilmiş durumda
PR incelemesi ve paylaşılan bağlamın zayıflaması
- FFConf’ta Jessica Rose ve Eda Eren’in sunumu şu temel mesajı veriyor: "Kendiniz yazmadığınız kod, anlamadığınız koddur; anlamadığınız kodun bakımını yapamazsınız"
- Bir ekip arkadaşının yazdığı PR belli bir düzeyde güven ve düşünme süreci içerir; ama LLM tarafından üretilen PR’larda böyle bir güvence yoktur
- Açık kaynak bakımcıları düşük kaliteli LLM üretimi PR’ların patlamasını yaşıyor
- Bazı şirketler Slack’te Claude’a sohbet üzerinden kod değişikliği istiyor ve otomatik üretilen PR’ı aynı kişinin onayladığı bir yöntem kullanıyor
- Bu durumda sorumluluk yalnızca tek bir inceleyicide toplanıyor ve iki çift gözden biri kaybediliyor
- Ekip içindeki paylaşılan bağlam (shared context) da azalıyor
- PR incelemesi sadece hata kontrolü değil, aynı zamanda kod ve değişiklikler hakkında ortak anlayış geliştirme süreci
İlerlemeye değil, abartıya karşı çıkmak
- Karşı olunan şey LLM’nin kendisi değil; "yapay zeka" markalaması
- LLM’ler zeki değildir; makine öğrenmesinin bir biçimidir
- "Generative AI", insanların aşırı beklenti yüklediği çok iyi yapılmış bir Markov zinciridir
- Prototip, wireframe ya da interaktif demo gibi şeyleri hızlı üretmek için kullanmak makul olabilir
- Sorun, "vibe code" ile production düzeyi yazılım üretilebileceğine inanmak ya da kodlamadaki düşünme sürecinin kendisini devretmek
- Zed blogunda Mikayla Maki’nin görüşü: ajanlara güvenilmeyen harici katkıcılar gibi davranılmalı; yalnızca zaten nasıl yapılacağını bildiğiniz işlerde kullanılmalı ve kodu anlamak şart
- "spicy autocomplete" kullanılmaya devam edilebilir; ancak düşünme dış kaynakla devredilmemeli ve bu işi başta neden sevdiğimizi hatırlamak gerekiyor
2 yorum
> Otomatik olarak üretilen kod deterministik değildir
> "yapay zeka" olarak markalanmasına karşıyım
Gerçekten de en önemli söz bu..
GeekNews'te de bunu hesap makinesi ve kameraya benzetenler vardı; geliştiricilerde bile böyle bir algı varsa sıradan insanların durumu nasıl olur diye düşününce gerçekten vahim görünüyor.
Hacker News görüşleri
Yapay zekâ, ‘zihnin bisikleti’ olarak değil de yalnızca büyük şirketlerin kârını maksimize etmeye yönelik bir ürün olarak görüldüğü sürece, mevcut yapay zekâ durumunu meşrulaştırmanın zor olduğunu düşünüyorum
Gerçek bir öğrenme süreci olmadan veriyi toplayıp işleyerek geri sunan bu yapı, insanın zihinsel gelişimi açısından elverişsiz
Sonuçta asıl mesele bir gelir modeli kurmak; aksi hâlde yüksek kaliteli LLM’leri sürdürmek mümkün değil
Artık neredeyse hiç manuel düzenleme yapmıyorum. Claude Code’a sadece ticket URL’sini atsam bile çoğunu tek seferde çözüyor
Bu yaklaşıma yatırım yapan ekiplerin, yapmayanlara kıyasla çok daha yüksek verimliliğe ulaşacağına inanıyorum
LLM’ler kişiden kişiye tamamen farklı deneyimler sunan bir teknoloji ve prompt serbestliği çok yüksek
Belirli bir tasarımı uygularken ise bizzat yazmak daha hızlı oluyor
“Benim yazmadığım kodu anlayamam” sözü gerçekçi değil
Code review’un amacı kodu kimin yazdığı değil, sistematik güvenilirliği sağlamak
İster insan yazsın, ister AI, hatta golden retriever klavyeye bassın, fark etmez
Ama AI’ın açtığı bir PR’ı sırf anlamak için zaman harcamaktansa, prompt’u kendim verip sonucu almak daha mantıklı geliyor
LLM’e bağımlı kalındığında geliştirici proje yapısını öğrenme fırsatını kaçırıyor ve sonunda sistemi bir kara kutu gibi ele alıyor
Bu eğilim, geliştiricileri ‘prompt kiddie’ye dönüştüren bir değişim
“Prompt’u inceltmekle zaman kaybedeceğime kodu kendim yazarım” sözüne katılıyorum
Sorun ‘üretim’ değil, yapısız üretim
Yani doğaçlama prompt’lar yerine, net beceri birimi bileşimi (composition) ile yaklaşmak gerekiyor
AI’a “sen dağıtık sistemler uzmanısın” demek GPT-3 dönemi işi
Artık fine-tuning ve sonradan işleme teknikleri sayesinde böyle rol tabanlı prompt’lara gerek yok
LLM ile kod üretme furyasını izlerken, “acaba geri mi kalıyorum?” diye kaygılandım
Copilot ve Claude’u sadece otomatik tamamlama yardımcısı olarak kullanıyordum ama karmaşık kodlarda hâlâ berbattılar
Ama bugünlerde ajan tabanlı araçlar kod tabanını tarıyor, web’de kaynak buluyor ve bağlamı kendi kendine ayarlıyor
Sonuçta mesele, “teknolojiyi gerçekten anlamadan şikâyet edenler” gibi görünüyor
Gerçekte sorun büyük ihtimalle prompt becerilerinin yetersizliği
Etrafındaki araçlar arama ve yürütmeyi otomatikleştirdiği için sanki ‘düşünüyormuş gibi’ görünüyor
Sonuçta bu otomasyon, zekâ değil
Son zamanlarda HN’deki birçok yazı ve yorum LLM yazmış gibi hissettiriyor
Yeni hiçbir şey yok; çoğu sadece yüzeysel genellemeleri tekrarlıyor
Son haberlere bakınca yapay zekânın henüz yeterince olgunlaşmadığı görülüyor
Örneğin: Microsoft’un Copilot gelir hedefini düşürmesi ve
Moltbook’un güvenlik sorunu örnekleri
Sonuç olarak çoğu insan AI’a güvenmiyor
AI; fikir keşfi ya da boilerplate yazımı için faydalı olsa da, hâlâ asıl kritik olan düşünme becerisi
AI, insan düşüncesinin yerini alabilecek en güçlü ayartı ama uzun vadede düşünme kaslarını zayıflatma riski taşıyor
Bir süre kullandıktan sonra tekrar elle kod yazmayı denerseniz akıcılığınızın azaldığını hissedebilirsiniz
Copilot değil de Claude daha iyi olduğu için de böyle görünüyor olabilir; Moltbook’un güvenlik sorunu da erken dönem servislerin kaderi olabilir
Sonuçta tablo, AI benimseyen ve benimsemeyen şirketlerin hayatta kalma oranlarıyla ortaya çıkacak
Ben de eskiden “AI aptal bir kara kutu” diye düşünüyordum ama son 6 ayda bakış açım tamamen değişti
Doğru şekilde öğrenildiğinde şaşırtıcı sonuçlar üretebiliyor
Şimdi AI’ı bir amplifikatör olarak görüyor, kendi yeteneklerimi genişleten bir araç gibi kullanıyorum