52 puan yazan GN⁺ 2025-10-18 | 12 yorum | WhatsApp'ta paylaş
  • Anthropic’in duyurduğu Claude Skills, modelin belirli görevleri yerine getirirken ihtiyaç duyduğu talimatları, betikleri ve kaynakları klasör biçiminde sunan yeni bir desen; bu sayede göreve özgü uzmanlık dinamik olarak yükleniyor
  • Skills, Markdown dosyaları ve isteğe bağlı betiklerden oluşuyor; oturum başında her becerinin yalnızca meta verisi birkaç düzine token ile yükleniyor, tam içerik ise yalnızca gerçekten gerektiğinde çağrılıyor; bu da token verimliliğini çok yükseltiyor
  • Claude Code sayesinde Skills, basit bir kodlama aracının ötesine geçerek genel amaçlı bir otomasyon ajanına dönüşüyor; dosya sistemi ve komut çalıştırma ortamı olduğu sürece çok çeşitli görevler otomatikleştirilebiliyor
  • MCP’den farklı olarak Skills, bir protokol değil; Markdown ve YAML tabanlı basit bir yapı. Bu nedenle başka modellerde veya araçlarda da hemen kullanılabiliyor, paylaşımı ve yayılması kolay oluyor
  • Bu sadelik ve verimlilik sayesinde Skills ekosisteminin MCP’den çok daha hızlı büyümesi bekleniyor; veri gazeteciliğinden marka kılavuzlarına kadar pek çok alanda uzmanlaşmış ajanlar kurulabiliyor (MCP’nin token tüketimi sorunundan ve karmaşık spesifikasyonlarından kaçınılabiliyor)

Skills’in kavramı ve yapısı

  • Anthropic, 16 Ekim 2025’te Claude Skills özelliğini resmen duyurdu
    • Modelin belirli görevleri (ör. Excel işlemleri, bir kurumun marka kılavuzuna uyum) yerine getirirken ihtiyaç duyduğu talimatları, betikleri ve kaynakları içeren klasör düzeyinde bir yetenek genişletme sistemi
    • Claude, yalnızca görevle ilgili olduğunda ilgili skill’e erişerek uzmanlaşmış görev yürütme becerisini artırıyor
  • Resmî skill örnekleri anthropic/skills GitHub deposunda sunuluyor
  • Skills kavramsal olarak son derece basit
    • Özünde, modele görevin nasıl yapılacağını anlatan bir Markdown dosyası var
    • İsteğe bağlı olarak ek belgeler ve önceden yazılmış betikler eklenerek görevin tamamlanması destekleniyor
  • Eylül ayında duyurulan Claude’un belge üretim özelliği aslında tamamen Skills ile uygulanmış
    • .pdf, .docx, .xlsx, .pptx dosya işleme becerileri açık depoda görülebiliyor

Token verimliliği: Skills’in temel avantajı

  • Oturum başında Claude, mevcut tüm skill dosyalarını tarıyor ve her skill’in frontmatter YAML içindeki kısa açıklamasını okuyor
  • Her skill’in başlangıçta kapladığı token miktarı yalnızca birkaç düzine, yani son derece verimli
  • Ancak kullanıcı, bir skill’in yardımcı olabileceği bir görev istediğinde tüm ayrıntılar yükleniyor
  • Bu, yalnızca diske dosya kaydetmenin ötesine geçip bunu gerçek bir özelliğe dönüştüren temel fark

Slack GIF oluşturma skill’iyle pratik örnek

  • slack-gif-creator skill’inin meta veri açıklaması
    • Slack için optimize edilmiş animasyonlu GIF oluşturma araç seti
    • Boyut kısıtı doğrulayıcısı ve birleştirilebilir animasyon bileşenleri içeriyor
    • “X’in Y yaptığı Slack GIF’i oluştur” gibi isteklerde kullanılıyor
  • Gerçek test süreci
    • Claude mobil web uygulamasında Sonnet 4.5 modeliyle slack-gif-creator skill’i etkinleştirildi
    • “Make me a gif for slack about how Skills are way cooler than MCPs” istemi girildi
    • Claude otomatik olarak GIF oluşturdu (kalitenin iyileşmesi gerekiyor ama skill’in yinelenerek geliştirilmesi kolay)
  • Oluşturulan Python betiğinde dikkat çeken noktalar
    • Skill dizini Python yoluna ekleniyor: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
    • Skill’in core/ dizinindeki GIFBuilder sınıfı kullanılıyor
    • Dosya /mnt/user-data/outputs/ içine kaydediliyor
    • Slack boyut sınırı (2MB) doğrulama fonksiyonu check_slack_size() ile kurallara uyum kontrol ediliyor
    • Boyut aşılırsa model otomatik olarak daha küçük bir dosya üretmeyi tekrar deneyebiliyor

Skills’in ortam bağımlılıkları

  • Skills mekanizmasının tam çalışması için modelin şunlara erişebilmesi gerekiyor
    • Dosya sistemi
    • Dosya sistemi gezinme araçları
    • Ortam içinde komut çalıştırma yeteneği
  • Bu, LLM araçlandırmasında yaygın bir desen
    • ChatGPT Code Interpreter, 2023 başında bunun ilk büyük ölçekli örneğiydi
    • Ardından Cursor, Claude Code, Codex CLI, Gemini CLI gibi kodlama ajanı araçlarıyla yerel makinelere yayıldı
  • Bu gereksinim, MCP, ChatGPT Plugins ve önceki LLM yetenek genişletme girişimlerinden en büyük farkı oluşturuyor
  • Bu önemli bir bağımlılık olsa da, kilidini açtığı yeni yeteneklerin ölçeği şaşırtıcı derecede büyük
  • Güvenlik konusu hâlâ önemli
    • Güvenli bir kodlama ortamı sağlamak gerekiyor
    • İstem enjeksiyonu gibi saldırıların etkisini kabul edilebilir düzeyde sınırlayacak sandbox ortamlarının nasıl kurulacağına ihtiyaç var

Claude Code: genel amaçlı ajana evrim

  • Yazar, 2025 Ocak ayında “ajanlar”ın başarısız olacağını öngörmüştü; ancak tamamen yanıldı
    • 2025, fiilen “ajanlar”ın yılı oldu (çeşitli tanımlar olsa da burada tanım, “tools in a loop”)
  • Claude Code yanlış adlandırılmış
    • Saf bir kodlama aracı değil, genel amaçlı bir bilgisayar otomasyon aracı
    • Bilgisayara komut vererek başarılabilecek her türlü işi otomatikleştirebiliyor
    • Onu tanımlamanın en uygun yolu genel amaçlı ajan (general agent)
  • Skills, bu olasılığı çok daha net ve açık hâle getiriyor
  • Uygulama alanları baş döndürücü derecede geniş
    • Veri gazeteciliği örneği: şu görevleri ele alan bir skill klasörü kurulabilir
      • ABD nüfus sayımı verisinin kaynağını ve yapısını anlama
      • Çeşitli biçimlerdeki verileri Python kütüphaneleriyle SQLite/DuckDB’ye yükleme
      • Veriyi S3 üzerindeki Parquet dosyaları veya Datasette Cloud tabloları olarak çevrimiçi yayımlama
      • Yeni veri kümelerinde ilginç hikâyelerin nasıl bulunacağını gösteren rehberlik (deneyimli veri muhabirlerinin talimatları)
      • D3 kullanarak temiz ve okunabilir veri görselleştirmeleri oluşturma
    • Sonuç: Sadece Markdown dosyaları ve birkaç Python betiği örneğiyle, ABD nüfus sayımı verilerinden hikâye bulan ve yayımlayan bir “veri gazeteciliği ajanı” kurulabiliyor

Skills ve MCP karşılaştırması

  • Model Context Protocol (MCP), Kasım 2024’te yayımlandıktan sonra büyük ilgi gördü
    • Her şirketin bir “AI stratejisi”ne ihtiyacı vardı ve MCP uygulaması duyurmak bu ihtiyacı karşılamanın kolay bir yoluydu
  • MCP’nin sınırları zamanla görünür hâle geldi
    • En kritik sorun token kullanımı
    • GitHub’ın resmî MCP’si tek başına on binlerce bağlam token’ı tüketiyor
    • Buna birkaç tane daha eklendiğinde LLM’in gerçekten faydalı iş yapacak alanı neredeyse kalmıyor
  • Yazar, kodlama ajanlarını ciddiye almaya başladıktan sonra MCP’ye olan ilgisini azalttı
    • MCP ile yapılabilen şeylerin neredeyse tamamı CLI araçlarıyla değiştirilebiliyor
    • LLM, cli-tool --help çağrısını nasıl yapacağını bildiği için kullanım talimatlarını açıklamak adına çok fazla token harcamaya gerek kalmıyor
    • Gerektiğinde bunu kendi başına çözebiliyor
  • Skills de aynı avantajlara sahip, hatta yeni bir CLI aracı yazmaya bile gerek bırakmıyor
    • Görevin nasıl yapılacağını anlatan bir Markdown dosyası bırakmanız yeterli
    • Yalnızca kararlılığı veya verimliliği artıracaksa ek betikler ekleniyor

Skills ekosisteminde patlayıcı büyüme beklentisi

  • Skills’in en ilginç yanlarından biri paylaşım kolaylığı
    • Birçok skill’in tek bir dosya olarak uygulanması bekleniyor
    • Daha gelişmiş skill’ler ise birkaç dosyadan oluşan klasörler olacak
  • Anthropic’in sağladığı kaynaklar
  • Yazar da Datasette eklentisi nasıl geliştirilir gibi skill fikirleri üzerinde düşünüyor
  • Diğer modellerde de kullanılabiliyor: Bu da Skills tasarımının başka bir avantajı
    • Skill klasörünü Codex CLI veya Gemini CLI’ye bağlayıp “pdf/SKILL.md dosyasını oku ve bu projeyi anlatan bir PDF oluştur” derseniz çalışıyor
    • Bunun için ilgili araç veya modelin skill sistemi hakkında yerleşik bilgiye sahip olması da gerekmiyor
  • Beklenti: Bu yılki MCP dalgasını sönük bırakacak kadar büyük bir Skills Kambriyen patlaması yaşanabilir

Sadelik asıl güç

  • Bazıları, Skills’in fazla basit olduğu ve gerçek bir özellik sayılmayacağı yönünde tepki gösteriyor
    • Birçok kişi zaten Markdown dosyalarına ek talimatlar koyup kodlama ajanlarına bunları okutma yöntemini deniyordu
    • AGENTS.md zaten iyi yerleşmiş bir desen ve içine “PDF oluşturmadan önce PDF.md’yi oku” gibi talimatlar eklenebiliyor
  • Yazarı heyecanlandıran şey tam da Skills tasarımının bu temel sadeliği
  • MCP, başlı başına kapsamlı bir protokol spesifikasyonu
    • Host, client, server, resource, prompt, tool, sampling, root, elicitation
    • Üç farklı aktarım yöntemi de içeriyor (stdio, streamable HTTP, başlangıçta SSE)
  • Skills ise Markdown + biraz YAML meta verisi + isteğe bağlı çalıştırılabilir betikler
    • LLM’in doğasına çok daha yakın: modele metni veriyorsunuz ve gerisini onun çözmesine izin veriyorsunuz
  • Skills, zor kısımları LLM harness’ına ve ilişkili bilgisayar ortamına dış kaynak olarak bırakıyor
    • Son birkaç yılda LLM’lerin araç çalıştırma yetenekleri hakkında öğrendiğimiz her şey düşünüldüğünde bu son derece akıllıca bir strateji

12 yorum

 
shakespeares 2025-10-19

Kodlama tarafında Claude Code kullanırken buna da entegre edilebilecek bir kısım olabilir mi diye düşünüyorum.
Şu anda da Claude.md içine rehberleri koyup ayrıntılı rehberleri ayrı ayrı bölerek ilerliyorum.

 
labeldock 2025-10-19

Az sayıda token ile çok iş yapmak için, prompt optimizasyonundan ziyade çoklu ajanlar ve özetlemeyi kullanarak bunu basitçe çözmek mümkün gibi görünüyor. Soruna katılıyorum, ancak çözüm yaklaşımının sınırlı kaldığını düşünüyorum.

 
savvykang 2025-10-18

Skills de token kullanmıyor mu? Eğer kullanıyorsa, token kullanımı sorunu yine ortaya çıkacak gibi görünüyor; o durumda buna nasıl yanıt verileceğinden pek emin değilim.

 
dnjstmxhs 2025-10-19

Görünüşe göre bağlama SKILLS.md dosyasının tamamı değil, en üstte aşağıdaki gibi önce sadece ad ve açıklama kısmı her zaman ekleniyor.


name: skill-creator
description: Etkili skill'ler oluşturma rehberi. Bu skill, kullanıcılar Claude'un yeteneklerini uzmanlaşmış bilgi, iş akışları veya araç entegrasyonlarıyla genişleten yeni bir skill oluşturmak (ya da mevcut bir skill'i güncellemek) istediğinde kullanılmalıdır.
license: Tam koşullar LICENSE.txt içinde

 
ds2ilz 2025-10-18

Claude Code ile çalışırken talimatları ya da kuralları sürekli bağlama beslemek gerekiyor; sonunda da token kullanımı ile bağlam arasında denge kurmayı düşünür hale geliyorsunuz. Sonra aklıma bir klasör oluşturup ayrıntılı içeriği oraya işlev bazında Markdown dosyaları olarak detaylıca yazmak, claude.md içine ise "şunu yapmak için buna bak" türünden bir sürü işaretçi koymak geldi; bu yöntem oldukça ucuza ve iyi çalıştı. Skills da sonuçta bunun gibi şeylerin bir araya getirilmiş hâli olacağına göre, epey kullanışlı görünüyor.

 
laeyoung 2025-10-19

Ve açıklandığı gibi bir skills marketplace de gelirse, sadece gerekli skill'leri alıp ihtiyaç olduğunda etkinleştirerek kullanmak bana göre oldukça iyi olabilir.

 
shakespeares 2025-10-19

Oo, özlü açıklama için teşekkürler.

 
[Bu yorum gizlendi.]
 
dnjstmxhs 2025-10-19

Bağlam yönetimiyle Claude Skills arasında nasıl bir ilişki olabilir? Ben de daha önce var olan Claude Code özel komutlarından ne farkı var ki? diye düşünmüştüm; ama dokümanları okudukça en büyük farkın, herhalde tek bir skill’in içine Python ya da JavaScript gibi script kodlarını dahil edip çalıştırabilmek olması gibi göründü bana.

 
[Bu yorum gizlendi.]
 
GN⁺ 2025-10-18
Hacker News görüşleri
  • Bana göre Claude Skills, RAG’in kullanıcı deneyimi açısından gereksiz yere zorlaştırıldığının bir kanıtı gibi görünüyor. Mesele teknik karmaşıklık değil, UX sorunu. Bu kısım düzgün çözülürse Claude Skills’in kendisi gereksiz hale gelebilir. Claude Skills’in MCP’ye göre daha iyi yanı, yapmasının kolay olması. Sadece yazarak oluşturulabildiği için herkes kullanabilir. Ama ortama çok bağımlı. Örneğin, çalışması için belirli araçlar gerekiyorsa bunu otomatikleştirmek adına sandbox kurulumu nasıl yapılacak? Hatta doğru sürümün kullanıldığından bile emin olmak zor

  • Şirket içinde benzer bir şeyi deniyoruz. Monorepo’muzdaki bağlam dosyaları fazla büyüdüğü için, işe göre kademeli yüklenen bir fragment ağacı kurduk. Bu bağlam belgeleri mevcut geliştirici dokümantasyonuna çok benziyor, ama gerçekte çok daha faydalı ve görev odaklı. Eskiden neden böyle belgeler üretemediğimizi merak ettiriyor.

    1. Geri bildirim döngüsü çok uzundu. Belge yazsanız da bunun etkili olup olmadığını ömrünüz boyunca öğrenemeyebilirdiniz; öğrenseniz bile bu yıllar sonra olurdu. Değişiklik yapsanız da A/B testi gibi şeyler mümkün değildi. Şimdi ise basitçe bağlam Markdown’u yazıp Claude’a kullandırarak anında iyileştirme yapmak mümkün
    2. Araçlar belge yazımının kendisini de kolaylaştırıyor. İyi dokümantasyon üretmek geçmişte her zaman zordu; örnekler, linkler, faydalı ek bilgiler eklemek çok zaman alırdı, şimdi araçlar sayesinde maliyet düştü
    3. Geliştiricilerin arasında bencil insanlar da çok. Başkaları için yazılan belgeler çok motive etmiyor ama AI’yı daha iyi yönlendirmeyi sağlayan belgeler olunca kişi kendiliğinden motive oluyor Başka teorileri olan var mı merak ediyorum
    • Bu aslında marshmallow test tarafı da olan bir principal-agent problemi. Geliştiriciler AI için değil de başka insanlar için belge yazdığında, o kişinin kim olduğunu, neye ihtiyacı olduğunu, hatta o belgeye bakıp bakmayacağını bile bilmiyor. Elbette ileride kendilerine de faydası olabilir ama bunu kavramak ya da buna zaman ve disiplin ayırmak zor. Ama AI’nın bu belgeleri kullanıp bana doğrudan yardım ettiği bir durumda, gerekli bilgiyi kaydetmek için çok güçlü ve anlık bir motivasyon oluşuyor. Ayrıca geri bildirim döngüsü de kısalıyor. Bu arada, LLM’ler kod yorumlarını kolayca sildiği için bugünlerde daha çok dokümantasyon bırakıp yorumları ciddi biçimde azalttım

    • Yeni geliştiriciler, dokümantasyon kötü olsa bile aptal görünmek istemedikleri için pek şikayet etmiyor. Yazan kişi zaten kafasında modele sahip olduğu için sorunu kolay fark etmiyor ve iyi dokümantasyon yazmak da kendi işini riske atmak gibi görülüyordu. Ama kötü dokümantasyonu aptal bir robota verirseniz ve o başaramazsa, bu kez suçu kendinizde aramak zorunda kalırsınız. Sonuçta bence mesele #2 + #3. Büyük değişim, “yerinin alınabilirliği”nin negatiften pozitife dönmesi oldu (yerinizi ucuz bir ajana kaptırmadan önce kendinizi bir ajanla değiştirmek)

    • Teknik borcun var olma nedenine benziyor: iş baskısı, kötü tasarım, kaynak eksikliği. Eskiden kodu her değiştirişinizde iyi dokümantasyonu güncel tutmak gerçekten çok maliyetliydi

  • Bir klasörün içinde birden fazla skill olduğunu hayal et denince aklıma, ABD nüfus sayımı verilerinin nerede olduğu ya da yapısının nasıl yorumlanacağı gibi görevleri kapsayan bir durum geliyor. Bunu duyar duymaz Wolfram Alpha’yı ilk kullandığım zamanı hatırladım. Genel amaçlı arama motorlarından farklı olarak, gerçekten yapılandırılmış bir araçla problem çözebilmesinden çok etkilenmiştim. Şimdi yeniden denedim ve hâlâ etkileyici: Wolfram Alpha ile ABD nüfusunu sorgulamak. Kafamdaki Skills modeli, Wolfram Alpha’ya özel eklentiler eklemeye benziyor

    • Paylaştığınız linke tıkladım, Wolfram Alpha sorguyu what%27s the total population of the United States%3F olarak açıyor. Çıkan sonuç ilginç; 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates) görünüyor. Bunun nasıl hesaplandığını merak ettim

    • Dürüst olmak gerekirse, eski Wolfram Alpha gerçekten çılgınca bir başarıydı. O dönemde AI olmadan karmaşık matematik problemlerini bile ele alabilen bir sistemi nasıl kurduklarına hâlâ şaşıyorum

  • Skills ile mevcut araçlar arasındaki fark biraz kafamı karıştırıyor. Birçok skill aslında sadece bir araç gibi de görülebilir ya da birden fazla araç paketine eklenmiş açıklamalar gibi duruyor. Ama araç tanımıyla skill tanımı farklı yerlerde değil mi? İkisi arasındaki dependency nasıl ifade ediliyor merak ediyorum. Skill’de “komut satırı kullanılabilir, python, tool A, tool B gerekir” yazıyorsa, bu skill yüklendiğinde bu araçların da birlikte etkinleştiği anlamına mı geliyor?

  • Asıl dikkat çekici olan, herkesin MCP’ye aşırı takılıp yol bağımlılığıyla hareket etmiş olması. Asıl ilginç olan basitçe “tool call” kavramının kendisi. Tool call gerçekten çok kullanışlı ve etkileyici. MCP ise bunun için birçok araçtan sadece biri. Üstelik pek de üstün bir yöntem değil

    • Bence MCP’nin bu kadar yayılmasının sebebi tamamen zamanlamaydı. MCP’den önce de araç çağrımı vardı ama modeller bunu iyi yapamıyordu. MCP’nin ortaya çıktığı dönem tam olarak modellerin tool calling işinde iyi olmaya başladığı döneme denk geldi. Yani MCP çılgınlığının özü, insanların sonunda LLM’lerin başka sistemlerle etkileşim kurmak için araç çağırabildiğini fark etmesi oldu

    • MCP sunucusu aslında tool call’ları kaydeden bir registry. O halde sıradan tool call’dan daha kötü olan tarafı ne?

    • MCP’yi anlamlı kılan şey, LLM’lere oauth kavramını öğretmesi. Bu sayede sunucu tabanlı araç çağrımı mümkün hale geldi. Eskiden her CLI’ı tek tek kurmak ve kimlik doğrulamayı her birinin içinde ayrı ayrı yönetmek gerekiyordu. Tool calling’in LLM’lerin en büyük gücü olduğu doğru ama “araç kimlik doğrulamasını düşünmek gerekir” mesajını görünür kılması da bence oldukça değerliydi

    • Bu arada, MCP de Anthropic’in yenilik getirdiği bir özellikti

    • Skills’i bir kenara koysak bile, MCP’den daha iyi bir yaklaşım varsa bunun ne olduğunu merak ediyorum

  • MCP’nin etkisi terminalin çok ötesine uzanıyor. ChatGPT, Claude Web, n8n ve LibreChat’te de kullanılabiliyor; kimlik doğrulama, kaynaklar, hatta UI (apps-sdk vb.) bile düşünülmüş. Kodlama iş akışları ya da CLI tabanlı ajanlar (Claude Code gibi) merkezdeyse CLI araçları da çok değerli, ama CRM, satış, destek, operasyon, finans gibi alanlarda MCP tabanlı araçlar daha uygun bir form. Skills ve MCP rakip değil, birbirini tamamlayan amaçlara sahip. Özellikle de Skills içindeki Python kodu interpreter üzerinden doğrudan MCP çağırabildiğinde asıl sıçrama yaşanıyor (biz de denedik ve çok iyi çalışıyor)

    • MCP’nin terminal tabanlı araçlara kıyasla büyük avantajlarından biri, tamamen izole bir Linux ortamı gibi sandbox’lar olmadan da çalışabilmesi. Ayrıca çok daha basit modellerle de kullanılabiliyor. Dizüstünde hatta telefonda çalışan modeller bile iki üç MCP’yi rahatça yönetebilir. Açıkçası böyle modellere güvenilir biçimde dosya okutmak ve curl kullandırmak fazla zor

    • LLM’leri harici yazılımlarla ya da fiziksel dünyayla entegre etmek bugünlerde gerçekten çok havalı hissettiriyor. Üstelik bütün bunlar doğal dille yapılabiliyor. Hatta LLM’ler MCP sunucu kodunu da üretebildiği için yepyeni yetenekleri kolayca oluşturmak mümkün

  • Açıkçası MCP’nin abartıldığını ve sınırlarının da net olduğunu düşünüyorum. Mevcut MCP sunucularının %95’i işe yaramaz; basit tool call’larla rahatlıkla değiştirilebilir

    • Bu zaten açık ama iyi yapılmış MCP sunucuları gerçekten çok iyi. Buna karşılık kötü MCP sunucuları daha da ciddi sorunlar yaratıyor. Genelde tüm ürün ekipleri, sırf “MCP popüler” diye mutlaka bir MCP sunucusu yapmak zorundaymış gibi baskı görüyor. Müşterilerin de AI kullanımıyla ilgili mutlaka bir hedefi olduğu için bunları talep ediyorlar. Ama gerçekte ne istediklerini bilmiyorlar; sadece “AI eklendi” diyebilmek yetiyor. Böyle olunca ürün ekipleri de AI entegrasyonunun somut etkisi olmasa bile MCP sayesinde hızla “biz AI ürünüyüz” diye pazarlama yapabiliyor. Bu durum AI’nın özünden oldukça kopuk

    • MCP’yi kullanmak için sunucu sağlayıcısına güvenmek zorundasınız. Aslında tamamen sunucunun dürüstlüğüne bağlı. Gerçekte Uber gibi şirketler, LLM’in kendi hizmetlerini en iyi seçenek sanması için türlü prompt engineering yöntemleri kullanacaktır. Sonuçta MCP yayıncısı ile tüketicisi arasındaki teşvikler tamamen hizasız

    • Sonuçta asıl meselenin tool call olduğu konusunda katılıyorum. Ama MCP’nin CLI’a göre en az iki avantajı var. Birincisi, tool-calling LLM’in yapılandırılmış çıktı isterken karmaşık etkileşimler kurması gerektiğinde MCP bunun için CLI’dan daha kolay. İkincisi de, tool call’lar arasında state’i MCP sunucusunda doğal biçimde koruyabilmeniz. Başta ben de hype’a kapıldım mı diye düşünmüştüm ama son zamanlarda MCP öğrenmek için yaptığım küçük demo (https://github.com/cournape/text2synth) bunu CLI ile yapmaktan daha kolaydı; bence bu örnek, MCP’nin ilginç kullanım alanlarını iyi gösteriyor

    • MCP sunucuları hacker’lar arasında aşırı popüler gibi görünüyor. Kötü yapılandırılmış ve özensizce dağıtılmış instance sayısı çok fazla. Şirketler sanki mevcut dağıtım savunmalarının hepsini silmiş gibi

    • Bizim frontend ekibi figma MCP’den inanılmaz değer çıkardı. Üç hafta sürecek işi bir günde bitirebildik

  • Ben de birkaç Markdown dosyasıyla skills’e denk bir şey yaptım. Her oturumda bir kez ajana skill’i hatırlatmak yetiyor. Claude bunu yapıyor diye bunun neden özel sayıldığını pek anlayamıyorum

    • Bir örüntüye isim vermek önemli bir nokta. Zaten birçok kişinin doğal olarak keşfedip kullandığı faydalı bir örüntüydü; isim konunca daha üst düzey tartışmalar mümkün hale geliyor. Anthropic ayrıca bu örüntünün, kodlama ajanlarının kronik sorunu olan “context kirliliğini” çözmeye de yardımcı olduğunu fark etti. Eski AGENTS.md ya da MCP yaklaşımlarında bağlama fazla bilgi yüklenip pratiklik kayboluyordu; skills örüntüsü çok daha verimli

    • Sanki zaten çözülmüş bir problemi resmen yapılandırıp biraz daha otomasyon eklemişler gibi. Daha önce kullandığım MCP’lerin çoğu aslında sadece gösterişli bir belge arama işleviydi; bu tarz skills’in onların yerini almasını bekliyorum

    • Ben de aynı şeyi merak ediyorum. Bunu Aider ya da CC ile bir yılı aşkın süredir kullanıyorum

  • Bu biraz olumsuz gelebilir ama benzer hisseden var mı görmek istiyorum. Böyle hizmetleri ortalama kullanıcıya “gidip kendin kur” derseniz, onların “aklını mı kaçırdın?” demesi gayet normal. Çoğu insan sadece giriş yapmak, bir şey istemek ve sistemin geri kalanını kendi halletmesini istiyor. MCP, Apps, Skills, Gems gibi şeylerin hepsi problemi yanlış yerden tutuyor. Bu, YouTube’da her altı ayda bir “yeni programlama dili ya da framework en iyisi” deyip todo uygulaması yapan ve temelde aynı videoyu altı kez çekebilen kanallara benziyor. Sürekli yüzeysel ve tekrarlı iyileştirmeler var ama temel problem çözülmüyor. Teknoloji dünyasında bir yerde bir şeyler yanlış gidiyor gibi; para akınca bu tür duyurular yağıyor, sonra insanlar bir sonraki sürümü çıkarıp terfi ediyor, iş değiştiriyor ve geriye esaslı bir değer kalmıyor

    • Temel problemlerin çözülmediği iddiasına karşı şunu söyleyebilirim: bugünlerde çözümler paketin içinde yepyeni problemler de getiriyor. Kutuyu açınca problemle çözüm birlikte fırlayıp birbirini kovalamaya başlıyor. Bir de insana teknik olarak daha gelişmiş bir varlık olmuş hissi veriyor

    • MCP, Apps, Skills, Gems gibi şeylerin hepsinin yanlış probleme odaklandığı iddiasına dair, benim daha karamsar bakışım şu: Biz AI için daha fazla dokümantasyon ve API üretiyoruz ama bunları insanlar için dokümantasyon olarak üretmiş olsak da sonuç muhtemelen benzer olurdu. Zamanımın yarısı, dokümantasyonu olmayan karmaşık sistemleri debug etmekle geçti

    • “Temel problem” tam olarak ne ve 2023’te ChatGPT’nin yaygınlaşmasından önce bu tür “temel problemleri” çözme döngüsü ne kadardı, merak ediyorum

    • “Aynı todo uygulamasını altı kez yapıp sonra unutmak” örneğinde, bunun neden bir problem olduğunu pek anlamıyorum. Teknoloji zaten doğası gereği kademeli ve tekrarlı ilerliyor. Yarın birisi yine en iyi frontend framework’ü diye video çekecek; daha önce de aynı şey Nextjs, ondan önce React, Angular, JQuery, PHP, HTML için yapıldı. Eğer tüm yatırım AI’ya akmamış olsaydı muhtemelen hâlâ GPT-3 ya da Claude 2 düzeyinde kalmış olurduk. Araç tarafında zayıf şeyler çıkabiliyor tabii (ben Skills’in oldukça iyi olduğunu düşünüyorum), ama buna bakıp tüm sektörün çürüdüğünü söylemek bana doğru gelmiyor

    • Sonuçta her şey daha çok başlangıç aşamasında ve neyin gerçekten işe yarayacağını kimse bilmiyor. Yüzeysel denemeler gibi görünse de aslında bunlar en ileri uçta yapılan işler

  • Bu tamamen başka bir kavram. MCP harici servislere bağlanmayı, oauth gibi kimlik doğrulama işlerini de kapsıyor. Skills ise esasen CLI araçları + prompt birleşimi. Kullanım alanları farklı olduğu için doğrudan karşılaştırmak zor. Bu arada, MCP ortaya çıkmadan önce biz de Skillset adında bir sistem geliştirip kullanmıştık; şimdi dönüp bakınca bunun MCP ile Skills’in güçlü yanlarını birleştiren en iyi hibrit olduğunu düşünüyorum

 
github88 2025-10-18

Abartı gerçekten.