LLM ile kod üretimi iş akışım

• tldr: Önce spesifikasyonu beyin fırtınasıyla çıkar, sonra plan yap, ardından LLM codegen ile uygula. Tek tek yinelemeli döngüler. Sonra sihir gerçekleşiyor
• LLM kullanarak çeşitli küçük ürünleri hızlıca geliştiriyorum. Eğlenceli ve faydalı
• Ancak yanlış bir yaklaşıma saparsanız çok fazla zaman kaybedebilirsiniz
• Birçok geliştiricinin birbirine benzer yaklaşımları var; aşağıdaki de benim iş akışım

  "Şu anda iyi çalışıyor ama 2 hafta sonra çalışmayabilir ya da iki kat daha iyi çalışabilir"

• Geliştirmenin 2 yolu var
  • Greenfield kod: yeni bir projeye başlamak
  • Legacy modern kod: mevcut bir kod tabanını iyileştirmek veya genişletmek

Greenfield: sıfırdan başlamak

• Bu süreç, “sıfırdan başlama” durumuna çok uygun
• Akış; fikri beyin fırtınasıyla netleştirmek, dokümante etmek, küçük adımlı bir plan çıkarmak ve ardından kod üretim araçlarıyla uygulamak şeklinde
• Adım 1: Fikri somutlaştırma
  • ChatGPT gibi bir LLM'e fikri anlatırken, tek tek sorular sormasını sağlayıp bunu daha somut bir spesifikasyona dönüştürüyorum
  • Sonunda geliştiriciye verilebilecek belge biçiminde ayrıntılı bir spesifikasyon olan spec.md hazırlanıyor
  • Gerekirse Deep Research gibi araçlarla fikir için dayanak materyali de toplanabilir
• Adım 2: Planlama
  • Spesifikasyona dayanarak, daha güçlü bir “anlama/çıkarım” modelinden ayrıntılı, adım adım bir plan üretmesini istiyorum
  • TDD kullanılsın ya da kullanılmasın, her adımı küçük iş birimlerine bölüp sıraya koyuyorum
  • Bu süreçte prompt_plan.md ve todo.md üretiliyor
    • prompt_plan.md kod üretimi için gerekli prompt tasarımını, todo.md ise kontrol listesini içeriyor
  • Bu planlama genelde 15 dakika kadar sürüyor ve sonradan başvurması da kolay oluyor
• Adım 3: Uygulama
  • Aider, Cursor, Claude gibi çeşitli kod üretim ve yardımcı araçlarla gerçek kodu yazıyorum
  • Temsili örnek olarak Claude ve Aider verilebilir
  • Claude yöntemi
    • Önce proje yapısını (boilerplate vb.) kurup ardından adım adım prompt'ları Claude'a veriyorum
    • Çıkan kodu IDE'ye kopyalayıp yapıştırıyor ve testleri çalıştırıyorum
    • Sorun çıkarsa repomix gibi araçlarla mevcut kod tabanını Claude'a verip debug ediyorum
    • İş akışı
      • Repo kurulumu (boilerplate, uv init, cargo init, vb.)
      • Prompt'u Claude'a yapıştır
      • claude.ai'den IDE'ye copy & paste
      • Kodu çalıştır, testleri çalıştır vb.
      • …
      • Çalışıyorsa bir sonraki prompt'a geç
      • Çalışmıyorsa, Repomix ile kod tabanını Claude'a gönderip debug et
      • Bunu tekrar tekrar yap
  • Aider yöntemi
    • Aider'da da prompt_plan.md dosyasını sırayla vererek ilerliyorum
    • Testleri otomatik çalıştırma ya da hataları bulup düzeltme sürecini destekliyor
    • Gerekirse etkileşimli debug ile sorunları çözüyorum
      • Repo kurulumu (boilerplate, uv init, cargo init, vb.)
      • Aider'ı çalıştır
      • Prompt'u Aider'a yapıştır
      • Aider'ın dans edişini izle ♪┏(・o･)┛♪
      • Aider testleri çalıştırabilir veya uygulamayı açıp doğrulayabilir
      • Çalışıyorsa bir sonraki prompt'a geç
      • Çalışmıyorsa, Aider ile soru-cevap yaparak düzelt
      • Bunu tekrar tekrar yap
• Sonuç
  • Bu yöntemle script'ler, Expo uygulamaları, Rust CLI'lar gibi çeşitli projeleri kısa sürede hayata geçirmek mümkün
  • Ertelediğiniz büyük ya da küçük projeler varsa bir denemenizi öneririm
  • Yeni bir dili ya da teknolojiyi öğrenirken hızlı denemeler yapabilme avantajı da sağlıyor

Non-greenfield: mevcut kod üzerinde kademeli/tekrarlı çalışma

• Bu yöntem, zaten var olan bir kod tabanına küçük işleri tekrar tekrar uygularken kullanılıyor
• Büyük bir genel plandan çok, iş birimi bazında somut istekler ve sonuçlar üzerinden ilerleyen bir akış
• Bağlamı toplama
  • repomix gibi araçlarla kod tabanını özetleyip LLM'e verebilirsiniz
  • mise vb. ile tekrar eden yapılandırmaları yönetip özet sonucu output.txt dosyasına kaydediyorum
  • Kod tabanı çok büyükse yalnızca gerekli bölümlerin özetlenmesini sağlayabilirsiniz
• Örnek iş akışı
  • mise run LLM:generate_missing_tests gibi bir komutla, testlerin eksik olduğu bölümleri LLM'e tespit ettiriyorum
  • Claude veya Aider ile ilgili önerileri (issue'ları) uygulayıp sonucu tekrar test ediyorum
  • Böylece mevcut kod tabanını kademeli olarak iyileştiriyorum

Önemli prompt örnekleri

• Code review
  “Kıdemli bir geliştirici olarak bu kodu çok dikkatli incele. Satır numaralarını ve bağlam bilgisini ekle. Yüzeysel bir inceleme yapma; derinlemesine bak”
  “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• GitHub Issue generation
  “Kıdemli bir geliştirici olarak kodu incele ve gördüğün başlıca sorunları GitHub issue formatında yaz”
  “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Missing tests
  “Kıdemli bir geliştirici olarak kodu incele ve eksik testleri ya da gerekli test senaryolarını somut şekilde belirt“
  “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

Kayak ᨒ↟ 𖠰ᨒ↟ 𖠰

• LLM ile yüksek hızda kod yazarken bir noktada karmaşıklık ve bağlam birbirine girip kafa karıştırıcı hale geliyor
• Planlama aşamasındaki belgeleri (ör. Greenfield süreci) yeniden gözden geçirmek ya da testleri sistemli biçimde yazmak yardımcı oluyor
• Hızlı ilerlerken kısa bir mola vermek ya da düşünceleri toparlamak için zaman ayırmak da önemli

Çok yalnızım (｡•́︿•̀｡)

• LLM tabanlı iş akışlarının çoğu şu anda ‘tek kişilik mod’ için optimize edilmiş durumda
• Ekip olarak birlikte kod yazmaya çalışınca çakışmalar veya merge sorunları gibi konular karmaşıklaşıyor
• Birden çok kişinin aynı anda LLM kullandığı ‘multiplayer’ tarzı işbirliği ortamlarının gelişmesini umuyorum

Zaman

• LLM sayesinde kod yazma verimliliğim çok arttı ama token işleme bekleme sürelerinden doğan bir ‘downtime’ de var
• Bu zamanı başka proje fikirleri düşünmek, müzik dinlemek ya da sohbet etmek için kullanıyorum
• Kişisel üretkenliğimin eskisine kıyasla ciddi biçimde arttığını hissediyorum

Haterade ╭∩╮( •̀_•́ )╭∩╮

• Birçok arkadaşım “lanet olası LLM, bu tamamen işe yaramaz” gibi bir tavır takınıyor; ben ise bu bakış açısını çok da umursamıyorum
• Elbette ben de bu görüşü paylaşmıyorum ama şüpheci yaklaşımın gerekli olduğu da doğru
• Yapay zekadan nefret etmek için sayısız neden var; benim en çok kaygı duyduğum konu enerji tüketimi ve çevresel etkisi
• Yine de… "kod akmalı" işte… eh
• Daha fazlasını öğrenmek istiyor ama ille de sibernetik bir programcı olmak istemiyorsanız, tavsiyem “fikrinizi değiştirmeye çalışmayın; Ethan Mollick'in Co-Intelligence: Living and Working with AI kitabını okuyun” olur
  • Kitap, teknolojik anarşist kapitalizm tarzı abartılara kaçmadan LLM'lerin sunduğu faydayı iyi anlatıyor
  • Bana kişisel olarak çok yardımcı oldu; kitabı okuyan arkadaşlarımla da çok daha derin sohbetler edebildim
  • Kesinlikle tavsiye ederim

[devs5]

Ethan Mollick’in ‘Co-Intelligence: Living and Working with AI’ kitabı
görünüşe göre mart ayında 'Çift Beyin' başlığıyla yayımlanacak

[kipsong133]

Demek Repomix diye bir şey varmış. Ben de her seferinde kopyala-yapıştır yapıyordum.. hıçkırık

[chugue85]

Teşekkür ederim!

[ahwjdekf]

Başka geliştiricilerin ettiği küfürleri de llm benim yerime göğüsleyecek mi?

[aer0700]

LLM’yi ben hâlâ gelişmiş bir Google, nazik bir Stack Overflow gibi kullanıyorum; daha iyi değerlendirmenin yolları olup olmadığını biraz düşünmem gerekecek gibi.
Benim için nasıl yapıldığı elbette önemli, ama neden çalıştığını yapay zekayla birlikte düşünmek de önemli görünüyor. Eski teknik belgeleri ya da standartları ararken LLM faydalı oluyor.

[GN⁺]

Hacker News görüşü

• LLM'ler, yeni projelerin prototiplerini hızlıca oluşturabilen araçlardır. Ancak mevcut koda ya da olgun projelere değişiklik yaparken bağlam eksikliği nedeniyle karmaşıklığı artırma veya gereksiz framework'ler ekleme eğilimindedirler. LLM'ler, kodu anlamanın yerine geçmez.

• LLM'lerle iş birliğinde, sorular üzerinden bağlam inşa etmek önemlidir. Bu, bağlamı doğrudan oluşturmaya çalışmaktan daha etkilidir.

• Son zamanlarda LLM'lerle birlikte mob programming deniyorum. Bir LLM implementasyonu üstlenirken, başka bir LLM eleştiri yapıp iyileştirme öneriyor.

• Projeye güçlü şekilde dayatmacı framework'ler eklememek tercih edilir. Çünkü bu, modelin kavraması gereken bağlamın boyutunu artırır. Örneğin Plasmo yerine, tarayıcı eklentisi kurulumunu LLM'ye yaptırıyorum.

• Cursor chat ile başlayıp daha iyi bir iş akışına evrilen kişilerin deneyimlerini duymak istiyorum. Planlamaya harcanan zamanın faydalı olup olmadığını, halüsinasyonların azalıp azalmadığını ve genel olarak zaman kazandırıp kazandırmadığını merak ediyorum.

• Bu yazı, LLM'leri doğru kullanma yöntemini açıklıyor. Birçok insanın dil modelleriyle etkili iletişim kurma konusunda yeterli pratiği yok. Yazar, LLM'lerle iletişim kurmayı ustalıkla öğrenmiş ve bu iş akışı verimliliği en üst düzeye çıkarıyor.

• LLM kullanılan iş akışlarında verimliliği en üst düzeye çıkarmak için hızlı yazma becerisi, doğru muhakeme ve her modelin güçlü ve zayıf yönlerine aşinalık gerekir.

• LLM tabanlı kodlama araçları eğlenceli, ancak gerçekten faydalı olup olmadıklarını görmek için somut hedefler ve teslim tarihleri belirlemek gerekir. LLM'lerin bu koşullarda başarısız olma olasılığı yüksektir.

• Birçok yeni programcı, programlamanın spesifikasyon ve uygulama planı kısmını unutuyor. LLM'leri başarılı şekilde kullanmak için onlara spesifikasyon ve uygulama planı oluşturtmak gerekir.

• Claude hakkındaki beklentileri anlamıyorum. Apache Spark ile ilgili sorularda çok fazla halüsinasyon yaşanıyor. Claude'un neden diğer modellerden daha iyi görüldüğünü anlamak istiyorum.

• Bireysel geliştiriciler için kabul edilebilir olabilir, ancak bir ekibin aynı kod tabanını analiz eden birden fazla LLM örneği kullanması ekonomik değil ve riskli olabilir. Ekipler için merkezi bağlam sağlayan bir ürün olup olmadığını merak ediyorum.