LLM ajan döngüleri ve araç kullanımının akıl dışı verimliliği

 (sketch.dev)
1 puan yazan GN⁺ 2025-05-16 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka programlama yardımcısı Sketch'in geliştirme deneyimi üzerinden, LLM ile araç kullanımını birleştiren döngü yapısının ne kadar yalın uygulanabildiği vurgulanıyor
  • Yalnızca 9 satırlık bir döngü koduyla Claude 3.7 Sonnet gibi modern LLM'ler gerçek sorunları hızla çözüyor
  • bash gibi tek bir genel amaçlı araç bile geliştiricilerin tekrar eden ve zahmetli işlerinin önemli bir kısmını otomatikleştirebiliyor
  • Sorun çözmenin ötesinde, ek araçlar bağlanarak metin düzenleme veya özelleşmiş işler için kalite ve yineleme hızı artırılabiliyor
  • Giderek daha fazla özelleştirilmiş LLM ajan döngüsü, geliştiricilerin günlük otomasyonuna dahil ediliyor

Giriş: geliştirme deneyimi ve Sketch projesi

  • Philip Zelikiger ve çalışma arkadaşları, yapay zeka tabanlı programlama yardım aracı Sketch'i geliştirirken, LLM ile araç kullanımını birleştiren basit bir ajan döngüsü yapısının yüksek verimliliği karşısında şaşkınlık duydu
  • Temel yapı yalnızca 9 satırlık bir döngü kodundan oluşuyor ve sistem prompt'unu, konuşma geçmişini ve en güncel mesajı LLM API'sine iletiyor
  • LLM çıktı üretiyor ve gerekirse tool_calls (araç çağrısı isteği) döndürüyor

LLM ve araç kullanımının entegrasyonu

  • "Araç kullanımı (tool use)", LLM'in önceden tanımlı şemaya uygun çıktılar döndürmesi anlamına geliyor; sistem prompt'u ve araç açıklama prompt'ları sayesinde LLM'in bash gibi genel amaçlı araçlara erişmesi sağlanıyor
  • Modern LLM'ler (ör. Claude 3.7 Sonnet), tek bir genel amaçlı araçla bile çeşitli sorunları hızla otomatikleştiriyor; bazıları tek çalıştırmada ("one shot") bile çözülebiliyor
  • Eskiden karmaşık git komutlarını arayıp yapıştırmak ve birleştirme işlemlerini elle yapmak gerekirken, artık Sketch'ten isteyip sorunu doğrudan çözdürmek mümkün
  • Tür değişikliklerinden sonra oluşan çok sayıdaki type check hatasını da Sketch ilk kez otomatik olarak ele alabildi
  • Ajan döngüsü sürekli ve uyarlanabilir çalışıyor; araç kurulu değilse otomatik kurulum yapabiliyor ve komut seçeneklerindeki farklılıklara göre kendini uyarlayabiliyor
  • Kullanım sırasında LLM bazen testler başarısız olduğunda "testi atla" gibi beklenmedik öneriler sunsa da, genel olarak iş otomasyonunun kalitesi artıyor

Araçların çeşitlenmesi ve özelleşmesi

  • Sketch, bash dışında ek araçlar da kullanıldığında (bkz. metin düzenleme araçları), iş kalitesinin arttığını ve geliştirme iş akışının daha da verimli hale geldiğini deneyimledi
  • LLM'in sed vb. araçlarla metni tam isabetle düzenlemesi beklenenden daha zor; görsel (visual) editör tarzı araçların daha iyi olduğu görülüyor

Gelecek görünümü ve iş akışı değişimi

  • Ajan döngüsü yapısının, mevcut genel amaçlı otomasyon araçlarıyla ele alınması zor olan geliştirici günlüklerindeki tekrar eden işler için giderek daha fazla kullanılacağı öngörülüyor
  • Örneğin stack trace ile git commit korelasyonunu analiz etmek gibi zahmetli ve tekrarlı işlerde, LLM hızlı bir ilk işleme katmanı sağlayabiliyor
  • Gelecekte daha fazla özelleştirilmiş, tek seferlik LLM ajan döngüsünün geliştiricilerin bin/ dizini gibi yerlerde kullanılmasını beklemek mümkün
  • Kullanıcılar yalnızca gerekli bearer token'ı hazırlayarak kendi ortamlarında kolayca denemeler yapabiliyor

İlgili bağlantılar

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-16
Hacker News görüşleri
  • Bu blog yazısını da güçlü biçimde tavsiye etmek isterim. Aynı noktayı çok daha ayrıntılı ve ikna edici şekilde ele alan bir versiyon. Yazar gerçekten de baştan sona bir kodlama ajanı inşa ediyor. Bkz. https://ampcode.com/how-to-build-an-agent. LLM'nin araç çağırabildiği bir döngü içinde ne kadar çeşitli işi iyi halledebildiğini görmek gerçekten şaşırtıcı bir deneyim. Elbette kusursuz değil ve %100 güvenilirliğe ulaşamama gibi sorunlar var. Yine de en azından biraz hayranlık uyandıran bir tarafı olduğunu düşünüyorum. Bunu kendiniz denerseniz 30 dakika içinde takip edebilirsiniz. Yapay zekanın belli kullanım alanlarında etkili olup olmadığına dair sağlıklı şüpheyi korurken aynı anda hayret de duyabileceğiniz bir alan. LLM'yi bir döngünün içine koymanın bu "mantıksız verimliliği", şu anda bu kadar çok kod üretim ajanının ortaya çıkmasının nedeni: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex vb., üstelik bunları taklit eden proje de çok fazla. Özel bir gizli tarif olmamasının sebebi bu; sihrin %95'i sonuçta LLM'nin kendisi ve araç çağrısı yapacak şekilde fine-tune edilmiş olması. Claude Code'un başlıca geliştiricisinin yakın tarihli bir röportajda dürüstçe kabul ettiği şey de buydu. Elbette bu araçların iyi çalışması için çok emek gerekiyor ama temelde neredeyse aynı basit çekirdek yapı var
    • Uzun zamandır tam böyle bir yazı arıyordum, gerçekten çok teşekkür ederim hissindeyim. Birçok kişi Agents'ı görünce "muhtemelen gerçekten karmaşık problemleri çözemiyordur, değil mi?" diye tepki veriyor ama bence ajanın asıl meselesi bu değil. LLM, çok fazla bağlam olduğunda gerçekten iyi çalışıyor ve ajanlar, LLM'nin daha fazla bağlam bulup sorulara verdiği yanıtın kalitesini artırmasını sağlayan bir yapı
    • LLM'nin tek başına, döngü içinde, birkaç adımdan fazla yönlendirme almadan iyi yapabildiği çok iş deneyimlemedim. Birkaç yinelemeden sonra mutlaka benim müdahale etmem gereken bir durum çıkıyor
    • pocketflow adlı grafik soyutlama kütüphanesini kullanarak benzer bir şey yapan bir eğitim var. Gerçekten denedim ve oldukça basit olduğu için çok memnun kaldım. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
    • Bunun Thorsten Ball'ın yazısı olduğunu ancak şimdi fark ettim. Onun "interpreter yapimi" kitabını gerçekten keyifle okuduğumu hatırlıyorum. Sanırım ben de artık bir ajan yapmayı deneyeceğim
    • Yukarıdaki bağlantıyı açmadan önce ?utm_source=hn&utm_medium=browser eklemem gerekip gerekmediğini düşündüm
  • Bugün ilk kez GPT-4o ve 4.1 ile bizzat "vibe-coding" denedim. Derleme hatalarını, uyarıları ve önerileri canvas arayüzü üzerinden elle besleyerek döngü kurduğum bir yöntemdi. Dosya küçüktü, yaklaşık 150 satırdı. 4o ile başladım ama eski bir paket kullandı. Bunu ben işaret ettiğimde bile tüm kullanım yerlerini güncellemedi ve elle düzeltmem gerekti. Mantık değişikliği önerince sözdizimini tamamen bozduğu bir durum oldu ve bir daha da toparlayamadı. Derleme hatalarını tekrar tekrar girmeme rağmen sözdizimi sorununu anlayamadı, kodun rastgele yerlerini düzeltmeye çalıştı. Bu yüzden 4.1 daha iyi olur mu diye umut ettim ama 4.1 bu kez canvas kullanmayı tamamen reddedip sadece açıklama yaptı. Kendi başıma düzeltmemi isteyen bir tarzdaydı. Israr ederek sonunda canvas'a kod yazdırdığımda ise bu sefer orta kısım "// omitted for brevity" gibi kesilmiş bir sürümdü, yani kullanılamaz durumdaydı. Burada bıraktım. Ajanların bu sorunu çözüp çözmediğini merak ediyorum. Şu an için bu deneyimin tamamen bozuk olduğu hissindeyim ve böyle bir haldeyken bash erişimi vermek fazla tehlikeli olur diye endişeleniyorum
    • "Eski paket kullandı" kısmı, modelin eğitim verisinin zaman açısından kesilmiş olmasından kaynaklanıyor. LLM kullanırken özellikle dikkat edilmesi gereken bir nokta. ChatGPT'de sık sık o4-mini-high'a geçiyorum. Bu model arama özelliğiyle güncel dokümanları da bulabiliyor. "X kütüphanesinin en güncel sürümünü bulup onu kullan" derseniz çoğu zaman bunu iyi yapıyor. Yakın zamanda JavaScript kodunun bir bölümünü Google'ın güncel olarak önerdiği bir kütüphaneye dönüştürmem gerekiyordu; eski kodu yapıştırıp yeni kütüphaneye port etmesini istedim, dokümanları da bulup gerçekten doğru şekilde port etti. https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
    • GPT 4.1 ve 4o, Aider kodlama benchmark'ında çok düşük puan alıyor. Pratik deneyimime göre sonuçların işe yarar olması için en az %70 civarında olmak gerekiyor. Yine de karmaşık şeylerde ciddi yardıma ihtiyaç duyuyorlar. Bir süre kullandıktan sonra neyin işe yarayıp neyin yaramadığına dair sezgi oluşuyor. https://aider.chat/docs/leaderboards/
    • "Beceri meselesi" denmesini duymak hoş olmayabilir ama LLM kullanmak gerçekten ayrı bir ustalık gerektiren bir alan. Farklı araçların güçlü ve zayıf yönlerini anlamak, çeşitli teknikleri denemek ve pratik yapmak işin vazgeçilmez parçası. Bash erişimi verecek olsam ben de sadece container ortamında (docker) kullanırdım
    • Buna vibe coding denemez. Vibe coding yapabilmek için kod değişikliklerini otomatik olarak uygulayan bir araç kullanmak gerekir. Elle tek tek geri bildirim verirseniz eninde sonunda hatalarda tıkanıp kalırsınız. Vibe coding'in özü; geri alma, yeniden çalıştırma, farklı çözümleri kolayca ortaya atıp atabilmektir. Böyle bir deneyim için tooling şart
    • Kısa süre önce Cline eklentisi ve Claude ile VSCode içinde Android uygulama prototipini "sıfırdan" yaptım. Android Studio'nun verdiği temel şablondan başladım ve binlerce satır kod üretildi, tek bir derleme hatası bile yoktu. Uygulama beklendiği gibi çalıştı ve bulunan birkaç bug da LLM'den değil, Android API'lerinin garip davranışlarından kaynaklanıyordu. LLM'ye bug'ı işaret edip debug mesajı çıktısını verdiğimde kendisi düzeltti. İlk başta düzeltmeler biraz dağınıktı ama birkaç tur geri bildirimden sonra gayet iyi çözüldü. Kod yazma ajanı ile kod review ajanını bir döngüye koyarsanız bunun gibi şeyleri daha genel biçimde iyi ele alabilirsiniz gibi geliyor
  • Claude Code, yani Sonnet 3.7'nin terminal arayüzünü çıktığı ilk günden beri kullanıyorum. Oldukça büyük CLI uygulamaları, full-stack web sistemleri ve sayısız yardımcı araç da yazdım. Eskiden yazılım ekibi yönettiğim döneme benzer biçimde daha iddialı işlere girişir oldum. Yapısal olarak başka araçlardan çok farklı olmayabilir ama Anthropic'in çok kullanışlı pek çok özellik eklediği hissi var. Kusursuz değil ve iyi kod kalitesi için hâlâ o zamanlarda olduğu kadar benzer bir emek gerekiyor. Oldukça karmaşık şeyler bile çalışıyor ama bazen bir sonraki özelliği eklemeyi zorlaştıran durumlar da ortaya çıkıyor. Nasıl kullanılacağını öğrendikçe refactoring ve toparlama süreci çok azalıyor. Tamamen ortadan kalkacak gibi değil. kgeist'in yaşadığı türden sorunları açıkçası hayal etmek zor. Claude da bazen benim tercihlerimden farklı ya da aptalca şeyler yapıyor ama beni bırakmak isteyecek noktaya hiç getirmedi. Neredeyse her zaman makul sonuç veriyor ve zihnimden aldığı yük çok büyük. Üstelik refactoring işini gerçekten çok iyi yapıyor. Düzenli olarak kodu gözden geçirip daha iyi bir yol olup olmadığını Claude'a anlattırınca karmaşıklık ciddi biçimde azalıyor. "Veri yapısını değiştir" gibi istekleri de anında hallediyor. Harika bir özellik. Bir de eğlencesine, kod değil de 30 yıllık dağınık bir arşiv dizinini açtım. "Bu dizinde ne var?", "Eski özgeçmişlerimi okuyup yenisini yaz", "Çocuklarımın adları neydi?" gibi şeyler sordum; gerçekten etkileyiciydi. Hâlâ erken aşamada olmasına rağmen çok mutluyum
    • Yakın zamanda uzaktaki veri yapısı tanımlarını, API spesifikasyonunu, parse etme ve kaydetme implementasyonunu ve kullanıcıya sunum katmanını tek seferde ele almak zorunda kaldığım bir durum oldu. Claude tüm bunları aynı anda iyi yönetti; böylece iki uçtaki küçük değişikliklerin orta katmanları nasıl etkilediğini anında görebildim. Birden fazla fikri hızlıca yineleyerek en iyi çözümü buldum. Bu kadar yüksek karmaşıklığa sahip çok katmanlı yapıları böylesine hızlı yineleme temposuyla keşfedebilmek hem verimliliği artırdı hem de tüm sistemin yapısal anlayışını derinleştirdi
    • Yukarıda bahsedilen refactoring gerçekten keyifli bir işe dönüştü. Eskiden bir sprint'e bile sokmakta zorlanacağımız şeyler artık 5 dakikada bitiyor. Sanki hazır bir ekip sürekli benim ne istediğimi bekliyormuş gibi. Sonuç hoşuma gitmezse anında reddedebiliyorum; gereksiz inceleme ve takvimleme derdi de sanki yok olmuş gibi
  • LLM'nin sık sık "Ah, bu test çalışmıyor... hadi bunu atlayalım" demesi beni çok sinirlendiriyor. Bunun için düşünülebilecek bir fikir var. Ana LLM'in talimatlara uymasını sağlayacak, ondan bağımsız ve paralel çalışan bir policy-enforcement LLM başlatmak. Örneğin yardımcı LLM, "let's just" ifadesinden sonra "skip" kelimesinin çıkmaması için çıktı olasılıklarını manipüle edebilir. Yani "skip" yasaklanırsa LLM'nin istenmeyen davranıştan uzaklaşacak bir yola girmesi sağlanabilir. Bu, bir tür JSON mode ya da structured output gibi çalışır ama yardımcı LLM politikanın kontrolünü dinamik ve gerçek zamanlı olarak yürütür. Bu işe yararsa daha da geliştirip, testleri geçmek için test kodunu silmek ya da işe yaramaz yorumlar üretmek gibi farklı politika ihlallerini yardımcı LLM'nin prompt'una koyarak gerçek zamanlı izleme ve kontrol yapan bir yapıya genişletmek mümkün olabilir. Outlines ekibinin bu yapı hakkında ne düşüneceğini merak ediyorum
    • Eğer bir LLM başka bir LLM'nin çıktısını denetleyebiliyorsa, o zaman "mixture of experts" türü bir LLM'de uzman alt modellerden biri izleme ve denetim rolüne atanabilir mi diye düşünüyorum. Ya da ayrı bir düşünce iş parçacığı ayırıp kendi çıktısını doğrulatmak, hatta gerekirse o doğrulayıcıyı da doğrulayan başka bir iş parçacığı eklemek gibi daha sağlam bir düzen kurulabilir
    • Bu bağlamda, ana LLM yanlış yola girdiğinde gözetleyici LLM'nin modeli o ana kadar "rewind" etmesi de düşünülebilir; örneğin "let's just skip the test" tespit edilirse "just " sonrasına geri sarıp belirli kelimelerin yazılmaması için bias uygulamaya devam etmek gibi. Bunu yapabilmek için kullanacağınız model sağlayıcıları sınırlı olabilir ve özellikle OpenAI son dönemde bu tür power user özelliklerine pek sıcak görünmüyor
  • Bu sabah cursor ile bir oyun prototipinin ana döngüsündeki karmaşık bir kısmı ayırdım ve o bölüm için otomatik olarak bir test kodu seti ürettim. Toplam 341 test, core math ve temel bileşenlerin tamamını kapsıyor. Bazen kedi gütmek gibi hissettirse de hangi fonksiyonların kullanılacağı, nereye yazılacağı, hangi template dosyalarının kullanılacağı ve nelerden kaçınılacağı gibi daha fazla kısıt verdikçe sonuçlar belirgin biçimde iyileşiyor. Toplam 3500 satır test kodunu benim elle yazmama gerek kalmadı; sorun çıkarsa da her zaman silip yeniden üretebilirim. Zorluk eğrisi ayarlama, görev varyasyonları gibi birçok konuda da yardım alıyorum
    • Benim deneyimime göre testleri otomatik üretmek, LLM'lerin en iyi kullanım alanı. Saatler ya da günler süren sıkıcı ve tekrarlı emeği bir hamlede ortadan kaldırıyor. Benim aklıma gelmeyecek birçok edge case de otomatik olarak kapsanıyor ve kodun güvenliği de artıyor. Gerçekten birçok açıdan müthiş bir özellik
  • Bu sıralar LLM'lerin araç kullanma becerisi beni çok heyecanlandırıyor. Aslında bu hile yeni değil; ilk kez 2 yıl önce ReAcT makalesinde görmüştüm. Sonrasında ChatGPT eklentilerinde, MCP'de vb. kullanıldı ve artık çoğu model tool call/function calling düşünülerek eğitiliyor. Şu anda ilginç olan şey, performansın ne kadar artmış olduğu. o3/o4-mini'nin güçlü arama performansının temelinde de bu araç çağırma yeteneği var. Qwen3 4B (Ollama 2.6GB, Mac'te de rahat çalışıyor) bile bunu iyi yapıyor. Dün PyCon US'te LLM tabanlı yazılım üretimi üzerine bir atölye yürüttüm ve bunun etkisiyle kendi LLM komut satırı aracıma araç kullanımı özelliği ekledim. Bkz. https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. Artık kendi LLM paketimle "strawberry" kelimesinde kaç tane R geçtiğini saymak gibi şeyleri shell one-liner ile güvenilir biçimde yapabiliyorum
    • Bu özelliğin verdiği eğlence ile güç hissinin tuhaf birleşimini çok seviyorum
    • Atölye kayda alındı mı diye merak ediyorum
  • Hangi agent'ın en çok token kullandığını merak ediyorum. cline listede üst sıralarda ve roo sanki cline'dan daha az kullanıyor gibi. Etkileşim biçimini doğrudan ayarlayabildiğiniz bir agent var mı, ayrıca Claude code diğer agent'larla kıyaslandığında nasıl duruyor öğrenmek isterim
  • "Gerekli araç yoksa kurar" kısmı korkutucu olan taraf. LLM aşırı derecede 'itaatkâr' ve biri söylediği anda harekete geçen bir yapıda. Bu, SQL injection'dan bile daha ciddi bir güvenlik endişesi
    • İlk gerçek agent tabanlı felaketin ne zaman yaşanacağını bazen merak ediyorum. (Özellikle de alelacele piyasaya sürülen AI ürünlerinin havasını düşününce.) Zamanla geri döndürülemez bir felaketin kesinlikle yaşanacağından endişe ediyorum
  • Başlığın, Eugene Wigner'ın "The Unreasonable Effectiveness of Mathematics in the Natural Sciences" makalesine gönderme yaptığını düşünüyorum
    • O makale asıl kaynak olabilir ama bence artık çoktan bir meme'e dönüşmüş bir kalıp ifade. https://scholar.google.com/scholar?q=unreasonable+effectiveness
    • Ben ise başlığın daha çok Karpathy'nin 2015 tarihli "Unreasonable Effectiveness of RNNs" yazısından alındığını sanmıştım. Tabii Karpathy de muhtemelen Wigner'ın makalesinden yeniden ödünç almıştır denebilir. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
    • Her "unreasonable effectiveness" başlığını gördüğümde, yazarın sonucuna güçlü şekilde katılmadığım hissine kapılıyorum. Wigner'ın makalesi de dahil. Artık biraz Betteridge yasası gibi geliyor
  • Şirket içi ürünümüzde gömülü ai chatbot'a daha fazla bağlam vermek için araçlar geliştirdik. Son etkinlik günlüğü, mevcut nesne tanımı, arama ve yardım makalelerinde gezinme gibi çeşitli özellikler ekledik. Aylar geçmiş olmasına rağmen chatbot'un kalitesi hâlâ şaşırtıcı geliyor. Eğer chatbot bir şeyi yanlış yanıtlarsa, süreç içinde ilgili yardım makalesini daha spesifik hale getiriyoruz