- Claude Code, kullanıcı onayı olmadan A/B testleri çalıştırdı; bu da plan mode davranışının haber verilmeden değişmesine ve iş verimliliğinin düşmesine yol açtı
- Aylık $200 ödenen profesyonel bir araçta, temel özelliklerin önceden bildirilmeden değiştirilmesi şeffaflık ve kullanıcı kontrolü açısından sorunlu
- Testlerden biri, planı 40 satırla sınırlayan, bağlam bölümlerini yasaklayan ve düzyazı yerine yalnızca dosya yollarını bırakmayı söyleyen agresif bir varyanttı
- Bu testi yürüten Anthropic mühendisi, amacın rate-limit yükünü azaltmak olduğunu, ancak ilk sonuçlarda büyük bir etki görülmeyince deneyi sonlandırdıklarını söyledi
- Yapay zeka araçlarının güvenilirliği ve sorumlu biçimde dağıtılması için kullanıcı kontrolü ve şeffaf deney yönetiminin vazgeçilmez olduğu vurgulanıyor
Claude Code'un A/B testi nedeniyle kötüleşen kullanıcı deneyimi
- Claude Code'un çalışma biçimini tamamen değiştirdiğini düşünen hevesli bir kullanıcı olarak, yazar geçen hafta boyunca kendi iş akışının bozulduğunu deneyimledi
- Anthropic'in Claude Code üzerinde A/B testleri yürüttüğü ve bunun kullanıcı iş akışını aktif olarak kötüleştirdiği belirtiliyor
- A/B testinin kendisi yanlış değil ve Anthropic'in deneyimi bilerek kötüleştirme niyeti olduğu da söylenmiyor; ancak test tasarımı önemli ve plan mode gibi temel bir özelliğin hissedilen davranışını gerekçe sunmadan değiştirmek sorunlu
Ücretli araçlar için şeffaflık talebi
- Aylık $200 ödenen profesyonel bir iş aracı olduğu için, nasıl çalıştığı konusunda şeffaflık ve ayar yapabilme imkânı gerekiyor
- Temel özelliklerin haber verilmeden değişmesi ya da kullanıcı onayı olmadan yıkıcı testlere dahil edilmek kabul edilemez bulunuyor
- Yapay zeka araçlarını sorumlu biçimde yönlendirebilmek (steer) için şeffaflık ve yapılandırılabilirlik kritik; kullanıcıların bunu yapabilmesi desteklenmeli
- Mühendislerin her gün Claude Code'daki regression'lar hakkında şikâyet ettiği, bazılarının A/B testine dahil olduklarını bile bilmediği ifade ediliyor
Testin içeriği ve kanıtlar
- Oluşturulan planlar, bağlam içermeyen kısa madde işaretli listeler olarak dönmeye başladı
- Yazar, Claude'a neden bu kadar kötü plan yazdığını sorduğunda; planı 40 satırla sabitleyen, bağlam bölümlerini yasaklayan ve "düzyazıyı sil, yalnızca dosya yollarını bırak" diyen özel bir sistem talimatına uyduğunu söyledi
- Somut kanıt yönteminin Hacker News'te dikkat çekmesi nedeniyle, başkalarının aynı denemeyi yapmaması için ayrıntıların kaldırıldığı belirtiliyor
- Bu yaklaşımın şeffaflık ile sorumlu yapay zeka dağıtımı/kullanımının tam karşıtı olduğu savunuluyor
Hacker News tepkisi ve maliyet perspektifi
- Bir Hacker News yorumunda, Anthropic'in Claude Code'un her adımında işleme kapasitesiyle ilgili tercihler yapmak zorunda olduğu; her şeyi en üst düzeye çıkarmanın kullanıcı başına daha büyük zarar / daha düşük kâr anlamına gelebileceği vurgulandı
- Aylık $200'lık fiyatın gerçekte aylık $400 maliyet yaratabileceği ve her süreç aşamasında A/B testiyle taban çizgisini bulmanın rastgele sınırlar koymaktan daha iyi bir yaklaşım olabileceği görüşü paylaşıldı
Anthropic mühendisinin yanıtı
- Söz konusu testi yürüten Claude Code mühendisi, Hacker News başlığında doğrudan yanıt verdi
- plan-mode isteminin 3.x serisi modellerden bu yana büyük ölçüde değişmediği, 4.x modellerin ise çok daha az talimatla da başarılı çalışabildiği söylendi
- Hipotez, planları kısaltmanın rate-limit'e ulaşma sayısını azaltırken benzer sonuçlar verebileceği yönündeydi
- Birden fazla varyant denendi ve bu yazarla birlikte binlerce başka kullanıcı, planı 40 satırla sınırlayan en agresif varyanta atandı
- İlk sonuçlarda rate limit üzerinde büyük bir etki görülmediği için deney sonlandırıldı
- Planlama (planning) iki amaca hizmet ediyor: modelin doğru yönde kalmasına yardımcı olmak ve kullanıcının modelin bir sonraki eylemine güven duymasını sağlamak; her ikisinin de belirsiz, karmaşık ve apaçık olmayan alanlar olduğu belirtildi
Sonuç: Yapay zeka araç deneylerinde sorumluluk ve kullanıcı güveni
- Yazar, Claude Code örneği üzerinden yapay zeka araçlarındaki deneylerin kullanıcı deneyimini doğrudan etkileyebileceğini gösteriyor
- Şeffaf deney yönetimi ve kullanıcı tercih hakkının güvence altına alınmasının, profesyonel araçlarda güveni korumak için zorunlu olduğu vurgulanıyor
- Yapay zeka sistemleri gelişmeye devam etse de, insanın kontrol edebildiği bir yapının korunması gerektiği yeniden teyit ediliyor
1 yorum
Hacker News yorumları
A/B testini "kullanıcılar üzerinde sessiz deney" diye tanımlayıp Meta'dan söz etmenin abartılı olduğunu düşünüyorum
A/B testinin kendisi kötü değil; bence önemli olan test tasarımı
Ancak LLM performansını ciddi biçimde düşüren deneylerin kabul edilemez olduğunu düşünüyorum
Zaten tekrarlanabilirlik ve güvenilirlik sorunları ciddi; şirketler bunun yükünü kullanıcılara yüklüyor
Böyle bir durumda şirket gizlice deney yaparsa araştırma güvenilirliği tamamen çöker
Claude Code gibi durumlarda, A/B testi yüzünden olumsuz sonuçlar çıksa bile "deney grubunda olabilir" denilerek görmezden gelinebilir
Özellikle işe alım gibi hassas alanlarda böyle deneyler yürütülürse etik ve hukuki sorunlar çok ciddi hale gelir
Bir anda UI ya da özellik değişiyor, ekip arkadaşına soruyorsun ama kimsenin haberi olmuyor
Genelde bu değişiklikler daha kötü olmasına rağmen "nesnel veri" bahanesiyle dayatılıyor
Düğme rengi gibi küçük unsurlar bile sonuçta bir deneydir ve çoğu kullanıcıya deney yapıldığı bile söylenmez
Bu, bizzat benim yürüttüğüm bir testti
3.x serisinden beri korunan plan-mode prompt'unu 4.x modelde sadeleştirince benzer sonuç verip vermeyeceğini denedim
Planı kısaltırsak rate-limit'e daha az takılacağını varsaydım, ama büyük fark olmayınca deneyi bitirdim
Plan modu iki amaca hizmet ediyor: modelin yönünü bulmasına yardımcı olmak ve kullanıcının sonuca güvenmesini sağlamak
Maliyet, plan metninden değil arama aşamasından (subagent) kaynaklanıyor
Plan modu her zaman 3 arama ajanı başlatıyor ve oturum durumunu dikkate almıyor
Zaten yüklenmiş dosyalar olsa bile yeniden okuyup token israfına yol açıyor
Oturum sıcak olduğunda aramayı atlayan koşullu mantık daha etkili olurdu
Beklenmedik tek bir davranış beni günlerce işlevsiz bırakabilir
Bu etkiyi hesaba katmamak sorumsuz ve saldırganca
Son zamanlardaki garip davranışların deneylerden kaynaklanıyor olabilmesi çok rahatsız edici
Beta kanalı yerine açık opt-in modeline geçilmeli
Benim için satır sayısından çok planın anlatısal netliği önemli
Ne yapıldığını ve neden yapıldığını anlayabileceğim bir plan gerekli
LLM'ler dilbilgisel olarak kusursuz görünse de araya halüsinasyon karıştırıp kullanıcıyı yanıltıyor
Buna rağmen boilerplate işler ya da hızlı fikir bağlantıları için faydalılar
Ama düzgün kullanmak için temel bilgi şart
Yazının aniden bitmesinin nedeni, yazarın Claude Code binary'sini decompile etme konusuna girip ToS ihlali riski nedeniyle o kısmı silmiş olması
İlgili tartışma bu yorumda görülebilir
İki düşüncem var
Çünkü büyük ölçekli A/B testleriyle veri temelli iyileştirme yapılamaz
Örneğin man-db'nin 'after midnight' easter egg'i gibi öngörülemez değişiklikler olabilir
Bağımlılık da çok olduğundan, kod denetimini gerçekten yapan kişi sayısı azdır
Gelir odaklı bozma deneyi (enshittification) de olabilir — YouTube bunun tipik örneği
A/B testinin kendisinde sorun yok ama plan mode pek iyi değil
Çoğu durumda sonuç kötü oluyor
Yine de compaction sırasında bilgi koruma konusunda iyi
Konuşmaları bir Markdown dosyasına kaydedip her compaction'da ona başvurmasını sağlarsanız çok daha iyi sonuç alabilirsiniz
Plan mode çok daha verimli, bu yüzden neredeyse her işten önce kullanıyorum
Model uygulamaya geçmeden önce planı gözden geçirip tartışabilmek büyük avantaj
Şu an plan mode, tamamlanınca konteksti sıfırladığı için bir sonraki planı temiz kurmak açısından iyi
Blogdaki decompile ayrıntılarının ToS nedeniyle silinmiş olması üzücü
Claude'un "planı 40 satırla sınırla, bağlam bölümlerini yasakla ve düzyazıyı sil" diyen sistem talimatlarını izlediği söyleniyor
Bu ayarları doğrudan görüp düzenleyebilmek iyi olurdu
Profesyonel araçların güvenilirlik ve tekrarlanabilirlik sunması gerekir, ama LLM'ler bunu sunmuyor
A/B testleri de bunun sadece bir kanıtı
Photoshop'un tonu hafifçe değiştirmesi ya da Word'ün başlık stilini değiştirmesi gibi deneyler de aynı sorun
Uyarı olmadan yapılan A/B testlerinin kendisi problem
Kota sınırları ve model kalitesi istikrarsız; yeni model çıkmadan önce eski modelin bozulduğu dönemler oluyor
Bu deney de kullanıcı deneyimini iyileştirmekten çok maliyet düşürme testi gibi görünüyor
İş amaçlı bir araçsa tutarlılık ve güvenilirlik gerekir
Bir uzmanın, aracın güçlü ve zayıf yönlerini anlayıp ona göre kullanması gerekir
LLM çıktısını körü körüne kabul etmek profesyonelce değildir, ama bu profesyonellerin LLM kullanamayacağı anlamına da gelmez
Yeterli değerlendirme sistemi ve prompt kontrolüyle oldukça deterministik hale getirilebilir
Finans sektöründeki istikrarsız modellerin bile hâlâ kullanılabildiğini düşünürsek, öngörülemezlik mutlak bir engel değil
Ben model çıktısını bir ekip arkadaşının kod incelemesini doğrular gibi doğruluyorum
Bu durum uzun zamandır vendor lock-in diye adlandırılıyor
Belirli bir araca bağımlı hale gelirseniz, o araç değiştiğinde ya da ortadan kalktığında iş yapamaz hale gelirsiniz
Ben CC'den opencode'a geçtim
CC kapalıydı ve promptları fazla opinionated olduğu için rahatsız ediyordu
Web arama yolunu da kontrol edemiyordum
Şimdi sadece hobi amaçlı kullandığım için açık kaynağı seçtim; ama işim olsaydı muhtemelen farklı düşünürdüm
Ancak küçük projelerde kullanılabilir gibi geldi
İyi bir kurulumun varsa paylaşırsan sevinirim