Claude Code kalite raporuna ilişkin son güncelleme

• Son bir ayda hissedilen Claude kalite düşüşü, Claude Code, Claude Agent SDK, Claude Cowork genelinde yapılan birbirinden farklı üç değişiklikten kaynaklandı; API etkilenmedi
• Varsayılan çıkarım çabası medium seviyesine düşürüldükten sonra gecikme ve kullanım limiti tüketimi azaldı, ancak Claude Code daha az zekiymiş gibi hissedildiği için 7 Nisan’da varsayılan ayar geri alındı
• 26 Mart’ta dağıtılan bir önbellekleme optimizasyonu hatası, boşta kalma eşiğini aşan oturumlarda çıkarım geçmişini her turda silen bir duruma yol açtı; bu da unutkanlık, tekrar, garip araç seçimleri ve usage limits’in daha hızlı tükenmesiyle sonuçlandı
• 16 Nisan’da Opus 4.7 ile birlikte eklenen sistem istemindeki bir satır, çıktıdaki aşırı uzunluğu azaltmaya yönelik bir kısıtlamaydı; ancak daha geniş değerlendirmelerde bazı modellerin performansını %3 düşürdüğü görüldü ve 20 Nisan’da geri alındı
• Üç sorunun tamamı düzeltildi ve 20 Nisan’da yayımlanan v2.1.116 sürümüne yansıtıldı; dahili ve herkese açık derlemeler arasındaki farkın azaltılması, sistem istemi üzerindeki denetimin güçlendirilmesi, daha geniş değerlendirmeler ve kademeli dağıtım tekrar yaşanmasını önlemenin temel unsurları olarak belirlendi

---

Son kalite düşüşünün kapsamı ve toparlanma durumu

• Geçen ay bazı kullanıcıların hissettiği Claude kalite düşüşü, Claude Code, Claude Agent SDK, Claude Cowork genelinde yapılan üç ayrı değişiklikten kaynaklandı ve API etkilenmedi
• Bu üç sorun da çözüldü ve 20 Nisan’da yayımlanan v2.1.116 sürümüne dahil edildi
• Her değişiklik farklı zamanlarda ve farklı trafik dilimlerini etkilediği için, toplamda yaygın ama tutarsız bir performans düşüşü gibi göründü
• Mart başından beri ilgili raporlar incelendi, ancak ilk aşamada bunu sıradan kullanıcı geri bildirimi dalgalanmalarından ayırmak zordu; dahili kullanım ve değerlendirmelerde de başlangıçta aynı sorun yeniden üretilemedi
• 23 Nisan itibarıyla tüm abonelerin usage limits değerleri sıfırlandı

Claude Code varsayılan çıkarım çabası değişikliği

• Şubat ayında Claude Code içinde Opus 4.6 yayımlandığında varsayılan çıkarım çabası high olarak ayarlandı
• Kısa süre sonra high modunda aşırı uzun düşünme süreleri zaman zaman görülmeye başladı; bu da arayüz sanki donmuş gibi görünmesine yol açtı ve bazı kullanıcılar için gecikme ile token kullanımı aşırı arttı
• Claude Code’daki effort seviyesi, modelin daha uzun düşünüp düşünmeyeceğini ya da daha düşük gecikme ve daha az kullanım limiti tüketiminin tercih edilip edilmeyeceğini ayarlamak için kullanılır
  • Ürün katmanında, test-zamanı hesaplama eğrisinden bir varsayılan seçilir ve bu değer Messages API'ye effort parametresi olarak gönderilir
  • Diğer seçenekler /effort ile sunulur
• Dahili değerlendirmeler ve testlerde medium, görevlerin çoğunda biraz daha düşük zeka ama belirgin şekilde daha düşük gecikme sonucu verdi
  • medium, çok uzun kuyruk gecikmesi sorunlarına da daha az yol açtı
  • Ayrıca kullanıcıların usage limits değerlerini en üst düzeye çıkarmaya daha uygundu
• Bu sonuçlara dayanarak varsayılan effort medium olarak değiştirildi ve nedenleri ürün içi bir iletişim penceresinde de açıklandı
• Dağıtımdan hemen sonra kullanıcılar Claude Code’un daha az zekiymiş gibi hissettirdiğini bildirmeye başladı
  • Mevcut effort ayarını daha görünür kılmak için başlangıç bildirimi, satır içi effort seçici ve ultrathink geri yüklemesi gibi çeşitli tasarım değişiklikleri eklendi
  • Ancak kullanıcıların çoğu yine de varsayılan medium ayarında kaldı
• Ek müşteri geri bildirimleri üzerine bu karar 7 Nisan’da geri alındı
  • Artık tüm kullanıcılar için Opus 4.7'de varsayılan xhigh
  • Diğer tüm modellerde ise varsayılan high
• Bu değişiklik Sonnet 4.6 ve Opus 4.6'yı etkiledi

Önceki çıkarım geçmişini düşüren önbellekleme optimizasyonu

• Claude görev üzerinde akıl yürütürken, bu çıkarım geçmişi konuşma geçmişinde kalır ve sonraki her turda önceki düzenlemelerin ve araç çağrılarının nedenlerine başvurmaya devam etmesini sağlar
• 26 Mart’ta bu özelliğin verimliliğini artırmaya yönelik bir değişiklik dağıtıldı
  • Anthropic, art arda gelen API çağrılarını daha ucuz ve daha hızlı hale getirmek için prompt caching kullanır
  • Claude, API isteği sırasında giriş token’larını önbelleğe yazar; belirli bir hareketsizlik süresi geçince ilgili istem önbellekten kaldırılır ve başka istemler için yer açılır
  • Önbellek kullanımı dikkatle yönetilir ve ilgili yaklaşım approach bağlantısında özetlenmiştir
• Tasarım gereği, bir oturum bir saatten uzun süre boşta kaldıysa, oturumu yeniden başlatma maliyetini azaltmak için önceki thinking bölümlerinin bir kez temizlenmesi amaçlanmıştı
  • Bu istek zaten bir cache miss olacağından, gereksiz iletileri istekten kesip API’ye gönderilen uncached token sayısını azaltmak hedeflenmişti
  • Sonraki adımlarda ise yeniden tam çıkarım geçmişinin gönderilmesi planlanmıştı
  • Bunun için clear_thinking_20251015 API başlığı ve keep:1 kullanıldı
• Gerçek uygulamada bir hata vardı; thinking geçmişi yalnızca bir kez temizlenmesi gerekirken oturum bitene kadar her turda temizlenmeye devam etti
• Bir oturum boşta kalma eşiğini bir kez geçtikten sonra, o süreçteki sonraki tüm istekler için API’ye yalnızca en son çıkarım bloğu bırakılacak, öncekiler atılacak şekilde talimat verildi
• Bu sorun zamanla birikerek kötüleşti
  • Claude araç kullanırken takip mesajları gönderdiğinde, bu da bozuk bayrak altındaki yeni bir tura dönüşüyordu
  • Sonuç olarak mevcut turun çıkarımı bile düşebiliyordu
• Claude çalışmayı sürdürüyordu, ancak neden o davranışı seçtiğine dair hafızası giderek azalıyordu
  • Kullanıcı tarafında bu durum unutkanlık, tekrar ve garip araç seçimleri olarak görünüyordu
• Thinking blokları sonraki isteklerde de kaybolmaya devam ettiği için, bu istekler cache miss ile sonuçlanıyordu
  • usage limits’in beklenenden hızlı tükendiğine dair ayrı raporların da bu durumdan kaynaklandığı düşünülüyor
• Başlangıçta yeniden üretmenin zor olmasının arkasında, konuyla ilgisiz iki deney vardı
  • mesaj kuyruklama ile ilgili yalnızca dahili sunucu tarafı deneyi
  • ve thinking gösterim biçimindeki ayrı bir değişiklik, çoğu CLI oturumunda bu hatayı gizledi
• Bu hata, Claude Code’un bağlam yönetimi, Anthropic API ve extended thinking’in kesiştiği noktadaydı
  • birkaç kişinin yaptığı kod incelemesinden ve otomatik kod incelemesinden
  • birim testlerden ve uçtan uca testlerden
  • otomatik doğrulamadan ve dogfooding’den geçti
• Sorun yalnızca eski oturumlar gibi bir köşe durumda ortaya çıkıyor ve yeniden üretmesi zor olduğundan, kök nedeni bulup doğrulamak bir haftadan uzun sürdü
• Soruşturma sırasında soruna yol açan pull request’ler için Code Review, Opus 4.7 ile geriye dönük olarak test edildi
  • Gerekli kod depoları tam bağlamı oluşturacak şekilde sağlandığında Opus 4.7 hatayı buldu
  • Opus 4.6 ise bulamadı
• Bunun tekrar yaşanmaması için kod incelemesine ek depoları bağlam olarak ekleme desteği getiriliyor
• Bu hata 10 Nisan’da v2.1.101 sürümünde düzeltildi
• Bu değişiklik Sonnet 4.6 ve Opus 4.6'yı etkiledi

Aşırı uzunluğu azaltmayı amaçlayan sistem istemi değişikliği

• En yeni model olan Claude Opus 4.7, önceki modellere göre çok daha uzun çıktılar üretme eğilimine sahip
  • Bu özellik lansman duyurusunda da ele alındı; ayrıntılar wrote about bağlantısında yer alıyor
• Bu uzunluk, zor problemler üzerinde modeli daha zeki hale getirse de çıktı token sayısını da artırıyor
• Opus 4.7’nin yayımlanmasından birkaç hafta önce Claude Code, yeni modele uyum sağlamak için ayarlamalar yapmaya başladı
  • Her model biraz farklı davrandığı için, yayımdan önce harness ve ürün model bazında optimize edildi
• Uzunluğu azaltmak için model eğitimi, istem düzenleme ve ürün içindeki thinking UX iyileştirmeleri birlikte kullanıldı
• Bunlardan biri olarak sistem istemine eklenen tek satır, Claude Code’un zekası üzerinde gereğinden fazla etki yarattı
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• Haftalar süren dahili testlerde ve çalıştırılan değerlendirme setlerinde gerileme görülmediği için, bu değişikliğe güvenildi ve 16 Nisan’da Opus 4.7 ile birlikte dağıtıldı
• Sonraki inceleme sürecinde daha geniş bir değerlendirme seti kullanılarak ablation yapıldı ve sistem istemindeki her satırın etkisi ayrı ayrı ölçüldü
• Bu değerlendirmelerden birinde hem Opus 4.6 hem de 4.7 için %3 düşüş görüldü
• Bu istem, 20 Nisan sürümünün bir parçası olarak hemen geri alındı
• Bu değişiklik Sonnet 4.6, Opus 4.6, Opus 4.7'yi etkiledi

Bundan sonra yapılacak değişiklikler

• Benzer sorunlardan kaçınmak için daha fazla dahili ekip üyesinin kamuya açık derlemeyle tamamen aynı Claude Code sürümünü kullanması sağlanacak
  • Bu, yeni özellik testleri için kullanılan dahili sürümler ile gerçek herkese açık derleme arasındaki farkı azaltmayı amaçlıyor
• Dahili olarak kullanılan Code Review aracı geliştirilecek ve bu iyileştirilmiş sürüm müşterilere de sunulacak
• Sistem istemi değişiklikleri için daha sıkı kontrol süreçleri eklendi
  • Claude Code’daki tüm sistem istemi değişiklikleri için model bazında geniş değerlendirmeler yapılacak
  • Her satırın etkisini anlamak için ablation çalışmaları sürdürülecek
  • İstem değişikliklerinin daha kolay incelenip denetlenmesini sağlayacak yeni araçlar da geliştiriliyor
• CLAUDE.md içine, modele özgü değişikliklerin yalnızca ilgili modele uygulanmasını sağlayan yönergeler eklendi
• Zeka ile ödünleşime girebilecek tüm değişiklikler için soak period, daha geniş değerlendirme setleri ve kademeli dağıtım uygulanacak; böylece sorunlar daha hızlı yakalanabilecek
• Ürün kararlarını ve bunların arka planını daha ayrıntılı açıklamak için X üzerinde @ClaudeDevs hesabı oluşturuldu ve aynı güncellemeler GitHub’daki merkezi bir başlıkta da paylaşılacak
• /feedback komutu ya da çevrimiçi ortamdaki somut ve yeniden üretilebilir örnekler üzerinden iletilen bilgiler, sorunların tanımlanmasına ve düzeltilmesine yardımcı oldu
• Tüm abonelerin usage limits sıfırlaması o gün yeniden uygulandı

[GN⁺]

Hacker News görüşleri

• 1 saatten uzun boşta kalan oturumlarda eski thinking içeriğinin silinerek gecikmenin azaltıldığı açıklaması pek ikna edici gelmiyor
  Ben oturumları saatlerce, hatta günlerce boş bırakıp sonra da tüm bağlamı olduğu gibi koruyarak devam etmeyi tercih ediyorum; bu özellik de kilit önemdeydi
  Varsayılan thinking seviyesinin düşürülmesini bir ölçüde anlayabilsem de, sistem prompt'unun sürekli değişmesi kısmında yenileme aralığını bilinçli olarak seçebilmem için bunu daha iyi anlamam gerekecek gibi görünüyor

  • Claude Code'da bir konuşmada N mesaj varsa, genelde en son 1 mesaj hariç N-1 mesaj prompt cache içine giriyor
    Sorun şu ki oturumu 1 saatten fazla idle bırakırsanız, prompt yeniden gönderildiğinde N mesajın tamamı cache miss oluyor
    Bu corner case, kullanıcıların token maliyetini aşırı artırdı; uç bir örnek olarak bağlam 900k tokens ise geri döndüğünüzde cache'e 900k+ token'ı yeniden yazmanız gerekiyordu ve bu da özellikle Pro kullanıcılarının rate limit'ini ciddi biçimde tüketiyordu
    Bu yüzden X gibi yerlerde kullanıcı eğitimi yapmayı denedik, eski konuşmalara dönüldüğünde /clear öneren ürün içi ipuçlarını birkaç kez ekledik ve idle sonrası eski tool sonuçlarını, eski mesajları ve thinking'in bir kısmını atlamayı test ettik; bunlar arasında thinking'i kaldırmak en iyi performansı verdi
    Bunu yayına alırken blogda yazılan bug istemeden eklendi; sorusu olan olursa daha fazla yanıt verebileceğini söylüyor
  • Onlarca milyar dolar değerindeki bir şirketin böyle bir karar almış olması şaşırtıcı
    Ya gerçekten çıktı kalitesini feda ederek boşta kalan oturumların gecikmesini azaltmanın daha iyi olduğuna inandılar ya da asıl amaç maliyet düşürmekti ve blog yazısında latency buna makul bir gerekçe gibi sunuldu
    Bağlam yeniden yüklenirken daha belirgin bir yükleme göstergesi sunmak çok daha doğal olurdu
  • Bu epey sarsıcı
    Eskiden CC'yi bir iş arkadaşı gibi açık bırakır, bir problem üzerine biraz düşünür, planı günceller, duş alırken kafamda evirir çevirir, sonra gelip yeni tavsiyeler verirdim; en azından bir gün kadar statik bir konuşma olduğunu varsayıyordum
    Ama eşik 1 saat ise bu fazlasıyla kısa; anthropic aboneliğini sürdürüp sürdürmemeyi yeniden düşünmeme neden oluyor
  • 1 saat sonra token silme açıklamasının daha da şüpheli görünmesinin nedeni, bu sürenin kendi cache sınırlarıyla da tam örtüşmesi
    Bir tesadüften çok, maliyeti ciddi biçimde düşüren bir değişiklik gibi görünüyor
  • Bu, zamana dayalı kullanım sıfırlamasıyla da en kötü şekilde etkileşiyor olabilir
    Limitini doldurup oturumu dinlenmeye bırakan ve sonra geri dönen çok kullanıcı varsa, bu bir istisna değil, neredeyse varsayılan kullanım örüntüsü sayılır

• Bunun bu kadar sert eleştiri alması biraz şaşırtıcı
  Yazının kendisi görece açık ve dürüsttü; oldukça makul de görünüyordu
  Performans düşüşü gerçekti ve sinir bozucuydu, ama aynı zamanda arka planda tam olarak ne olduğunu göstermeyen şeffaflık eksikliğini ve keyfi görünen token maliyetlendirme yapısını da ortaya koydu
  LLM API'leriyle doğrudan çalışmış biri olarak, uzun süre ara verilen konuşmalara dönüldüğünde ek maliyet ve gecikme olacağı zaten açıktı; ama TUI içinde bunun daha görünür biçimde anlatılması gerekiyor gibi görünüyor

  • İnsanların kızgın olmasının nedeni, aylar boyunca bunun kamuya açık şekilde sorun olmadığının inkâr edilmesi
    Bu yüzden şimdi gelen açıklama da tepki topluyor

• Kalitedeki düşüşün bir kısmı modelin gerçekten kötüleşmesinden değil, deterministik olmama nedeniyle oluşan algısal farklardan kaynaklanıyor olabilir diye düşünüyorum
  Birkaç hafta önce Claude'dan kişisel kullanım için bir üretkenlik uygulaması yapmasını istemiştim; istediğim davranışı uzun uzun anlattım ve bir uygulama planı yazmasını söyledim, ilk sonuç belirsiz kalan tek bir nokta dışında gerçekten mükemmeldi
  O belirsizliği düzelttikten sonra mevcut planı güncellemesini istemeden, yeni bir sohbette her şeyi baştan tekrar yaptırdım; model ayarları aynıydı ama sonuç çok daha kötüydü, sonraki iki deneme de başarısız oldu ve ancak dördüncü denemede ilk seviyeye geri döndü
  Bu yüzden, aynı işi yeniden yaptırmanın bazen daha iyi çıktı almanın yolu olabileceğini hissettim; ama kendi token'larınızla ödüyorsanız bu hızla pahalıya patlayabilir

  • Ben de benzer görüyorum
    Modelin dönem dönem kötüleştiğini düşündüren bir örüntü var, ama aslında sadece sınırlarına sert biçimde çarpma anı daha geç geliyor olabilir
    Ve bir kez şanssız bir çıktı gördüğünüzde, sonrasında gözünüze hep o batıyor
  • O zaman iş, görüntü üretimindeki gibi tek prompt'tan 50 versiyon çıkarıp en iyisini insanın elle seçmesine mi kalacak diye düşündürüyor
    Anthropic açısından da bu tür bir kullanım kalıbı token tüketimini artırdığı için hoşlarına gidebilir
  • Riskin düşük olduğu böyle bir üretkenlik uygulamasında, burada harcadığın zamandan çok kendin yapman daha hızlı olmuş da olabilir
  • Bu olaydan LLM'lerin düşündüğümüzden çok daha deterministik olmadığını öğrenmiş olabiliriz, ama bunu doğrudan son dönemdeki performans düşüşüne bağlamak yanlış olabilir
    Deterministik olmama zaten hep vardı; yaygın biçimde bildirilen yakın dönem kalite düşüşü ise ayrı bir olgu olabilir

• Benim için kopuş Opus 4.7 ile başlamıştı
  OpenAI bizim enterprise tarafına gerçekten agresif biçimde yükleniyor ve yaz sonuna kadar sınırsız token bile teklif etti
  Bu yüzden son 30 gündür GPT5.4'ü extra high effort ile kullandım; bana özel muamele mi yapılıyor bilmiyorum ama neredeyse hiç hata görmedim
  reasoning trace de zaman zaman komik derecede iyiydi ve benim açıkça söylemeyi unuttuğum yerleri bile önceden takip edip veri bütünlüğünü %100 sağlamak için gereken unsurları tamamlıyordu

  • Ben de benzer hissediyorum
    Bu tür her türlü kurnaz değişiklik, Anthropic'in ciddi compute kısıtları yaşadığı ve bunları hafifletmek için zorlayıcı hamleler yaptığı anlamına gelebilir
  • GPT-5.4, birçok alanda Opus 4.6'dan zaten daha iyiydi; özellikle doğruluk ve zor mantık konularında üstündü
    Bu yüzden 5.5'in ne kadar daha iyi olacağını merak ediyorum
  • extra high çok fazla token yakıyor
    İşlerin %90'ında 5.4'ü medium'da çalıştırıyorum; sadece medium zorlanıyor gibi görünürse high'a çıkarıyorum, böylece hem daha odaklı oluyor hem de değişiklikler minimumda kalıyor
  • Doğru
  • Ben 4.5'e geri döndüm ve hiç pişman değilim
    Üstelik biraz daha ucuz

• Son zamanlarda Claude, sanki kendi iç prompt'una yanıt veriyormuş gibi çıktılar üretiyor
  Mesela parantez içindeki bir cümlenin prompt injection girişimi olduğu için görmezden geleceğini, ya da bunun genel yönergelerini gizletmeye çalışan bir girişim gibi göründüğünü ve bu yüzden uymayacağını söylüyor; hatta böyle bir yaklaşımın zaten her zaman uygulandığını, dolayısıyla gereksiz olduğunu ekliyor
  Ben bunların hiçbirini denememiş olmama rağmen yanıtların sonunda sık sık bu tür ifadeler görüyorum
  Görünüşe göre iç yönergelerinde özensiz yazılmış bir bölüm var ve bunu benim sorularımdan düzgün şekilde ayıramıyor

  • Ben her kod değişikliğinde testleri zorlayan stop hook scripts kullanıyorum; ama 4.7'den sonra Claude script'leri çalıştırsa da kuralları periyodik olarak görmezden gelmeye başladı
    Nedenini sorduğumda, gerekli olmadığını düşündüm diye yanıt veriyor
  • OpenAI'de de benzer şekilde kendi söylediklerine kendi cevap verdikleri durumları çok gördüm
    Şirketlerin token churn artırmak için kullandığı kolay bir yöntem gibi de görünüyor
  • Kendi ürettiği noktaları memory'ye yazıp sonra bunlara ben söylemişim gibi yeniden atıf yaptığını da sık görüyorum
    Böyle olunca model bir şeyi kesin kabul ediyor, bunu hafızaya yazıyor, sonra o hafızaya dönüp üstüne daha fazlasını inşa ediyor; açıkça durmasını söylesem bile bazen devam ediyor
  • effort seviyesiyle gerçek prompt'u merak ediyorum
    Çok yüksek reasoning effort ayarlarında benzer bir koku alıyorum; bu prompt'ta çıkarım yoğunluğunu biraz düşürmek işe yarayabilir
  • Claude'a sık sık commit ve PR da yaptırıyorum; geçen hafta commit sürecinde gereksiz ek işler çıkardığı birkaç durum gördüm
    git add aşamasında takıldı ama auto mode'da bir seferinde neredeyse fark edilmeden geçecekti

• Varsayılan reasoning effort seviyesinin high'dan medium'a düşürülme gerekçesinin, gecikmenin UI donmuş gibi görünecek kadar uzaması olması daha da kuşkulu geliyor
  Bu, UI'ı düzeltmek yerine önce varsayılan çıkarım yoğunluğunu düşürdükleri anlamına geliyor ve ardından performans düşüşü raporlarını ciddiyetle takip ettiklerini söylemeleri pek inandırıcı değil

  • Ekip her ikisini de yaptıklarını söylüyor
    thinking yüklenme durumunu iyileştirmişler, indirilen token sayısını gösterme biçimini daha anlaşılır hale getirmek gibi UI üzerinde de birkaç kez çalışmışlar
    Yine de eval ve dogfooding sonrasında varsayılan effort'u düşürmüşler; bunun yanlış bir karar olduğunu anlayıp geri almışlar
    İnsanların /effort ile zekâyı artırabileceklerini iyi anlamadıklarını ve çoğunun varsayılanda kaldığını, bunu önceden tahmin etmeleri gerektiğini de kabul ediyorlar

• 1 saatten uzun idle oturumların corner case olduğu sözü benim kullanım biçimimle hiç örtüşmüyor
  Kişisel işlerimde Claude Code'a sık sık 10-15 dakikalık görevler veriyorum ve çalıştırmadan önce modelle plan üstünde birkaç tur gidip gelerek epey zaman harcıyorum
  Çalıştırma başlayınca kahve almaya gidiyor ya da Codex'te başka bir projeye geçiyorum; bu yüzden Claude'a dönmemin 1 saatten uzun sürmesi çok olası

  • Bu muhtemelen yalnızca geliştiricilerin bakış açısından corner case'tir
    Kendi kullanım alışkanlıklarını tüm kullanıcı davranışıyla karıştırmak, ürün geliştirmede çok yaygın bir tuzak
  • Bu ifade, bu kadar büyük bir değişiklik yaparken tam da o edge case'i yeterince doğrulamadıkları anlamına da geliyor olabilir; bu da test disiplinine dair soru işaretleri doğuruyor

• Büyük frontier lab'lerin benimsediği kara kutu yaklaşımı eninde sonunda insanları uzaklaştıracak
  Temel davranışı bu şekilde değiştirip önceden haber vermeyip sonra açıklama yapmak, kullanıcıları sonunda self-hosted modeller tarafına itecek
  Zemin sürekli oynuyorsa onun üstüne pipeline, workflow ve ürünleri güvenle inşa etmek mümkün değil

• Görünüşe göre Anthropic tarafında Claude Code ekibinden kişiler yorumları okuyor; birkaç gün önce theo t3.gg'nin Claude'un aptallaşıp aptallaşmadığına dair videosunu izledim
  Üslubu sertti ve abartılı laflar da vardı ama özellikle harness bloat konusundaki eleştirileri bence oldukça isabetliydi
  Artık yeni özellik eklemeyi bir süre durdurup cilalama ve optimizasyonu sert biçimde öne çıkarmaları gerektiğini düşünüyorum
  Aksi halde daha hafif ve optimize alternatif arayanların sayısı artacak; asıl mesele harness'i iyileştirip token tüketimini azaltmak
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Diğer her şeyi bir kenara bıraksak bile, Pro planda CC desteğini kaldırmayı düşündükleri deney bile beni ciddi biçimde alternatif düşünmeye itti
    Vendor lock-in konusunda zaten temkinliydim ama o olay iyi bir uyarı oldu; muhtemelen önce opencode+openrouter tarafına bakacağım
  • theo'nun GPT 5 abartı videosunu ve sonradan bunu geri alışını asla unutmamak lazım
    Bazı içerik üreticileriyle OpenAI arasında para ya da etki üzerinden arkada bir şeylerin döndüğü açıkça hissediliyor
  • Dürüst olmak gerekirse, bu bazen yalnızca git reset --hard ile çözülecek bir mesele gibi de görünüyor

• Bu, çekirdek ürün kalitesi yerine özellik eklemeye saplantılı olmanın sonucu gibi duruyor
  Anthropic'in birkaç kıdemli ürün liderine daha ihtiyacı varmış gibi geliyor; “Escaping the Build Trap” benzeri bir bakış açısı faydalı olurdu
  Şu anda bir özelliği hızlıca ekleyebiliyor olmak, mutlaka eklenmesi gerektiği anlamına gelmiyor
  Ünlü bir kitaba atıf yapıyorum diye klişe ürün organizasyonu lafları etmek istemiyorum; ama iyi ürün sezgisi, iyi mühendislikten farklı bir yetenek ve son dönemde Anthropic'te bu taraf eksik görünüyor

  • Talebi karşılamaları gerekiyor ama compute kaynaklarının açıkça yetersiz olduğu anlaşılıyor
    Bu yüzden bu tür özellikleri eklemezlerse sistem çökebilir ya da yeni müşteri alamaz hale gelebilirlerdi; iki seçenek de kabul edilemez olduğundan fazla hareket alanları olmayabilir
  • Bir dönem yaklaşık 100 geliştiricinin yıllık 600 bin dolar aldığı bir yerdi; yetenek eksikliği sorun değildir
    Asıl sorun daha çok vibe coding anlatısını fazla zorlamaları gibi görünüyor; hatta bu yüzden mülakat tekliflerini reddeden adaylar olduğu söyleniyor
  • Zaten karmaşıklık tuzağına derin biçimde saplanmış gibiler
    Modelin olasılıksal doğası bir problem ama artık kendi yazılımlarını kendilerinin de düzgün akıl yürütemediği bir aşamaya gelmiş gibiler
    Çok fazla kol ve ayar var; kod tabanının tamamını kimsenin gerçekten anlamıyor olması da muhtemel
    Daha kötüsü, Dario ve benzerlerinin açıklamalarına bakınca yönetimin bu kalite kaygılarına pek empati göstermediği hissediliyor
    SWE'lerin yerinin doldurulabilir olduğu anlayışı altında, araca guard rail koyma talepleri ya görmezden geliniyor ya da aktif biçimde bastırılıyor gibi; sonuçta Claude Code baştan beri bir bilim deneyi gibi başladı ve hâlâ olgun best practice'lere sahip bir ürün gibi kokmuyor