- Kodlama LLM’lerini kullanarak net bir değer üretimi sağlamakta zorlanan geliştiriciler var
- Bazı kullanıcılar LLM’lerin çıktı kalitesinden memnun değil
- Somut gereksinimler veya karmaşık problemlerde LLM’ler beklentilerin altında kalma eğilimi gösteriyor
- Buna karşılık basit otomasyon ya da tekrar eden işlerde belli ölçüde kullanım kolaylığı sağlıyor
- Geliştiriciler prompt engineering ya da iş akışını iyileştirme yöntemlerini araştırıyor
Kodlama LLM’lerini kullanmadaki zorluklar ve iyileştirme yöntemleri üzerine tartışma
LLM’lerin sınırlı değeri
- Son dönemde birçok geliştirici ChatGPT, GitHub Copilot, Claude gibi kodlama LLM’lerini çeşitli amaçlarla deniyor
- Ancak hatırı sayılır sayıda kullanıcı, beklediği kadar gerçek üretkenlik artışı hissetmiyor
- Özellikle karmaşık algoritma yazımı, büyük ölçekli kodun yapılandırılması, proje mimarisi tasarımı gibi alanlarda LLM’lerin önerdiği kodlar çoğu zaman parçalı ya da verimsiz kalıyor
Çıktı kalitesine yönelik memnuniyetsizlik
- Bazı geliştiriciler, LLM’lerin sunduğu kodun bug içerdiğini ya da bağlamı yeterince anlayamadığı için hatalı sonuçlar verdiğini belirtiyor
- Açıklama veya analizlerin yetersiz olması ya da kodun projenin karmaşıklığını ve bağlamını doğru yansıtamaması sık görülen bir durum
Basit kullanım alanlarında sağladığı yardım
- Kısa kod parçacıkları üretme, tekrar eden işler, basit sözdizimi sorunlarını çözme gibi temel otomasyon alanlarında belirgin bir kolaylık sağladığı görülüyor
- Unit test, refactoring, kod stili düzeltmeleri gibi rutin görevlerde kullanım değeri yüksek bulunuyor
İyileştirme için denemeler
- Bazı geliştiriciler daha iyi sonuçlar almak için prompt engineering tekniklerini aktif biçimde uyguluyor
- Kendi iş akışlarına uygun LLM kullanım biçimlerini ve çeşitli açık kaynak araçlarla kombinasyonları deniyorlar
Sonuç ve çıkarımlar
- Şimdilik LLM’lerin tüm geliştirme ihtiyaçları için her derde deva bir çözüm olamayacağı kabul ediliyor
- Topluluk ve geliştiriciler, deneyimlerini paylaşarak verimli kullanım stratejileri ve sınırlamaları aşma yollarını arıyor
1 yorum
Hacker News yorumu
Bence geliştiriciler ikiye ayrılıyor. Bir grup, LLM'lerin kodlama konusunda tam bir süper güç olduğunu söyleyip üretkenliklerinin 100 kat arttığını iddia ediyor; diğer grup ise onları, gerçekten çok uğraşıp çabalayarak ancak sıradan sonuçlar alınabilen, oldukça uğraştırıcı araçlar olarak görüyor. Ama eğer LLM'lerle üretkenliği devrimsel biçimde artırdığını söyleyen ilk grup gerçekten bu kadar güçlüyse, o insanların çoktan pazarı ezip rakipleri silip süpürüyor olması gerekmez miydi diye merak ediyorum
Greenfield işlerde LLM sayesinde üretkenliğimin hissiyat olarak 100 kata kadar çıktığını düşünüyorum. Örneğin bir React uygulamasına birden fazla sayfa, Redux store, kimlik doğrulama gibi temel yapıları birkaç dakikada hızla ekleyebiliyor. "Şimdi X'i ekle" dediğimde çoğu zaman iyi sonuç veriyor. Ama mevcut sistemlerin bakımında, karmaşık özellik eklemede ya da alan bilgisinin önemli olduğu durumlarda LLM pek işe yaramıyor. Kod otomatik tamamlama veya fonksiyon tamamlama için iyi, ama bütün bir özelliği uygulama aşamasında kolayca sınırına geliyor. Bu gibi durumlarda LLM'e yaptırmakla benim doğrudan kodlamam aşağı yukarı aynı zamanı alıyor. Bu yüzden genelde istediğim yapıda önce stub kodu kendim yazıp boşlukları LLM'e doldurtuyorum. LLM'in 100 kat üretkenlik sağladığını söyleyenler muhtemelen daha kolay kısımlarla karşılaştı ya da henüz zor bölümlere toslamadı. Gerçekte işin %90'ı kolay, son %10'u ise gerçekten zor ve LLM orayı düzgün yapamıyor
Biraz alaycı olacak ama, 100 kat üretkenlik diyenler aslında küçük bir sayıyı 100 ile çarpıyor. Araştırma aşamasında LLM gerçekten inanılmaz yardımcı oluyor. Mesela yakın zamanda açıkça belirli bazı alanlara özgü lineer cebir kodu yazmam gerekti ve LAPACK gibi kütüphaneleri kullanamadığım için kendim uyguladım. Böyle durumlarda LLM'i başvuru kaynağı yerine kullanıp istediğim bilgiyi tek seferde toparlatınca, gerçek araştırma süresi 100 kat kısalabiliyor. Ama gerçek kod uygulamasını LLM'e bıraktığımda, uzman olmayanın fark etmesinin zor olduğu ince hatalar ekliyor. Junior biri olsa muhtemelen gözden kaçırabilirdi. Ben kod incelemesini önemli gördüğüm için, LLM ne kadar iyi olursa olsun kod yazma hızının kendisi çok artmayacak gibi geliyor. Ama hangi kodu yazmam gerektiğine karar verme, araştırma ve özetleme aşamasında LLM inanılmaz hız kazandırıyor. Sonuçta dünyadaki gerçek değer yenilik ve yaratıcı fikirlerdir, bunun da hâlâ insanın işi olduğunu düşünüyorum. LLM önemli bir yardımcı olacak ama yüksek katma değerli kodun doğrudan yazılması gerektiğine inanıyorum
Aslında bu iki grubun hiçbirine girmeyen bir durum da var. 100 kat üretkenlik değil ama kullanması da çok çileli değil. 30 yılı aşkın süredir profesyonel olarak kod yazıyorum ve her zaman bir şeyleri aramak zorundaydım; belirli dilleri ya da söz dizimini sık sık unutuyordum. Sonuçta birçok işte birden fazla dili dönüşümlü kullanmak gerekiyor. Eskiden sürekli referans kitaplarını, kılavuzları, hatta daha da zahmetli kaynakları didiklemek gerekiyordu. Google gibi arama motorları çıktıktan sonra biraz daha iyi oldu, Stack Overflow gibi platformlar ise bundan da verimliydi. Şimdi LLM bunun bir adım ötesi. Otomatik tamamlama önerileri bazen tam da aradığım ipucu olabiliyor. Elbette gereksiz olanı görmezden geliyorum ama sohbet arayüzünün Google veya SO aramasına kıyasla çok daha konuşmalı şekilde soru sormaya izin vermesi güzel
Matematik çalışmayı Math Academy, ChatGPT ve YouTube'la yapıyorum; özellikle 3Blue1Brown gibi kanallar çok faydalı. Bu kombinasyon olmasaydı çok eziyetli olurdu, şimdi ise keyifli. Daha önce University of Amsterdam'da benzer bir ders aldığımda ChatGPT bugünkü kadar akıllı değildi ve çok daha zordu. ChatGPT, öğretmenin cevap vermekte zorlanacağı soruları da yanıtlıyor; matematiğin kültürel arka planını da anlamam gerektiği için bana çok uyuyor, çünkü ancak o zaman bağ kurup yaratıcı çözümler üretebiliyorum. Mesela açılarda neden m harfinin kullanıldığını sordum, tarihsel olarak measure'dan geldiğini söyledi. Böylece artık tekrar matematiğin özüne odaklanabiliyorum. Hızlı varyans hesaplama formülünü de ChatGPT çok kolay açıkladı. Bu dünyayı ele geçirecek bir araç değil ama aslında hiç öğrenemeyeceğim bilgileri öğrenmemi sağlıyor. Tabii YouTube ve Math Academy'nin katkısı da büyük
LLM, birçok alanı geniş biçimde kapsıyor ve hiçbir alanda uzman olmayan kişiler için bir süper güç sağlıyor. Ama tek bir alanın derinine inip sürekli sadece orada çalışıyorsanız çok da faydalı değil. Örneğin her projede sadece bir kez gereken ve ayrı bir dağıtım uzmanı bulunmayan durumlarda LLM ile Dockerfile yazdırmak gerçekten harika. Ufak söz dizimi hataları ya da küçük sorunlar da Google'dan daha hızlı çözülebiliyor. Mimari trade-off'ları LLM'e analiz ettirip son kararı kendiniz verirseniz üretkenlik artışına yardımcı oluyor. Yine de prompt ile LLM'in saçma şeyler yapmaması için kapsamı iyi daraltmak gerekiyor ve gerçekte sık sık var olmayan API'ler uydurmak gibi akıl dışı hatalar yaptığı için tekrar tekrar düzeltme de gerekiyor. Buna rağmen yinelemeli çalışmada bile hız avantajı var
Ben de LLM'i çeşitli şekillerde kullanıyorum. Küçük debug sorunları, shell script'ler, kodlama, sorular gibi farklı durumlarda yardım alıyorum. Kişisel işlerde Claude, OpenAI dışında Google veya Perplexity gibi farklı araçlar arasında en iyi sonucu vereni seçiyorum. İş tarafında ise VSCode'da Copilot ya da şirket içi platform üzerinden Claude, OpenAI, Google kullanıyorum ve Copilot Studio'yu da biraz denedim. Bir buçuk yıldan uzun süredir bu şekilde çalışıyorum; bütün araçları sürekli kullanmış değilim ama genel izlenimim şu. LLM sayesinde üretkenliğim kesinlikle arttı. Farklı programlama dillerinde denemeler yaptım, çeşitli konuları daha iyi anlar hale geldim ve bazı işler belirgin biçimde kolaylaştı. Ama model ve sürümden bağımsız olarak, iş karmaşıklaştığında, kendi yolunu çizdiğinde veya basit birleştirmelerin ötesine geçtiğinde hepsinin başarısız olma eğilimi çok net. Hatta bazen LLM'in saçma çıktısını düzeltmek için harcadığım zaman, başta LLM temposuyla kazandığım tüm süreyi geri alıyor. Şu an dürüst sonucum şu: LLM küçük kod otomatik tamamlama, debug ve açıklamalar için yararlı ama hepsi bu. İşlerimizi hemen tehdit edemiyor
Yeni bir kütüphane, API veya dili öğrenirken LLM çok yardımcı oluyor. Mesela OpenGL'de metin render etmenin nasıl yapıldığını, dağınık ve hacimli resmî belgeleri okumaktansa doğrudan LLM'e sormak çok daha hızlı. Ya da tekrarlı ve sıkıcı boilerplate kod yazarken, elde örnek alınacak mevcut kod yoksa LLM işe yarıyor. Ama benim gerçek "iş" olarak gördüğüm, hizmetime özgü benzersiz kod alanlarında, "benim yerime kod yazıyor" anlamında LLM'in kullanımı çok yüksek değil. Kıdemli bir mühendis olarak gerçek kod yazmaya neredeyse hiç zaman harcamıyorum; önemli olan yapı tasarımı, legacy refactor, performans sorunları, nadir bug'ların ayıklanması gibi konular. LLM sadece tekrarlı kod yazımını hızlandırıyor; bu yüzden her hafta sıfırdan yeni proje başlatmıyorsanız pek de büyük faydası yok. Hâlâ çok fazla boilerplate yazıyorsanız, yalnızca LLM'e güvenmek yerine başka temel çözümleri de düşünmek gerekir
Dağınık resmî belgeleri okuyup açıklama konusunda LLM, sıradan bir programcıdan çok daha iyi. Bu alanda açıkça değer katıyor. Ayrıca boilerplate'i aşırı olan diller de yok mu diye düşünüyorum
Sihirli bir mermi yok; asıl zor olan kavramsallaştırma kısmı. Mythical man-month önemli bir metin, daha fazla okunmalı
Sihirli mermi yok. Fred Brooks'un basit tavsiyesini durmadan unutuyor olmamız şaşırtıcı. Beklentiyi fazla şişirmeden, eğitim verisinde bug'lı kod çok olduğu için LLM'lerin de doğal olarak bug taşıyacağını kabul edip kullanırsanız çok daha faydalı oluyor. Tasarımı ona yıkmamak, fonksiyonları bölmek gibi ön çalışmaları kendiniz yapmak ve onu sıkıcı işlerde, yabancı olduğunuz alanlarda zahmeti azaltmak için kullanmak gerekiyor. Ama LLM'in ürettiği kodun sorumluluğunu alacaksanız, bunun mutlaka kendi bilginize ve doğrulamanıza dayanması gerekir. LLM kodu kusursuz görünse bile içinde kusurlar saklı olabilir; bu yüzden kendi çalışmanızı ve becerilerinizi geliştirmeyi sürdürüp şüpheci kalmalısınız. Asla körü körüne güvenilmemeli
Sorunun ölçeği büyüdüğünde LLM'in işe yaramaz hâle geldiği çok açık. Tekrarlı işler veya karmaşık find & replace işlemlerinde mükemmel. API kaynaklarına CRUD metotları doldurmak gibi sıradan ve net kodlarda çok faydalı. Son zamanlarda Claude Opus 4 ile yamalarımı da gözden geçirtiyorum; bazen hataları yakalıyor, bazen de yapmam gerekenleri hatırlatıyor. Ama karmaşıklık belli bir eşiği geçince LLM'in faydası keskin biçimde düşüyor. Mesela birden fazla nispeten büyük dosyada değişiklik gerektiğinde, zaten hangi dosyaları değiştirmeniz gerektiğini kendiniz doğal olarak çıkarmaya başlıyorsunuz. Buna rağmen LLM'i bir 'rubber duck' olarak kullanmak fena değil. AI düzgün yaparsa güzel, yapamazsa hemen ben devam ediyorum. Sonuç olarak LLM başlangıçta biraz yardımcı oluyor ama değişikliklerin çoğunu zaten sonunda benim yapmam gerekiyor. Kabaca iskeleti oturtup sonra istediğim gibi elden geçirmek, tamamen sıfırdan yazmaktan daha kolay gibi. LLM'in açıkça zorlandığını görünce zorlamıyorum. Şartname belirsiz olduğu için yanlış tahminde bulunduysa söylüyorum; yine de yapamazsa gidip kendim bitiriyorum
Benim deneyimim de benzer. Şu alanlarda LLM'in değerini görüyorum: oldukça bağımsız React bileşenleri veya sayfaları, popüler bir UI kütüphanesiyle birlikte çok iyi üretebiliyor. İyi tanımlanmış saf fonksiyonları epey güvenilir biçimde yazıyor, doğrulaması da kolay. Bilinen framework'lerin boilerplate'ini gerçekten kolay ve düzgün çıkarıyor. Ama çevremdeki insanlar inanılmaz güçlü uçtan uca deneyimlerden söz ediyor, bende ise pratikte hiç öyle olmuyor ve bu biraz delirtici. Normalde ciddi emek versem bile tam bir özellik seviyesinde LLM tamamen çöküyor. aider gibi araçlarla Next.js'te basit bir şablon e-posta özelliğini bile yaptıramadım; işi daha küçük parçalara bölüp tek tek isteyince biraz daha iyi oluyor ama bu kez de mevcut kod giderek bozuluyor. Sorunları açıklasam da prompt arttıkça daha da tuhaflaşıyor. Sonunda elle düzeltmeye çalıştım ama kod tamamen darmadağın olmuştu
Vibe coder arkadaşlarımdan bazen "standartların çok yüksek" sözünü duyuyorum. Bence vibe coder'lar temelde kodu düzgün incelemediği için kalite çıtaları yok. Eğer vibe coding gerçekten bu kadar işe yarasaydı, Google AI gibi yerler devasa GPU, TPU bütçeleri ve en yeni yapay zeka modelleriyle ürünlerini insanlardan ezici biçimde daha hızlı geliştiriyor olurdu. Eğer gerçekten böyle bir şey olsaydı, işimizin kolaylaştığını görmeden önce bunu haberlerde patlayan beklenmedik dev bir gelişme olarak öğrenirdik; bunun nedeninin AI olduğunu ise çok daha sonra anlardık
LLM tek kullanımlık kod için iyi. Geliştirme, bakım, debug ve düzeltme ise kolay şeyler değil. Kodun büyük kısmı gerçekte ürün değil, adeta 'tüketimlik' kod olduğu için buna uygun. Fast food, montaj hattı, otomasyonlu üretim gibi kavramlar burada uygulansa da arada çok büyük fark var. Fabrikada makinelerin ürettiği şeyler %99,99'dan fazla doğrulukla çıkıyor ve güvenilebilir. Ama LLM'de her adımı benim tek tek doğrulamam gerekiyor; doğrulamazsam çoğu zaman zaten çalışmıyor. LLM'in 24 saat gözetimsiz biçimde başarıyla çözüm üretmesi mümkün değil. Bu yüzden de henüz işlerimizi elimizden almıyor
Ben hiçbir zaman LLM'e karmaşık bir problemin tamamını bırakıp sonucu almayı düşünmem. Bu onun güçlü olduğu yer değil. LLM'in gerçek değeri, ilerlemeyi sağlayan 'ipuçları' vermesi ve basit ama zaman alan parçaları atlatmayı sağlaması. Birkaç gün önce log string'i oluşturuyordum; LLM, aklımdakinden daha güzel formatlanmış bir kodu hemen önerdi ve 15 dakika sürecek işi 30 saniyede gayet iyi biçimde bitirdim. Bu tür küçük kazanımlar birikerek değer oluşturuyor
notepad.exebile yeterli olabilir. Lisp gibi hem basit hem güçlü dillerde parantez vurgulama kesinlikle gerekli. Son 10-20 yıla bakınca dillere göre değişim var. Java, C#, C++ fonksiyonel dillerden çok şey ödünç aldı; JVM'de Clojure var; Go iseif err != nilgibi inatçı kalıpları koruyor. Rust?ekledi, Zig de benzer. Python ise tür ek açıklamaları gibi şeylerle giderek daha uzun ve karmaşık hâle geliyor. Otomatik biçimlendiriciler gerçekten rahat; girintiyi düşünmeyi bırakıyorsunuz ama Python boşluğa duyarlı olduğu için kusursuz da değil. Araçlar geveze dillere yardımcı oluyor, ifade gücü yüksek diller ise kısa ve öz kod yazmayı sağlıyor. Kod yazmaktan çok okumaya zaman harcıyoruz. Deterministik araçlar kodun yapısında güçlü; LLM gibi olasılıksal araçlar ise niyete yaklaşmada güçlü. Dil modelleri otomasyon araçlarının evrimleşmiş biçimi ve otomatik tamamlama gibi giderek iyileşecekler ama kodlamayı 'tamamen çözemezler'. Burada tek bir doğru cevap yok; eninde sonunda sadece görüş farkı var