LLM ile Kodlama (2025 Yazı)
(antirez.com)- Redis geliştiricisi antirez'in LLM kullanım deneyimine dair güncelleme
- Gemini 2.5 PRO ve Claude Opus 4 gibi en ileri LLM'ler, geliştiricinin yeteneklerini güçlendirir
- LLM kullanımı, hata giderme, fikir testi, bilgi alanını genişletme gibi birçok yolla iş verimliliğini artırabilir
- Uzman olunmayan alanlarda veya yeni teknolojilerde, LLM yardımıyla bunları kolayca ele alma deneyimi mümkündür
- Ancak kodun genel kalitesi ve sürdürülebilirliği için 'insan + LLM' işbirliği kritik önemdedir
- LLM'den en iyi verimi almak için yeterli bağlam sağlama ve net iletişim kurma becerisi önemlidir
LLM ile geliştirmenin değişimi ve temel noktalar
En ileri LLM'ler (Gemini 2.5 PRO, Claude Opus 4 vb.), güçlü anlama kapasitesi ve büyük hacimli kodu işleme yeteneği sayesinde yazılım geliştiricilerin becerilerini genişleten bir rol üstleniyor.
- Problemi açık biçimde tanımlayabiliyor ve yinelemeli iletişime alışkınsanız
- Hataları yayına çıkmadan önce giderme deneyimi yaşayabilirsiniz (ör. Redis'in Vector Sets uygulamasında Gemini/Claude kod incelemesiyle hataların anında kaldırılması)
- Bir fikrin çalışıp çalışmadığını hızla test ederken deneysel kod yazımı ve performans değerlendirmesi yapabilirsiniz
- Deneyim ve sezgiye dayalı pair-design mümkün olur; LLM'in zengin uzman bilgisi ile insan sezgisi birleşir
- LLM'e net yönergeler verirseniz, kodun bazı bölümlerinin uygulanmasını hızlıca tamamlayabilirsiniz
- Yabancı alanlarda bile (ör. Amiga için 68000 assembly kodu) hızlı teknik uyum mümkündür
Önceki 'LLMs ve 2024 başında programlama' yazısında LLM'lerin faydasından söz edilmişti; ancak son 1,5 yılda LLM'ler sıçramalı biçimde gelişti.
LLM'lerden en iyi şekilde yararlanmak için hem insanın hem de LLM'in belirli yetkinlik ve alışkanlıklara sahip olması gerekir; bu yüzden bu konuda bazı ilkeler önemlidir.
Vibe Coding'e mesafeli durmak ve insan+LLM işbirliği ilkeleri
Bugünün LLM'leri geliştirici yeteneğini büyüten araçlar olarak çok başarılı olsa da, tamamen kendi başına tüm işi yürütecek düzeye henüz ulaşmış değiller.
- Testler, küçük yardımcı araçlar gibi tek seferlik küçük projelerde yalnızca LLM ile tasarım mümkün olabilir
- Ancak büyük ve sıradışı projelerde LLM'i tek başına kullanmak; karmaşıklık, gereksiz kod ve yapısal zayıflıklar gibi sorunlara yol açma riski taşır
- En büyük üretkenlik artışı LLM+insan işbirliğiyle görülür; ancak bunun önkoşulu etkili iletişim ve LLM yönetimi konusunda deneyim sahibi olmaktır
- Karmaşık işleri yalnızca LLM'e bırakmayın; insanın sürece her zaman aktif biçimde müdahil olduğu bir strateji gereklidir
LLM'e yeterli bağlam vermenin önemi
LLM'in geliştirme veya hata düzeltme yönünü doğru biçimde anlamasını sağlamak için geniş kapsamlı bağlam bilgisi sunmak şarttır.
- Makaleler, hedef kod tabanı (mümkünse bütünü) ve işin amacı gibi bilgiler verilmelidir
- Uygulamanın amacı, gereksiz ya da zayıf yaklaşımlar, uygulanabilir temel fikirler, hedefler, değişmez koşullar ve kod stili gibi temel bilgiler yer almalıdır
- Örneğin LLM'in bilmediği yeni bir teknolojiyi (ör. Redis vector sets) ele alırken, README belgesini bağlama eklemek anında uzman düzeyinde yanıtlar alınmasını sağlayabilir
LLM seçimi ve kullanım yöntemi
En çok bilinen LLM her zaman en iyi sonucu vermeyebilir.
- Kodlama için Gemini 2.5 PRO ve Claude Opus 4 özellikle etkilidir
- Gemini 2.5 PRO, karmaşık hata tespiti ve problem çözmede üstündür
- Claude Opus 4, yeni kod yazma konusunda güçlüdür ve kullanıcı deneyimi de iyidir
- Bu iki modeli dönüşümlü kullanmak, karmaşık tasarımlarda kavrayışı artırır
- Tek bir model seçilecekse Gemini 2.5 PRO önerilir
- LLM kullanırken uyulması gereken koşullar
- Kod ajanları veya IDE içine entegre ajanların kullanımından kaçınılmalıdır
- LLM'in tüm bağlamı (kod, belgeler vb.) doğrudan görebilmesi, en iyi yanıtları teşvik eder
- RAG (bilgi çıkarım tabanlı) gibi yalnızca bağlamın bir kısmını gösteren işlevler kullanıldığında performans düşebilir
- Her aşamada insanın kodu elle kopyalayıp yapıştırarak akışı doğrudan takip etmesi gerekir
Sonuç – kontrolü elde tutmak kritik
Kodu tek başına yazan agent'ların ortaya çıkması uzak değil; ancak şu anda en keskin kodu üreten yaklaşım, insanın LLM ile aktif biçimde işbirliği yapmasıdır.
- Ne yapılacağına ve bunun nasıl yapılacağına karar veren taraf olarak insanın rolü hâlâ temel önemdedir
- LLM kullanımı, mevcut bilgi sınırlarını aşarak yeni teknolojiler ve kavramlar öğrenip gelişmeyi mümkün kılar
- Kodu doğrudan kontrol etmek, tasarım ve uygulamada tutarlılığı korur; ayrıca LLM hatalarının yarattığı belirsizliği de en aza indirir
- Agent performansındaki gelişmeleri düzenli olarak gözden geçirmek de akıllıca bir stratejidir
- Bu aşamada LLM kullanımından kaçınmak değişimin gerisinde kalmaya yol açabilir; bu nedenle dengeli bir kullanım yaklaşımı önemlidir
1 yorum
Hacker News görüşü
Gemini 2.5 PRO ya da Claude Opus 4 gibi kapalı LLM modellerinin standart hâline gelmesinden dolayı hayal kırıklığı yaşıyorum; LLM’lerin gelişimini ve bir araç olarak gücünü çok olumlu bulsam da, geliştiricilerin neden programlama yapmak için üçüncü taraf ücretli hizmetlere bağımlı olmayı sorun etmediğini anlamakta zorlanıyorum; eskiden yalnızca açık kaynak ve ücretsiz araçlarla kod yazılabiliyordu; birkaç yıl sonra ücretli LLM’lere bağımlı olmanın, bugün IDE ya da vim olmadan kod yazmak kadar rahatsız edici hâle gelmesinden endişeliyim; aylık $200’ın o kadar da önemli olmadığını söylemek temel sorunu çözmüyor
Şu anda yerelde çalıştırılabilen açık modeller kalite açısından yetersiz, üstelik işletme maliyetleri çok daha yüksek; Claude 4 seviyesinde bir modeli kişisel bilgisayarda ekonomik biçimde çalıştırmak mümkün olduğunda pek çok kişi bunu deneyecektir; şu an için Kimi K2 gibi bir model iki adet 512GB Mac Studio’da çalışıyor ama sadece donanım maliyeti yaklaşık $20,000
Abonelik modeli, ilk başta sunduğu fiyat/performansla son derece değerliymiş gibi hissettiriyor; ama zamanla fiyatlar artıp kalite düştükçe sonunda hizmete kilitlenmiş oluyorsunuz; adeta Black Mirror’daki "Common People" bölümü gibi
Şahsen tüm geliştiricilerin ücretli LLM’lere tamamen bağımlı olduğu bir geleceğin gerçekleşmesinin zor olduğunu düşünüyorum; uzun vadede insanlar çok fazla kod üretmenin başlı başına bir sorun olduğunu fark edecek; kod borçtur ve kararsız ya da yavaş kod biriktikçe bu borç da büyür; yapay zeka ortadan kaybolmayacak ama biraz heyecan yatışınca nerede ve nasıl kullanılması gerektiğine dair anlayış artacaktır; ayrıca yatırım parası kuruduğunda ne olacağı da soru işareti; OpenAI ve Anthropic kârlı değil ve mevcut durumu sürdürebilmek için sürekli sermaye girişi gerekiyor; eğer LLM’lerin evrimi şu anki seviyede tıkanıp sınırına geldiyse yatırım da çekilecektir, o durumda kullanım maliyetleri artabilir ya da hizmet tamamen ortadan kalkabilir
Gerçekte bunun büyük bir sorun olduğunu düşünmüyorum; üretkenlik artışı için somut bir gerekçe yoksa pahalı ve kullanıcı dostu olmayan bir hizmete bağımlı kalmak için neden yok; açık modeller de sürekli gelişiyor, açık modellerle aradaki fark büyük değilse kullanmaya devam etmeye gerek kalmaz; eğer LLM gelişimi durmadan çok hızlı ilerlerse zaten mevcut yöntemlerle rekabetçi olamayız ve başka alanlara yönelmemiz gerekir; sonuç olarak çok büyük endişe duymaya gerek olmadığını düşünüyorum; ayrıca büyük model şirketlerinin değerlemelerinin gerçekte olduğundan çok daha şişirilmiş olduğunu hissediyorum
Kodlamanın açık kaynak ve ücretsiz araçlarla yapılabildiği sözüne şunu eklemek isterim: JetBrains çalışma arkadaşlarımdan daha eski bir şirket ve MS’in Visual Basic/C++/Studio ürünleri Windows geliştirmeyi kolaylaştırdı ama hepsi ücretliydi
"PhD-level knowledge" ifadesine katılmıyorum; doktora sürecinin amacı mevcut bilgiyi edinmek değil, araştırma yapmayı öğrenmektir; yapay zeka tartışmalarında sık görülen bir yanlış anlama bu ve doktora düzeyinde bilgi ifadesi bu yüzden muğlak kalıyor
Doktoranın araştırmayı öğrenme süreci olmasının yanı sıra, soru sorabilmek de işin özü; LLM’ler kendi başına soru sorup hipotez araştırmayan, "geniş bilgiye sahip tembel bir işçi"ye daha yakın; gerçek bir örnek vermek gerekirse, Claude Code(Max Pro)’dan test assertion sayılarını yorum satırına almasını istediğimde, ilk plandaki hatalı varsayıma dayanarak bir bug üretti; nedenini bulup düzeltmesi için planı yeniden yazmasını benim özellikle istemem gerekti; örneğin ORM nesnesinin
nulldeğer taşımasının sebebi commit sonrası refresh yapılmamasıydı ve başka bir DB session’ından yüklenen şey de oturum kapandıktan sonra olduğu gibi kaldığı için sorun çıkmıştıKatılıyorum; uzman seviyesinde bilgisi var ama insanların iyi yaptığı şeyi LLM’ler aynı ölçüde yapamıyor; örneğin LLM’ler baştan sona etkileyici bir programı tek seferde yazabiliyor ama onu yinelemeli biçimde iyileştirmekte zorlanıyor
Doktoranın bilgiden daha fazlası olduğunu kabul etsek bile, o bilgiye kolayca erişebilmenin kendisi çok büyük bir değer; önceki şirketimde sadece PhD seviyesindeki birinin yanıtlayabileceği zor sorulara LLM oldukça işe yarar cevaplar verebiliyordu; kabaca "iki malzemenin sınırına belirli yönde voltaj verirsek ne olur?" gibi sorular
PhD alınca dersin kendisine daha fazla önem verilmiyor; sonuçta önemli olan araştırma yapma yöntemini öğrenmiş olmak
LLM tabanlı kodlama tartışmalarında ele alınan alanın ve kullanılan programlama dilinin mutlaka belirtilmesi gerektiğini düşünüyorum; bu iki değişken, LLM kullanım biçiminden çok daha büyük etki yaratıyor; biri LLM ile kodlamayı seviyorsa ya da sevmiyorsa, önce hangi problem alanında çalıştığını sormak ve ardından o problemi yapay zekayla bizzat çözmeyi denemek gerekir; aksi takdirde hep "yanlış kullandığın için öyle", "ben denedim ama kötüydü" gibi kısır tartışmalar çıkıyor
Son aylarda agentic coding üzerine yoğun biçimde çalışmış biri olarak, gönderide söylenen her şeye katılıyorum; en yeni LLM’ler şu anda nispeten en kolay kullanılanlar ama açık modellerin de yakında yetişmesini bekliyorum; LLM’den yeni yöntemler önermesini ya da zaten bildiğiniz bir yaklaşımı sunmasını isteyebilirsiniz; bazen LLM gereksiz yere işleri karmaşıklaştırma eğiliminde oluyor, bunu erken fark edip ya da refactor istemek yeterli; yeni modeller çıktıkça tablo yine değişecek; her iş için mutlaka en gelişmiş modele ihtiyaç yok; basit özellikler ya da bug fix işleri için Copilot da gayet iyi bir başlangıç noktası; herkesin bu yeni değişim içinde farklı şeyler deneyip öğrenme sürecinden keyif almasını isterim
Claude’un GitHub action’ını yaklaşık 10~20 issue implementasyonu ve PR review için kullandım; tam anlamıyla hit or miss olduğu için, onu düşünmeden otomasyon yerine artırıcı bir araç olarak kullanmak gerektiğine katılıyorum; değişikliklerin küçük olduğu ve testlerin iyi kurulduğu küçük ölçekli özellikler/refactor işleri neredeyse otomatik olarak başarılı oluyor; action olarak çalıştırınca ben de başka işlerime bakabiliyorum, bu da avantaj sağlıyor (issue’yu da Claude yazarsa daha da rahat); ama orta ölçek ve üstünde kod çoğu zaman ikna edici görünüyor fakat gerçekte çalışmıyor; bunda test coverage eksikliğinin payı olabilir ve bu benim sorumluluğumdur ama bunun sık yaşandığı da kesin; issue’yu daha ayrıntılı yazmak ya da prompt’u çeşitlendirmek de sonucu pek iyileştirmiyor; büyük işlerse söylemeye bile gerek yok, çok zor; PR review özelliği küçük/orta işler için işe yarar ama gereksiz onaylar da çok oluyor; sonuç olarak LLM’lerin kendi başına kod yazması için hâlâ erken olduğunu düşünüyorum; küçük işlerde issue yazdırıp PR gelmesini beklemek en verimli yöntem gibi; çoğu işte (orta ölçekli olanlarda) ben daha çok Claude’a yön veriyorum, kodlamayı neredeyse yapmıyorum ve üretkenliğim kesin olarak artıyor; Gemini’yi de denedim ama kendi hâline bırakıldığında kodu öngörülemez biçimde savuruyor; şirket içinde Copilot ile PR review de yapıyoruz ama pek etkili değil; büyük kod tabanlarında Gemini daha faydalı olabilir diye düşünüyorum
OP’den farklı olarak, bu alana bir ay boyunca yoğun biçimde girdikten sonra şunu gördüm: Gemini 2.5 PRO ve Opus 4, mimari gibi soyut tartışmalarda daha iyi sonuç veriyor; tek tek kod implementasyonlarını ise Sonnet’e bırakmak daha verimliydi; 2.5 PRO ve Opus çoğu zaman doğru cevabın etrafında dolaşıp kendi kendini düzeltmeye çalışırken, Sonnet daha doğrudan çözüme gidiyor ama bunun için yeterince ayrıntılı talimat vermek gerekiyor
Bu gayet mümkün; gerçekten de Sonnet/Opus 4 en iyi sonuçlarda daha güçlü olabilir ama bazı açılardan Sonnet 3.5v2’nin (bazıları 3.6 da diyor) hatta 3.7’nin bile tutarlılık ya da hizalanma bakımından daha iyi olduğu durumlar var; ayrıca modeller karmaşık nesneler olduğu için, alana göre "daha zayıf görünen" model daha iyi iş çıkarabiliyor; bir de etkileşimli ortamla ajan odaklı ortamda kullanılan pekiştirmeli öğrenme teknikleri farklı olduğu için modeli nasıl kullandığınız performansı etkiliyor
Gerçek iç istatistik verilerinde de Opus ile Gemini 2.5 pro’nun gerçekçi ortamlarda Sonnet 4’ten daha düşük performans gösterdiği sonucu doğrulandı ilgili istatistik bağlantısı
Benim de benzer bir deneyimim oldu; Gemini 2.5 Pro’yu AI Studio’da büyük tasarım fikirlerini doğrulamak ve rafine etmek için kullanıyorum, ardından gereksinimleri Claude Code’a verdiğimde genelde temiz biçimde kodluyor; yakın zamanda Gemini CLI’ı da denedim ama Claude Code’a kıyasla kodlama becerisi çok geride; syntax hatası çok yapıyor ve döngüden çıkamadığı için çıktısı gereksiz uzuyor, ayrıca o kadar hızlı akıyor ki takip etmek zorlaşıyor; buna karşılık Claude Code’un debug becerisi gerçekten çok güçlü; "büyük resim" tipi problem çözümünde DeepSeek R1 de denenebilir, çok yavaş ama doğruluk oranı yüksek
AI/LLM’lerin bazen aşırı verimsiz kod yazdığına dair gerçek bir örnek paylaşılıyor ilgili blog bağlantısı
LLM’den önce sadece yapmak istediğim işi açıklamasını istiyorum; ben arada geri bildirim verip birkaç tur yineleme yaptıktan sonra ortaya çıkan kodun kalitesinin çok daha iyi olduğunu gördüm; önce ayrıntılı planı onaylatmak etkili oluyor
Benim deneyimime göre, frontend tarafında doğrulaması kolay, tekrarlı ve basit işleri vibe coding’e bırakabilirsiniz; ama normalde LLM’i kendi kodumu gözden geçiren ve çeşitli alternatifleri değerlendiren bir sparring partner gibi kullanıyorum; önerileri bazen saçma ya da mantıksal kusurlu olsa bile, benim çok bariz şeyleri kaçırmamamı sağladığı için memnunum; karmaşık düğümlenmiş sorunlarda gereğinden fazla karmaşık çözümlere yönelme alışkanlığımı da törpülüyor
OP’nin tam olarak ne tür bir kullanım biçiminden söz ettiğini anlamadım; gerçekten redis C dosyasını elle Gemini Pro’nun web sohbet penceresine yapıştırmaktan mı bahsediyor?