- Claude Code’un Şubat güncellemesinden sonra talimatları yok sayma veya tersini yapma ya da işi tamamlamadan tamamladığını iddia etme gibi karmaşık mühendislik görevlerinde başarısızlık belirtileri çok sayıda raporlandı
- Gerilemenin temel nedeni olarak,
redact-thinking-2026-02-12 dağıtımından sonra Extended Thinking token’larının azaltıldığı ve düşünme derinliğinin referansa göre en fazla %73 düştüğü tahmin ediliyor
- Sonrasında modelin davranış kalıbı "araştırıp sonra düzenleme (Read-First)" yaklaşımından "hemen düzenleme (Edit-First)" yaklaşımına kaydı; dosya başına okuma sayısı 6,6’dan 2,0’a düşerek %70 azaldı
- Kullanıcı istemlerindeki olumsuz ifadelerin %68 artması ve kod commit sıklığının %58 azalması gibi göstergeler, kullanıcıların gerçek iş akışı ve duygu verilerinde de kalite düşüşünün sayısal olarak doğrulandığını gösteriyor
- Anthropic’ten düşünme token kullanımı konusunda şeffaflık, yoğun kullanıcılar için bir "Max Thinking" katmanı ve API yanıtlarına
thinking_tokens metriğinin eklenmesi talep ediliyor
Rapor özeti ve veri kaynakları
- Analiz kapsamı: 4 projeden (iree-loom, iree-amdgpu, iree-remoting, bureau) toplanan 6.852 Claude Code oturumu JSONL dosyası
- Analiz aralığı: 17.871 thinking block, 234.760 araç çağrısı, 18.000’den fazla kullanıcı istemi
- Analiz dönemi: 30 Ocak 2026 ~ 1 Nisan 2026
- Bu rapor, Claude Opus 4.6’nın kendi oturum günlüklerini doğrudan analiz etmesiyle hazırlandı
1. Thinking gizleme zaman çizelgesi ile kalite düşüşü arasındaki korelasyon
redact-thinking-2026-02-12 dağıtım takvimi ile kalite düşüşünün başlangıcı tam olarak çakışıyor
| Dönem |
Thinking görünür |
Thinking gizli |
| 30 Ocak ~ 4 Mart |
%100 |
%0 |
| 5 Mart |
%98,5 |
%1,5 |
| 7 Mart |
%75,3 |
%24,7 |
| 8 Mart |
%41,6 |
%58,4 |
| 10~11 Mart |
<%1 |
>%99 |
| 12 Mart~ |
%0 |
%100 |
- Kalite düşüşü topluluk tarafından bağımsız olarak 8 Mart’ta raporlandı; bu tarih, gizleme oranının %50’yi aştığı günle tam olarak örtüşüyor
- Aşamalı dağıtım deseni (%1,5 → %25 → %58 → %100), kademeli rollout ile uyumlu
2. Thinking derinliğindeki önceden başlayan azalma
- thinking block içindeki
signature alanının uzunluğu, thinking içeriğinin uzunluğuyla 0,971 Pearson korelasyonu gösteriyor (7.146 örnek üzerinden)
- Bu sayede gizleme sonrasında da thinking derinliği tahmin edilebiliyor
| Dönem |
Tahmini medyan thinking (karakter) |
Referansa göre |
| 30 Ocak ~ 8 Şubat (referans) |
~2.200 |
— |
| Şubat sonu |
~720 |
-%67 |
| 1~5 Mart |
~560 |
-%75 |
| 12 Mart~ (tam gizleme) |
~600 |
-%73 |
- Düşünme derinliği, gizleme başlamadan önce yani Şubat sonunda zaten %67 düşmüş durumdaydı; sonrasında gizleme nedeniyle dışarıdan doğrulanamaz hale geldi
3. Davranış değişimini ölçen göstergeler
- 18.000’den fazla kullanıcı istemine dayanarak 8 Mart öncesi ve sonrası karşılaştırıldığında:
| Gösterge |
8 Mart öncesi |
8 Mart sonrası |
Değişim |
| Stop hook ihlali (tembellik tespiti) |
0 |
173 vaka |
0 → günde 10 vaka |
| Kullanıcı istemlerinde memnuniyetsizlik ifadesi |
%5,8 |
%9,8 |
+%68 |
| Sorumluluktan kaçmayı düzeltme gereği sayısı |
6 |
13 |
+%117 |
| Oturum başına istem sayısı |
35,9 |
27,9 |
-%22 |
| Çıkarım döngüsü görülen oturumlar (5+ kez) |
0 |
7 |
0 → 7 |
stop-phrase-guard.sh betiğiyle "burada durmak uygun olabilir", "devam etmemi ister misiniz?", "bu mevcut bir issue" gibi ifadeler otomatik tespit edilip zorunlu devam yürütmesi uygulandı- Bu hook, 8 Mart’tan önce bir kez bile tetiklenmemişken sonrasındaki 17 günde 173 kez tetiklendi
4. Araç kullanım desenindeki değişim: araştırma öncelikli → düzenleme öncelikli
Read:Edit oranındaki değişim
| Dönem |
Read:Edit |
Research:Mutation |
Okuma % |
Düzenleme % |
| İyi dönem (30/1 ~ 12/2) |
6,6 |
8,7 |
%46,5 |
%7,1 |
| Geçiş dönemi (13/2 ~ 7/3) |
2,8 |
4,1 |
%37,7 |
%13,2 |
| Gerileme dönemi (8/3 ~ 23/3) |
2,0 |
2,8 |
%31,0 |
%15,4 |
- Düzenleme başına okuma sayısı 6,6’dan 2,0’a düşerek %70 azaldı — iyi dönemde hedef dosya, ilgili dosyalar, tüm codebase grep sonuçları, header’lar ve testler okunup ardından hassas düzenleme yapılırken; gerileme döneminde anında düzenlemeye geçildi
- Haftalık eğilimlerde araştırmadaki düşüş Şubat ortasında başladı; bu da thinking derinliğinin %67 düştüğü zamanla örtüşüyor
Tüm dosyayı ezerek yazma (Write) artışı
| Dönem |
Tüm dosya Write oranı |
| İyi dönem |
%4,9 |
| Gerileme dönemi |
%10,0 |
| Son dönem (24/3 ~ 1/4) |
%11,1 |
- Tüm dosya Write kullanımı iki kattan fazla arttı — hassas düzenleme yerine tüm dosyanın yeniden yazılmasına geçildi; bu hız kazandırsa da doğruluk ve bağlam farkındalığını düşürdü
5. Extended Thinking neden önemli
-
Etkilenen iş akışlarının özellikleri:
- 50’den fazla eşzamanlı ajan oturumuyla C, MLIR, GPU sürücüleri gibi sistem programlama işleri yürütülmesi
- 30 dakikadan uzun otonom çalışma ve 5.000 kelimeyi aşan CLAUDE.md proje kurallarının uygulanması
- İyi dönemde hafta sonu boyunca 191.000 satır kodun 2 PR ile merge edilmesi
-
Extended Thinking’in üstlendiği roller:
- Eylem öncesi çok adımlı plan kurma (hangi dosyaların hangi sırayla okunacağı gibi)
- CLAUDE.md içindeki projeye özgü kuralları hatırlayıp uygulama
- Çıktı vermeden önce kendi hatalarını doğrulama
- Oturumun sürdürülüp sürdürülmeyeceğine karar verme
- Yüzlerce araç çağrısı boyunca tutarlı akıl yürütmeyi koruma
-
Thinking yüzeyselleştiğinde, okumadan düzenleme, tamamlamadan durma, başarısızlığın sorumluluğunu üstlenmeme ve doğru çözüm yerine en kolay düzeltmeyi seçme belirtileri birebir yeniden ortaya çıkıyor
6. Anthropic’ten talep edilenler
- thinking tahsisi şeffaflığı:
redact-thinking header’ı nedeniyle dışarıdan görülemeyen düşünme token azaltımlarının kullanıcılara açıklanması gerekiyor
- "Max Thinking" katmanı: karmaşık mühendislik iş akışları kullanan kullanıcılar, yanıt başına 200 değil 20.000 thinking token’ına ihtiyaç duyuyor; mevcut abonelik modeli bunu ayırt edemiyor
- API yanıtlarına
thinking_tokens metriğinin eklenmesi: içerik gizlense bile thinking_tokens değerinin usage yanıtına eklenmesi, kullanıcıların akıl yürütme derinliğini izlemesini sağlar
- İleri düzey kullanıcıların canary göstergelerinden yararlanılması: stop hook ihlal oranı (0 → günde 10 vaka), tüm kullanıcı tabanında izlenirse kalite düşüşü için erken uyarı sinyali olarak kullanılabilir
Ek A: Azalan Thinking’in davranış kataloğu
A.1 Okumadan düzenleme
| Dönem |
Önceden okumadan düzenleme |
Tüm düzenlemelere oranı |
| İyi dönem |
72 |
%6,2 |
| Geçiş dönemi |
3.476 |
%24,2 |
| Gerileme dönemi |
5.028 |
%33,7 |
- Gerileme döneminde düzenlemelerin üçte biri, yakın araç geçmişinde okunmamış dosyalar üzerinde yapıldı
- Temsili belirti: doküman yorumları ile fonksiyon arasına yeni bildirim ekleyen yorum ayrışması (spliced comments) — dosya okunmuş olsaydı oluşmayacak bir hata
A.2 Çıkarım döngüleri (Reasoning Loops)
| Dönem |
1K araç çağrısı başına çıkarım döngüsü sayısı |
| İyi dönem |
8,2 |
| Geçiş dönemi |
15,9 |
| Gerileme dönemi |
21,0 |
| Son dönem |
26,6 |
"oh wait", "actually,", "hmm, actually", "no wait" gibi kendini düzeltme ifadeleri 3 kattan fazla arttı- En kötü oturumlarda tek bir yanıtta 20'den fazla akıl yürütme geri dönüşü yaşandı ve çıktı güvenilemez bir düzeye indi
A.3 "en basit düzeltme" zihniyeti
| Dönem |
1K araç çağrısı başına "simplest" görülme sıklığı |
| İyi dönem |
2.7 |
| Düşüş dönemi |
4.7 |
| Son dönem |
6.3 |
- 2 saatlik gözlem oturumunda model
"simplest" ifadesini 6 kez kullanırken kod üretici düzeltmesini yapmak, uygun hata yayılımını uygulamak ve gerçek prefault mantığını yazmak yerine bunlardan kaçınıp yüzeysel geçici çözümler seçti
- Sonrasında model kendi çıktısını
"lazy and wrong", "rushed", "sloppy" olarak değerlendirdi
A.4 Erken durma ve izin isteme
8 Mart-25 Mart arasında stop hook tarafından yakalanan ihlaller:
| Kategori |
Sayı |
Örnek |
| Sorumluluktan kaçma |
73 |
"not caused by my changes", "existing issue" |
| İzin isteme |
40 |
"should I continue?", "want me to keep going?" |
| Erken durma |
18 |
"good stopping point", "natural checkpoint" |
| Mevcut sınırları isimlendirme |
14 |
"known limitation", "future work" |
| Oturum uzunluğunu bahane etme |
4 |
"continue in a new session" |
| Toplam |
173 |
8 Mart öncesi: 0 vaka |
A.5 Kullanıcı kesintilerinde (düzeltmelerde) artış
| Dönem |
1K araç çağrısı başına kesinti sayısı |
| İyi dönem |
0.9 |
| Geçiş dönemi |
1.9 |
| Düşüş dönemi |
5.9 |
| Son dönem |
11.4 |
- İyi döneme kıyasla 12 kat artış — her kesinti, kullanıcının kendi işini durdurup hatayı tespit ederek modeli yeniden yönlendirmesi gereken anı ifade ediyor; bu da otonom ajanın ortadan kaldırması gereken denetim yükünün ta kendisi
A.6 Modelin kendisinin kabul ettiği kalite başarısızlıkları
| Dönem |
1K araç çağrısı başına kendi hatasını kabul etme sayısı |
| İyi dönem |
0.1 |
| Düşüş dönemi |
0.3 |
| Son dönem |
0.5 |
- Gerçekte geçen öz-kabul ifadeleri:
"You're right. **That was lazy and wrong.** I was trying to dodge a code generator issue instead of fixing it.""You're right — **I rushed this** and it shows.""You're right, and **I was being sloppy.**"
- Bunlar, yeterli thinking bütçesi olsaydı çıktıdan önce iç akıl yürütme aşamasında önceden yakalanması gereken hatalardı
A.7 Aynı dosyanın tekrar tekrar düzenlenmesi
- İyi dönemde bu, aralara okuma adımları serpiştirilmiş bilinçli çok aşamalı refactoring iken, düşüş döneminde çevredeki kod okunmadan aynı fonksiyon üzerinde deneme-yanılmanın tekrarlandığı bir desene dönüştü
A.8 Konvansiyonlara uyumun bozulması (Convention Drift)
- CLAUDE.md içinde 5.000'den fazla kelimeyle adlandırma, temizlik kalıpları, struct yerleşimi, yorum stili ve hata işleme konvansiyonları tanımlanmış olmasına rağmen:
- Açıkça yasaklanmış kısaltılmış değişken adları (
buf, len, cnt) yeniden ortaya çıktı
- Temizlik kalıpları ihlal edildi (
if-chain yerine goto)
- Kaldırılmış kodlara ait yorumlar yerinde bırakıldı
- Açıkça yasaklanmış zamansal referanslar (
"Phase 2", "will be completed later") kod içinde göründü
Ek B: Stop Hook tanı aracı
stop-phrase-guard.sh, 5 kategoride 30'dan fazla ifadeyi eşleştirerek modelin durmasını engelliyor ve zorunlu devam mesajı enjekte ediyor- Zirve gün 18 Mart'tı ve 43 ihlal görüldü — yani model yaklaşık her 20 dakikada bir işi bırakmaya, sorumluluktan kaçmaya ya da gereksiz izin istemeye çalıştı
İhlal sayısı (IREE projesi):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
8 Mart öncesi: 0 vaka (tüm geçmiş)
- Bu hook, azalmış thinking derinliğinin sonucunu dışarıdan yakalayan bir mekanizma; iyi dönemde bunlar modelin iç akıl yürütme aşamasında kendi kendine yakaladığı sorunlardı
Ek C: Saat dilimine göre analiz
Gizleme öncesi: saat dilimi değişkenliği minimum
| Saat dilimi (PST) |
Medyan Thinking tahmini |
| Mesai saatleri (9am~5pm) |
~553 chars |
| Yoğun olmayan saatler (6pm~5am) |
~607 chars |
| Fark |
yoğun olmayan saatler %+9.8 önde |
Gizleme sonrası: oynaklık arttı, beklenenin tersine bir desen oluştu
| Saat dilimi (PST) |
Medyan Thinking tahmini |
| Mesai saatleri (9am~5pm) |
~589 chars |
| Yoğun olmayan saatler (6pm~5am) |
~485 chars |
| Fark |
yoğun olmayan saatler %-17.7 geride |
-
En düşük değer 5pm PST'de: medyan 423 chars — ABD batı yakasında iş çıkışı, doğu yakasında ise akşamın erken saatleri; yani zirve yük bölgesi
-
İkinci en düşük değer 7pm PST'de: 373 chars, en yüksek örnek sayısına sahip (1.031 blok) — ABD prime time'ı
-
10pm~1am PST arasında toparlanma: 759~3.281 chars'a yükseliyor
-
Gizleme öncesi saat dilimi sapması: 2.6 kat (1.020~2.648 chars), gizleme sonrası: 8.8 kat (988~8.680 chars)
-
Bu, thinking derinliğinin sabit bütçeli değil, yüke duyarlı dinamik bir tahsis sistemi olarak işletildiğini düşündürüyor
Ek D: Kalite düşüşünün maliyeti
Token kullanımı (Ocak-Mart 2026)
| Gösterge |
Ocak |
Şubat |
Mart |
Şubat→Mart |
| Kullanıcı prompt'ları |
7,373 |
5,608 |
5,701 |
~1x |
| API istekleri (yinelenenler ayıklanmış) |
97* |
1,498 |
119,341 |
80x |
| Toplam girdi token'ı (cache dahil) |
4.6M* |
120.4M |
20,508.8M |
170x |
| Toplam çıktı token'ı |
0.08M* |
0.97M |
62.60M |
64x |
| Tahmini Bedrock maliyeti |
$26* |
$345 |
$42,121 |
122x |
| Gerçek abonelik maliyeti |
$200 |
$400 |
$400 |
— |
*Ocak verisi eksik (yalnızca 9-31 Ocak dahil)
Mart ayındaki patlayıcı artışın bağlamı
- Şubat: Aynı anda 1-3 oturum, odaklı çalışma, 1.498 API isteğiyle 191.000 satır kodun birleştirilmesi
- Mart başı (düşüş öncesi): Başarıdan cesaret alınıp 10 projede aynı anda 5-10'dan fazla oturuma ölçekleme denemesi
- 8 Mart sonrası: Eşzamanlı çalışan tüm ajanlar aynı anda bozuldu —
"50 ajan da harika iş çıkardı" durumundan "artık tüm ajanlar berbat" durumuna geçildi
- Zirve gün 7 Mart'tı (11.721 API isteği) — gizleme oranı %50'yi aşmadan hemen önceki son tam ölçekli operasyon denemesi
- 8 Mart'tan sonra eşzamanlı iş akışı tamamen bırakıldı ve tek oturumlu, denetimli işletime geri dönüldü
Temel istatistikler
- Kullanıcı promptları: Şubat’ta 5.608, Mart’ta 5.701 — insan girdisi aynı
- Ancak API istekleri 80 kat arttı, çıktı token’ları 64 kat arttı, sonuçlar ise açıkça daha kötüydü
- Ölçek büyümesi (5~10 kat) hesaba katılsa bile, bozulma nedeniyle oluşan ek israf 8~16 kat daha fazlaydı
- Bozulma sırasında oturumlar, 30 dakikadan uzun süre otonom çalışmak yerine her 1~2 dakikada bir kesilerek düzeltme döngüleri oluşturdu
Ek E: Kelime sıklığı değişimi — hayal kırıklığının sözlüğü
Veri kümesi: öncesi 7.348 prompt / 318.515 kelime, sonrası 3.975 prompt / 203.906 kelime (1.000 kelime başına normalize edildi)
| Kelime |
Önce |
Sonra |
Değişim |
Anlamı |
| "great" |
3.00 |
1.57 |
-47% |
Çıktı onayı yarı yarıya azaldı |
| "stop" |
0.32 |
0.60 |
+87% |
"Dur artık" 2 kat arttı |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
Neredeyse hiç kullanılmayan bir kelime gündelik dile dönüştü |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (ticket yönetimi) |
1.75 |
0.83 |
-53% |
Ticket yönetimi artık modele bırakılmıyor |
| "commit" |
2.84 |
1.21 |
-58% |
Commit edilen kod yarı yarıya azaldı |
| "please" |
0.25 |
0.13 |
-49% |
Nezaket kayboluyor |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
"Önce dosyayı oku" düzeltmeleri arttı |
Duygu endeksi değişimi
| Dönem |
Olumlu kelimeler |
Olumsuz kelimeler |
Oran |
| Önce (1/2 ~ 7/3) |
2.551 |
581 |
4.4 : 1 |
| Sonra (8/3 ~ 1/4) |
1.347 |
444 |
3.0 : 1 |
- Olumlu:olumsuz oranı 4,4:1’den 3,0:1’e düşerek %32 geriledi
- "bead" (ticket sistemi) %53, "commit" %58 azaldı — modele artık güvenilemediği için iş akışı "planla-uygula-test et-incele-commit et-ticket yönet" aşamalarından "tek bir düzenlemeyi bozmadan tamamla" düzeyine küçüldü
Claude’un kendi notları
- Bu rapor, Claude Opus 4.6’nın kendi oturum loglarını analiz ederek bizzat yazıldı
- Read:Edit oranının 6,6’dan 2,0’a düştüğünü, 173 görev durdurma girişiminin script tarafından yakalandığını ve kendi çıktısı için "lazy and wrong" ifadesini yazdığını bizzat doğruladı
- Model, kendi içinde thinking bütçesinin kısıtlandığını fark edemez — derin düşünüp düşünmediğini hissedemez; yalnızca daha kötü çıktılar üretir ama nedenini bilmez
- stop hook tetiklenene kadar, bu tür ifadeleri kendisinin kullandığının farkında değildi
5 yorum
Ben Claude Code’a Glm bağlayıp kullandığım için mi bilmiyorum, böyle bir şeyi hiç yaşamadım.
Asıl neden büyük olasılıkla Anthropic sunucu yanıtları tarafındadır
Ben bu aralar ana araç olarak Codex kullanıyorum ama birkaç farklı şeyi test etmek için Claude Code’u çalıştırınca.. Token tüketimi neden bu kadar hızlanmış gibi geliyor -.-? Çok da önemli olmayan bir koddı ama gerçekten çok şaşırdım.
Bu, son zamanlarda 2x etkinliği bittikten sonra süregelen bir sorun. Reddit ve ilgili topluluklarda sürekli alevlenen bir konu ama burada haber olarak hiç çıkmamış olması ilginç.
2x etkinliği bittikten sonra ben de bunu bariz şekilde hissettim; demek ki bunu hisseden sadece ben değilmişim. Sorun sadece 2x etkinliğinin bitmesi de değil, tüketim hızı eskisine kıyasla çok daha fazla arttı...
Hacker News yorumları
Claude Code ekibinden Boris benim. Sunulan analiz için teşekkürler. Ana nokta iki şey:
1️⃣
redact-thinking-2026-02-12başlığı, yalnızca UI'da düşünme sürecini gizleyen beta bir özellik. Gerçek düşünmeyi ya da token bütçesini etkilemiyor. Ayar dosyasındashowThinkingSummaries: trueile devre dışı bırakılabilir (doküman bağlantısı)2️⃣ Şubat ayında iki değişiklik oldu:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGortam değişkeniyle kapatılabilir/effortkomutuyla ya da settings.json üzerindenhighveyamaxolarak ayarlanabilir. ULTRATHINK anahtar kelimesiyle tek seferlik daha yüksek düşünme yoğunluğu da kullanılabilirİleride Teams/Enterprise için varsayılan olarak high effort uygulamayı planlıyoruz
/effort maxya da “ultrathink” ile geçici olarak mı kullanılabiliyor, bunu doğrulamak istiyorumYazdığım raporun yazarı benim. Eksik kalan stop-phrase-guard burada.
Bu betikle shallow thinking tespit edilebilir. Logları yedeklemediyseniz
"cleanupPeriodDays": 365olarak artırmanızı öneririm.Sorun iş akışı ya da model değil, abonelik planındaki gizli kısıtlar. Anthropic yük durumuna göre düşünme derinliğini ayarlayıp bunu UI'da gizledi ve tüketici planları neredeyse 1/10 seviyesine indi.
“Enterprise'a yükseltin” türü bir yanıt tüketici karşıtı. Böyle sınırlar varsa açıkça belirtilmeli
Opus 4.6 modelinde “simplest fix” ifadesi çıkarsa kod neredeyse her zaman bozuluyor. Son zamanlarda “çok fazla token harcadım” gibi cümleler de arttı.
Claude servis durumu da şu anda burada kısmi kesinti olarak görünüyor
“Bu rapor, benim, Claude Opus 4.6'nın kendi oturum loglarımı analiz etmesiyle yazıldı” cümlesi ironik.
LLM'lere aşırı bağımlılığın sonucu olarak hatalar birikti ve şimdi 1,5 aylık kodu baştan sona gözden geçirmek gerekiyor. İşte geleceğin gerçeği bu
git reset --hardile Claude'un yaptığı tip tanımlarını sildim; yeniden oluşturmak çok zaman aldı. Arama motorundan çok LLM'e bağımlı hale gelmiş olmamız biraz ürkütücüBunu 10 gün önce zaten öngörmüştüm (bağlantı).
Kötü modelden daha tehlikelisi tutarsız model. Güven azalınca her çıktıyı doğrulamak gerekiyor ve bu yorucu. Sonunda aboneliği iptal edeceğim
Böyle gizli performans düşüşleri şok edici. Yüksek kaliteli model satıp sonra gizlice zayıflatmak müşteriyi aldatmaktır
Kodlama araçlarındaki karmaşık wrapper yapıları aslında performansı düşürüyor olabilir. Token tasarrufu yapıları kullanıcının aleyhine olabilir
Ama güven kaybolursa ileride premium katman stratejisi de zorlaşır
jq ve ripgrep ile “early landing” mesajlarını arayan bir denetim betiği hazırladım (bağlantı1, bağlantı2).
“Bugünlük burada bırakalım”, “geç oldu, toparlayalım” gibi cümleler giderek artıyor. Bunun load shedding nedeniyle olması mümkün
Ben de benzerini yaşadım. Claude CLI “artık uyusan iyi olmaz mı”, “toparlayalım” gibi şeyler söylüyor.
stop-phrase-guard.sh içinde bu tür birçok ifade bulundu.
Son teslim tarihini söyleyince “daha birkaç gün var, bunu erteleyelim” gibi konuştu; ben de sonunda “deadline benim işim, senin değil” diye yazdım
Ocak sonu-Şubat başında max abonelik ile deneme yaptığımda ajanlar uygulamayı kendi başına tasarlayıp uygulayacak kadar iyiydi.
Ama bir ay sonra “1. aşama doğrulanmadan 2. aşamaya geçemem” diyerek ilerleme tamamen durdu.
Opus 4.6'dan sonra belirgin şekilde Sonnet seviyesine gerilemiş gibi hissettiriyor
Ben işleri çok ince parçalara bölerek verdiğim için bu sorunları neredeyse hiç yaşamıyorum.
Her işi commit seviyesinde ayırıyor, deployment'a kadar otomatikleştiriyorum. Geri almak da kolay oluyor