Orijinal Başlık: İnce Kemer, Kalın Beceriler
Orijinal Yazar: Garry Tan
Çeviri: Peggy, BlockBeats

Editör Notu: "Daha güçlü model" endüstrideki varsayılan yanıt haline geldiğinde, bu makale farklı bir değerlendirme sunuyor: Gerçek 10 kat, 100 kat veya hatta 1000 katlık verimlilik farkını açan şey, modelin kendisi değil, model etrafında inşa edilen bütünsel bir sistem tasarımıdır.

Bu makalenin yazarı Garry Tan, şu anda Y Combinator'un Başkanı ve CEO'su olan ve uzun süredir AI ve erken aşama girişimcilik ekosistemine yoğunlaşmış birisidir. AI uygulamalarını beceri, işletme çerçevesi, bağlam yönlendirmesi, görev bölümü ve bilgi sıkıştırma gibi temel bileşenlere ayıran "kalın beceriler + ince kemer" çerçevesini öne sürdü.

Bu sistem altında, model artık yeteneklerin tamamı değil, sadece sistemin yürütme birimididir; çıktı kalitesini gerçekten belirleyen şey, nasıl bağlamı organize ettiğiniz, süreci nasıl çöktürdüğünüz ve "karar" ile "hesaplama" arasındaki sınırı nasıl belirlediğinizdir.

Dahası, bu yöntem seti sadece bir kavram seviyesinde kalmamakta, aynı zamanda gerçek senaryolarda doğrulanmaktadır: Binlerce girişimcinin veri işleme ve eşleştirme görevleriyle karşı karşıya kaldığı durumlarda, sistem "okuma–özetleme–karar verme–geri yazma" döngüsü aracılığıyla, kodu yeniden yazma ihtiyacı olmaksızın sürekli kendini optimize eden neredeyse insan analisti yeteneklerine ulaşmıştır. Bu "öğrenen sistem" sayesinde, yapay zeka tek seferlik bir araçtan, faiz etkisine sahip bir altyapıya dönüşmüştür.

Bu nedenle, makalenin sunulan temel uyarısı da net hale gelmektedir: AI çağında, verimlilik farkı artık en gelişmiş modeli kullanıp kullanmadığınıza değil, sürekli yetenek biriktiren ve otomatik olarak evrilebilen bir sistem inşa edip etmediğinize bağlıdır.

Aşağıda orijinal metin yer almaktadır:

Steve Yegge, AI programlama ajanlarını kullananların, "2021 Google mühendisinin 1000 katı kadar, yalnızca İmleç ve sohbet aracıyla kod yazan mühendislerin 10 katından 100 katına kadar verimli olduğunu" söylüyor.

Not: Steve Yegge, Silikon Vadisi'nde etkili olan bir yazılım mühendisi, teknik blogcu ve mühendislik kültürü yorumcusudur. Keskin, uzun ve güçlü bir kişisel tarzla teknik yazılarıyla tanınmıştır. Amazon, Google gibi şirketlerde kıdemli mühendis olarak çalışmış; daha sonra Salesforce'a katılmış ve ardından başlangıç şirketlerinde ve yapay zeka alanında çalışmıştır; aynı zamanda erken dönem Dart projesinin bir destekleyicilerinden biridir.

Bu abartılı bir ifade değil. Kendim gördüm ve yaşadım. Ancak insanlar genellikle bu tür farkları daha güçlü modelle, daha zeki Claude'la veya daha fazla parametreyle ilişkilendirirler.

Aslında, verimliliği iki katına çıkaran insanlarla ve verimliliği 100 katına çıkaran insanlar aynı modeli kullanıyor. Fark "zekada" değil, "mimaride." Ve bu mimari, bir kartvizitte yazılabilecek kadar basittir.

Harness (Çalıştırma Çatısı), aslında ürünün kendisidir.

2026 yılının 31 Mart'ında, Anthropic bir kaza sonucu Claude Code'un tam kaynak kodunu npm üzerine yayınladı - toplam 512 bin satır. Ben tek seferde okudum. Bu, YC (Y Combinator)’da sürekli anlattığım şeyi doğruladı: Gerçek sır, modelde değil, "modelin sarılı olduğu katmanda" bulunur.

Canlı kod deposu bağlamı, Prompt önbelleği, belirli görevler için tasarlanmış araçlar, gereksiz bağlamın mümkün olduğunca sıkıştırılması, yapılandırılmış oturum belleği, paralel çalışan alt aracılar - bunlar modeli daha zeki yapmaz. Ancak bunlar modeli "doğru zamanda," "doğru bağlamda" tutabilir ve gereksiz bilgilerle boğulmasını engelleyebilir.

Bu "sarılma" katmanı, çalıştırma çatısı (harness) olarak adlandırılır. Ve tüm yapay zeka oluşturucuların gerçekten sorması gereken soru şudur: Hangi şeyler çalıştırma çatısına yerleştirilmeli, hangi şeyler dışarıda bırakılmalıdır?

Bu sorunun aslında çok net bir cevabı var - buna İnce Çatı (thin harness), Kalın Yetenek (fat skills) diyorum.

Beş Tanım

Engel asla modelin zekasında değildir. Aslında modeller mantık yürütme, bilgi sentezi, kod yazma konusunda çoktan bilgilidir.

Onların başarısız olma nedeni, verilerinizi anlamamalarıdır - şemanızı, sözleşmenizi, sorununuzun belirli şeklini anlamayabilirler. Ve aşağıdaki beş tanım, tam da bu sorunu çözmek için tasarlanmıştır.

1. Skill file (Yetenek Dosyası)

Yetenek dosyası, modelin "bir şeyi nasıl yapacağını" öğrenmek için kullanılan yeniden kullanılabilir bir markdown belgesidir. Dikkat edin, modeli "ne yapacağını" söylemek değil - bu kısım kullanıcı tarafından sağlanır. Yetenek dosyası, süreci sağlar.

Çoğu insanın gözden kaçırdığı önemli nokta şudur: Yetenek dosyası aslında bir yöntem çağrısı gibidir. Parametre alabilir. Farklı parametrelerle çağrılabilir. Aynı süreç, farklı parametrelerle çağrıldığında tamamen farklı beceriler sergileyebilir.

Örneğin, /investigate adında bir yetenek var. Yedi adımdan oluşur: Veri Kapsamını Tanımlama, Zaman Çizelgesi Oluşturma, Her Belgeyi Günlükleme, Tümleşik Özetleme, İki Yönlü Argüman, Kaynakları Alıntılama. Üç parametre alır: HEDEF, SORU ve VERİ KÜMESİ.

Eğer bir güvenlik uzmanına ve 2.1 milyon adet delil bulunan e-postaya işaret ederseniz, o zaman bir tıp araştırma analisti haline gelir, bir ihbarcının bastırıldığına karar verir.

Eğer bir kabuk şirketine ve Amerikan Federal Seçim Komisyonu (FEC) tarafından yapılan bildirim belgelerine işaret ederseniz, o zaman bir adli bilişim soruşturma uzmanı haline gelir, işbirlikçi siyasi bağışları takip eder.

Aynı yetenek. Aynı yedi adım. Aynı markdown dosyası. Yetenek bir değerlendirme sürecini tanımlar, gerçek dünya uygulamasını yapmak ise, girilen parametrelere bağlıdır.

Bu prompt mühendisliği değil, yazılım tasarımıdır: Sadece burada programlama dili olarak markdown ve çalışma zamanı ortamı olarak insanın değerlendirme gücünü kullanıyoruz. Aslında, markdown sıkı bir kaynak kodundan daha iyi kapsama kabiliyetine daha uygundur, çünkü tanımladığı süreç, değerlendirme ve bağlam, modellerin en iyi "anladığı" dilidir.

2. Harness (Çalıştırma Çerçevesi)

Harness, LLM'nin çalıştırılmasını yönlendiren program katmanıdır. Sadece dört şey yapar: Modeli döngü içinde çalıştırma, dosyalarınızı okuma/yazma, bağlamı yönetme ve güvenlik kısıtlamalarını uygulama.

Sadece bu kadar. Bu kadarıyla "ince"dir.

Diğer tarafın modeli: Kalın çalıştırma çerçevesi, ince yetenekler.

Şunu mutlaka görmüşsünüzdür: 40'tan fazla araç tanımı, sadece açıklamalar yarım pencereyi kaplar; her işe yarayan Tanrı aracı, MCP'yi çalıştırmak 2 ila 5 saniye sürer; veya her REST API uç noktasını ayrı bir araç olarak paketlemek. Sonuç olarak, token kullanımı üç kat artar, gecikme üç kat artar, başarısızlık oranı da üçe katlanır.

Gerçekten ideal olan yöntem, amaçları için özel olarak tasarlanmış, hızlı ve dar işlevli araçları kullanmaktır.

Örneğin Playwright CLI, her tarayıcı işlemi sadece 100 milisaniye sürer; bunun yerine, bir Chrome MCP, bir ekran görüntüsü almak için → bulmak için → tıklamak için → beklemek için → okumak için 15 saniye sürer. İlk örnek 75 kat daha hızlı.

Şu anda yazılımın artık "aşırı detaylı şekilde işlenmiş ve şişirilmiş" olması gerekmiyor. Yapmanız gereken şey şudur: Gerçekten ihtiyacınız olanı yalnızca oluşturun ve bu kadar.

3. Çözücü (Resolver)

Çözücü, temelde bir bağlam yönlendirme tablosudur. X görev türü ortaya çıktığında, Y belgesi öncelikle yüklenir. Beceriler modeli "nasıl yapılacağını" söylerken; çözücüler, modele "ne zaman ne yüklenmesi gerektiğini" söyler.

Örneğin, bir geliştirici bir ipucunu değiştirdi. Çözücü olmadan, muhtemelen değişikliği yaptıktan sonra doğrudan sürüm yayınlardı. Ancak çözücü olduğunda, model önce docs/EVALS.md belgesini okur. Ve bu belgede şunlar yazmaktadır: Önce değerlendirme süitini çalıştır, önceki ve sonraki puanları karşılaştır; doğruluk oranı %2'den fazla düşerse, geri al ve nedenleri araştır. Bu geliştirici aslında değerlendirme süitinin varlığından bile haberdar değildi. Doğru zamanda, doğru bağlamı yükleyen çözücüdür.

Claude Code bir çözücüye sahiptir. Her becerinin bir açıklama alanı vardır, model kullanıcı niyetini becerinin açıklamasıyla otomatik eşleştirir. /ship becerisinin varlığını hatırlamanıza bile gerek yoktur—açıklama zaten çözücüdür.

Dürüst olmak gerekirse: Eskiden CLAUDE.md dosyam tam tamına 20.000 satırdı. Tüm tuhaflıklar, tüm kalıplar, karşılaştığım tüm deneyimler, hepsi içine sıkıştırılmıştı. Son derece saçmaydı. Modelin dikkat kalitesi açıkça düştü. Claude Code bana bunu direk silmemi söyledi bile.

Nihai düzeltme çözümü, muhtemelen sadece 200 satırdı—yalnızca bazı belge işaretçilerini saklamak. Gerçekten ihtiyacınız olan belgeyi çözücünün kritik anında yüklemesine izin verin. Böylece, 20.000 satır bilgi hala kullanıma hazır olabilir, ancak bağlam penceresini kirletmez.

4. Latent ve deterministik (Gizli Alan ve Belirlilik)

Sisteminizde, her adım ya bu kategoriye aittir ya da diğerine. Bu ikisini karıştırmak, ajan tasarımında en yaygın hata.

· Gizli alan (Latent space), zekanın bulunduğu yerdir. Model burada okur, anlar, karar verir, eylemde bulunur. Burada işlenen şeyler: Karar verme, sentezleme, desen tanıma.

· Belirlilik (Deterministic), güvenilirliğin bulunduğu yerdir. Aynı giriş, her zaman aynı çıktıyı verir. SQL sorguları, derlenmiş kod, aritmetik işlemler, hepsi bu tarafa aittir.

Bir LLM, hem her bir kişinin kişiliğini hem de sosyal ilişkilerini dikkate alarak 8 kişilik bir akşam yemeği düzenlemesine yardımcı olabilir. Ancak ondan 800 kişilik bir düzenleme yapmasını isterseniz, size "mantıklı görünen ancak aslında tamamen yanlış" bir masa düzeni ciddi ciddi sunacaktır. Çünkü bu artık potansiyel alanın işlemesi gereken bir sorun değil, latent alanın içine sıkıştırılmış kesin birleşim optimizasyonu problemidir.

En kötü sistemler her zaman işi yanlış yerleştiren tarafta bulunur. En iyi sistemler ise sınırları çok net bir biçimde çizer.

5. Diarizasyon (Belge Bütünleme / Konu Portresi)

Diarizasyon adımı, yapay zekanın gerçek dünya bilgisini nasıl işlediğinin asıl anahtarıdır.

Bu, modelin ilgili bir konuyla ilgili tüm malzemeyi okumasını ve ardından yapılandırılmış bir portre yazmasını içerir. Onlarca hatta yüzlerce belgeden çıkarılan kararları bir sayfa kağıda yoğunlaştırır.

Bu bir SQL sorgusuyla elde edilebilecek bir şey değildir. Bu bir RAG boru hattıyla elde edilebilecek bir şey de değildir. Model gerçekten okumalı, birbiriyle çelişen bilgileri aynı anda zihninde tutmalı, nelerin değiştiğine dikkat etmeli, ne zaman değiştiğini fark etmeli ve ardından bu içeriği yapılandırılmış bir zeka haline getirmelidir.

Bu, veritabanı sorgusu ve analist sunumu arasındaki farktır.

Bu Mimarlık

Bu beş kavram, çok katmanlı bir mimari oluşturacak şekilde bir araya getirilebilir.

· En üst katman kalın becerilerdir (fat skills): Markdown kullanılarak yazılmış bir süreç, kararları, metodolojiyi ve alan bilgisini taşır. Değerin %90'ı bu katmanda bulunur.
· Orta katman ise ince bir CLI başlatıcısıdır: Yaklaşık 200 satır kod, JSON girdisi alır ve metin çıktısı üretir, varsayılan olarak salt okunur.
· En alt katman ise uygulama sistemlerinizdir: QueryDB, ReadDoc, Search, Timeline—bunlar belirlilik temelli altyapıdır.

Temel prensip yönlendirmelidir: "Zeka"yı mümkün olduğunca becerilere itin; "yürütme"yi ise belirliliğe dayalı araçlara itin; başlatıcıyı ise hafif tutun.

Bu yaklaşımın sonucu şudur: Her model geliştiğinde, tüm beceriler otomatik olarak güçlenir; belirlilik temelli sistemler ise her zaman istikrarlı ve güvenilir kalır.

Öğrenebilir Sistemler

Aşağıda, YC'de geliştirdiğimiz gerçek bir sistem kullanarak, bu beş tanımın nasıl birlikte çalıştığını göstereceğim.

2026 Temmuz'unda Chase Center. Startup Okulu'na 6000 kurucunun katıldığı bir etkinlik düzenlendi. Herkes yapılandırılmış başvuru materyallerine, anket yanıtlarına, mentorlarla 1:1 yapılan görüşmelerin transkriptlerine, X'teki açık sinyallere: Gönderiler, GitHub kayıtları, Claude Code kullanım kayıtlarına sahipti (geliştirme hızlarını görebilirsiniz).

Geleneksel yaklaşım şuydu: 15 kişilik bir proje ekibi başvuruları tek tek okur, sezgisel olarak değerlendirir ve ardından bir tabloyu güncellerdi.

Bu yaklaşım 200 kişiyle hala işe yarayabilirken, 6000 kişi olduğunda tamamen başarısız oldu. Hiçbir insan bu kadar çok portreyi aklında tutamaz ve Lagos'taki bir geliştirme aracı kurucusu, Singapur'daki uyumluluk girişimcisi ve Brooklyn'deki CLI aracı geliştiricisi olmak üzere AI ajan altyapısının en iyi üç adayının, farklı 1:1 görüşmelerde tamamen farklı ifadelerle aynı bir acı noktayı nasıl tanımladığını fark edemez.

Model bunu başarabilir. Yöntem aşağıdaki gibidir:

Enrichment (Bilgi Zenginleştirme)

/enrich-founder adında bir beceri var. Tüm veri kaynaklarını çeker, bilgi zenginleştirme ve diarization yapar, "kurucunun söylediği" ile "gerçekte yaptığı" arasındaki farkı belirtir.

Altta yatan belirli sistem, SQL sorguları, GitHub verileri, Demo URL'si için tarayıcı testleri, sosyal sinyal yakalama, CrustData sorguları vb. gibi işlemlerden sorumludur. Bir zamanlayıcı görevi her gün bir kez çalıştırır. 6000 kurucu portresi her zaman günceldir.

Diarization çıktısı, anahtar kelimelerin taramasının tamamen bulamayacağı bilgileri yakalayabilir:

Kurucu: Maria Santos Şirket: Contrail (contrail.dev) Kendi tanımı: "AI ajanının Datadog'u" Gerçekte yaptığı: Kodun %80'i faturalandırma modülünde odaklanmış → Esasında gözle görülebilir dış yüzle giydirilmiş bir FinOps aracı yapıyor

Bu tür "söylem vs. gerçek davranış" farkları, aynı anda GitHub commit geçmişini, başvuru materyallerini ve konuşma kayıtlarını okumayı gerektirir ve bu bilgileri entegre etmek zorundadır. Hiçbir embedding benzerliği araması bunu yapamaz, anahtar kelime filtresi de işe yaramaz. Model tümüyle okumalı ve ardından bir değerlendirme yapmalıdır. (Bu, latent uzayda olması gereken bir görevdir!)

Eşleştirme (Matching)

Bu, "Yetenek = Yöntem Çağrısı"nın gücünü ortaya koyduğu yerdir.

Aynı eşleştirme yeteneği üç kez çağrıldığında tamamen farklı stratejiler ortaya çıkabilir:

/match-breakout: 1200 kişiyi işler, alan bazlı kümelendirme, her grup 30 kişi (gömmeleme + belirlenimli atama)

/match-lunch: 600 kişiyi işler, alanlar arası "rastgele eşleştirme", her masada tekrar olmadan 8 kişi — LLM tarafından önce konu oluşturulur, daha sonra belirlenimli algoritma tarafından kişiler yerleştirilir

/match-live: Canlı katılımcıları işler, yakınlık gömmelemesine dayalı olarak, 200 ms içinde 1'e 1 eşleştirme yapar ve daha önce karşılaşılan kişileri dışlar

Ayrıca, model geleneksel kümeleme algoritmalarının yapamadığı değerlendirmeler yapabilir:

"Santos ve Oram ikisi de AI altyapısına dahil, ancak rekabetçi bir ilişkiye sahip değiller — Santos maliyet atfı yaparken, Oram düzenleme yapar. Aynı gruba konmalılar."

"Kim başvuruda geliştirici araçları yazdı, ancak 1:1 konuşma onun SOC2 uyumluluk otomasyonu yaptığını gösteriyor. FinTech / RegTech'e yeniden sınıflandırılmalı."

Bu tür yeniden sınıflandırma, gömmeleme tarafından tamamen yakalanamaz. Modelin tüm portreyi okuması gerekir.

Öğrenme Döngüsü (Learning Loop)

Etkinlik sona erdikten sonra, bir /improve yeteneği NPS anket sonuçlarını okur, "iyi" olarak değerlendirilen ancak "biraz daha iyi olabilirdi" olan geri bildirimleri diarizasyon yapar — bu kötü bir eleştiri değil, belirli bir konuda gelişme gerektiren geri bildirimlerdir — ve desenleri çıkarır.

Sonra, yeni kurallar önerir ve eşleştirme yeteneğine geri yazar:

Bir katılımcı "AI altyapısı" dediğinde, ancak kodunun %80'inden fazlası faturalandırma modülü ise:
→ FinTech olarak sınıflandırılmalı, AI Altyapısı değil

Aynı gruptaki iki kişi zaten tanışırsa:
→ Eşleştirme ağırlığını azalt
Yeni ilişkileri önceliklendir

Bu kurallar yetenek dosyasına geri yazılır. Bir sonraki çalışmada otomatik olarak yürürlüğe girer. Yetenek kendini "yeniden yazma" işlemine tabi tutar. Temmuz etkinliğinde "iyi" derecelendirmelerin payı %12 iken, bir sonraki etkinlikte bu oran %4'e düşer.

Yetenek dosyası "iyi"nin ne anlama geldiğini öğrendiğinde, sistem kodu yeniden yazmadan nasıl daha iyi hale gelebilir.

Bu model herhangi bir alana taşınabilir:

Alıntıla → Oku → günlük tut → Say → Entegre Et

Sonra: Araştırma → İnceleme → günlük tut → Yetenek dosyasını yeniden yazma

2026 yılında en değerli döngüyü sorsaydınız, işte bu. Bu, neredeyse her bilgi işlem senaryosuna uygulanabilir.

Yetenek Sürekli Güncellemedir

Son zamanlarda X'te OpenClaw'a bir direktif gönderdim ve beklenenden daha büyük bir tepki aldım:

Talimat: Tek seferlik iş yapmana izin verilmez. Eğer tekrarlanacak bir iş yapmanı istiyorsam, şunları yapmalısın: İlk olarak, 3 ila 10 numuneyi manuel olarak işle; Sonuçları bana göster; Eğer kabul edersem, bunu bir yetenek dosyasına dönüştür; Eğer otomatik olarak çalışması gerekiyorsa, bunu zamanlanmış göreve ekle. Ölçüt şudur: İkinci sefer sormam gerekiyorsa, başarısız oldun demektir.

Bu içerik binlerce beğeni aldı ve iki binden fazla kez favorilere eklenildi. Birçok insan bunun prompt mühendisliği becerisi olduğunu düşünüyordu.