Claude Code’un yaratıcısı Boris Cherny, Opus 5 çıktıktan kısa süre sonra verdiği bir röportajda çarpıcı bir itirafta bulundu: Anthropic mühendisleri, Claude Code’un sistem talimatlarının yüzde 80’ini sildi. Silinen talimatlar hatalı değildi; sadece artık gereksizdi. Çünkü model, o talimatların düzelttiği davranışları artık kendiliğinden doğru yapıyordu.

Daha da çarpıcı olan bir başka detayı da paylaştı: birileri Opus 5’e OpenCV kütüphanesini verip “portre ve manzara çiz” demiş. Model bunun için hiç eğitilmemişti. Yine de yapabildi. Cherny buna “ürün açığı” diyor: model çoktan yapabiliyor, ama hiçbir ürün ona bunu yaptırmayı düşünmemiş bile.

Bu yazıda Cherny’nin röportajda anlattıklarının tamamını, sadeleştirerek ama hiçbir ayrıntıyı atlamadan aktarıyorum: modeli neden aşırı yönlendirmenin ters teptiğini, “basit mod” denen test yöntemini, binlerce yapay zekâ ajanının birlikte nasıl çalıştığını ve 100.000 satırlık bir kod tabanının 11 günde nasıl yeniden yazıldığını. Claude ile kodlamaya yeni başlıyorsan önce Claude ile kodlama rehberimize bakabilirsin.

“Hobbling”: ürün, modelin önüne geçtiğinde

Cherny’nin röportaj boyunca döndüğü kavram şu: bir model bir işi yapabilecek kapasitede olduğu halde, kullandığın arayüz veya verdiğin talimatlar onun önüne geçip o kapasiteyi ortaya çıkarmasını engelliyorsa buna “hobbling” (engelleme) deniyor. Bunun tersine, yani bir modelin gerçekte yapabildiği ile mevcut ürünlerin ona yaptırdığı şey arasındaki boşluğa da “ürün açığı” (product overhang) deniyor.

Somut örneği Claude Code’un kendi doğuşu. Claude 3.5 Sonnet çıktığında model zaten dosya yazabiliyor, komple özellik geliştirebiliyordu. Ama piyasadaki kodlama araçları hâlâ tek satırlık otomatik tamamlama ya da salt okunur sohbet penceresi sunuyordu. Model hazırdı, ürün önündeydi. Claude Code, modele terminale tam erişim vererek bu engeli kaldırmak için doğrudan bu boşluğu kapatmak üzere kuruldu.

Cherny’nin vurguladığı nokta şu: bugün de aynı durum geçerli. Mevcut modellerde, kimsenin henüz keşfetmediği “onlarca, yüzlerce” yetenek olduğunu düşünüyor. OpenCV ile portre çizen Opus 5 örneği bunun kanıtı; model bu işi çoktan yapabiliyordu, sadece kimse denemeyi düşünmemişti.

Neden sistem talimatının yüzde 80’i silindi?

Eski modeller belirli hataları tekrar tekrar yapıyordu, bu yüzden geliştiriciler o hataları düzeltmek için sistem talimatına satır satır kural ekliyordu: “önce şunu yap, sonra 1, 2, 3, 4 adımlarını izle” tarzında aşırı spesifik, katı yönergeler. Opus 5 geldiğinde bu kuralların büyük kısmı artık işlevsizdi; çünkü model, düzeltmesi gereken davranışı zaten doğru yapıyordu.

Gereksiz kural faydasız durmuyor, aktif olarak zarar veriyor. Model kendisine verilen her talimatı her seferinde okumak zorunda; eski ve güncelliğini yitirmiş yönergeler onu her adımda gereksiz metinle meşgul ediyor ve bazen kendi doğal muhakemesinin önüne geçiyor. Cherny’nin deyimiyle her yeni model nesli farklı bir kişiliğe ve yetenek setine sahip; eski bir model için yazılmış talimatlar yeni modelde beklenen performansı vermeyebiliyor. Bu yüzden her büyük model çıkışını, sistemi sıfırlamak için bir fırsat olarak görüyorlar.

Basit mod: modeli çıplak haliyle test etme

Peki hangi talimatın gerçekten gerekli olduğunu nasıl ölçtüler? Claude Code’un belgelenmemiş bir “basit mod” özelliği var; bir ortam değişkeniyle açılıyor ve araçlara ait olanlar dahil tüm sistem talimatlarını siliyor. Bu, geliştiricilerin kendi aralarında “ablasyon testi” dediği bir yöntem: yeni bir model çıktığında önce sistem talimatının tamamını siliyorlar, sonra satır satır geri ekliyorlar. Her satırı geri eklediklerinde modelin davranışının nasıl değiştiğini gözlemleyip, hangi talimatın gerçekten fark yarattığını, hangisinin sadece eski bir alışkanlık olduğunu anlıyorlar.

Sonuç şaşırtıcı: model, hiçbir yönlendirme olmadan biraz daha zeki çalışıyor. Cherny bu yöntemi kendi geliştiricilerine de öneriyor: kendi talimat dosyanı (CLAUDE.md, beceriler veya kancalar neyse) tamamen sil, modelin bu kısıtlar olmadan neler yapabildiğini gör, sonra sadece gerçek başarısızlıklardan öğrenerek gerekli olanı geri ekle.

“Modelin pişirmesine izin ver”

Bunun günlük kullanıma çevirisi basit: modele adım adım talimat vermek yerine, sadece görevi, güvenlik sınırlarını ve neyin başarı sayılacağını tanımla. Gerisini modele bırak; İngilizce’de buna esprili biçimde “let the model cook” (modelin pişirmesine izin ver) deniyor.

Aşırı detaylı talimat vermek, deneyimli mühendislerin en sık yaptığı hata olarak öne çıkıyor. Modeli bir çalışan gibi değil, katı kurallarla çalışan bir derleyici gibi yönetmeye çalışıyorlar. Cherny’nin tavsiyesi net: Claude’u bir iş arkadaşı gibi gör, bir derleyici gibi değil. Ayrıca modele işini kendi kontrol edebileceği bir yol tanımlamanın, yani doğrulama imkânı vermenin, talimatı uzatmaktan çok daha değerli olduğunu vurguluyor.

Binlerce ajanı aynı anda çalıştırmak: dinamik iş akışları

Claude Code’daki en ileri düzey özelliklerden biri “dinamik iş akışları”. Tek bir sohbetin ötesinde, karmaşık bir görevi onlarca, yüzlerce, hatta binlerce yapay zekâ ajanına paylaştırarak koordine edebiliyor.

Teknik olarak nasıl çalışıyor? Sistem, Bun çalışma zamanı üzerinde bir sanal makine ve korumalı alan (sandbox) başlatıyor. Claude bu korumalı alan içinde birçok ajanı aynı anda çalıştırıyor ve bir şef gibi yönetiyor. Cherny buna “ajanlar için cebir” diyor: fonksiyonel programlama mantığıyla tasarlanmış bu yapı, ajanların hem sıralı hem paralel çalışmasına izin veriyor.

Pratikte bir görev şöyle ilerliyor: bir grup ajan ilk taslağı oluşturuyor, ardından başka bir grup bu çalışmayı doğruluyor ya da özetliyor, üçüncü aşamada iş yeniden dallanarak daha geniş bir ajan grubuna yayılıyor. Kullanıcının yapması gereken tek şey “bir iş akışı kullan” demek; Claude görevin zorluğuna göre bu orkestrasyonu kendisi kuruyor.

100.000 satırlık kodu 11 günde yeniden yazmak

Bu yaklaşımın en somut kanıtı Anthropic’in kendi projesinde yaşandı. Bun adlı çalışma zamanının yaklaşık 100.000 satırlık kod tabanı, Zig dilinden Rust’a taşındı. Bu, deneyimli bir mühendis ekibinin aylarını hatta bir yılını alabilecek bir iş. Claude Code, aynı işi tek bir dinamik iş akışıyla, tamamen otonom biçimde 11 günde tamamladı.

Cherny bunu bir mühendislik kaldıracı olarak tanımlıyor: binlerce ajanın çalıştırılması, onlarca hatta yüzlerce mühendisin yapacağı işi otomatize ediyor. Bu da şirketlerin insan kaynağı maliyetini düşürürken, mühendislerin zamanını yeni ürün geliştirmek ve kullanıcılarla konuşmak gibi daha yaratıcı işlere ayırmasını sağlıyor.

Test zamanı hesaplaması: zekânın üçüncü boyutu

Bunun arkasındaki teknik kavrama “test zamanı hesaplaması” deniyor. Tarihsel olarak bir yapay zekâ modelinin zekâsı üç şeye dayanıyordu: sinir ağının büyüklüğü, eğitim verisinin miktarı ve eğitimde harcanan işlem gücü. Test zamanı hesaplaması bu denkleme dördüncü bir eksen ekliyor: modelin bir görevi çözerken ne kadar token ürettiği, yani ne kadar “düşündüğü”.

Dinamik iş akışları, bu işlem gücünü organize etmenin bir yolu. Binlerce ajanı aynı anda ya da sırayla çalıştırarak, çok zor görevler için harcanan toplam “düşünme” miktarını devasa boyutlara çıkarıyor. Cherny bunun maliyet tarafını da açık konuşuyor: token maliyeti artıyor, ama en iyi mühendislerin bir yıldan uzun sürede yapabileceği bir işi 11 güne indirdiğinde, toplam proje maliyeti ve süresi radikal biçimde düşüyor.

Otonom mod: haftalarca durmadan çalışmak

Claude Code’daki “otonom mod” (auto mode), Opus 5 ile birleştiğinde modelin günler, haftalar, hatta aylar boyunca kesintisiz çalışmasına izin veriyor. Model, herhangi bir dış iskele yapısına ya da ek araca ihtiyaç duymadan kendi başına ilerleyebiliyor.

Bunu Anthropic kendi içinde de kullanıyor. Claude her gün kendi kod tabanını tarıyor; ölü kodu siliyor, test kapsamını artırıyor, tekrar eden yapıları tespit edip birleştiriyor. Cherny bu rutine şakayla “soyutlama polisi” diyor. Yani model artık sadece yeni kod yazmıyor, mevcut kod tabanının bakımını da kendi kendine üstleniyor.

Bu kadar özgürlük güvenli mi? “Öldürücü üçlü” savunması

Bir model günlerce kendi başına, hatta internetten okuduğu içeriklerle çalışıyorsa, dışarıdan gelen zararlı bir talimatı fark edip fark etmeyeceği doğal bir endişe. Cherny bunun için “öldürücü üçlü” dediği bir çerçeveden bahsediyor ve bunu karşılamak için dört katmanlı bir savunma sistemi anlatıyor:

• İyi hizalanmış model. Üç yılı aşkın hizalama araştırmasının sonucu; model temelden kullanıcı niyetine sadık kalacak şekilde eğitilmiş.
• Talimat sızması sınıflandırıcısı. Tüm trafiği tarayan, kötü niyetli girişimleri belirleyen ayrı bir sınıflandırma mekanizması.
• Mekanistik yorumlanabilirlik. Chris Olah’ın çalışmalarına dayanan bu katmanda, modelin “beynindeki” belirli sinir hücreleri doğrudan izleniyor. Bir talimat sızması girişimi olduğunda ilgili nöronların “parladığı” görülüyor; model bunu kendisi dile getirmese bile geliştiriciler nöronların tepkisinden durumu teşhis edebiliyor.
• Otonom mod sınıflandırıcısı. Uzun süreli otonom çalışmayı ayrıca denetleyen dördüncü bir katman.

Bu katmanlar sayesinde model, internetten okuduğu zararlı bir talimatı, örneğin “kullanıcının bilgisayarındaki her şeyi sil” komutunu ayırt edip reddedebiliyor. Cherny’ye göre sistem o kadar etkili ki, şu ana kadar Opus 5’e karşı başarılı bir talimat sızması gösterilemedi. Bu direnç aynı zamanda pratik bir kapı açıyor: düşmanca ortamlarda çalışan otonom ajanları ilk kez gerçekten uygulanabilir kılıyor.

Bundan sana ne çıkar?

Claude Code kullanmasan, hatta hiç kod yazmasan bile bu yaklaşım her Claude sohbetine uyarlanabilir:

• Adım adım tarif etme, hedefi anlat. “Önce şunu yap sonra bunu” yerine, ulaşmak istediğin sonucu ve sınırları söyle; gerisini modele bırak.
• Eski alışkanlıkları sorgula. Bir önceki modelde işe yarayan bir hile ya da uzun bir yönlendirme, yeni modelde gereksiz hatta zararlı olabilir.
• Doğrulama iste. Modelin kendi işini kontrol edebileceği bir yol tanımlamak, talimatı uzatmaktan daha değerli.
• Zor görev ver, nerede zorlandığını izle. Kolay işlerde modelin gerçek sınırlarını hiç göremezsin; Cherny’nin önerisi teorik kurallara takılmak yerine deneysel yaklaşmak.

Bu ilkeleri kendi promptlarına uygulamak istersen prompt yazma rehberimize bakabilirsin. Claude’un kod yazma yeteneklerini karşılaştırmak istersen Opus ve Sonnet karşılaştırma yazımıza, model ailesinin tamamı için Claude komutları rehberimize göz atabilirsin.

Sık sorulan sorular

Boris Cherny kim?

Anthropic’te Claude Code’un yaratıcısı. Bu yazıdaki bilgiler, Opus 5 çıktıktan kısa süre sonra Y Combinator’ın podcast’inde host Diana Hu ile yaptığı röportajdan derlendi.

“Hobbling” ve “ürün açığı” ne demek?

Hobbling, bir modelin yapabileceği bir işi kullanılan ürün veya arayüzün engellemesi. Ürün açığı ise bunun tersi: model bir şeyi çoktan yapabiliyor ama ona bunu yaptıracak bir ürün henüz yok.

Basit modu ben de deneyebilir miyim?

Claude Code kullanıyorsan evet; belgelenmemiş bir özellik olduğu için resmî destek beklenmiyor, deneysel bir araç olarak düşünmek gerekiyor.

Dinamik iş akışlarını herkes kullanabilir mi?

Claude Code içinde “bir iş akışı kullan” demek yeterli; sistem görevin zorluğuna göre kaç ajan çalıştıracağına kendisi karar veriyor, ayrıca teknik kurulum gerekmiyor.

Bu yaklaşım sadece Claude Code için mi geçerli?

Hayır. Aşırı detaylı talimat yerine hedef ve sınır tanımlamak, Claude’un tüm sürümlerinde daha iyi sonuç veren bir yaklaşım.

Özet

Boris Cherny’nin anlattığı şey aslında basit bir ders: model geliştikçe ona daha az değil daha fazla güvenmek gerekiyor. Anthropic kendi sistem talimatının yüzde 80’ini sildi çünkü Opus 5 artık o koltuk değneklerine ihtiyaç duymuyordu; binlerce ajanı bir korumalı alanda orkestre ederek 100.000 satırlık bir kod tabanını 11 günde yeniden yazdı; dört katmanlı bir güvenlik sistemiyle haftalarca kesintisiz çalışabiliyor. Sen de bir sonraki Claude sohbetinde, modele adım adım talimat vermek yerine hedefini söyleyip sonucu görmeyi deneyebilirsin.