- LLM tabanlı kodlama yardımcı araçlarının piyasaya çıkmasının üzerinden yaklaşık 2 yıl geçti
- Bazı geliştiriciler üretkenliğin 5 ila 10 kata kadar arttığını bildiriyor
- Ancak yazılım sektörünün genelinde üretkenliğin 5–10 kat arttığına dair net bir kanıt yok
- Gerçekte, bir kod tabanına basit boilerplate özellikler eklemenin ötesindeki işlerde LLM araçları zorlu davranıyor
- Programcıların çoğu LLM araçlarını etkili kullanmayı bilmiyor ya da buna ilgi duymuyor
Üretkenlik artışı neden yalnızca belirli kullanıcılarda yoğunlaşıyor?
- Eğer üretkenlik 5 ila 10 kat arttıysa, bu büyük olasılıkla LLM’leri iyi kullanan az sayıdaki ileri düzey kullanıcıya veya deneyimli geliştiriciye özgüdür
- Yazılım sektörünün genelinin bir anda çok daha fazla faydalı özellik sunduğuna ya da kalitenin gözle görülür biçimde arttığına dair bir işaret yok
- Yazar, son 1–2 yılda LLM’lerin etkisini neredeyse hiç hissedemediğini söylüyor
LLM’ler gerçekte hangi projeleri mümkün kıldı?
- LLM performansı sayesinde mümkün hale gelen projelerin neler olduğu net biçimde görülemiyor
- Araştırma sonuçlarında da somut örneklere neredeyse hiç rastlanmıyor (tek örnek olarak COBOL refactoring anılıyor)
- AGI laboratuvarlarının LLM tabanlı ürünleri de özellikle etkileyici sonuçlar göstermiyor
- Sohbet penceresinde PDF yükleme gibi temel işlevler sunma düzeyinde
- LLM’lerin çeşitli yazılım ve veri türleriyle sorunsuz arayüz kurmasını sağlayan yetenekler yetersiz
Soru: Üretkenliğin gerçekten arttığı alanlar var mı?
- LLM sayesinde hangi projelerin daha hızlı yayımlandığına dair açık bir kanıt yok
- Yazılım ekosisteminde belirli bir alanın 10 kat büyüdüğüne dair iz görünmüyor
İstenen şey açık ve somut kanıt
- Aşağıdaki türde bilgiler gereksiz görülüyor
- Üretkenliğin 10 kat arttığına dair muğlak iddialar
- Soyut ekonomik göstergeler veya kod üretim miktarındaki artışa dair sözler
- Basit LLM tabanlı araç ya da özellik üretimi örnekleri
- "ChatGPT ile Snake klonu yapmak" gibi önemsiz örnekler
Komplo teorisi: LLM’ler gerçekte üretkenliği artıramıyor olabilir
- LLM’in ürettiği kodu düzeltmek ve sorunlarını çözmek için tersine zaman harcanıyor
- LLM’in ürettiği büyük kod tabanları belli bir karmaşıklık düzeyini aşınca değiştirilemez hale gelip en baştan yeniden yazılmak zorunda kalabiliyor
- LLM’ler yeni yazılım oluştursa bile bunun çoğu tek seferlik araçlar ya da kullanılmayan proof-of-concept kodlarla sınırlı kalabilir
- Gerçekten faydalı yazılımlarda kod miktarı artsa bile gereksiz özelliklerin veya bloatware’in çoğalma riski var
- Programcılar, LLM’lerle anında sonuç almanın verdiği "sihir" hissiyle yanıltılıyor olabilir
Gerçekçi üretkenlik artışı aralığı
- Yazara göre LLM’ler yalnızca şu gibi belirli durumlarda faydalı
- Basit özellik yazımı
- Belirli kütüphaneleri veya kod tabanlarını öğrenmeye yardımcı olma
- Basit refactoring işleri yapma
- Üretkenlik artışının kabaca %10–30 düzeyinde olması daha olası
- Üretkenliği en üst düzeye çıkarmak, AGI (yapay genel zeka) ortaya çıkana kadar zor görünüyor
[Richard Horvath’ın yorumu]
LLM’lerin belirli durumlarda 10 kat hız artışı sağlayabildiği örnekler
- Küçük, bağımsız script’ler yazmak
- Basit görevlerde (ör. dosya işlemleri için bash script’i, Excel VBA kodu) büyük fayda sağlıyor
- Kısa bir açıklamayla kolayca üretilebiliyor ve doğrulaması da kolay
- Dile dair derin bilgi olmadan da yazılabiliyor
- Bakım, modülerlik, unit test gibi konuları hesaba katmak gerekmiyor
- Özellikle regex ile ilgili işlerde çok etkili
- Yabancı olunan bir stack içinde çalışırken öğrenme hızını artırmak
- Yeni bir kütüphanenin sınıf ve metotlarını hızlıca kavramayı sağlıyor
- Kod tamamen çalışmasa bile sorunu çözmeye dönük bir yaklaşım sunuyor
- Eskiden doküman veya ders aramak için harcanan süreyi ciddi biçimde azaltıyor
- Ancak üretilen kodun yine de elle düzeltilmesi ve refactor edilmesi gerekiyor
10 kat üretkenlik artışı bildiren kişilerin muhtemelen girdiği kategoriler
- Geliştirme bilgisi düşük olanlar
- Temel kodlama becerileri zayıfsa, LLM yardımıyla yazılan kod öncekine kıyasla çok daha iyi görünebilir
- Ancak bu durumda LLM kodunun uzun vadede olumsuz etki yaratma ihtimali yüksektir
- Çok sayıda küçük ve bağımsız çözüm yazması gerekenler
- Excel otomasyonu işleri veya DevOps tarafında shell script yazımı gibi alanlarda LLM özellikle faydalıdır
- Farklı stack’ler ve kütüphanelerle sık sık deney yapmak zorunda olanlar
- Uzun süre tek bir stack’te çalışmaktan ziyade, deney ağırlıklı işlerde bu daha geçerlidir
- Anchoring Effect oluşması
- LLM’in belli görevlerde anında sonuç vermesi, uzun vadeli üretkenlik artışının abartılmasına yol açabilir
[Davidmanheim’in yorumu]
- Sıradan şirketlerde kod yazan kişiler ve yöneticiler açısından LLM’lerin üretkenlik katkısı pratikte sınırlı kalmak zorundadır
- Bu durum Theory of Constraints perspektifiyle açıklanabilir:
- Önceden işin şu süreçle tamamlandığını varsayalım:
- İş analisti (Business Analyst) → 1 gün
- QA test uzmanı → 1 gün
- Programcı → 1 gün
- Programcının üretkenliği 2 kat ya da 5 kat artsa bile toplam iş süresi kısalmaz
- Çünkü diğer aşamalar (iş analizi ve QA) darboğaz olur ve sürecin genel hızı değişmez
- Kurumsal süreçlerin yeniden yapılandırılması gerekir
- LLM’lerin üretkenlik artışından tam yararlanmak için şirketin tüm süreçlerini yeniden düzenlemek gerekir
- Ancak şu anda bu tür süreç dönüşümleri yalnızca bazı şirketlerde yeni yeni başlıyor
[faul_sname’in yorumu]
- LLM’lerle özellikle UI mockup üretiminde şu sonuçları yaşadığını söylüyor:
- Önceden UI mockup üretimi toplam iş süresinin yaklaşık %10’unu alıyordu
- LLM sayesinde UI mockup üretim hızı yaklaşık 5 kat arttı
- Ancak toplam çalışma süresi aslında azalmadı
- Bunun yerine UI mockup’larının detayı ve etkileşim seviyesi ciddi biçimde gelişti
- Daha fazla iterasyon mümkün olduğu için sonuçta ürün kalitesi iyileşti
- "Atılacak kod" mutlaka işe yaramaz demek değildir
- Prototip veya proof-of-concept kodları bile daha iyi bir nihai ürün geliştirilmesine katkı sağlayabilir
- LLM’ler ayrıca arama motoruyla bulunması zor belirli hatalara yanıt verebiliyor
- Örnek: "xyz stack üzerinde çalışan bir işte oluşan hatanın nasıl çözüleceği"
- Belirli stack ve Kubernetes yapılandırması bağlamında debug etmeye yardımcı oluyor
- Toplam üretkenlik artışını yaklaşık %10–30 olarak değerlendiriyor
- Ancak üretkenlik tüm işlerde eşit biçimde artmış değil
- Belirli görevlerde çarpıcı hızlanma var (ör. UI mockup, debugging vb.)
- Karmaşık veya legacy kodla çalışırken belirgin bir kazanım yok
- Üretkenlik artışı projenin başında daha belirgin, karmaşık bakım aşamalarında ise etkisi azalıyor
- Bu yüzden asıl sınırın agency eksikliği değil, context management sorunu olduğunu düşünüyor
[Noosphere89’un yorumu]
- Ajeya Cotra’nın görüşüne atıfla, LLM’lerin programcı üretkenliği üzerindeki etkisine dair şu noktaları öne çıkarıyor:
- Kodlama işlerinde AI verimliliği beklenenden yüksek
- AI, kodlama görevlerinde kayda değer sonuçlar veriyor
- Ancak kodlama dışı işlerde performans çok daha zayıf
- Bu yüzden AI’nin genel endüstriyel etkisi hâlâ sınırlı
- Ajeya Cotra’nın ilgili açıklama bağlantıları
- "Uzun vadeli sonuçlar için AGI gerekir" iddiası hakkında ise
- AI’nin bugünkü gelişim çizgisinde genel yetenek (Generality) beklenenden daha sınırlı görünüyor
- AI performansı bazı görevlerde keskin biçimde yükselirken bazı alanlarda belirgin zayıflıklar gösterebiliyor
- Bu performans dengesizliği nedeniyle AGI (yapay genel zeka) kavramı beklenenden daha az kullanışlı olabilir
[yo-cuddles’ın yorumu]
- Ofiste robotik süreç otomasyonu (RPA) yapan bir kişiye dair örnek veriyor
- Bu kişi kendisinin çok daha üretken olduğunu güçlü biçimde savunuyor
- Ama gerçekte verimsiz ve güvenilmez çalıştığı için başkaları onun işini düzeltmekle zaman kaybediyor
- İş arkadaşları onu iş akışının dışına itmeye çalışıyor
- İnsanlar kendi üretkenliklerini doğru ölçemiyor; özellikle bazı kazanç veya kayıpları daha fazla fark ediyorlar:
- Göze çarpan kazanımlara odaklanma
- Otomasyonla bir işi hızlıca bitirmek anında güçlü bir başarı hissi yaratıyor
- Hızlı sonuçlar hemen görülebildiği için olumlu etki olarak algılanıyor
- Uzun vadeli maliyetleri fark etmek daha zor
- İş sonrasında ortaya çıkan zaman maliyeti kolayca izlenemiyor
- Özellikle sorunları başkaları düzeltirse, bu maliyet daha da görünmez hale geliyor
- Otomasyonlu işlerde oluşan hatalar düzeltilse bile bunun doğurduğu zaman kaybını hissetmek zor
- LLM kodunun yol açtığı sorunları fark etmek şu nedenlerle daha zor:
- Hata çıktığında bunun nedeninin LLM kodu olduğunu doğru biçimde izlemek zor
- Sorunu düzeltme sürecinde başka insanlar ek zaman harcayabiliyor
- Kişi sorunun kök nedenini fark etmeyip bunun otomasyon aracını kullanmasından kaynaklandığını anlamayabiliyor
- "Otomasyon sayesinde hızlı bitirdim" hissi güçlü, ama "otomasyon yüzünden boşa zaman harcandı" hissi zayıf kalıyor
- LLM kullanımı yaygınlaşmış olmasına rağmen sektör genelinde üretkenlik artışının net biçimde görünmemesi dikkat çekici
- İnsanlar "2 kat daha üretkenim" diyebiliyor ama gerçekte gizli sorunlar yüzünden üretkenlik düşmüş olabilir
- Yani sorun çözmeye harcanan zaman ve kaynaklar görünmez kaldığı için başarı algısı abartılabiliyor
6 yorum
Benim deneyimime de benzer geliyor.
Yukarıdaki gibi durumlarda epey zaman kazandırdı. Google + Stack Overflow kombinasyonuyla da iyi bulunmayan durumlar çok oluyor; özellikle Stack Overflow'da bir yanıt varsa yorumlarda sürekli itirazlar çıkması, eski sürüm uygulama yöntemleri olup artık kullanılmaması gerektiği gibi sorunlar yüzünden gerçekten çok sinir bozucu oluyordu...
Sanırım 10x verimlilik, prototipleme yaparken ortaya çıkıyor.
Bana bayağı tatlı geliyor.
> Programcıların çoğu LLM araçlarını etkili biçimde nasıl kullanacağını bilmiyor ya da buna ilgi duymuyor
Çevremdeki birçok geliştirici şaşırtıcı biçimde teknolojiyle ilgilenmiyor. Zamanlarının çoğunu yeni ya da tekrar eden YouTube Shorts videolarını mekanik bir şekilde tüketerek geçiriyorlar.
Hacker News görüşleri
Seattle'daki popüler bir teknoloji şirketinde çalışıyor ve yapay zeka kullanımı dayatılıyor. Yönetim, geliştiricilerin yapay zekayı ne kadar kullandığını takip ediyor ve kendisine neden daha fazla kullanmadığını da sormuş. Doğru araçları doğru işlerde kullanmanın önemli olduğuna inanıyor ve yapay zekanın her zaman uygun olmadığını düşünüyor
Yazılım projelerinde son %10'un zamanın %90'ını aldığına dair eski bir söz var. Yapay zeka ilk %90'da yararlı ama son %10'da işe yaramıyor
FAANG'de LLM'ler IDE'ye entegre edilerek kullanılıyor ve bir miktar olumlu etkisi var
Gerçekten 10 kat iyileşme yaşayan bir geliştirici örneği olarak, Pieter Levels'ın 3D çok oyunculu bir uçuş simülatörünü birkaç günde kodlaması gösteriliyor
LLM kullanarak kod üretmeyi denemiş ama başlangıçta üretkenliği düşmüş
GitHub'da Copilot Autofix geliştiren ekibin bir üyesi; CodeQL uyarılarına dayalı düzeltme önerileri sunuyorlar
LLM kodlama yardımcılarının yanıt kalitesi, programcının iletişim becerisinden büyük ölçüde etkileniyor
Yazılım üretkenliğinin 5-10 kat artmadığı varsayımı yanlış olabilir
Hacker News görüş özeti çevirisindeki son madde olan "yazılım üretkenliğinin 5-10 kat artmadığı varsayımı yanlış olabilir" ifadesi bir çeviri hatası gibi görünüyor. Aslına bakılırsa, orijinal metne göre "yazılım üretkenliğinin 5-10 kat arttığını söylemek, üretkenlik artışına dair hatalı bir varsayıma dayanıyor" şeklinde özetlemek daha isabetli görünüyor.