Agent Skills

• Agent Skills, yapay zeka kodlama ajanlarının spesifikasyon, test, incelenebilir PR ve güven sınırı incelemesi gibi kıdemli mühendislik süreçlerini atlayamaması için bunları iş akışıyla zorunlu kılan bir scaffold yapısıdır
• Skill frontmatter içeren bir Markdown dosyasıdır; bir referans dokümanından çok, adım sırası, kontrol noktası kanıtları ve tamamlanma kriterleri olan bir iş akışına yakındır
• Depodaki 20 skill; Define, Plan, Build, Verify, Review, Ship olmak üzere 6 yaşam döngüsü aşaması ile /spec, /plan, /build, /test, /review, /ship, /code-simplify olmak üzere 7 slash command'dan oluşur
• Temel ilkeler; düzyazı yerine süreç, anti-rasyonalizasyon tabloları, doğrulamayı tamamlanma kriteri saymak, kademeli görünür kılma ve kapsam disiplini olup using-agent-skills yalnızca işe uygun skill'leri etkinleştirir
• Claude Code marketplace kurulumu, Cursor .cursor/rules/, Gemini CLI, Codex, Aider, Windsurf, OpenCode gibi araçlara Markdown koyma yöntemiyle kullanılabilir ve MIT lisansı altında yayımlanmıştır

---

Amaç ve problem tanımı

• Agent Skills, yapay zeka kodlama ajanlarının varsayılan olarak atladığı kıdemli mühendislik süreçlerini iş akışlarıyla zorunlu kılmak için tasarlanmış bir scaffold yapısıdır
• Yapay zeka kodlama ajanları bir özellik istendiğinde genellikle işi en kısa yoldan tamamlamaya çalışır; spesifikasyon yazma, önce test yazma, güven sınırı incelemesi yapma, incelenebilir PR hazırlama gibi adımları varsayılan olarak yerine getirmez
• Kıdemli bir mühendisin işinde diff'te görünmeyen çok şey vardır
  • varsayımları görünür kılmak
  • spesifikasyon yazmak
  • işi incelenebilir parçalara bölmek
  • sıkıcı ama güvenli tasarım seçimleri yapmak
  • sonucun doğru olduğuna dair kanıt bırakmak
  • değişiklikleri insanların gerçekten inceleyebileceği boyutta tutmak
• Ajanların bu adımları atlamasının nedeni, junior mühendislerde olduğu gibi, ödül sinyalinin “iş tamamlandı”ya ayarlı olması ve “spesifikasyon dokümanıyla birlikte iş tamamlandı”ya ayarlı olmamasıdır
• Agent Skills deposu 26K yıldızı geçti; README'nin ötesine geçerek tasarım seçimlerinin nedenlerini, standart SDLC ve Google'ın açık mühendislik pratikleriyle eşleşmesini, hatta kurulum yapmadan alınabilecek kalıpları da ele alıyor

Skill'in pratikte ne anlama geldiği

• Skill, duruma göre ajan bağlamına enjekte edilen, frontmatter içeren bir Markdown dosyasıdır; sistem prompt parçası ile runbook arasında bir formdadır
• Skill bir referans dokümanı değildir; “test hakkında bilmeniz gereken her şey” gibi bir bilgi koleksiyonu da değildir
• Faydalı bir skill, ajanın takip ettiği bir iş akışıdır
  • adımların bir sırası vardır
  • kontrol noktalarında kanıt üretir
  • net tamamlanma kriterleriyle biter
• Test en iyi pratikleri üzerine 2.000 kelimelik bir denemeyi bağlama koyarsanız, ajan kulağa makul gelen cümleler üretebilir ve gerçek testleri atlayabilir
• Buna karşılık önce başarısız olan testi yazma, çalıştırıp başarısızlığını doğrulama, geçmek için gereken minimum implementasyonu yazma, geçtiğini doğrulama ve refactor etme şeklinde bir iş akışı koyarsanız, ajan için yapılacak somut işler oluşur ve insanlar da bunu doğrulayabilir
• Temel ayrım, düzyazı yerine süreç, referans yerine iş akışı, tamamlanma kriteri olmayan deneme yerine tamamlanma kriteri olan adımlardır
• Birçok “AI rules” deposunun pratikte etkili olmamasının nedeni, kuralların iş akışı değil deneme olarak kalmasıdır

SDLC ve slash command yapısı

• Depodaki 20 skill, 6 yaşam döngüsü aşamasından oluşur ve bunların üzerine 7 slash command yerleşir

• Aşamalar ve komutlar

  • /spec: ne inşa edileceğini belirleyen Define aşamasıdır
  • /plan: işi parçalara ayıran Plan aşamasıdır
  • /build: dikey dilimler halinde implementasyon yapılan Build aşamasıdır
  • /test: davranışı kanıtlayan Verify aşamasıdır
  • /review: gözden kaçan sorunları yakalayan Review aşamasıdır
  • /ship: kullanıcıya güvenli biçimde teslim eden Ship aşamasıdır
  • /code-simplify: tüm akış boyunca uygulanabilen sadeleştirme komutudur
  • Bu yapı, sağlıklı çalışan mühendislik organizasyonlarının SDLC akışıyla aynıdır; kurumlardan kuruma değişen şey yalnızca terminolojidir
  • Google'da bu akış design doc → review → implementation → readability review → launch checklist olarak, Amazon'da ise working-backwards memo ve bar raiser gibi pratiklerle görünür
  • Yapay zeka kodlama ajanlarının yeni problemi, çoğu ajanın bu aşamaların büyük kısmını varsayılan olarak atlamasıdır
  • Bir özellik istediğinizde yalnızca implementasyon gelir; spesifikasyon, plan, test, review ve yayın kontrol listesi gelmez
  • Skill'ler, kıdemli mühendislerin kendilerine zorunlu tuttuğu adımları ajana da uygular; bu süreçler olmadan kod dağıtmak arızalara yol açar
  • Karmaşık bir özellikte 11 skill sırayla etkinleşebilir; küçük bir bug düzeltmesinde yalnızca 3 skill kullanılabilir
  • using-agent-skills yönlendiricisi, mevcut işe hangi skill'lerin uygulanacağını belirler; iş akışı varsayılan kapsama göre değil gerçek kapsama göre genişler

Çalışmasını sağlayan ilkeler

• 1. Düzyazı yerine süreç

  • İş akışları ajanın eyleme dökebileceği şeylerdir; denemeler ise değildir
  • Aynı ilke insan ekipleri için de geçerlidir
  • Ekip el kitabınız 200 sayfaysa baskı altında kimse okumaz; ama kontrol noktaları olan küçük bir iş akışıysa gerçekten uygulanma ihtimali daha yüksektir

• 2. Anti-rasyonalizasyon tabloları

  • Agent Skills içindeki en ayırt edici ve başka ekiplerin de alması gereken tasarım seçimi anti-rasyonalizasyon tablolarıdır
  • Her skill içinde, ajanların ya da yorgun mühendislerin iş akışını atlamak için kullanabileceği yaygın bahaneler ve bunlara karşı önceden yazılmış yanıtlar bulunur
  • Örnekler şöyledir
    • “Bu iş spesifikasyon gerektirmeyecek kadar basit” → kabul kriterleri yine de geçerlidir. 5 satır olur ama 0 satır olmaz
    • “Testleri sonra yazarım” → sorun tam da “sonra”dır. Sonra diye bir şey yoktur. Önce başarısız olan testi yazmalısın
    • “Test geçti, hadi deploy edelim” → geçen testler kanıttır ama ispat değildir. Runtime kontrol edildi mi, kullanıcıya görünen davranış doğrulandı mı, bir insan diff'i okudu mu bunlara bakılmalıdır
  • LLM'ler rasyonalizasyon konusunda iyidir; belli bir işin spesifikasyon gerektirmediğine ya da belli bir değişikliğin review olmadan merge edilebileceğine dair kulağa makul paragraflar üretebilirler
  • Anti-rasyonalizasyon tabloları, ajanın henüz söylemediği yalanlara verilmiş önceden yazılmış yanıtlardır
  • Bu kalıp insan ekipleri için de geçerlidir
  • Mühendislik kalitesi çoğu zaman birinin bilinçli olarak kötü iş yapmaya karar vermesinden değil, yapılması istenmeyen bir süreci atlamaya yönelik makul görünen gerekçelerin kabul edilmesinden bozulur

• 3. Doğrulama pazarlığa kapalıdır

  • Her skill somut kanıtlarla sona erer
  • Testlerin geçmesi, temiz build çıktısı, beklenen davranışı gösteren runtime trace, reviewer onayı gibi unsurlar tamamlanma kriteridir
  • “Makul görünüyor” yeterli değildir
  • Bu, Anthropic'in harness'inin hatadan toparlanabilmesi, Cursor'ın planner/worker/judge ayrımının gerçekten bug yakalaması ve long-running agent'ların toparlanabilir hale gelmesiyle aynı ilkedir
  • Ajanlar üreticidir; dolayısıyla işin tamamlandığını anlamak için ayrı bir sinyale ihtiyaç duyarlar ve skill'ler bu sinyali her iş akışına gömer

• 4. Kademeli görünür kılma

  • Oturum başında 20 skill'in tamamı bağlama yüklenmez
  • Yalnızca mevcut aşama için gereken skill'ler etkinleştirilir
  • Küçük bir meta skill olan using-agent-skills, mevcut işe uygun skill'i seçen bir yönlendirici gibi davranır
  • Bu, harness engineering'den alınan derslerin skill düzeyine uygulanmış halidir
  • Bağlama yüklenen her token bir yerlerde performansı düşürür; bu nedenle yalnızca ilgili olanlar yüklenmeli, kalanı diskte kalmalıdır
  • Kademeli görünür kılma, 20 skill'lik bir kütüphaneyi 5K-token'lık bir alana tüm bağlamı kirletmeden sığdırmanın yoludur

• 5. Kapsam disiplini

  • Meta skill, “yalnızca isteneni değiştir” ilkesini pazarlığa kapalı biçimde kodlar
  • Bitişik sistemleri refactor etmemeli, tam anlamadığı kodu kaldırmamalı, bir TODO gördü diye tüm dosyayı yeniden yazmaya karar vermemelidir
  • Ajan, tek bir bug'ı düzeltmeye çalışırken ilgisiz 3 dosyayı da modernize etmeye kalkabilir
  • Kapsam disiplini, bir ajanın PR'ının merge edilebilir mi yoksa geri mi alınmalı sorusundaki en büyük belirleyicidir
  • Bu ilke, bir PR birden fazla iş yapıyorsa reviewer'ın bunu durdurabildiği Google kod inceleme normlarıyla da uyumludur

Google mühendislik pratikleriyle bağlantı

• Agent Skills, Software Engineering at Google ve Google'ın açık mühendislik kültüründen gelen çok sayıda pratiği yansıtır
• Google ölçeğinde yazılımı çalışır halde tutan birçok unsur kamuya açık biçimde belgelenmiştir ve ajanların en sık atladığı şeyler de tam olarak bunlardır

• Skill'ler ile pratiklerin eşleşmesi

  • api-and-interface-design: Hyrum’s Law ilkesini yansıtır. Bir API'nin gözlemlenebilir her davranışı sonunda birileri tarafından bağımlılık haline getirilir; tasarım buna göre yapılmalıdır
  • test-driven-development: ~80/15/5 test piramidini ve Beyoncé Rule'u yansıtır. İlke şudur: “Sevseydin test yazardın”; bug'ları altyapı değişiklikleri değil testler yakalar
  • Testlerde DRY yerine DAMP: Google'ın test felsefesi, test kodunun biraz tekrar içerse bile bir spesifikasyon gibi okunması gerektiğini savunur. Aşırı soyutlanmış testler bilinen bir anti-pattern'dir
  • code-review-and-quality: ~100-line PR boyutunu ve Critical / Nit / Optional / FYI ciddiyet etiketlerini yansıtır. Büyük PR'lar gerçekte incelenmez, kolayca göstermelik şekilde onaylanır
  • code-simplification: Chesterton’s Fence ilkesini yansıtır. Bir şeyin neden orada olduğunu anlamadan onu kaldırmamak gerekir
  • git-workflow-and-versioning: trunk-based development ve atomic commit yaklaşımını yansıtır
  • ci-cd-and-automation: Shift Left ve feature flag yaklaşımını yansıtır. Sorunlar mümkün olduğunca erken yakalanmalı, deploy ile release birbirinden ayrılmalıdır
  • deprecation-and-migration: code-as-liability yaklaşımını yansıtır. Koruduğunuz her satır sonsuza kadar bakım ister; bu yüzden daha küçük bir yüzey alanı tercih edilmelidir
  • Bu kavramlar yeni değildir, ancak ajanlara varsayılan olarak yüklü gelmez
  • Bir frontier model, eğitim verisinde “Hyrum’s Law” ifadesini görmüş olsa bile, sabah 3'te API tasarlarken bunu otomatik olarak uygulamaz
  • Skill'ler bu pratiklerin ajan tarafından gerçek iş sırasında uygulanmasını sağlar

Gerçek kullanım şekli

• Yöntem 1: marketplace üzerinden kurulum

  • Claude Code kullanıyorsanız şu komutlarla kurabilirsiniz

  /plugin marketplace add addyosmani/agent-skills
  /plugin install agent-skills@addy-agent-skills
  

  • Kurulumdan sonra /spec, /plan, /build, /test, /review, /ship, /code-simplify slash command'larını kullanabilirsiniz
  • Ajan, bağlama göre ilgili skill'leri otomatik etkinleştirir
  • Çoğu kullanıcı için başlangıçta önerilen yöntem budur

• Yöntem 2: Markdown'u istediğiniz araca koymak

  • Skill'ler, frontmatter içeren sıradan Markdown dosyalarıdır
  • Cursor kullanıcıları bunları .cursor/rules/ içine koyabilir
  • Gemini CLI'ın kendine ait bir kurulum yolu vardır
  • Codex, Aider, Windsurf, OpenCode ve sistem prompt alabilen diğer araçlar da bunları okuyabilir
  • Kritik olan, aracın kendisinden çok altındaki iş akışıdır

• Yöntem 3: spesifikasyon gibi okumak

  • Hiçbir şey kurmadan da skill'ler, yapay zeka ajanlarıyla iyi mühendisliğin nasıl yapılacağına dair belgelenmiş bir açıklama olarak okunabilir
  • code-review-and-quality.md okunup 5 eksenli çerçeve ekip review sürecine uygulanabilir
  • test-driven-development.md okunup “testler önce mi yazılmalı” gibi tartışmalarda kullanılabilir
  • Meta skill okunup 5 adet pazarlığa kapalı ilke kendi AGENTS.md dosyanıza taşınabilir
  • En acı veren mevcut probleme en yakın 4-5 skill seçmek, zorunlu kılmak istediğiniz iş akışını belirlemek ve ardından bunu enforce edecek runtime'ı kurmak ya da kendiniz yazmak iyi bir başlangıç olabilir

Kurulum yapmadan alınabilecek kalıplar

• Anti-rasyonalizasyonu ekip pratiği haline getirmek

  • Ekip, kendine söylediği yalanları yazmalıdır
  • Örnekler: “testi release'den sonra düzeltiriz”, “bu değişiklik çok küçük, tasarım dokümanı gerekmez”, “monitoring var, sorun olmaz”
  • Her cümleye bir karşı argüman ekleyip bunu AGENTS.md veya mühendislik wiki'sine koyarsanız tartışmaları azaltabilir ve cuma öğleden sonralarının yorgun kestirmelerini engelleyebilirsiniz

• İç dokümanları düzyazı yerine süreç olarak yazmak

  • “X'e nasıl yaklaşırız” diye 2.000 kelimelik bir metin yazıyorsanız, referans materyali yazıyorsunuz demektir
  • Bunu kontrol noktaları olan bir iş akışına çevirdiğinizde doküman 400 kelimeye iner ve gerçekten uygulanma ihtimali yükselir
  • Bu ilke onboarding rehberleri, runbook'lar ve ajan skill'leri için de geçerlidir

• Doğrulamayı sert bir tamamlanma kriteri yapmak

  • Her işin son adımı “kanıt üretmek” olmalıdır
  • Bu; ajanlar, mühendisler ve bireysel çalışma için de geçerlidir
  • Kanıt; yeşil test koşusu, ekran görüntüsü, log veya review onayı gibi işin tamamlandığını ispatlayan herhangi bir şey olabilir
  • Kanıt yoksa iş bitmemiştir; “makul görünüyor” döngüyü kapatmaz

• Her kural kitabına kademeli görünür kılma uygulamak

  • 50 sayfalık bir el kitabı yazmak yerine, uygun durumda küçük bölümlere yönlendiren küçük bir router yazılmalıdır
  • Bu ilke AGENTS.md, runbook'lar, incident response playbook'ları ve baskı altında okunması gereken tüm dokümanlar için geçerlidir

• AGENTS.md içine konacak 5 pazarlığa kapalı ilke

  • İnşa etmeye başlamadan önce varsayımlar görünür kılınmalıdır. Sessizce korunan yanlış varsayımlar en yaygın başarısızlık modudur
  • Gereksinimler çakışıyorsa durup sormak gerekir. Tahmin edilmemelidir
  • Gerektiğinde itiraz edilmelidir. Ajan ya da mühendis bir yes-man değildir
  • Sıkıcı ve açık çözümler tercih edilmelidir. Aşırı zekice çözümler pahalıdır
  • Yalnızca istenen şey değiştirilmelidir

Harness içindeki yeri

• Skill'ler, daha geniş perspektifte agent harness engineering'in bir katmanıdır
• Harness; modelin kendisini ve çevresine kurduğunuz her şeyi kapsar, skill'ler ise sistem prompt'una kademeli olarak açılan yeniden kullanılabilir iş akışı parçalarıdır
• Skill'ler AGENTS.md, hooks, tools ve session log ile yan yana durur
  • AGENTS.md: sürekli güncellenen kural kitabı işlevi görür
  • hooks: deterministik enforcement katmanıdır
  • tools: ajanın gerçekleştirebildiği eylemlerdir
  • session log: kalıcı bellektir
  • skills: kıdemli mühendislik süreçlerinden sorumludur
• Skill'ler, sohbet tipi ajanlardan çok long-running agents'larda daha önemlidir
• Uzun çalışma süreleri tüm kestirmeleri büyütür
  • 10 dakikalık bir oturumda testleri atlayan bir ajan bir bug üretebilir
  • 30 saatlik bir oturumda testleri atlayan bir ajan, çalışmanın sonunda kimsenin orijinal niyeti hatırlamadığı bir debugging archaeology süreci yaratabilir
• Çalışma süresi uzadıkça kıdemli mühendislik scaffold'ı öneri değil zorunlu uygulama olmalıdır
• Skill formatının taşınabilirliği de önemlidir
• Aynı SKILL.md dosyası Claude Code, rules kullanan Cursor, Gemini CLI, Codex ve sistem prompt içeriği alabilen diğer harness'lerde kullanılabilir
• İş akışını bir kez yazarsınız, runtime onu zorunlu kılabilir; markdown-with-frontmatter formatının, özel prompt engineering'e göre avantajı da budur

Sonuç

• Yapay zeka kodlama ajanları, diff'te görünmeyen işlere dair içgüdüsü olmayan ama çok yetenekli bir junior mühendis gibi davranır
• Varsayımları görünür kılmak, değişiklik boyutunu ayarlamak, spesifikasyon yazmak, kanıt bırakmak, incelenemeyecek değişikliklerin merge edilmesini reddetmek gibi kıdemli mühendislik işleri; ajanların bunları atlaması engellenmezse büyük olasılıkla atlanır
• Giderek daha önemli hale gelen şey, bu disiplinin ajanın sözle sıyrılamayacağı bir biçimde kodlanmasıdır
• Skill'ler bunun bir biçimidir; anti-rasyonalizasyon tabloları, kademeli görünür kılma, düzyazı yerine süreç, tamamlanma kriteri olarak doğrulama ve zaten işe yarayan Google pratiklerini taşınabilir hale getiren yapı asıl çekirdeği oluşturur
• Agent Skills deposu MIT lisansı altında açıktır; daha geniş scaffold perspektifi ise Agent Harness Engineering ve Long-running Agents'de devam eder

[GN⁺]

Hacker News görüşleri

• Yılan yağına çok yakın. Okumaya değer ve kulağa makul geliyor ama sonuçta yine yılan yağı
  Çünkü slot makinesi gibi çalışan model, AGENTS.md, memory.md ve onlarca skill markdown dosyasına yazılmış zorunlu gereksinimleri her an atlayabilir; hatta bu neredeyse garantidir
  Bu tür harness yaklaşımı, sanki LLM'ler kurallara katı ve kusursuz şekilde uyuyormuş da sorun sadece yeterince açık ve yeterince çok kural yazamamamızmış gibi davranıyor. Bu, LLM'lerin nasıl çalıştığına dair temel bir kavrayış hatası
  Sonuçta güvenilir değil; ama görece daha güvenilir tek seçenek yine insan incelemesi ve gözetimi, mümkünse bunu art arda iki kez yapmak
  Geri kalan her şey yılan yağı ve o noktada vaat edilen verimlilik artışının da öyle olduğunu fark ediyorsunuz. Çünkü kodu okuyup zihinde model kurmak, zaten zihinsel modeliniz varken onu koda dökmekten çok daha zor

  • Yılan yağı ifadesi biraz ağır. Böyle ilaçlar asla işe yaramaz ama LLM içeren şeyler olasılıksal da olsa epey yüksek bir ihtimalle çalışıyor
    Kod okuma, ne tür kod olduğuna bağlı ama diğer beceriler gibi pratikle kolaylaşır. Bu, uzun zamandır var olan büyük ve karmaşık kod tabanlarıyla uğraşırken, yazdığınızdan çok okuduğunuz kodun olduğu durumlarda gayet yaygın
    Daha da kolaylaştığı durum, dokümantasyon, geçmiş deneyim ya da ekip arkadaşlarına sorma gibi yollarla kod hakkında zaten bir zihinsel modele sahip olduğunuz zamandır
    Ajanlarla da bu mümkün. Genelde AI'a prompt vermeden önce kod yapısını zaten iyi biliyor oluyorsunuz ve işi dikkatlice bölerseniz üretilen kodu gözden geçirmek çok kolaylaşıyor. Sanki daha önce okuduğunuz bir kitabı yeniden okumak gibi; nadiren bir şey yanlışsa da hemen göze çarpıyor ve çoğunu erkenden yakalayabiliyorsunuz. Her iki durumda da hız artışı büyük
  • İnsanlar da belirtilmiş zorunlu gereksinimleri sık sık atlıyor ve onlar için de inceleme gerekiyor. Yine de süreçler ve review ile insan çıktılarının güvenilirliğini artırdık; harness'te kullanılan yöntemlerin çoğu da güvenilir biçimde aktarması zor olan insan kaynaklı sorunları azaltmaya çalışma deneyiminden geliyor
  • Söylenenlerin hepsi mümkün ve teorik olarak katılıyorum
    Ama son birkaç aydır spec-kit, yani bu tarz AI kullanımını denedim ve pratikte şaşırtıcı derecede iyi oldu. Harika şeyler üretiyoruz ve varsayım olarak ortaya konan sorunları henüz yaşamadık. Bir gün olabilir, o yüzden dikkatliyiz
    Yine de belli bir süre bizzat kullandıktan sonra buna sadece yılan yağı deyip geçemiyorsunuz. 30 yılı aşkın süredir programcıyım ve gerçekte neyin işe yarayıp neyin yaramadığını ayırt edebildiğimi düşünüyorum
  • Bu, +5 kılıcın olsa da 1 atınca ıskaladığı için işe yaramaz demeye benziyor. Beklenen değer açısından bakmak lazım. Biri beş düzgün PR merge edip üçünü çöpe atarken, içlerinden biri berbattı diye büyük şikayet etmek anlamlı bir karşılaştırma değil
  • İnsanların bu markdown önerilerine iş akışı demesinin sebebinin, daha yapılandırılmış bir yaklaşımı rafine ederken eskiyip gitmesinden korkmaları olmasını umuyorum. Temel model yeniliklerinin hızı sonsuza kadar böyle kalacak gibi görünmüyor
    Gelecekte rica eden değil, talep eden harness'ler görmek istiyorum. Plan modunda kalması söylenmesine rağmen belirlenmiş plan prosedürünü izlemeyen ajanı öldüren türden. Kusursuz olmasa bile, insanın işin içinde olduğu mevcut yöntemden daha iyi olmalı

• “Skill'ler, uygun olduğunda ajan bağlamına enjekte edilen frontmatter'lı markdown dosyalarıdır” deniyor ama bunun uygun durum olup olmadığına karar veren yine LLM
  “Ajanın izlediği bir dizi adımdır; kanıt üreten kontrol noktaları ve net bitiş kriterleriyle sona erer” deniyor ama o adımları izleyip izlememeye karar verebilen de LLM

  • Skill'ler çoğu zaman kullanıcı tarafından emir kipinde çağrılıyor. Doğrudan LLM'in kullanması amaçlanıyorsa bağlamın bir yerine koymanız yeterli. Örneğin:

    After implementing the feature, read the testing skill for instructions on how to test.  
    

  • Adil olmak gerekirse Codex gibi yerlerde skill'leri $my-skill ile doğrudan çağırabiliyorsunuz; o zaman gerçekten o skill bağlama enjekte ediliyor. Ondan sonrasıysa, LLM'in promptu, talimatları ve bağlamın diğer kısımlarını ne ölçüde takip ettiğine benzer şekilde o skill'i de takip etmesi

• Herkesin bir yılı aşkın süredir ajanlarla oyalanıp sadece sahte üretkenlik hissi yaşadığını fark edeceği günü bekliyorum

  • Bir miktar şüpheciliği anlıyorum ve AI'ın çeşitli nedenlerle kötü olduğuna kökten inanıyor da olabilirsiniz. Ama bu kadar kesin ifadeleri giderek daha az anlayabiliyorum. AI geliştirmesinin bu kadar başarısız olduğundan nasıl bu kadar emin olunabildiğini merak ediyorum
    Benim gerçek deneyimimle hiç örtüşmüyor. AI ile kodlamanın kaçınılmaz çöküşünden bu kadar emin olmanızı sağlayan deneyimin ne olduğunu merak ediyorum. Bunun, AI'ın ahlaken kötü olduğuna dair felsefi bir inanç mı, yoksa gerçekten AI ile bir şeyler üretip yeterince derinlemesine denedikten sonra varılmış güçlü bir sonuç mu olduğunu bilmek isterim
    30 yılı aşkın süredir her gün kod yazıyorum, 20 yıldan uzun süredir de bunu meslek olarak yapıyorum. Gelip geçen modaları da gördüm, çalışma biçimimizi gerçekten değiştiren ilerlemeleri de birkaç kez yaşadım. AI ile daha çok proje yaptıkça, bunun yazılım geliştirme ve bilgisayar kullanma biçiminde kalıcı ve temel bir değişim olduğuna dair inancım artıyor
    Hem AI'ın geliştiğini görüyorum hem de gerçek işleri bitirmede benim daha yetkin hale geldiğimi. Bu çalışmalar zaten gerçek dünyadaki production yükü altında test edildi. Olan bitenden hoşlanmayabilir, AI ile çalışmanın hissini sevmeyebilirsiniz; ama bu, insanlara gerçek değer üretmediği ve gerçek iş yapmadığı anlamına gelmez
  • Bu bakış açısını merak ediyorum. İyi niyetle soruyorum: AI/ajan/harness kullanan insanların özellik dağıtmadığı gibi bir varsayım mı var?
    Biz yaklaşık eylülden beri Claude Code'a tamamen geçtik ve iyileşmeleri başarıyla takip edebildik. Gerçek production'da kullanılan özellikler yayımlıyoruz. Altyapıda da, iş mantığı uygulamasında da, frontend ve backend tarafında da durum aynı
    İnsanların o kadar zaman boşa harcadığını düşünmüyorum. Ama bu tür yazıların çoğunun saçmalık olduğuna katılıyorum; buna bu yazı da dahil. Yine de AI ile geliştirme dünyanın pek çok şirketinde zaten yaşanıyor
  • İnsanların kağıt defter tutmayı bırakıp sözde veritabanı denen şeyle oyalanarak üretkenliği kaybettiğini söylemeye benziyor
  • Çıktının ölçüldüğü bir projede çalışıyorum ve burada hiçbir şey “sahte” değil
  • Ben buna Minecraft otomasyonu gibi bakıyorum. Sadece eğlence ve vakit geçirme amaçlı
    Ajan tarzı iş akışlarının henüz o noktaya geldiğini düşünmüyorum ama elle çağrılıp AI ile yan yana çalışırken kullanılan skill uygulamaları kesinlikle fena değil. Şirketimiz son zamanlarda sandboxing ve güvenli skill'lere çok odaklanıyor
    Özellik geliştirmeyi henüz tam yakalayamadığını düşünüyorum ama yazdığımız review skill'i ve Grafana skill'i gayet sağlam çıktı

• Daha önce daha büyük ajan skill paketleri denedim ama çok fazla şey yapmaya çalıştıkları için zaman kaybı gibi geldi. Vim'deki gibi, skill'leri bir IDE gibi toptan kurmak yerine topluluktan seçerek almak çoğu zaman daha iyi
  Skill'ler geliştiriciye ve ekibe göre değişiyor, yani fazla kişisel. Başkasının ayarlarını topluca kurmaktansa, kendi ayarlarınızı oluşturmak için referans materyali gibi yaklaşmak daha iyi

  • MCP ve sistem talimatları için de aynısı geçerli. Pek çok kişi ne yaptığını anlamadan hepsini kuruyor, gereksiz araçlarla bağlamı kirletip 50 bin token'dan fazlasını harcıyor, sonra limite çok hızlı ulaştığı için ayda 100 dolardan fazla ödemek zorunda kaldığını söylüyor

• Arama optimizasyonu ya da LLM optimizasyonu açısından bakınca, adı değişmezse bu skill'lerin keşfedilebilirliği zor olabilir gibi görünüyor: https://agentskills.io/
  Addy bunu görse, bunu Superpowers ile karşılaştırınca nasıl açıklardı merak ediyorum: https://github.com/obra/superpowers

  • Gerçekte superpowers kullanan kaç kişi var merak ediyorum
    superpowers'tan önce de ajan geliştirme tarafındaydım ama kendi kurduğum süreçlerin %50'den fazlasının artık superpowers ile kapsanıyor gibi görünmesi beni endişelendiriyor
    Artık GitHub yıldızlarına güvenmiyorum. Biri bana söylesin. superpowers gerçekten benimsendi mi artık? Gerçekten bu kadar değerliyse Boris neden hâlâ bu kavramı entegre etmedi?
  • NextJS ile rekabet etmek için bir React framework'üne ReactJS adını vermek gibi
  • Eklenti olarak sunulan hazır skill paketleri gibi görünüyor
  • superpowers gerçekten çalışıyor mu? Ana skill dosyası pek güven vermiyor:
    “Yaptığın işte bir skill'in işe yarama ihtimali %1 bile olsa, o skill'i mutlaka çağırmalısın”

• İnsanların kendi işlerini ortadan kaldırma konusunda neden bu kadar hevesli olduğunu anlamıyorum
  Bunlar ya da herhangi bir “skill” bunu gerçekten yapmayacak olabilir ama ilke düzeyinde söylüyorum. Bu bana emeğe yabancılaşmanın kitlesel ölçekte yaşanması gibi geliyor

  • On yıllardır eski işlerin büyük bir kısmını otomatikleştiriyoruz. Aksi halde herkes işleri mümkün olduğunca uzun sürdürmek için en verimsiz yöntemleri seçmeye çalışırdı ki bu iyi bir fikir değil
    İnsanlık, izlenebildiği kadarıyla, hep belirli bir çıktıyı üretmek için gereken emeği azaltmaya çalıştı; medeniyet dediğimiz şey de bu. Harcanan emeği en üst düzeye çıkarmak için çapayla elle tarım yaptığımız günlere mi dönelim? Sokak lambalarını tek tek yaktığımız döneme mi dönelim?
    Otomasyonda geri kalan toplumlar yoksullaşır ve sonunda ölür. Çünkü orada doğan insanlar bile daha üretken yerlere gider. Bu Doğu Avrupa'da da, Amish topluluklarında da, göç veren yoksul toplumların her yerinde görüldü. Daha azla daha fazlasını yapmak her zaman heyecan vericiydi
  • Bir bilgisayar programcısı olarak bu düşünceyi anlamak zor. Tüm hayatım boyunca bilgisayarların işleri yapmasını sağlayıp insanların artık yapmak zorunda kalmamasını hedefledim. Yazılan her yazılım, birinin yaptığı işi ortadan kaldırmak içindir
    Merak ediyorum, yaptığınız her otomasyon hakkında da böyle mi hissediyorsunuz. Eski usul sistem yöneticileri arasında da altyapı otomasyonundaki gelişmeleri böyle görenler vardı; önceden elle yapılan işlerin script'ler ve sistemler tarafından yapılmasından hoşlanmıyorlardı
    Ekibimiz bir iş yerinde 30 bin sunucuya otomatik yama uygulayan ve sistemleri production'dan otomatik çıkarıp geri alan bir otomatik patch sistemi yaptı. Tüm süreç dokunmadan yürür hale geldi; oysa eskiden bunu elle işleten ayrı bir ekip vardı. Otomasyonla onların işini ellerinden mi aldık?
    Bir anlamda evet ama yapılacak başka işler vardı ve artık onları yapabiliyorlardı
    Programlamayı, bilgisayarları ve teknolojiyi sevmemin nedeni tam da bizim yerimize iş yapmaları. Benim ütopyam, robotların bütün zor işleri yaptığı ve insanların istediklerini yapabildiği bir dünya. AI da bizi buna bir adım daha yaklaştırıyor. İnsanların zaten istemediği işleri yaparak meşgul kalmalarını sağlayacak kadar iş bırakmaya çalışmak yerine, robotların işleri devralmasının faydasını yalnızca varlıklı sahiplerin değil tüm dünyanın paylaşmasını nasıl sağlayacağımıza odaklanmayı tercih ederim
  • Genelde işini kaybeden kişi, piyasaya uyum sağlayamayan kişidir
    Şu anda her şeyin hangi yöne evrildiği net değil; bu yüzden insanlar verilerini rastgele ajanlara vermeyi deniyor, bağlamı kaydedip erişmenin yollarını arıyor, prompt'ları yeniden kullanıyor ve bu teknolojiyle başa çıkmak için farklı denemeler yapıyor
    Bunların çoğu, bir yıl sonra yeni nesil modellere derinden entegre edilip anlamsız hale gelebilir. Yine de gelişime ayak uydurmak bu alanda çalışmanın eğlenceli yanlarından biri oldu
  • Bu bir hayatta kalma içgüdüsü. Etrafınızdaki herkes ve her şey, işiniz bile “AI kullan” diye bağırırken ters yönde durmak ya da uyarı dile getirmek zorlaşıyor. Bu daha çok heyecandan değil, treni kaçırıp geride kalma korkusundan kaynaklanıyor
    Uzun vadeli veriler, ortalama olarak üretkenlik artışının sınırlı kaldığını ve en gelişmiş modeller destek olsa bile kaliteli yazılım üretmek için hâlâ özen ve insan dikkati gerektiğini gösterirse hem destekleyenler hem karşı çıkanlar biraz şaşıracaktır
    Yapılan iş aynı; sadece tornavida yerine elektrikli matkap verilmiş oluyor. Kimi insan yüzlerce yıl dayanacak ev yapar, kimi yapamaz
  • En hevesli olanların, daha önce iyi geliştirici olmayan ama bir anda “normal” seviyeye hızlanmış gibi hissedenler olduğunu düşünüyorum. Tanıdığım iyi geliştiricilerin hepsi benimsemekte daha temkinliydi

• Son zamanlarda bunu sık duyuyorum. Geliştirici ekibi yönetmek için iyi olan şeylerin LLM yönetimi için de iyi olduğu söyleniyor
  İyi test case'leri, net ve kısa dokümantasyon, CI/CD, best practice'ler ve onboarding dokümanları gibi
  LLM yönetmek giderek bir insan ekibini yönetmeye benzemeye başlıyor

  • Evet. Ben de yaklaşık bir yıldır bunu söylüyorum ve şirket içi sunumlarda da aynen bu anekdotu kullandım
  • Aynı şekilde ajan tarzı kodlama başarı hikayeleri de baştan beri bunların hepsine sahip olan organizasyonlardan çıkıyor

• Bunun spec-kit'e göre neyin daha iyi ya da farklı olduğunu merak ediyorum. Felsefesi çok benzer görünüyor ve birlikte kullanılıp kullanılamayacağını da merak ediyorum. Yoksa sadece tekrar mı?
  https://github.com/github/spec-kit

  • Hiçbir farkı yok. Kod yazarken AI'ı dikkatli kullanma niyeti olmayan ama toplu işten çıkarmalardan şikayet eden geliştiriciler için aynı çöp

• Bazı skill'lerin bu kadar uzun olmasına şaşırdım. Tablolar, checkbox listeleri, kod örnekleri vs. ile birkaç sayfa sürüyorlar
  Bunun ne kadar yaygın olduğunu merak ediyorum. Bunlardan birkaç tane bile bağlamı epey doldurur gibi geliyor

  • Uzun olmalarının nedeni, bu skill'lerin çoğunun Claude Code ve Opus ile yazılmış olması ve aklı başında hiç kimsenin o dosyaları okuyup onlardan zihinsel model çıkarmaya çalışmaması. Bunun işe yaradığı varsayımı birkaç katman üzerine kurulu ama gerçek hayatta ne çalışıyor ne de verimli
    Eğlenceli bir deney var. LLM'e belirsiz ama tanıdık bir şey yazmasını söyleyin. Mesela “write a fib” derseniz, neredeyse tüm LLM'ler koda göre fine-tune edildiği için, programcı olmayan biri için bu “küçük bir yalan yaz” anlamına gelebilecek olsa da Fibonacci dizisi algoritması ile cevap verir
    Yani bir sıkıştırma oluyor. Fibonacci dizisinin tam olarak ne olduğunu ayrıntılı açıklamadan, yalnızca muğlak üç token ile sonucu ifade edebiliyorsunuz
    Bu yüzden prompt uzunluğunun önemli olmadığını görüyorsunuz. Önemli olan doğru kelimeler, sıklık ve sıralama. İki sayfalık bir prompt ile iki cümlelik bir prompt aynı sonucu verebilir
  • Hızlıca baktığımda en azından birkaç tanesi skill'den çok dar kapsamlı alt ajanlar için bir system prompt gibi görünüyordu. Uzun süren çalışma oturumlarında bunların çok sayıda kullanılmasını istemem dediğinize katılıyorum
    Şimdiye kadar kısa ve odaklı skill'lerle başarılı oldum. Onları yeniden kullanılabilir bağlam parçaları gibi ele alıyorum ama küçük tutuyorum. Örneğin projemde Python'u nasıl kullandığımız ve unit test'leri nasıl çalıştırdığımız hakkında birkaç paragraf
    Ayrıca ajana talimat vermeyen, sadece gerektiğinde çekilebilecek yararlı bağlam bilgisi içeren kısa “info” skill'lerim de var
    Skill sayısı çok arttığında bu da sorun olabilir. Çünkü skill adları ve açıklamalarının listesi de bir noktada bağlama giriyor
  • Hiç skill yazmadım, o yüzden bunun ne kadar yaygın olduğunu bilmiyorum. Birkaçının kelime sayısını saydım, kabaca 2 bin kelime civarındaydı. Beş skill yaklaşık 10 bin kelime eder
    Küçük sayılabilecek 128k LLM bağlamında bu yaklaşık %10 eder, büyük modellerin 1M bağlam penceresinde ise neredeyse fark edilmez
  • Temelde bağlama skill'in tamamı değil, frontmatter'ı yani adı, açıklaması, tetikleyicileri vb. yükleniyor; dolayısıyla binlerce skill'iniz yoksa bunun pek yaşanacağını sanmıyorum
  • Projemdeki skill dosyalarının satır sayılarına baktım; ilk üçü 805 satır, 660 satır ve 511 satır çıktı
    Belki bu konuda fazla muhafazakâr davranıyorumdur. Daha keşfedecek çok şey var

• “Kıdemli mühendisin işinin çoğu diff'te görünmeyen kısımdır”
  Agent Skills, Addy'nin o işi de ortadan kaldırma girişimi. Şerefe, Addy :P