Ajanları Neden Bizzat İnşa Etmelisiniz

• LLM ajanları, yalnızca kavram olarak anlamaktan ziyade bizzat uygulandığında çalışma mantığı daha iyi hissedilen bir teknik yapı
• Yalnızca birkaç onlarca satırlık Python koduyla OpenAI Responses API kullanarak konuşmalı bir ajan oluşturulabilir; buna tool call özelliği eklendiğinde otonom davranış mümkün hale gelir
• Ajanın özü, durumsuz bir LLM ile tekrarlanan çağrı döngüsüdür; konuşma bağlamını (context) doğrudan yöneterek çok turlu konuşmalar uygulanabilir
• Context Engineering, gerçek bir programlama görevi düzeyinde bir problemdir; token sınırları içinde girdi, çıktı ve araç açıklamalarını optimize eden bir tasarım gerekir
• Bugünkü ajan tasarımı, açık bir yazılım mühendisliği problem alanıdır ve bireysel geliştiricilerin de deneylerle yeni yaklaşımlar deneyebileceği bir alandır

---

Ajan Yazmanın Basitliği

• LLM ajanları, karmaşık ayarlara gerek olmadan yalnızca OpenAI Responses API ile uygulanabilir
  • Örnek kodda context listesi üzerinden kullanıcı ile model arasındaki konuşma saklanır ve bu liste tekrar tekrar çağrılarak ChatGPT benzeri konuşmalı yanıtlar üretilir
• “İyi kişilik” ve “kötü kişilik”e sahip iki ayrı bağlam oluşturarak çoklu kişilik konuşması simüle edilebilir
  • LLM durumsuzdur; konuşmanın sürekliliği, kullanıcının yönettiği string dizisi (context) ile korunur
• Bu basit yapı tek başına bile çok turlu konuşmayı mümkün kılar ve LLM'lerin nasıl çalıştığını doğrudan deneyimlemenizi sağlar

Araç Entegrasyonu ve Otonom Davranış

• Ajana ağ bağlantı durumunu denetleyen bir araç olarak ping fonksiyonu kaydedilerek işlev eklenebilir
  • OpenAI API, araç tanımını JSON biçiminde ister; LLM gerektiğinde araç çağrısı talep ettiğinde Python kodu bunu çalıştırır ve sonucu yeniden iletir
• LLM, açık bir talimat olmadan bile birden fazla host'u (google.com, www.google.com, 8.8.8.8) otomatik olarak ping'ler
  • Bu, LLM'in yalnızca “araç kullanma yetkisi” ile bile otonom muhakeme yapabildiğini gösterir
• Tüm döngü temelde yalnızca “araç çağrısı isteği → çalıştırma → sonuç döndürme” yapısından oluşur; böylece karmaşık kontrol mantığı olmadan da otonom ajan davranışı uygulanabilir

Gerçek Uygulamalar ve MCP Eleştirisi

• Örnek kod basit olsa da buna ek araçlar (traceroute vb.) ya da SQLite tabanlı bağlam depolama eklenirse pratik biçimde genişletilebilir
• MCP (Multi-Context Protocol), yalnızca Claude Code veya Cursor için bir eklenti arayüzüdür; zorunlu bir teknoloji değildir
  • API'yi doğrudan kullanırsanız MCP olmadan da aynı işlevleri uygulayabilirsiniz
• MCP, yalnızca kod üzerinde denetiminizin olmadığı ortamlarda yararlıdır; hatta ajan mimarisinin esnekliğini sınırlayabilir
• LLM güvenliği karmaşık olsa da ayrılmış bağlamlar ve araç kısıtları ile güvenli bir yapı tasarlanabilir

Bağlam Mühendisliğinin Önemi

• “Prompt engineering” abartılmış bir kavram olabilir, ancak context engineering gerçek bir programlama problemidir
  • Bağlam penceresindeki token sayısı sınırlıdır; girdi, çıktı ve araç açıklamaları bu alanı birlikte tüketir
  • Bu sınır aşıldığında modelin yanıt kalitesi kararsız hale gelir
• Çözüm olarak alt ajanlar (sub-agent) oluşturup her birine farklı bağlamlar ve araçlar vererek, bunların birbirine özet aktardığı ve bilgi alışverişi yaptığı yapılar tasarlanabilir
  • Bu tür yapılar ağaç biçimli ajan ağları veya gerçek zamanlı özetleme tabanlı sıkıştırma gibi çeşitli deneylere genişletilebilir
• Karmaşık fikirler bile 30 dakika içinde uygulanabilecek kadar basitlik taşıyabilir

Açık Mühendislik Problemleri ve Deneyin Değeri

• Bugün çok sayıda startup, zafiyet tespiti için ajanlar geliştiriyor; bireysel geliştiriciler de aynı deneyleri yapabilir
• Ajan tasarımı şu tür çözülmemiş mühendislik görevlerini içerir
  • Belirsizlik ile yapısal programlama arasında denge kurma
  • Gerçeklik doğrulaması (ground truth) ve döngünün erken sonlanmasını önleme
  • Çok aşamalı ajanlar arasında veri alışverişi biçimleri (JSON, SQL, Markdown vb.)
  • Token tahsisi ve maliyet kontrolü
• Bu problemler, büyük ölçekli araştırmalardan ziyade bireysel deneylerle de keşfedilebilecek alanlardır ve her iterasyon birkaç on dakika içinde denenebilir
• Sonuç olarak, ajanı bizzat inşa etme deneyimi, LLM teknolojisini anlamanın başlangıç noktasıdır

[GN⁺]

Hacker News görüşleri

• Yapılacak gerçekten çok şey var. NAND gate kullanarak CPU’yu breadboard üzerinde doğrudan yapmak istiyorum, Rust ile bir CDN de kurmak istiyorum ama zaman yetmiyor
  Bunun yerine Karpathy’nin eğitimini takip ederek bir LLM yaptım; böyle adım adım deney yapmak oldukça iyi hissettiriyor

  • Sonu olmayan bir eğri gibi. Eskiden breadboard üzerinde 8 bitlik bir bilgisayar yapmıştım, bu kez de uçuş eğitimine (PPL) sardım
    Her “tamam, bitti” dediğim anda bitiş çizgisi daha da uzaklaşıyor gibi geliyor. Sonuçta bizim gibi insanlar herhalde tam anlamıyla tatmin olmayan bir grup
  • TFA’nın başında bunun ne kadar kolay yapılabildiğini anlatıyor. Yazının asıl ana fikri de tam olarak bu

• Örnekte GPT-5 kullanılıyor ama sorgu arayüzü zaten endüstri standardı seviyesinde
  Örneğin OpenRouter.ai bağlarsanız çalışma sırasında model ve sağlayıcıyı kolayca değiştirebilirsiniz
  Ücretsiz modeller de var (ör. DeepSeek) ama yavaş ve kısıtlılar. Yine de deney yapmak için harikalar

• Birkaç ay önce Ruby ile kendi ajanımı yaptım. Gerçekten çok eğlenceliydi
  Temel mantık sadece dört satırdı; kavramsal olarak şaşırtıcı derecede basitti

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• 2 yıl önce PHP ile 25 satırda bir ajan yapmıştım; o zamanlar tool calling bile yoktu ama yine de oldukça iyi çalışıyordu
  LLM bana sed ya da awk gibi UNIX metin işleme araçları gibi geliyor — girdi ve komut veriyorsunuz, çıktı üretiyor
  LLM çağrılarını bu şekilde birleştirip döngüler veya dallanmalar kurunca oldukça güçlü sistemler ortaya çıkıyor
  İlgili kodlar: hubcap, llm

  • hubcap’i gerçekten çok seviyorum. Kod azdı ama çıkan sonuç etkileyiciydi
    Simon Willison’ın yazısı bana büyük ilham vermişti

• Claude Code’a alternatif bir şeyi kendin yapma kısmı özellikle çok tanıdık geldi. Kendini geliştiren kodlama ajanı yapmak neredeyse büyülü bir deneyim
  Modeli özgürce değiştirebiliyorsunuz ve Cerebras gibi hızlı modeller kullanınca etkileşimli araç çağrılarında fark gerçekten hissediliyor
  Buna bellek, konuşma tanıma vb. eklerseniz çok daha verimli oluyor. Birkaç dakikada yapılabiliyor ve gerçekten çok eğlenceli

  • Hangi konuşma tanıma modelini kullandığını merak ediyorum. Whisper yavaştı ve yeterince doğru değildi, GPT ses modelleri ise sık sık reddetme yanıtı veriyor
    Google modellerinin kalitesi düşüktü, Mistral modelleri hızlıydı ama bazen metne tepki veriyordu
    Bu yüzden bazen benim söylediklerim yerine LLM’in bilinç akışı yazıya dökülmüş oluyordu
  • “build your own lightsaber” ifadesini gerçekten çok seviyorum
    Başta iç yapıyı anlamak için yaptım ama beklediğimden basit çıktı; şimdi istediğim özellikleri kendim ekliyorum
    Takım ürünü geliştirmekten daha hızlı özellik ekleyebiliyorum. Ajanlar şaşırtıcı derecede basit bir yapıya sahip
  • Başlamak için nereden başlanacağını bilmiyorum. Cerebras adını ilk kez duyuyorum. Şu an sadece VS Code’da Copilot kullanıyorum
    Bunun yerel model tabanlı olup olmadığını merak ediyorum
  • Cerebras artık glm 4.6 sunuyor. Hâlâ inanılmaz hızlı ve artık çok daha akıllı

• Bu yazı insana Unix felsefesini — tek işi çok iyi yapan araçlar — yeniden kurma isteği veriyor
  Bu, ajanları sadece daha basit yapmakla kalmıyor, güvenliği de artırıyor

  • 2021’de ağ bağlantısını test eden bir ajan yapmıştım; ping, dig, traceroute gibi temel araçları ajana verdiğinizde oldukça iyi sonuçlar üretiyor
    İnsan eliyle yapılmış telemetri sistemleri kadar kusursuz değil ama %90 düzeyinde kullanışlılığı çok daha kolay elde edebiliyordum
  • Doğrudan insanlara sunulan sınırlı amaçlı bir araç seti de hayal edilebilir
  • Tek bir işi iyi yapmak için daha fazla araca ihtiyaç oluyor ve buna paralel olarak bağlamı anlama kapasitesi büyüyor
    LLM için ideal boyutun, geleneksel Unix araçlarından biraz daha büyük bir orta nokta olduğunu düşünüyorum

• “Ajan yapmak gerçekten şart mı?” diye düşündürüyor.
  Tüm AI sağlayıcıları zarar ederken sürdürülebilir bir gelir modeli mümkün mü, bundan şüpheliyim

  • Kendin yapınca ajanların nasıl çalıştığını ve sınırlarını sezgisel olarak anlıyorsun. Asıl mesele bu
  • Bu sadece teknolojiyi eğlence için deneme yazısı. Gelir elde etmekle ilgisi yok
    Python kullanmamak için Astral’ın zarar etmesini gerekçe göstermekle benzer bir mantık
  • Tüm AI şirketleri zarar etmiyor
    Bir sonraki modelin eğitim maliyeti büyük olduğu için finansmana ihtiyaç duyuyorlar; çıkarım aşaması ise kârlı
  • Hatta doğrudan bir AI sağlayıcısı da olabilirsiniz
  • Bu yorumda biraz duygusal yorgunluk hissediliyor. Acaba çok kıdemli bir geliştirici mi diye merak ettim

• Bağlam mühendisliği kısmı bana özellikle dokundu
  Ben kişisel bir asistan yapıyorum ve bu sistem, genel ajanlardan daha fazla hafıza, görev takibi ve problem çözme yeteneğine sahip
  Birden fazla ajanı birbirleriyle konuşup sorun çözmeleri için tasarladım; ilk ajan ise görev yönetimi denetçisi rolünde
  Bu sürece ne kadar derin girerseniz mesele o kadar mühendislik problemine dönüşüyor
  Ayrıntıları blog yazımda anlattım

  • Gerçekten harika bir proje gibi duruyor

• Herkes ajan yapmayı seviyor ama debug etmeyi sevmiyor
  Başta sihir gibi çalışıyor, sonra yavaş yavaş olasılıksal hatalar birikiyor ve yeniden üretmek zorlaşıyor
  Her adım 0,5 saniye sürdüğü için, hatanın nerede olduğunu görmek adına 10-20 dakika beklemek gerekiyor

  • Bu yüzden ben de paralel çalıştırma aracı yaptım; değiştirdiğim kodu yüzlerce kez koşturabiliyorum
    Eski senaryoları da yeniden çalıştırıp hiçbir şeyin bozulmadığını doğruluyorum

• Verilen koda dayanarak bir MCP yaptım: gurddy-mcp.fly.dev
  Kaynak koduna GitHub deposundan bakabilirsiniz