LLM’leri Büyük Ölçekli Kod Tabanlarına Ölçeklendirmek

 (blog.kierangill.xyz)
9 puan yazan GN⁺ 2025-12-24 | 1 yorum | WhatsApp'ta paylaş
  • LLM’leri büyük ölçekli kod tabanlarında etkili şekilde kullanmak için ‘rehberlik (guidance)’ ve ‘gözetim (oversight)’ yatırımı kilit önem taşıyor
  • Rehberlik, bağlam ve ortam sağlayarak LLM’in daha iyi seçimler yapmasına yardımcı olurken, gözetim ise sonuçları doğrulayıp yön veren rolü üstlenir
  • Prompt kütüphanesi oluşturarak kod tabanının kurallarını, dokümantasyonunu ve en iyi uygulamalarını LLM’in anlayabilmesini sağlamak önemlidir
  • Teknik borç yönetimi ile kod yapısının sadeliği, modülerliği ve tutarlılığı, LLM’in kod anlama becerisi ve üretkenliğindeki artışla doğrudan bağlantılıdır
  • Otomatik gözetim ve doğrulama sistemleri aracılığıyla LLM’in güvenli ve tutarlı kod üretmesine yardımcı olmak, uzun vadeli ölçeklenebilirliğin anahtarıdır

LLM ölçeklendirme için temel kavramlar

  • LLM’lerin büyük ölçekli kod tabanlarına nasıl uygulanacağı henüz tam olarak yerleşmiş değil, ancak rehberlik ve gözetim yatırımı en etkili yaklaşım olarak sunuluyor
  • Rehberlik (Guidance), LLM’in doğru seçimler yapmasına yardımcı olan bağlam ve ortamı ifade ederken, gözetim (Oversight) üretilen çıktıları doğrulama ve yönü ayarlama görevini üstlenir

Rehberliğe yatırım

  • LLM’in tek denemede yüksek kaliteli kod üretmesi anlamına gelen ‘one-shotting’ hedefine ulaşmak için net rehberlik gerekir
    • Buna karşılık, sonuç uygun olmayıp manuel düzeltme gerektirdiğinde ortaya çıkan durum rework olup verimsizdir
  • LLM, kod içindeki tüm seçimleri (değişken adı, fonksiyon yapısı, teknoloji yığını vb.) ürettiği için, prompt’un yalnızca iş gereksinimlerini içermesi; geri kalanının ise çıkarılabilir ya da önceden kodlanmış olması idealdir

Prompt kütüphanesi oluşturma

  • Prompt kütüphanesi, kod tabanının dokümantasyonu, en iyi uygulamaları ve yapısal haritaları gibi unsurları içeren, LLM’e yönelik bir bağlam kümesidir
    • LLM’in çıktısı her saptığında, “neyin daha net ifade edilmesi gerekiyordu?” sorusu gözden geçirilip bu içerik kütüphaneye eklenir
    • Kapsamlılık ile kısalık arasındaki denge önemlidir
  • Örnekte, @prompts/How_To_Write_Views.md, @prompts/The_API_File.md gibi belgeler LLM’e verilerek özellik geliştirme yönlendiriliyor
  • Prompt yeterince spesifik olmalı, ancak üretilen kodun her satırı yine de gözden geçirilmelidir

Ortam ve kod kalitesi

  • Teknik borcu yüksek bir kod tabanı, LLM kullanım verimliliğini düşürür
    • Meta örneğinde, teknik borcun otomasyon hedeflerine ulaşmayı zorlaştırdığı belirtiliyor
  • Temiz kod, modülerlik, açık adlandırma ve sade yapı, LLM’in anlama düzeyini ve doğruluğunu artırır
  • Django örneğinde, her uygulamanın giriş noktası _api.py dosyası olarak belirlenerek LLM’in gerekli işlevleri hızlıca bulabilmesi için yapılandırma yapılıyor
    • Örnek: visit_api.handoff_to_doctor(user) biçiminde dış erişimi tek noktada toplamak
    • _api deseni prompt kütüphanesinde açıkça belirtilerek LLM’in doğru konuma başvurması teşvik ediliyor

Gözetime yatırım

  • LLM otomasyonuna, mühendislerin yerini almaktan çok ekibi güçlendiren bir yaklaşım olarak bakılmalı
  • Gözetim; ekip, alignment ve workflow yatırımlarına da uzanır
    • Ekip düzeyinde, tasarım yetkinliğini artırmak önemlidir ve bu doğrudan mimari kaliteye yansır
  • Tasarım yetkinliğini geliştirme yolları olarak kitap, blog ve kod okumak; ustalık işi örnekleri kopyalamak; doğrudan uygulama pratiği yapmak öneriliyor
    • Örnek olarak, TLDraw ve SerenityOS Jakt kodlarını analiz ederek tasarım sezgisini geliştirmek gösteriliyor

Otomatik gözetim

  • Tasarım doğrulamasının bir kısmı programatik olarak otomatikleştirilebilir
    • Örneğin, tip hataları veya kural ihlalleri için ortamın anında geri bildirim vermesi
  • ‘Güvenlik (safety)’, soyutlamaları korumak anlamına gelir
    • Pierce’ın tanımına göre güvenli bir dil, programcının istemeden soyutlamaları bozmasını engeller
  • Örnek: Django uygulamaları arasında iç dosyalara doğrudan erişimi yasaklayan kuralın AST tabanlı denetim betiği ile otomatikleştirilmesi
    • from visit import logic.internal_file biçimindeki yasa dışı erişimi tespit etmek

Doğrulama (Verification)

  • Tasarım ve uygulamanın yanı sıra doğrulama aşaması (kod incelemesi, QA) da kalite güvencesi için kritik önemdedir
  • İş yükü arttıkça inceleme hızı darboğaz hâline geldiğinden, şu iyileştirmeler öneriliyor
    • Geliştirme ortamı olmadan da QA yapılabilmesi için giriş engelini azaltmak
    • Test verisi üretimi gibi konularda test yazmayı kolaylaştıran bir ortam kurmak
    • Tekrarlayan PR geri bildirimlerini dokümante ederek LLM’in bazı incelemeleri otomatik yapmasını desteklemek
    • Güvenlik kurallarını framework varsayılanlarına gömmek

Sonuç ve ek gözlemler

  • LLM’ler özellikle yeni (greenfield) projelerde iyi çalışır
    • Çünkü mevcut bağlam yoktur ve tutarlılık gereksinimi daha düşüktür
  • Proje büyüdükçe tutarlılık ve modülerlik üretkenliği belirler
    • Doğrulanmış bileşenleri yeniden kullanan modüler yapı, verimli geliştirmenin temelidir

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-24
Hacker News görüşleri

  • Modeller giderek geliştikçe karmaşık kod tabanlarını ve uzun dosyaları da işleyebilir hale geldi
    Bu yüzden ben, tekrar tekrar kullandığım basit bir framework döngüsü oluşturdum

    1. Research: Mevcut işlevi açıklamasını isteyip ilgili dosyaları bağlama yüklüyorum
    2. Plan: Yeni özellik geliştirme ya da refactoring için en iyi pratikler üzerine beyin fırtınası yaptırıyorum. Sonucu bir md dosyası olarak yazdırıyorum
    3. Clear: Bağlamı tamamen sıfırlıyorum. Basit sıkıştırmadan daha iyi sonuç veriyor
    4. Execute plan: Yalnızca planı yeniden yükleyip uygulatıyorum. Gerekirse soruları yineletiyorum
    5. Review & test: Bağlamı tekrar sıfırlayıp planın düzgün yansıtılıp yansıtılmadığını gözden geçirtiyorum. Bu aşamada test kodu, lint, type-check gibi şeyleri ekliyorum
      Bu döngüyü 20-30 dakika çalıştırınca oldukça kullanılabilir sonuçlar çıkıyor. Sonuçta işin özü, bağlam yönetimi ve test geri bildirim döngüsü kurmak
    • Aralık 2025 itibarıyla Sonnet/Opus, GPTCodex gibi modellerde zaten yerleşik subagent keşif özelliği bulunuyor
      Keşfi explore anahtar sözcüğüyle başlatırsanız ayrı bir plan yazmadan ya da bağlamı sıfırlamadan da Research yapılabiliyor
      Ancak kod dilini C ya da Python varsayma eğilimindeler; bu yüzden durumu nesne olarak kapsüllemek yerine beş fonksiyona bölen türde yapısız kod üretebiliyorlar
      Ayrıca claude bazen CLAUDE.md dosyasını görmezden geliyor; bu yüzden önce o dosyayı okutıp ardından explore yaptırmak daha stabil
      En yeni modeller gereksiz bağlamı iyi ayıklıyor ama eski modellerde plan belgesi tabanlı yaklaşım hâlâ daha iyi olabiliyor
    • Model temel akıl yürütme yeteneğinde başarısız oluyorsa hiçbir workflow işe yaramıyor
      Planları ve yönergeleri tam tersine uyguladığı, hatta aynı cümleyi tekrar okuyup zıt sonuca vardığı durumlar çok oldu
      Bir süre LLM merkezli bir süreç kurulabileceğine inanıyordum ama artık bundan daha az eminim
      Model “iyi durumda” olduğunda fena değil ama o duruma getirmek hâlâ büyük ölçüde şansa bağlı
    • Ben de benzer bir yaklaşım kullanıyorum. HumanLayer'ın Advanced Context Engineering yönergelerinden ilham aldım
      Claude Code'a /research_codebase, /create_plan, /implement_plan gibi özel komutlar ekledim
      Dikkatli inceleyip düzeltince çok iyi çalışıyor ama tüm ekibe yaygınlaştıramadım
    • Ben bu tür prosedürleri neredeyse hiç kullanmıyorum. GitHub Copilot ve Claude Sonnet 4.5 ile yalnızca net talimatlar vermek bile yeterince iyi sonuç veriyor
      Bağlamı yalnızca tamamen yeni bir özellik yaparken sıfırlıyorum. Codespaces'te fena değil ama Tasks özelliği neredeyse hiç işe yaramıyor
      Büyük işleri verirseniz alakasız bir yöne sapabiliyor; bu yüzden sürekli izlemek gerekiyor
    • Ben de neredeyse aynı workflow'u kullanıyorum. Plan md dosyasını depoda bırakıp yeni özellik eklerken başvurmasını sağlıyorum
      Bağlamı yeniden çerçeveleme için de faydalı, bu yüzden sık kullanıyorum

  • Bir prompt kütüphanesini gerçekten faydalı hale getirmek için yinelemeli iyileştirme gerekiyor
    LLM biraz saptığında her seferinde kendime “Neyi daha açık belirtmeliydim?” diye sorup cevabı prompt'a ekliyorum
    Sadece Enter'a basmak ya da otomatik onay vermek token israfı. Bunun yerine LLM'nin nerede takıldığını gözlemleyip CLAUDE.md'ye kısa not düşüyorum
    Bağlam dosyası büyürse iş türlerine göre ayırıyorum
    Benim başlıca kullanım durumlarım kod tabanını keşfetmek, yürütme yolunu izlemek ve gerekli dosyaların özetini sunmak. Soru türüne göre çıktının nasıl iletileceğini belirtmek verimi çok artırıyor

    • “Neyi daha açık belirtmeliydim?” sorusundan daha iyi yöntem, bunu LLM'nin kendisine sordurmak
      Ben buna “Student Pattern (Fresh Eyes)” diyorum. Alt ajan, belgeyi ya da kodu yeni başlayan birinin gözünden okuyup kafa karıştıran noktaları, çelişkileri ve eksik bilgileri buluyor
      Geliştiricinin gözden kaçırdığı örtük bilgiyi yakalamada çok başarılı. Yeni belge incelemesi ya da prompt değerlendirmesi öncesinde çok faydalı bir adım
    • Ben de bunu yapıyorum ama Claude Code bazen prompt'ları veya belgeleri görmezden gelme konusunda çok kötü
      CLAUDE.md'yi okumasını defalarca söylesem de çoğu zaman yok sayıyor, hatta oturum başlar başlamaz rastgele atladığı da oluyor
      Belgeleri ve komutları tamamen hazırlasanız bile hâlâ “unuttuğu” çok oluyor

  • Büyük kod tabanlarını ajana dost yapıda yapılandırma üzerine deneyler yapıyorum
    Projeyi nix flakes tabanlı bir yönlü graf olarak parçalara ayırıp her düğüme bağımsız bir geliştirme ortamı veriyorum
    Claude Code'u ilgili flake devshell içinde çalıştırınca yalnızca o kapsamı görüyor ve bağlam aşırı yükünü önleyebiliyor
    Flakeler arası giriş/çıkışlar üzerinden işbirliği yapmalarını, birbirlerine özellik isteği ve test iletmelerini sağlıyorum
    Bence bu tür bağlam bölme, token patlaması sorununu azaltmanın anahtarı

    • Bu yaklaşım ilginç. Ben de yazılım yapısı ile nitelikler arasındaki korelasyonu düşünüyorum
      Mevcut workflow'ları iyileştirmek yerine, LLM'nin kolay ölçeklenebileceği yapıları baştan tasarlamak gerekiyor
      “Test edilebilirlik, ölçeklenebilirlik, güvenlik” gibi niteliklerle kod yapısı arasındaki ilişkiyi araştırıyorum
    • Yalnızca bağlam bölme açısından değil, yeniden üretilebilirlik ve bağımlılıkların sabitlenmesi açısından da ilginç
      Ben de Docker tabanlı projelerde benzer deneyler yaptım; bunu otomatikleştiren bir araç olsa iyi olurdu

  • LLM, çok iyi bilmediğim konuları harika açıklıyor ama uzmanlık alanımda kendinden emin biçimde yanlış yapıyor

    • Bu, Gell-Mann Amnesia etkisi gibi
    • Konuya göre büyük fark var. Web tarafında doğruydu ama Hare gibi nadir dillerde berbattı
    • Sanırım bilmediğimiz alanlarda basit sorular, bildiğimiz alanlarda ise çok daha zor sorular soruyoruz; o yüzden böyle hissediliyor
    • Aslında bilmediğimiz alanlarda saçmalığı ayırt edemiyor olmamız da mümkün

  • Ben farklı düşünüyorum. LLM performansını artırmanın en iyi yolu, anlamı doğrudan kod tabanına gömmek
    Yani DDD (Domain-Driven Design) gibi yapılandırılmış kodlar, LLM için de daha anlaşılır
    Karmaşık kodu araçlarla zorla yönetmeye çalışmak para israfı
    Sonuçta LLM'lerin kanıtladığı şey, “dil ve anlam” vurgusu yapan DDD felsefesinin doğru olduğudur
    İlgili yazı: DDD & the Simplicity Gospel

    • Ben de iki büyük kod tabanı yönetiyorum; yapılandırılmış olanı LLM çok daha iyi anlıyor

  • “LLM neden greenfield projelerde iyi çalışıyor?” sorusuna benim deneyimim ters yönde
    Kod tabanında bir desen 2-3 kez tekrarlandığında LLM bunu öğrenip tutarlı biçimde kopyalıyor
    Ama “tutarlılık” ile “kalite” aynı şey değil. Ölçüt olmadan sadece tutarlılık peşinde koşarsanız bakımı imkânsız kod ortaya çıkar

  • “Mühendisin anlayamadığı kodu LLM de anlayamaz” sözü doğru ama tersi geçerli değil
    İnsanların anladığı ama ajanların anlayamadığı çok durum var
    Bir kod tabanını insanlar için değil de ajanlar için daha anlaşılır hale getirmek daha zor
    “Geri bildirimi bilgisayara taşırsanız tek seferde başarı oranı artar” deniyor ama bu, P=NP demeye benziyor
    Doğrulaması kolay olan bir şeyin çözümünü bulmak da kolay olmak zorunda değil
    ATS veya Idris gibi dillerde doğruluk ispatı kodla birlikte yazılabiliyor
    Eğer bu iddia doğru olsaydı, LLM'lerin en iyi performansı bu dillerde göstermesi gerekirdi
    Ama pratikte durum böyle değil. Sonuçta şimdilik model iyileşmesini beklemek daha mantıklı diye düşünüyorum

  • Bu sorunlar yüzünden ben, görüşü güçlü framework'lerin AI kodlama verimliliğini artıracağını düşünüyorum
    Framework kurallarını LLM zaten bildiği için ayrı yönergelere ihtiyaç kalmıyor

    • 1,6 milyon satırlık bir kod tabanında çalışıyorum; desen tutarsızlığının yüksek olduğu yerlerde LLM neredeyse hiç işe yaramadı
    • Aynı uygulamayı birden çok dilde yaptım; Rails neredeyse anında tamamlandı, Bun da iyiydi
      Buna karşılık Go, Rust, Elixir ve C# çok daha fazla bağımlılık ve yönlendirme gerektirdi
      Rust'ın sonucu iyiydi ama 200'den fazla paket çektiği için yükü fazlaydı

  • “Garbage in, garbage out” ilkesi doğru ama LLM'lere tam olarak uygulanmıyor
    İnternetin tamamındaki gürültülü verilerle eğitilmelerine rağmen oldukça iyi çalışıyorlar
    Hallucination basit gürültüden çok, yanlış bağlam verildiğinde daha sık ortaya çıkıyor
    Yapısı dağınık bir kod tabanı bile yeterince bilgi içeriyorsa hâlâ faydalı bağlam sağlayabiliyor

  • Sonuçta insanlar temel ilkeleri yeniden öğreniyor
    Dokümantasyonun (=prompt kütüphanesi) ve düzenli kod yapısının geliştirme hızını artırdığını yeniden fark ediyoruz

    • Yine de bunun sonucunda daha fazla insan test yazmaya başlarsa, bence bu kötü bir şey değil