Tools: Kodunuz Varsa Yeter - Code Is All You Need

 (lucumr.pocoo.org)
20 puan yazan GN⁺ 2025-07-04 | 2 yorum | WhatsApp'ta paylaş
  • MCP tarzı araç bağlamanın "gelecek" olduğu iddia edilse de, pratikte yetersiz bileşebilirlik ve aşırı bağlam tüketimi gibi sınırlamalar nedeniyle, doğrudan kod yazma yaklaşımı hâlâ daha verimli
  • LLM çağında bile otomasyon ve tekrar eden işler için kod üretmek/kullanmak, güvenilirlik ve doğrulanabilirlik açısından üstün
  • LLM'ler, çıkarım temelli otomasyondan çok kod üretimi ve tekrar tekrar çalıştırma konusunda güçlü; kod tabanlı süreçler sorun tespiti, doğrulama ve ölçeklenebilirlikte daha başarılı
  • Playwright gibi bazı araçlarda (MCP yaklaşımı), her "çıkarım temelli" adımda belirsizlik ve hata ayıklama zorluğu artıyor; betikleri doğrudan kodla üretip/düzenlemek ise tekrar edilebilirlik, hız ve güvenilirliği iyileştiriyor
  • LLM'in kod üretip, başka bir LLM'in o kodu inceleyip açıklamasından oluşan "kod-denetim-tekrar" döngüsü, pratikte en güçlü otomasyon akışı

Kodunuz Varsa Yeter

  • Beni Twitter'da takip ediyorsanız, son zamanlarda Model Context Protocol (MCP) konusunda pek olumlu olmadığımı biliyor olabilirsiniz
  • Bunun nedeni fikrin kendisine karşı olmam değil; MCP'nin reklam edildiği kadar etkili olmaması
  • MCP'nin iki temel kusuru var
    • Gerçek anlamda bileşebilir (composable) olmaması
    • Aşırı bağlam sağlama gereksinimi yüzünden, kodu doğrudan yazıp çalıştırmaktan daha fazla bağlam tüketmesi
  • Bunu basit bir deneyle görebilirsiniz
    • Örneğin GitHub MCP ile bir görevi tamamladıktan sonra aynı işi gh CLI aracıyla yaparsanız, ikincisinin bağlamı çok daha verimli kullandığını ve istenen sonuca daha hızlı ulaştığını görürsünüz

But MCP is the Future! : Ama MCP geleceğin kendisi değil mi?

  • Kodun daha iyi olduğu yönündeki bu görüşüme gelen geri bildirimlerden bahsetmek istiyorum
  • MCP'yi ajanik kodlama (agentic coding) bağlamında derinlemesine denedim ve onu sınırlarının en net ortaya çıktığı noktada değerlendirdim
  • Aldığım geri bildirimlerden biri şu: "MCP, genel amaçlı kod üretimi için pek gerekli değil. Zaten modeller kod üretiminde yeterince iyi." Buna karşılık belirli alanlarda (ör. finans şirketlerindeki otomasyon işleri) gibi son kullanıcıya dönük uygulamalarda MCP'nin anlamlı olabileceğini söyleyenler de oldu
  • Bir başka görüş de şu: Gelecekte modeller daha çeşitli araçlara erişecek ve daha karmaşık işleri de yapabilecek; bu potansiyele odaklanmak gerek
  • Ama şu anki değerlendirmem şöyle: Denediğim veriler ve gerçek deneyimlerime göre, mevcut MCP'yi kullanmak doğrudan kod yazmaktan her zaman daha zor
    • En büyük sebep, MCP'nin çıkarıma (inference) dayanması
    • Son dönemde "LLM'ye daha fazla araç bağlama" yönündeki tüm girişimlerde, sonunda LLM'in tüm araçları alıp işe uygun şekilde filtrelediği bir katman ekleniyor
    • Şimdiye kadar bundan daha iyi bir yapı ya da yaklaşım önerilmiş değil
  • Bu yüzden şu sonuca varıyorum: Geliştirici olmayanlara yönelik belirli alan otomasyonları gibi özel durumlarda bile, sonuçta kod üretimi, bileşebilirlik ve yeniden kullanılabilirlik açısından her zaman daha iyi bir tercih

Replace Yourself With A Shellscript

  • Bu soruna bakmanın bir yolu şu: Yapay zeka yokken, bir geliştiricinin problem çözme aracı koddur
  • Geliştirici değilseniz kod zor gelebilir ve birçok kişinin elle yaptığı pek çok iş aslında yazılımla otomatikleştirilebilir
  • Asıl pratik sorun, o kodu kimin yazacağı
  • Özel bir ortamdaysanız ve programlama bilmiyorsanız, sıfırdan kodlama öğrenmek de zordur; birinin size özel kod yazmasını beklemek de pek gerçekçi değildir
  • Elbette bazı işler çıkarım (insani yargı/esneklik) gerektirebilir; ama tekrar eden ve açık tanımlı işlerin çoğu aslında kodla otomatikleştirilebilir
  • "Kendimi bir shell script ile değiştirmek" eski bir geliştirici deyişidir ve bu tür otomasyon uzun zamandır var
  • LLM ve programlama çağında ise shell script yerine kendimizi LLM ile değiştirmeye çalışıyoruz; ama burada üç sorun (maliyet, hız, güvenilirlik) ortaya çıkıyor
  • Bu üç sorun çözülmeden, araçları (MCP vb.) kullanmayı tartışma aşamasına bile gelinmez
  • Yani asıl mesele, otomasyonun gerçekten ölçeklenebilir biçimde düzgün çalıştığını önce garanti altına almak

Automation at Scale : Büyük Ölçekli Otomasyonun Özü

  • Otomasyonun özü, tekrar eden ve yeniden kullanılabilir işleri kodla yürütmektir
  • Bir kez yapıp bir daha asla yapmayacağınız bir şeyi otomatikleştirmeniz gerekmez. Otomasyon, birçok kez tekrarlanacak ve makinenin gerçekten verim kazancı sağlayacağı işlerle başlar
  • Gerçekte önce işi 1-2 kez elle yapar, çalışma biçimini netleştirir, sonra makinenin bunu binlerce kez tekrar etmesini sağlarsınız; otomasyonun özü budur
  • Böyle tekrar eden otomasyonlarda her zaman "kod" kullanmak en iyi yoldur
    • LLM'e her seferinde "çıkarımla" yaptırırsanız, küçük işlerde idare eder; ama doğrulamaya harcanan zaman ve emek otomasyonun faydasını azaltır
    • Örneğin LLM'e hesabı doğrudan yaptırmak yerine, LLM'in Python kodu yazmasını ve hesabı o kodla yapmasını sağlamak hem güvenilirlik hem ölçeklenebilirlik açısından daha iyidir
      • Kod kullanınca formülün/mantığın kendisini inceleyebilirsiniz; gerekirse doğrudan düzeltebilir ya da LLM'e "bu yöntem doğru mu" diye denetlettirebilirsiniz
      • Python'un hesabı yanlış yapacağından kaygı duymanıza gerek olmadığı için, kod üretimi yaklaşımının doğrulama ve güven açısından daha iyi olduğu netleşir
  • Bu mantık basit hesaplamaların ötesine geçip gerçek yazılım geliştirme işlerine de uygulanır
    • Örneğin yakın zamanda bu blogun tüm biçimini reStructuredText'ten Markdown'a dönüştürdüm
    • Bunu epey zamandır erteliyordum; üşendiğim için de değil, dönüşümü doğrudan LLM'e bırakırsam bir yerlerde ince eksikler, hatalar ya da bağlam bozulmaları olabilir diye güvenemediğim için
    • Bu yüzden sonunda LLM'i dönüşümü doğrudan yapmak için değil, dönüşüm kodu üretmek için kullandım ve işi kodla çözdüm

LLM → Kod → LLM: Tekrarlı Doğrulama Otomasyonunun Pratiği

  • İlk adımda LLM'den reStructuredText'i Markdown'a dönüştüren çekirdek dönüşüm mantığını üretmesini istedim
    • Bu basit bir dönüşüm değildi; AST'yi (soyut sözdizimi ağacı) doğrudan kullanacak şekilde
      • reStructuredText'i AST'ye ayrıştırma → Markdown AST'ye dönüştürme → HTML olarak render etme
      • Böylece ara bir dönüşüm katmanı elde ediyor ve sonucu doğrudan karşılaştırıp doğrulamayı kolaylaştırıyorsunuz
  • İkinci olarak, LLM'den eski HTML ile yeni HTML'i karşılaştıran bir betik de yazmasını istedim
    • Dönüşümden sonraki HTML farklarını (diff) incelerken, karşılaştırma öncesinde küçük farkları (ör. boşluklar, dipnot işleme biçimi vb.) otomatik düzeltilecek şekilde tasarladım
    • LLM'in dönüşüm sürecinde kabul edilebilir hata türlerini kendi başına dikkate almasını sağladım
    • Örneğin Markdown/reStructuredText kütüphanelerinin HTML gösterimleri küçük farklılıklar üretebilir; ama betiğe yalnızca özsel kayıp ve hataları yakalayacak mantık koyabilirsiniz
  • Üçüncü olarak, LLM'den yüzlerce dosyanın sonucunu toplu analiz edecek bir batch betiği de ayrıca istedim
    • Bu betikle tüm dosyaları döndürerek, farklar azalana kadar tekrarlı iyileştirme (agentic loop) yaptım
  • Genel süreç şöyle ilerledi:
    • Önce yaklaşık 10 örnek dosya üzerinde çalıştırıp farklar ciddi biçimde azalana kadar tekrarladım
    • Sonuç tatmin edici hale gelince bunu tüm yazılara uyguladım; her şey yaklaşık 30 dakikada otomatik işlendi
    • Buradaki kilit nokta, LLM'in dönüşümü gerçekten 'başarmış' olması değil; tüm süreci "kod" üzerinden doğrulayıp inceleyebilmem sayesinde buna güvenebilmemdi
  • Buna ek olarak, başka bir LLM'e üretilen kodu ve yapılan değişiklikleri inceletip açıklattım; böylece daha yüksek güven elde ettim
    • Veri kaybı olmadan, mekanik olarak doğru dönüştürüldüğüne emindim ve istediğim anda örnek kontrolü ya da düzeltme yapabiliyordum
    • En kötü durumda bile sadece Markdown sözdiziminde küçük hatalar oluşuyordu; asıl metnin bozulması gibi bir durum yaşanmadı
  • Bir diğer önemli nokta da şu: Bu yaklaşımda çıkarım (inference) maliyeti sabit olduğu için toplam dosya sayısının (15 mi 150 mi) yük üzerinde büyük fark yaratmaması
    • Son analiz aşamasında küçük farklar zaten otomatik atlandığından, büyük ölçekli dönüşümlerde tekrarlı doğrulama yükü de büyümüyor

MCP Bunu Yapamaz

  • Bu uzun anlatımın özü şu: Tüm dönüşüm ve otomasyon hattı "kod" ile çalışıyor
    • İnsan girdisi → kod üretimi → LLM denetimi → tekrarlı iyileştirme; bu yapıyı genel görevlerde de aynı şekilde uygulayabilirsiniz
  • Örneğin MCP yaklaşımının tipik örneklerinden biri Playwright
    • Bu, tarayıcıyı uzaktan kontrol eden bir otomasyon aracı; sayfayı okuyup anlamak, düğmelere basmak gibi şeylerde her adımda tekrar tekrar çıkarım gerekiyor
    • Bu tür görevleri pratikte "kod yaklaşımıyla" tamamen ikame etmek her zaman kolay değil
  • Ama sayfa yapısını zaten biliyorsanız (ör. geliştirdiğim kendi uygulamamın testi gibi)
    • LLM'e Playwright Python betiği yazdırıp onu çalıştırmak çok daha hızlı ve daha güvenilir
    • Bu yaklaşımda bir kez betik oluşturduktan sonra onlarca, yüzlerce kez tekrar çalıştırabilirsiniz ve ek çıkarım gerekmez
    • Ekranı her seferinde gerçek zamanlı yorumlamaya veya düğmenin yerini bulmaya gerek kalmaz; tüm otomasyon akışını tek seferde çalıştırabilirsiniz
  • MCP yaklaşımı her adımda soyut araç çağrıları ve çıkarım gerektirdiği için, LLM'in her zaman doğru davranmasını sağlamak çok zordur; hata ayıklamak da güçtür
    • Örneğin bir MCP istemcisini shell script içine gömüp uzak servis çağrılarını verimli yapmak isteseniz bile, bunun gerçekte oldukça verimsiz ve uygulanması zor olduğunu fark edersiniz
  • Sonuçta, ben bir insanım; MCP istemcisi değilim
    • Kodu çalıştırmak ve hata ayıklamak kolaydır; MCP çağrıları ise her seferinde belirsizdir ve güvenilmez
    • Gerçekte ise LLM'in kod üretirken oluşturduğu küçük araçları (ör. Claude Code snippet'ları) geliştirme sürecimde uzun vadeli araçlar olarak daha çok kullanıyorum

Bu Sonuç Bizi Nereye Götürüyor?

  • Açıkçası bu akışın nereye varacağını ben de bilmiyorum. Ama tam da şimdi, "kasıtlı ajanik kodlama (agentic coding)" için kod üretimi yaklaşımını nasıl daha da geliştirebileceğimizi düşünmek için iyi bir zaman
  • Kulağa tuhaf gelebilir ama MCP bazen gerçekten çok iyi çalışabiliyor. Yine de mevcut yapı fazlasıyla "çıkarıma" dayanıyor ve ölçeklenebilir büyük otomasyon için uygun olmayan bir çıkmaz sokak gibi görünüyor
  • Bu yüzden muhtemelen MCP'nin güçlü olduğu alanlarla kod üretimi yaklaşımının rolünü daha net ayırıp soyutlamanın yollarını bulmamız gerekiyor
    • Bunun için daha iyi sandbox'lar (güvenli çalıştırma ortamları) kurmak ve ajanın API'ler üzerinde serbestçe "fan out/fan in" çıkarımı yapabilmesini sağlayacak API tasarım değişiklikleri denemek de gerekli
    • "Kodla yapılabilecek her şeyi mümkün olduğunca kodla yapmak" ve büyük hacimli çalıştırmalardan sonra LLM'in toplam sonucu değerlendirip incelemesi daha doğru bir yapı gibi görünüyor
  • Ayrıca kod üretimi sırasında yeterli bağlam bilgisi de eklenirse, LLM'in üretilen betiğin ne yaptığını geliştirici olmayanlara doğal dille açıklayabilmesi mümkün olur; böylece bu otomasyon akışları gelecekte geliştirici olmayanlar tarafından da kolayca kullanılabilir
  • Sonuç olarak, MCP yerine LLM'in kod üretme yeteneğini daha cesur biçimde kullanmayı ve yeni olasılıkları denemeyi öneriyorum
  • LLM'in doğrudan kod yazmasına izin verirseniz, hayal ettiğimizden çok daha fazla şeyi otomatikleştirebiliriz

Referanslar

İlgili okumalar

2 yorum

 
bluems 2025-07-04

Katılıyorum ama bunun MCP sorunu olmaktan çok, onu yapanların tasarım yönünü nasıl optimize ettiğine dair bir mesele olduğunu düşünüyorum. Aynı işlevi görse bile, hangi MCP olduğuna bağlı olarak içeride kod ve komut üretilip gereksiz işler azaltılabiliyor. Github mcp yerine gh cli mcp ya da terminal mcp kullanılırsa token yine harcanır ama çok daha az kullanılır ve aynı etki elde edilebilir; sanırım bu nokta gözden kaçmış.
 
GN⁺ 2025-07-04
Hacker News görüşleri

  • Genel olarak bu yönelimin doğru olduğuna katılıyorum. Büyük ölçekli LLM kullanımı çoğunlukla iki sağlam arayüz arasındaki boşluğu doldurmak için kullanılıyor. Güvenilirliğin özü LLM çıktısından değil, aslında bu arayüzlerin yalnızca belirli ayarlara izin vermesinden geliyor.
    LLM çıktısı çoğu zaman tip ya da DB primary key gibi daha deterministik değerlere zorla dönüştürülüyor. LLM’in değeri, mevcut kod ve araçların benim alanımdaki veri, mantık ve davranışları ne kadar iyi modellediğine büyük ölçüde bağlı.
    Şahsen bugünlerde LLM’leri 3D yazıcılara benzetiyorum. İkisi de hızlı prototipleme sırasında parçaları hızla birleştiriyor ama ölçeklenebilirlik ve sağlamlık istiyorsanız, sonunda mühendislerin ya da LLM’lerin bu geçici bağlantıları metal/kod gibi deterministik desteklerle değiştirmesi gerekiyor.
    Geçmişte 3D yazıcılara yüklenen abartılı beklentiler gibi, LLM’ler de tüm operasyonel gerçekliğin yerini alabilecekmiş gibi görünüyor; ama gerçekte ancak mevcut dijital modelleme sağlam bir temel olduğunda gerçekten faydalılar

    • Drone’lar ve VR için yaşanan abartılı hype cycle da benzerdi. Herkes drone’ların paket teslim edeceğini, VR’da bütün gün yaşayacağımızı söylüyordu ama gerçek kullanım alanları çok daha dardı
    • İlginç bir görüş ama LLM’ler konusunda fazla muhafazakâr bir bakış gibi geliyor. Gerçekte LLM’ler zaten derin araştırma veya çeviri gibi alanlarda büyük ölçekte kullanılıyor ve 3D yazıcılardan daha genel amaçlı biçimde yayılmış durumdalar
    • "Yönelim doğru" ifadesine katılıyorum. Bizim şirkette de tam isabetli olmasa bile sık sık 'directionally accurate' terimini kullanıyoruz. Kabaca doğru yöne işaret ettiği anlamına geliyor

  • LLM araçlarını kullanırken fark ettiğim bir şey var. Problemi sandbox içinde araçları tekrarlı kullanarak LLM’in çözebileceği bir forma indirgerseniz, bu problemi brute force ile çözebilirsiniz. Buradaki kritik nokta, bu tür problemleri tespit etmek ve uygun sandbox’ı, kullanılacak araçları ve başarı kriterlerini belirlemek.
    Bu süreç de ciddi beceri ve deneyim gerektiriyor ama her şeyi elle deneme-yanılma ile yapmaktan çok daha üst düzey bir iş.
    Bunu 'assembly Mandelbrot deneyi' yaparken fark ettim.
    (deney bağlantısı: https://simonwillison.net/2025/Jul/…)

    • En sonda mutlaka başarı kriterini tanımlamak gerekiyor. Fraktal matematiğini ya da x86 assembly bilmiyorsanız, "görüntü Mandelbrot’a benziyor mu?" şeklindeki görsel kontrolün ötesinde doğrulama yapamazsınız.
      İdeal olarak sürekli bir fonksiyon biçiminde değerlendirme ölçütü, en azından da çeşitli girdiler ve bunlara karşılık beklenen çıktılar nicel biçimde tanımlanmalı ki gerçek otomasyon mümkün olsun
    • Bu deney gerçekten çok ilginç. Ben de LLM ile brute force problem çözmeyi düşünüyordum.
      Örneğin LLM’ler TypeScript generic’lerinde zayıf ama gerçek TSC çalıştırılırsa, testlerle sürekli doğrulayıp doğru olana kadar denemeye devam edebilir. Kodun bakım yapılabilirliği düşebilir ama teoride çok ilginç bir yapı.
      Üstelik Cursor TypeScript hatalarını görebildiği için, yalnızca utility type testleri hazırlanırsa Cursor testleri kendisi yazıp problemi basit tekrarlarla brute force çözebilir
    • Benim deneyimime göre LLM’e işe uygun araçları kullandırmak hâlâ büyük bir zorluk. Bir çocuğa çamaşır yıkamayı öğretmek gibi; çoğu zaman kalkıp kendim yapmak istiyorum
    • LLM’e doğru bağlamı sağlamak önemli. Örneğin önceden tanımlı "bilişsel araçlar" kullanılarak bağlam zenginleştirildiğinde performans belirgin biçimde artıyor.
      Bakmaya değer rapor: https://github.com/davidkimai/Context-Engineering/…
      Henüz tamamını okuyamadım ama oldukça etkileyici
    • Sandbox içinde araç döngüsü çalıştırma yönteminin, cloud API üzerinde çok token harcamayı gerektirip gerektirmediğini merak ediyorum.
      Bunun yerel modellerle de mümkün olup olmadığını ya da Claude Code Pro gibi aboneliklerle yapılıp yapılamayacağını düşünüyorum.
      Mandelbrot deneyi eğlenceliydi ama gerçek, karmaşık ticari kod tabanlarıyla zorluk seviyesi biraz farklı

  • Bunun MCP’nin kendisine özgü bir sorun olduğunu düşünmüyorum. Mevcut AI seviyesinde insanın arada olduğu yapı çok daha üstün.
    LLM’ler belirli işlerde güçlü ama sık sık yerel minimumlara takılıyor. Bu yüzden web arayüzünde gidip gelerek "program yaz → kontrol et & ipucu ver → test et" döngüsü kurulduğunda kalite belirgin biçimde artıyor.
    10.000 satırlık dağınık kodu 400 satırlık net koda dönüştürebiliyorsunuz. Şu an için gerçek bu.
    Elbette birçok şirket veya geliştirici "programcının kendisini LLM ile değiştirmeye" çalışacaktır ama pratikte bu henüz mümkün değil.
    Gerçek etki, programcıların çalışma hızını birkaç kat artırmakta ya da yeni başlayanların LLM sayesinde hızla üretken işler yapabilmesinde ortaya çıkıyor. Ama "agentic coding" henüz iyi çalışmıyor.
    Mevcut durumda LLM’leri iş arkadaşı ya da yardımcı olarak kullanmak doğru yaklaşım. Bugünün gerçeği, bunların özerk geri bildirimi olan "AI ajanları" olmadığı

    • Ben de kendi ürününü geliştiren bir ürün geliştiricisiyim; bütün kodla tek başıma ilgileniyorum ve claude-code’u araç olarak kullanıyorum. Bir gün Claude’un tüm kodlamanın yerini almasını umuyorum ama daha orada değiliz.
      Type-safe, fonksiyonel ve derlenen bir dilde çalıştığım için çıktıyı her zaman kendim okumam gerekiyor; daha az katı bir dil olsa daha da fazla endişelenirdim.
      Buna rağmen zaman kazancı büyük. Özellikle işleri parçalara ayırıp büyük hedefleri daha kolay ele alabilir hâle gelmekten memnunum

  • Gerçekten de GitHub MCP ile görev yaptığınızda, aynı işi gh CLI ile yapmak bağlamı çok daha verimli kullandığı için çok daha hızlı oluyor.
    Benim "devops" klasörümde CLAUDE.md dosyası var (ortak bash komutları derlemesi).
    Yeni bir görev tamamlandığında Claude’dan örnek eklemesini istiyorum; sonrasında benzer sorgularda Claude işi tek seferde çözüyor.
    CLAUDE.md’nin başlangıç içeriğini paylaşıyorum:

    • Bu dosya Claude Code’a kod çalışmaları sırasında yönergeler sağlar
    • Özellikle GCP ile ilgili DevOps komutlarını (Cloud Composer, Logging, Kubernetes, Cloud Run) belgeler
    • Başlıca komut örnekleri: ortam ayrıntılarını görüntüleme, DAG yönetimi, Airflow loglarını kontrol etme vb.
      (belirli komutlar özetlendi)
    • Bazen kafam karışıyor. Gerekli komutlar derlemesini içeren bir dosya zaten varken sadece AI’ın bunları çalıştırmasını beklemek verimsiz geliyor
    • Bu arada, o komut bölümlerini basit bir stdio MCP sunucusu hâline getirip Claude Code’a bağlarsanız her görevi araçlaştırabilir ve girdi şemasını da tanımlayabilirsiniz. Bunu zaten destekleyen açık kaynak bir MCPServer var (örnek: https://github.com/inercia/MCPShell)
    • Ben de benzer komut derleme dosyalarını doğrudan Emacs org-mode içinde tutuyorum. Katlayıp açmak kolay olduğu için verimli ve kod parçacıkları (shell, elisp vb.) doğrudan çalıştırılabiliyor
    • LLM’e production/test ortamlarında ayrıcalıklı API çağrıları yapma yetkisini doğrudan mı verdiğinizi, yoksa yalnızca sanity check yapılabilir örnek komutlar mı aldığını merak ediyorum. Somut kullanım senaryolarını merak ettim
    • Ben de benzer bir yapıyla ilerledim ama claude.md giderek büyüyüp rahatsız edici hâle geldi. Bunun üzerine özel prompt’ları uygulamalaştırdım ve durum iyileşti; fakat uygulamalar deterministik olduğu için bilinmeyen durumlarda başa çıkmak zor oluyor. Buna karşılık CC yavaş olsa da bilinmeyen durumlarla da baş edebiliyor.
      Böylece sorun çıktığında komuta uygulamayı test etme ve düzeltme adımları ekleyen bir self-healing software ortaya çıktı

  • Şimdiye kadar gördüğüm MCP kullanımları içinde en etkileyici olanı gerçekten Bruce Hauman’ın clojure-mcp’siydi.
    LLM’e (a) bash, (b) kalıcı Clojure REPL, (c) yapısal düzenleme araçları sunuyor.
    Bu sayede Clojure kodu düzenlerken, saf metin diff tabanlı yaklaşıma göre çok daha verimli çalışıyor.
    Uygun bir test paketi de varsa dosya düzenleme, yeniden yükleme ve test tekrarları insanın çalışma biçimine çok yakın ilerliyor; bu beni şaşırttı

    • Bence de clojure-mcp şimdiye kadar gördüğüm MCP örnekleri arasında en havalı kullanım.
      Kod debug etme, tek tek ifadeleri değerlendirme, fonksiyon dönüş tiplerini belgeleme gibi temel özellikleri destekliyor.
      Güçlü bir REPL’i olan dillerin bu tür işlerde çok daha üstün olduğunu hissettim ve clojure-mcp’nin neler yapabildiğini görünce AI hakkındaki izlenimim ciddi biçimde değişti
    • Resmî repo bağlantısı da şu: https://github.com/bhauman/clojure-mcp

  • GitHub CLI örneği MCP’nin güçlü yanlarını tam göstermiyor.
    gh CLI gibi belgelerine erişimi iyi olan araçlar için LLM kolayca kod üretebildiğinden, doğal olarak onları daha iyi kullanıyor.
    Ama MCP’nin gerçek avantajı, kurum içi araçlarda veya çevrimiçi dokümantasyonu neredeyse olmayan niş API’lerde ortaya çıkıyor.
    Tüm dokümantasyonu bağlama koymak da bir yöntem ama bu gibi durumlarda MCP daha verimli olabiliyor.
    İyi tasarlanmış bir MCP aracı doğru girdilerle kullanıldığında, LLM’in API’yi anlama, kimlik doğrulama ve edge case yönetimi yükü büyük ölçüde azalıyor.
    GitHub için MCP’ye belki gerek yok ama şirket içi/eksik belgelenmiş API’lerde önceden hazırlanmış MCP araçları çok daha güçlü sonuç veriyor

    • MCP de sonuçta dokümantasyonu LLM giriş bağlamına enjekte etme yaklaşımı. LLM’in zaten iyi bildiği ortamlarda (Python, JavaScript, bash vb.) MCP aracı çağırmak yerine bildiği yöntemleri kullanmak daha iyi; hatta araç tanımları bağlamı daha da tüketiyor.
      Örneğin sonnet4’te 15 aracı geçince sınırlarına dayanıyorsunuz. Yalnızca resmî playwright MCP bile araç kapasitesinden yiyor
    • MCP sunucusu kimlik doğrulama gibi işleri basitleştiriyor ama buna karşı şu da söylenebilir: iç API en baştan niye böyle tasarlanmadı?
      Sonuçta MCP’nin tek avantajı, API fazla zor hissettirdiğinde "aslında gereksiz yere karmaşıktı" gerçeğini yeniden doğrulamaya yarıyor olabilir

  • Playwright örneğiyle ilgili olarak,
    ben de bu hafta Playwright MCP sunucusu tabanlı bir ajan kurdum ama yavaş, token açısından verimsiz ve güvenilirliği düşük bulduğum için tekrar doğrudan Playwright çağrılarına döndüm.
    MCP sunucusu nelerin mümkün olduğunu test etmek için iyi ama pratikte API çağrısı daha verimli ve daha kararlı.
    Kendi yaptığım kişisel LinkedIn ajanı örneğini ve demosunu paylaşıyorum:

    • Playwright MCP uygulaması da bana göre aşırı bir çözüm olmuştu. Hatta daha çok Playwright API’sinin bazı parçalarının sınırlı biçimde yeniden yapılmış bir referans uygulaması gibi geliyor.
      LinkedIn’in otomasyonu çok zor bir platform olarak ünlü olduğu düşünülürse, kişisel bir LinkedIn ajanı yaparken ne tür zorluklar veya sınırlamalarla karşılaştığınızı merak ediyorum

  • Aslında terminal tek başına yeterli gibi geliyor.
    Aylar boyunca her gün MCP kullandım ama artık yalnızca tek bir iTerm2 tabanlı MCP sunucusu (terminal) kullanıyorum.
    Gerektiğinde OpenAPI spec mevcut ama pratikte shell command ve curl ile neredeyse her şeyi yapabiliyorsunuz

    • Ben de LLM’in bash shell’in yerleşik araçlarını kullandığını görünce, bash’in sınırlarının nerelere kadar uzandığını ilk kez fark ettim

  • "Çok fazla bağlam gerekiyor" eleştirisi aslında sadece başlangıç prompt’unun varsayılanlarını doğru ayarlayarak çözülebilir.
    Claude Code ya da Gemini CLI dâhil başlıca araçların hepsi bunu destekliyor
    LLM’e tüm araç listesini verip kendi kendine elemesini beklemek en iyi yaklaşım değil ama
    en yeni LLM’ler sürekli gelişiyor ve açıkçası uygun MCP fonksiyonunu seçme konusunda ciddi bir sorun yaşamadım.
    Maliyet, hız ve güvenilirlik sorunlarına gelince

    • Maliyet: Son dönemde giderek ucuzluyor. Gerçekten şaşırtıcı bir fiyat/performans var.
    • Hız: Birden fazla işi aynı anda yaptırabildiğiniz için verimsiz değil.
      Sohbete doğrudan zaman harcamanız da gerekmiyor
    • Güvenilirlik: Büyük ölçüde prompt kalitesine bağlı.
      Yakın zamanda Notion, Linear, git, GitHub PR/CI logları gibi çok sayıda dış aracı LLM otomatik yönetti ve
      ben yalnızca tek bir PR incelemesi yaptım.
      Maliyet de 1 doların altındaydı
    • MCP araçları arttıkça başlangıç prompt’unda tüketilen bağlam da büyüyor.
      Hatta araç ekledikçe başlangıçta gereken bilgi miktarı artıyor ve bu ciddi bir sınıra dönüşebiliyor
    • Maliyet meselesinde, aslında giderek ucuzlamasından çok
      maliyetlerin şimdilik gizlenmiş olması söz konusu; ücretsiz ve düşük ücretli promosyon yapıları uzun ömürlü olmaz.
      Örneğin Cursor’da aylık 200 dolarlık plan geldi ve düşük fiyatlı planların hizmet kalitesi düştü.
      Ücretsiz promosyonlar bitince her şey asıl seviyesine dönecek

  • Ben Julia ile çalışıyorum ve uzun süre çalışan oturum ortamından fayda görüyorum.
    Fonksiyon ilk çalıştırmada derlendiği için, MCP oluşturarak Claude Code’un kalıcı bir Julia kernel’ına (Jupyter) kod göndermesini sağladım.
    Test kodunu çalıştırmak çok daha hızlandı ve CC, özel yazılmış bash komutları yerine kod tabanındaki mevcut fonksiyonları daha iyi kullanmaya başladı.
    CCUsage ölçümüne göre token kullanımı da neredeyse %50 azaldı.
    Bunun ille de MCP olması gerekmiyordu belki ama ana fikir şu: belirli bir yeteneği kod tabanına bağlamak, Claude için tek tek özel kod yazmaktan daha kolay

    • "Claude’un özel bash yerine doğrudan kod fonksiyonlarını çalıştırmayı" seçmesinin tek sebebinin, kernel’a doğrudan kod gönderebilmesi olup olmadığını merak ediyorum