7 puan yazan GN⁺ 2026-01-09 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka kodlama asistanlarının temel yapısı, karmaşık bir sihir değil; yaklaşık 200 satırlık basit Python kodundan oluşuyor
  • Sistem, LLM ile bir diyalog döngüsü üzerine kurulu; LLM araç çağrısı istediğinde yerel kod bunu çalıştırıyor ve sonucu tekrar iletiyor
  • Gerekli temel araçlar dosya okuma (read), dosya listeleme (list) ve dosya düzenleme (edit) olmak üzere üç tane; bunlarla proje gezintisi ve kod değişikliği yapılabiliyor
  • LLM, araçların imzası ve açıklamasına (docstring) bakarak hangi aracı ne zaman çağıracağına kendisi karar veriyor
  • Bu yapı, Claude Code gibi ticari ürünlerin çekirdeğiyle aynı ve basit bir yapıyla da güçlü bir kodlama ajanı uygulanabileceğini gösteriyor

Kodlama ajanının temel kavramı

  • Kodlama ajanı, LLM ile diyalog tabanlı bir sistemdir; kullanıcının komutunu alır ve araç çağrıları üzerinden gerçek dosya işlemlerini yürütür
    • Kullanıcı, “hello world fonksiyonu içeren yeni bir dosya oluştur” gibi bir istek girer
    • LLM, gerekli araç çağrısını JSON biçiminde yanıtlar
    • Program ilgili aracı çalıştırır ve sonucu yeniden LLM'e iletir
  • LLM dosya sistemine doğrudan erişmez; yalnızca istekte bulunur, gerçek işlem yerel kod tarafından yapılır

Gerekli üç araç

  • read_file: Belirtilen dosyanın tüm içeriğini okuyup döndürür
  • list_files: Bir dizindeki dosya ve klasör listesini döndürür
  • edit_file: Var olan bir metni yeni bir metinle değiştirir ya da old_str boşsa yeni dosya oluşturur
    • Değiştirilecek metin yoksa “old_str not found” döndürür
  • Yalnızca bu üç araçla bile dosya oluşturma, düzenleme ve gezinme mümkündür

Araç kaydı ve LLM entegrasyonu

  • Tüm araçlar, LLM'in çağırabilmesi için ad ve fonksiyon olarak TOOL_REGISTRY içine kaydedilir
  • Her aracın docstring'i ve imzası çıkarılıp LLM'e iletilir
  • Sistem prompt'u, LLM'e “kullanılabilir araçlar listesi”ni ve “çağrı biçimi”ni açıkça bildirir
    • Araç çağrıları 'tool: TOOL_NAME({JSON_ARGS})' biçimiyle sınırlandırılır
    • Araç çalıştırma sonuçları tool_result(...) biçiminde LLM'e iletilir

Araç çağrısı ayrıştırma ve LLM yanıt işleme

  • LLM yanıtında tool: ile başlayan satır bulunarak araç adı ve argümanlar (JSON) çıkarılır
  • Her araç çalıştırıldıktan sonra sonuç JSON olarak serileştirilip konuşma kaydına eklenir
  • execute_llm_call fonksiyonu LLM API'sini çağırır ve yanıt metnini döndürür
  • run_coding_agent_loop, kullanıcı girdisini alıp LLM ile diyalog döngüsünü sürdürür
    • İç döngü, LLM artık araç çağrısı istemeyene kadar tekrar eder

Çalıştırma örnekleri ve genişletilebilirlik

  • Örnek diyalog:
    • “hello.py dosyasını oluştur ve hello world'ü uygula” → edit_file çağrısıyla yeni dosya oluşturma
    • “hello.py dosyasına iki sayıyı çarpan bir fonksiyon ekle” → read_file ardından edit_file çağrısı
  • Yaklaşık 200 satır kodla tam bir kodlama asistanı uygulanabilir
  • Ticari ürünler bunun üzerine hata işleme, akış yanıtları, bağlam yönetimi, ek araçlar, onay süreçleri gibi özellikler ekler
  • Temel yapı aynıdır ve LLM'in karar verdiği, kodun yürüttüğü basit bir döngüden oluşur

Uygulama ve genişletme

  • Tüm kaynak kod yaklaşık 200 satırdır ve başka LLM sağlayıcılarıyla değiştirme ya da araç ekleme yoluyla genişletilebilir
  • Basit bir yapıyla bile güçlü bir yapay zeka kodlama ajanı prototipi doğrudan uygulanabilir

1 yorum

 
GN⁺ 2026-01-09
Hacker News yorumları
  • Benim eklemek istediğim şey planning
    Etkili araç kullanımının kilit noktası, bunların dinamik bir TODO listesi üzerinde çalıştığını fark ettiğiniz andır
    Plan modu, bu listenin nasıl tohumlandığını ve her maddenin ne zaman yürütüleceğini bootstrap eder
    Kullanıcı etkileşimi de bu listeyi yeniden sıralayarak çalışır
    Geçen ay Claude Code'un CTF problemlerini ne kadar iyi çözdüğünü test etmiştim; TodoList aracını ve planning'i kapatınca performans 1-2 kademe düştü
    İlgili video için bkz. Breaking Bots: Cheating at Blue Team CTFs with AI Speed Runs
    İlginç olan, birçok kişinin sadece “plan modunu kullanalım mı kullanmayalım mı” kısmına odaklanması, ama TODO listesinin aslında her zaman aktif olması
    Bir de “akıllı context yönetimi”ni basit TODO maddelerine indirgeyen yazıları görünce gülüyorum
    Bunu kendileri uygulamaya çalışıp prod ortamında çöken değerlendirme sonuçları yüzünden 1 yıl kaybeden çok kişi var

    • Claude Code'un sistem prompt'unu çıkaran gist içinde TODO iterasyonu hakkında çok ayrıntı var
      Bunu sadece reasoning token'larıyla da ekleyebilirsiniz ama pratikte açık tek anahtarlı bir depolama aracı olarak uygulamak çok daha öngörülebilir ve etkili oluyor
      Dil yapısını saklayan başka araç fikirlerinde de bu kadar basit bir yaklaşım işe yarayabilir gibi görünüyor
    • CLI agent'ları için bir “working memory” dosyası tutma yaklaşımı bende çok iyi sonuç verdi
      Codex'i test ederken spesifikasyonu yaklaşık 10 dakikada toparlayıp değişiklik listesine böldüm, bunu bir dosyaya kaydettirdim, ardından her değişiklikten sonra planı gözden geçirip düzeltmesini söyledim
      Böyle olunca LLM, kısa ve hedef odaklı işlere yoğunlaşabiliyor ve sürekli prompt girişi gerekmiyor
      Fiilen bir subagent eklemekle benzer etki yaratıyor
    • Ben de prompt'un sonuna sık sık “bu görev için çok ayrıntılı bir todo listesi kullan” diye ekliyorum
      Son todo maddesi olarak da “tüm işi yeniden gözden geçir ve linter vb. ile kaliteyi kontrol et” talimatı veriyorum
    • TODO listesi çoğu zaman context'in HEAD'ine yeniden eklenir; böylece LLM geçmişi ve sonraki adımları fark eder
      Context sıkıştırılırken de oturumun özlü bir temsili olarak kullanılır
    • Yıl sonuna doğru “How to Code Claude Code in 200 Million Lines of Code” gibi şakalar çıkabilir
  • Kodlama agent'larının özü aslında basit bir loop ve araç çağırma yapısı
    Ama “The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code” gibi bir yazı yazacaksanız, Thorsten Ball'ın How to Build an Agent yazısına mutlaka bakmalısınız
    O yazı, “agent'ın özü basittir” fikrini ilk ortaya koymuştu
    Elbette pratikte TODO'lar ve çeşitli scaffolding gerekli; Claude Code'un kendisinde de karmaşık ayarlar, eklentiler ve UI özellikleri var
    Yine de elinizde o minimal loop varsa, sistemi kendi kendine özellik genişletecek şekilde bootstrap etmek mümkün
    İçeride ne olduğunu görmek isterseniz claude-trace ile LLM ve araç çağrıları arasındaki etkileşimi takip edebilirsiniz

    • Claude Code ve Codex'in yerel transcript'lerini analiz ederek iç yapıya baktım
      Basit loop'un dışında uuid threading, mesaj kuyruğu işleme, dosya değişikliği snapshot'ları, subagent sidechain'leri gibi pek çok karmaşık unsur var
      Bu yüzden “200 satır” kavramsal olarak doğru olsa da gerçek production seviyesi çok daha karmaşık
      Codex'te henüz queueing yok ama yine de güçlü
      Ben de Contextify adlı bir macOS uygulaması yaptım; Claude Code ve Codex CLI transcript'lerini gerçek zamanlı izliyor ve Total Recall özelliğiyle konuşma geçmişini sorgulamayı sağlıyor
    • Kod düzenleme en önemli kısım
      Claude modelleri kendi str replace araç şeması ile eğitilmiş durumda
      Dosyanın tamamını yeniden yazmak verimsiz olduğundan asıl kritik nokta kısmi düzenleme
    • “Aynı yazı tekrar paylaşılmış sandım” diyenler de oldu
    • “O basit core loop'u doğrudan gösterebilir misin?” diye soranlar da vardı
  • Gerçekte daha fazla unsur var
    Örneğin agent bazen early stopping yapıp işi bitirmiş gibi davranabiliyor
    Bu sorun en yeni reasoning modellerinde bile çözülmüş değil
    Claude Code bunu, her prompt'a TODO enjekte ederek kalan işleri hatırlatma yoluyla çözüyor
    HolmesGPT'nin açık deposunda çeşitli deney benchmark'ları var

    • “Early stop neden oluyor?” diye soranlar da vardı
  • “LLM'ye sadece araç listesini ve çağrı formatını vermek yeterli” fikri ilk başta sarsıcıydı
    LLM sadece metin üretiyorken nasıl araç çağırabilir diye düşünüyordum, ama hepsinin bundan ibaret olduğunu fark ettiğim an büyü gibiydi

  • Tatilde Opus ile Prolog DSL tabanlı bir kodlama agent'ı yaptım (200 satırı geçti)
    Şaşırtıcı biçimde neredeyse hemen iyi çalıştı
    Son nesil modeller, agent harness'inin öneminin azaldığı bir aşamaya ulaşmış gibi görünüyor
    İlgili deney için bkz. bu gönderi

  • 1 yıl önce bu yazı oldukça isabetliydi ama bugün harness'ler çok ilerlediği için, basit loop modeliyle Claude Code'un gerçek davranışını açıklamak zor

    • Elbette modern harness'ler daha fazla özellik taşıyor ama temel kavram hâlâ geçerli
      Aynı modeli kullanan basit bir agent'ın performansı da çok geri kalmıyor
      Bu, “kendi DB'ni yap” eğitimlerinde temel B-tree'yi göstermeye benziyor
    • tbench.ai leaderboard'a göre karmaşıklık performansı biraz artırıyor, ama “Terminus” gibi basit loop tabanlı sistemler de fazlasıyla güçlü
    • “Bu yazı 2025 Ocak'ta yayımlandı” diye belirtenler de oldu
    • Aslında son 1 yıldaki ilerleme daha çok prompt ve araç tasarımının sadeleştirilmesi üzerine yoğunlaştı
      Subagent'lar, MCP ve Skills orta seviyede; context optimizasyonu ise ancak uzun süreli çalışmalarda anlamlı
    • codex-cli deposu kullanılarak daha iyi model analizi yapılabilir
  • Ben kurumsal kullanım için agent loop'ları doğrudan inşa ediyorum ve ayda 1 milyardan fazla token işliyorum
    Basit loop çekirdekte dursa da gerçek ortamda sayısız ayrıntı karmaşıklığı patlayıcı biçimde artırıyor
    Örneğin kullanıcı süreç ortasında mesaj atarsa loop nasıl ele alınacak, Slack gibi webhook girdileri nasıl senkronize edilecek,
    onaylar, guardrail'ler, asenkron task işleme gibi pek çok konu var
    Bu deneyimleri bir blog yazısında toplamayı düşünüyorum

  • Bakmaya değer yazılar arasında You Should Write An Agent ve How To Build An Agent var

  • Bizim SWE-bench ekibi 100 satırlık açık kaynak bir agent yayımladı
    Adı mini-swe-agent; hem akademide hem sektörde oldukça popüler
    Agent dünyasını öğrenmek için iyi bir başlangıç noktası

  • 2023'te “LangChain'i 100 satırda yeniden uygulamak” hakkında bir yazı vardı
    O yazıyı görüp gerçekten uyguladım ve çeşitli projelerde kullandım

    • “Bunun üzerinden şimdiden 3 yıl mı geçti?” diye tepki verenler oldu