हाल की Claude Code गुणवत्ता रिपोर्ट पर अपडेट

 (anthropic.com)
3 पॉइंट द्वारा GN⁺ 6 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पिछले एक महीने में महसूस हुई Claude गुणवत्ता में गिरावट Claude Code, Claude Agent SDK, Claude Cowork में हुए तीन अलग-अलग बदलावों से आई थी, और API प्रभावित नहीं हुआ
  • डिफ़ॉल्ट reasoning effort को medium पर घटाने के बाद latency और usage limits का दबाव कम हुआ, लेकिन Claude Code कम समझदार जैसा लगा, इसलिए 7 अप्रैल को डिफ़ॉल्ट फिर वापस बदला गया
  • 26 मार्च को deploy किए गए caching optimization bug ने idle threshold पार कर चुके sessions में हर turn पर reasoning history मिटने की स्थिति बना दी, जिससे भूलना, दोहराव, अजीब tool selection, और usage limits का तेज़ी से ख़र्च होना हुआ
  • 16 अप्रैल को Opus 4.7 के साथ जोड़ी गई system prompt की एक पंक्ति output verbosity कम करने की सीमा थी, लेकिन व्यापक evaluation में कुछ models का performance 3% गिर गया, इसलिए 20 अप्रैल को इसे वापस लिया गया
  • तीनों समस्याएँ अब ठीक हो चुकी हैं और 20 अप्रैल को जारी v2.1.116 में शामिल की गईं; internal और public builds के अंतर को कम करना, system prompt पर कड़ा नियंत्रण, और व्यापक evaluation व gradual rollout को दोबारा ऐसी समस्या रोकने की कुंजी माना गया है

हाल की गुणवत्ता गिरावट का दायरा और रिकवरी स्थिति

  • पिछले एक महीने में कुछ users ने जो Claude गुणवत्ता में गिरावट महसूस की, वह Claude Code, Claude Agent SDK, Claude Cowork में हुए तीन अलग-अलग बदलावों से आई थी, और API प्रभावित नहीं हुआ
  • तीनों समस्याएँ अब हल हो चुकी हैं, और 20 अप्रैल को जारी v2.1.116 में शामिल हैं
  • हर बदलाव ने अलग-अलग समय पर और अलग-अलग traffic segments को प्रभावित किया, इसलिए कुल मिलाकर यह व्यापक लेकिन असंगत performance degradation जैसा दिखा
  • मार्च की शुरुआत से संबंधित reports की जाँच की गई, लेकिन शुरुआत में इन्हें सामान्य user feedback variability से अलग पहचानना मुश्किल था, और internal usage व evaluation में भी शुरू में वही समस्या reproduce नहीं हुई
  • 23 अप्रैल तक सभी subscribers के usage limits reset कर दिए गए

Claude Code का डिफ़ॉल्ट reasoning effort बदलाव

  • फरवरी में Claude Code पर Opus 4.6 जारी करते समय डिफ़ॉल्ट reasoning effort high पर सेट था
  • इसके तुरंत बाद high mode में बहुत लंबा सोचने का समय कभी-कभी आने लगा, जिससे UI अटका हुआ लगने लगा, और कुछ users के लिए latency व token usage बहुत बढ़ गया
  • Claude Code में effort level इस बात को नियंत्रित करने का साधन है कि मॉडल ज़्यादा देर सोचे या कम latency और कम usage limits खपत को चुने
    • product layer में test-time compute curve के एक डिफ़ॉल्ट बिंदु को चुनकर Messages API में effort parameter के रूप में भेजा जाता है
    • दूसरे विकल्प /effort के ज़रिए दिए जाते हैं
  • internal evaluation और testing में medium ने ज़्यादातर tasks पर थोड़ी कम intelligence और काफी कम latency का परिणाम दिया
    • medium में बहुत लंबे tail latency की समस्या भी कम थी
    • और users के usage limits को अधिकतम करने में भी यह बेहतर था
  • इन्हीं परिणामों के आधार पर डिफ़ॉल्ट effort को medium में बदला गया और product के अंदर dialog के ज़रिए उसका कारण भी बताया गया
  • deploy होते ही users को लगने लगा कि Claude Code कम समझदार हो गया है
    • मौजूदा effort setting को अधिक स्पष्ट दिखाने के लिए startup notification, inline effort selector, और ultrathink recovery जैसी कई design changes जोड़ी गईं
    • लेकिन अधिकतर users फिर भी medium डिफ़ॉल्ट पर ही रहे
  • अतिरिक्त customer feedback को देखते हुए 7 अप्रैल को यह फ़ैसला वापस लिया गया
    • अब सभी users के लिए Opus 4.7 में xhigh डिफ़ॉल्ट है
    • और बाकी सभी models में high डिफ़ॉल्ट के रूप में लागू है
  • इस बदलाव का असर Sonnet 4.6 और Opus 4.6 पर पड़ा

पिछली reasoning history गिराने वाला caching optimization

  • जब Claude किसी task पर reasoning करता है, तो उसकी reasoning history conversation history में बनी रहती है, ताकि बाद के हर turn में वह पहले किए गए edits और tool calls के कारणों का संदर्भ ले सके
  • 26 मार्च को इस सुविधा की efficiency बढ़ाने के लिए एक बदलाव deploy किया गया
    • Anthropic लगातार आने वाले API calls को सस्ता और तेज़ बनाने के लिए prompt caching का उपयोग करता है
    • Claude API request के समय input tokens को cache में लिखता है, और एक निश्चित idle समय बीतने पर वह prompt cache से हटा दिया जाता है ताकि दूसरे prompts के लिए जगह खाली हो सके
    • cache utilization को सावधानी से manage किया जाता है, और संबंधित approach इस approach में संक्षेपित है
  • design के अनुसार, अगर session एक घंटे से ज़्यादा idle रहा हो, तो session resume की लागत कम करने के लिए पहले की thinking segments को एक बार हटाना था
    • वह request वैसे भी cache miss होती, इसलिए request से गैर-ज़रूरी messages काटकर API को भेजे जाने वाले uncached tokens की संख्या कम करनी थी
    • उसके बाद फिर से पूरी reasoning history भेजी जानी थी
    • इसके लिए clear_thinking_20251015 API header और keep:1 का उपयोग किया गया
  • लेकिन वास्तविक implementation में bug था, और thinking history को सिर्फ़ एक बार साफ़ करना था, पर session ख़त्म होने तक हर turn पर लगातार साफ़ किया जाता रहा
  • एक बार session idle threshold पार कर गया, तो उसके बाद उस process की सभी requests API को इस तरह भेजी गईं कि सबसे हाल का reasoning block छोड़कर पहले वाले हटा दिए जाएँ
  • यह समस्या cumulative तरीके से और बिगड़ती गई
    • अगर Claude tools का उपयोग करते हुए follow-up message भेजता था, तो वह भी टूटे हुए flag के नीचे एक नया turn बन जाता था
    • नतीजतन मौजूदा turn की reasoning भी गिर सकती थी
  • Claude चलता तो रहा, लेकिन उसने वह behavior क्यों चुना इसकी memory धीरे-धीरे खोता गया
    • users को यह भूलना, दोहराव, और अजीब tool selection के रूप में दिखा
  • क्योंकि आगे की requests में भी thinking blocks गायब होते रहे, वे requests cache miss में बदलती रहीं
    • usage limits उम्मीद से तेज़ी से ख़र्च होने की अलग रिपोर्टें भी इसी घटना से जुड़ी मानी गईं
  • शुरुआत में reproduce करना मुश्किल होने के पीछे दो असंबंधित experiments भी थे
    • message queueing से जुड़ा internal-only server-side experiment
    • और thinking display के अलग बदलाव ने ज़्यादातर CLI sessions में इस bug को छिपा दिया
  • यह bug Claude Code के context management, Anthropic API, और extended thinking के मिलने वाले बिंदु पर था
    • इसने कई लोगों के code review और automated code review
    • unit tests और end-to-end tests
    • automated verification और dogfooding तक पार कर लिया
  • यह समस्या केवल पुराने sessions जैसे corner case में होती थी और reproduce करना भी कठिन था, इसलिए root cause खोजने और पुष्टि करने में एक हफ़्ते से ज़्यादा लगा
  • जाँच के दौरान समस्या पैदा करने वाले pull requests पर Code Review को Opus 4.7 के साथ backtest किया गया
    • जब पूरा संदर्भ इकट्ठा करने के लिए ज़रूरी code repositories साथ दी गईं, तो Opus 4.7 ने bug ढूँढ लिया
    • Opus 4.6 ऐसा नहीं कर पाया
  • ऐसी स्थिति दोबारा न हो, इसके लिए code review में अतिरिक्त repositories को context के रूप में जोड़ने का support लाया जा रहा है
  • यह bug 10 अप्रैल को v2.1.101 में ठीक किया गया
  • इस बदलाव का असर Sonnet 4.6 और Opus 4.6 पर पड़ा

verbosity कम करने के लिए किया गया system prompt बदलाव

  • नवीनतम model Claude Opus 4.7 में पिछले models की तुलना में बहुत verbose output देने की प्रवृत्ति है
    • launch announcement में भी इस विशेषता का ज़िक्र किया गया था, और अधिक जानकारी wrote about में देखी जा सकती है
  • यह verbosity कठिन समस्याओं पर इसे अधिक समझदार बनाती है, लेकिन output tokens की संख्या भी बढ़ाती है
  • Opus 4.7 के launch से कुछ हफ़्ते पहले से Claude Code इस नए model के लिए tuning कर रहा था
    • हर model थोड़ा अलग behave करता है, इसलिए release से पहले harness और product को model-specific तरीके से optimize किया जाता है
  • verbosity कम करने के लिए model training, prompting, और product के अंदर thinking UX improvements का साथ में उपयोग किया गया
  • इनमें system prompt में जोड़ी गई एक पंक्ति ने Claude Code की intelligence पर ज़रूरत से ज़्यादा असर डाला
    • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
  • कई हफ़्तों की internal testing और चलाए गए evaluation sets में regression नहीं दिखा, इसलिए इस बदलाव पर भरोसा करके इसे 16 अप्रैल को Opus 4.7 के साथ deploy किया गया
  • बाद की जाँच में व्यापक evaluation sets के साथ ablation चलाया गया, ताकि system prompt की हर पंक्ति के असर को अलग करके देखा जा सके
  • उनमें से एक evaluation में Opus 4.6 और 4.7 दोनों पर 3% गिरावट देखी गई
  • यह prompt 20 अप्रैल release के हिस्से के रूप में तुरंत वापस लिया गया
  • इस बदलाव का असर Sonnet 4.6, Opus 4.6, Opus 4.7 पर पड़ा

आगे क्या बदलेगा

  • ऐसी मिलती-जुलती समस्याओं से बचने के लिए अधिक internal staff को ठीक वही Claude Code इस्तेमाल कराया जाएगा जो public build में है
    • इसका उद्देश्य नई features की testing के लिए internal version और वास्तविक public build के बीच का अंतर कम करना है
  • internal रूप से इस्तेमाल होने वाले Code Review tool को बेहतर बनाया जाएगा, और इसका सुधरा हुआ संस्करण customers को भी दिया जाएगा
  • system prompt changes के लिए अधिक सख़्त control procedures जोड़ी जा रही हैं
    • Claude Code के सभी system prompt changes पर model-by-model व्यापक evaluation किए जाएँगे
    • हर पंक्ति के प्रभाव को समझने के लिए ablation जारी रहेगा
    • prompt changes को आसानी से review और audit करने के लिए नए tools भी बनाए जा रहे हैं
  • CLAUDE.md में model-specific changes केवल उसी model पर लागू हों इसके लिए guidance जोड़ी गई है
  • intelligence के साथ trade-off ला सकने वाले सभी बदलावों पर soak period, व्यापक evaluation sets, और gradual rollout लागू किया जाएगा ताकि समस्याएँ जल्दी पकड़ी जा सकें
  • product decisions और उनके पीछे की वजह को ज़्यादा विस्तार से समझाने के लिए X पर @ClaudeDevs बनाया गया है, और वही updates GitHub के centralized thread में भी साझा की जाएँगी
  • /feedback command या online दिए गए ठोस और reproducible examples से मिली जानकारी ने समस्या की पहचान और fixes तक पहुँचने में मदद की
  • सभी subscribers के usage limits reset उसी दिन फिर से लागू किए गए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 일 전
Hacker News की राय

  • 1 घंटे से ज़्यादा idle session में पुराने thinking को हटाकर latency कम की गई, यह बात ठीक से समझ नहीं आती
    मैं अक्सर session को कई घंटे या कई दिनों तक छोड़कर भी पूरा context जस का तस रखकर वहीं से आगे काम करता हूँ, इसलिए यह feature मेरे लिए core था
    default thinking level कम करना कुछ हद तक समझ आता है, लेकिन system prompt लगातार बदलने वाली बात में लगता है मुझे जानना पड़ेगा कि refresh cycle को मैं जानबूझकर कैसे चुन सकता हूँ

    • Claude Code में अगर conversation में N messages हों, तो आमतौर पर सबसे नया 1 छोड़कर N-1 messages prompt cache में चले जाते हैं
      समस्या यह है कि अगर session को 1 घंटे से ज़्यादा idle छोड़ दिया जाए, तो prompt दोबारा भेजते समय N के सभी messages cache miss हो जाते हैं
      इस corner case ने user token cost को बहुत बढ़ा दिया, और अगर context 900k tokens जैसा बड़ा हो, तो वापस लौटने पर cache में 900k+ tokens फिर से लिखने पड़ते, जिससे खासकर Pro users की rate limit बुरी तरह घट जाती
      इसलिए X जैसी जगहों पर user education भी की गई, पुराने conversation पर लौटने पर /clear सुझाने वाले in-product tips भी कई बार डाले गए, और idle के बाद पुराने tool results, पुराने messages, और thinking के कुछ हिस्से छोड़ने के तरीके भी आज़माए गए, जिनमें thinking हटाना सबसे अच्छा चला
      उसे deploy करने की प्रक्रिया में blog में लिखी bug अनजाने में आ गई, और कहा गया कि सवाल हों तो वे और जवाब देंगे
    • यह हैरानी की बात है कि सैकड़ों अरब डॉलर valuation वाली कंपनी ने ऐसा फैसला लिया
      या तो उन्हें सच में लगा कि output quality गिराकर भी idle sessions की latency कम करना बेहतर है, या फिर असली मकसद cost cutting था और blog में latency को बस एक ठीक-ठाक बहाना बनाया गया
      context फिर से load होने तक loading indicator को ज़्यादा साफ़ दिखाना कहीं ज़्यादा स्वाभाविक लगता
    • यह काफ़ी चौंकाने वाला है
      पहले मैं CC को किसी सहकर्मी की तरह रखता था, थोड़ी देर समस्या पर सोचता, plan update करता, नहाते समय सोचता, फिर नया advice डाल देता, और कम से कम एक दिन तक static conversation मानकर चलता था
      लेकिन अगर cutoff 1 घंटा है, तो यह बहुत छोटा है और इससे anthropic plan जारी रखने पर फिर से सोचना पड़ रहा है
    • 1 घंटे बाद tokens हटाने की बात और भी संदिग्ध लगती है, क्योंकि वही समय उनके cache limit से भी बिल्कुल मेल खाता है
      यह महज़ संयोग से ज़्यादा, cost को बहुत घटाने वाला बदलाव लगता है
    • यह time-based usage reset के साथ भी बहुत बुरी तरह interact करेगा
      अगर बहुत से users limit ख़त्म होने के बाद session को छोड़ दें और फिर लौटें, तो यह exception नहीं बल्कि लगभग default usage pattern है

  • इतनी तीखी प्रतिक्रिया थोड़ी अप्रत्याशित है
    post खुद काफ़ी स्पष्ट और ईमानदार थी और काफ़ी हद तक भरोसेमंद लगी
    performance drop सच था और परेशान करने वाला भी, लेकिन साथ ही इसने यह opacity भी दिखा दी कि पीछे असल में क्या हो रहा है, और token cost charging की मनमानी-सी संरचना भी सामने आ गई
    जिसने LLM API सीधे इस्तेमाल किए हैं, उसके लिए लंबे समय बाद conversation resume करने पर extra cost और latency आना स्वाभाविक था, लेकिन TUI में इस बात को और स्पष्ट दिखाना चाहिए

    • लोग इसलिए नाराज़ हैं क्योंकि कई महीनों तक उन्होंने सार्वजनिक रूप से कहा कि कोई समस्या नहीं है
      इसलिए अब स्पष्टीकरण आने पर भी नाराज़गी बनी हुई है

  • quality में कुछ गिरावट शायद model के सचमुच खराब होने से नहीं, बल्कि non-determinism के कारण महसूस हो रही हो
    कुछ हफ़्ते पहले मैंने Claude से एक personal productivity app बनवाने के लिए लंबे text में मनचाहा behavior समझाया और implementation plan लिखने को कहा, तो पहली output एक अस्पष्ट हिस्से को छोड़कर शानदार थी
    उस ambiguity को ठीक करने के बाद, पुराने plan को edit कराए बिना मैंने नई chat में वही काम फिर शुरू से कराया; model settings वही थीं, लेकिन नतीजा बहुत खराब था, अगले दो प्रयास भी विफल रहे, और चौथे try में जाकर पहली बार जैसी quality वापस आई
    इसलिए लगता है कि एक ही काम दोबारा कह देना कई बार बेहतर output पाने का तरीका हो सकता है, हालांकि अपने tokens से भुगतान कर रहे हों तो यह जल्दी महँगा पड़ सकता है

    • मुझे भी कुछ ऐसा ही लगता है
      एक pattern दिखता है कि model समय-समय पर खराब हो जाता है, लेकिन असल में यह भी हो सकता है कि उसकी सीमाओं से ज़ोरदार टकराव थोड़ा देर से हो
      और एक बार bad luck वाली output मिल जाए, तो उसके बाद वही चीज़ बार-बार दिखने लगती है
    • तो क्या image generation की तरह एक prompt पर 50 versions निकलवाकर इंसान को हाथ से सबसे अच्छा चुनना पड़ेगा
      Anthropic के नज़रिए से यह usage pattern token consumption बढ़ाता है, इसलिए उन्हें यह मॉडल पसंद भी आ सकता है
    • अगर productivity app उतना ही low-stakes था, तो संभव है कि इसमें लगाया गया समय खुद बनाना ज़्यादा तेज़ होता
    • इस घटना से यह तो सीखा कि LLM हमारी सोच से कहीं ज़्यादा non-deterministic हैं, लेकिन इसे हाल की performance गिरावट से सीधे जोड़ना ग़लत हो सकता है
      non-determinism तो पहले से थी, और व्यापक रूप से रिपोर्ट हुई हाल की quality गिरावट शायद अलग phenomenon हो

  • मेरा मन तो Opus 4.7 पर ही उठ गया था
    OpenAI हमारी enterprise side में काफ़ी आक्रामक तरीके से घुसने की कोशिश कर रहा है, और गर्मियों तक unlimited tokens तक offer किए गए
    इसलिए मैंने पिछले 30 दिनों से GPT5.4 को extra high effort पर इस्तेमाल किया, और पता नहीं मुझे special treatment मिल रहा है या नहीं, लेकिन मैंने लगभग कोई गलती नहीं देखी
    reasoning trace भी कभी-कभी हँसी ला देने जितना अच्छा था, और जहाँ मैं instruction देना भूल गया था, वहाँ भी उसने आगे समझकर data integrity को 100% सही रखने के लिए ज़रूरी चीज़ें संभाल लीं

    • मुझे भी कुछ ऐसा ही लगता है
      इस तरह के सारे trick-type changes शायद इसलिए हैं क्योंकि Anthropic पर compute constraints ज़्यादा हैं और वे दबाव में कटौती कर रहे हैं
    • GPT-5.4 पहले ही कई क्षेत्रों में Opus 4.6 से बेहतर था, खासकर accuracy और tricky logic में
      इसलिए 5.5 कितना बेहतर होगा, यह देखने की उत्सुकता है
    • extra high बहुत ज़्यादा tokens जला देता है
      90% काम के लिए 5.4 को medium पर चलाना बेहतर है, और सिर्फ तब high पर जाना चाहिए जब medium कम पड़ता दिखे; इससे focus बेहतर रहता है और बदलाव भी कम होते हैं
    • सही बात है
    • मैं तो 4.5 पर वापस चला गया और कोई पछतावा नहीं है
      ऊपर से थोड़ा सस्ता भी है

  • हाल में Claude अक्सर ऐसे outputs दे रहा है जैसे वह अपने ही internal prompt का जवाब दे रहा हो
    जैसे कहता है कि कोष्ठकों के अंदर का वाक्य prompt injection की कोशिश लगता है इसलिए उसे ignore करेगा, या यह कि कोई उसकी general guidelines छिपाने की कोशिश कर रहा है इसलिए वह नहीं मानेगा, या फिर कि ऐसी तरकीबें पहले से लागू हैं इसलिए अनावश्यक हैं
    जबकि मैंने ऐसा कुछ भी करने की कोशिश नहीं की, फिर भी जवाब के अंत में ऐसी पंक्तियाँ अक्सर जुड़ जाती हैं
    लगता है internal guidelines में कहीं कुछ भद्दा हिस्सा है और वह उसे मेरे सवाल से ठीक से अलग नहीं कर पा रहा

    • मैं code changes के लिए tests enforce करने वाले stop hook scripts इस्तेमाल करता हूँ, लेकिन 4.7 के बाद Claude scripts चलाता तो है, फिर भी समय-समय पर नियमों को ignore कर देता है
      वजह पूछने पर कहता है कि उसे लगा ज़रूरत नहीं थी
    • OpenAI में भी ऐसा बहुत देखा है, जहाँ model अपनी ही बात का खुद जवाब देता है
      यह कंपनियों के लिए token churn बढ़ाने का आसान तरीका भी लगता है
    • यह भी अक्सर देखा है कि model अपने बनाए हुए points को memory में डाल देता है और बाद में उन्हें मेरे दावे की तरह फिर से reference करता है
      तब एक self-reinforcing loop बन जाता है जिसमें model कुछ assert करता है, उसे memory में रखता है, फिर उसी memory को देखकर और परतें जोड़ता जाता है, और मैं साफ़ तौर पर रोकूँ तब भी कभी-कभी जारी रखता है
    • effort level और actual prompt जानने की जिज्ञासा है
      यह बहुत ऊँचे reasoning effort की गंध भी हो सकती है, इसलिए उस prompt में reasoning intensity थोड़ा कम करने से सुधार हो सकता है
    • मैं Claude को अक्सर commit और PR तक सौंप देता हूँ, और पिछले हफ़्ते कई बार देखा कि commit process में वह फ़ालतू अतिरिक्त काम अपने आप करने लगा
      git add पर जाकर वह रुक गया, लेकिन auto mode में एक बार यह लगभग निकल ही गया था

  • default reasoning effort को high से medium करने की वजह अगर यह थी कि latency इतनी लंबी थी कि UI जमी हुई लगती थी, तो यह और संदिग्ध लगता है
    इसका मतलब UI ठीक करने के बजाय default reasoning intensity कम की गई, और फिर यह कहना कि performance degradation reports को गंभीरता से ट्रैक किया गया, आसानी से मानने लायक नहीं है

    • टीम का कहना है कि दोनों काम किए गए
      thinking loading state सुधारी गई, download हो रहे tokens की संख्या को ज़्यादा स्पष्ट किया गया, यानी UI पर भी कई बार काम हुआ
      फिर भी eval और dogfooding के बाद default effort कम किया गया, लेकिन वह ग़लत निर्णय था और उसे वापस पलटा गया
      उन्होंने माना कि लोग /effort से intelligence बढ़ाकर इस्तेमाल करना समझ नहीं पाए और default पर ही टिके रहे; यह पहले से समझ लेना चाहिए था

  • 1 घंटे से ज़्यादा idle session को corner case कहना मेरे usage pattern से बिल्कुल मेल नहीं खाता
    personal work में मैं Claude Code से 10–15 मिनट वाले कई tasks करवाता हूँ, और execution शुरू होने से पहले model के साथ plan पर कई बार आना-जाना करता हूँ, जिसमें काफ़ी समय लग जाता है
    execution शुरू हो जाए तो मैं कॉफ़ी पीने चला जाता हूँ या Codex में किसी और project पर लग जाता हूँ, इसलिए Claude पर लौटने में 1 घंटे से ज़्यादा लगने की संभावना बहुत ज़्यादा रहती है

    • यह शायद सिर्फ developers के हिसाब से corner case होगा
      अपने usage habits को सभी users के behavior समझ लेना product development की आम भूल है
    • यह सुनकर लगता है कि इतना बड़ा बदलाव करते समय उन्होंने उसी edge case को ठीक से validate ही नहीं किया, जिससे testing rigor पर भी सवाल उठते हैं

  • बड़े frontier labs का अपनाया हुआ black-box approach आख़िरकार लोगों को दूर कर देगा
    अगर इस तरह के बुनियादी behavior बदल दिए जाएँ, पहले से बताया भी न जाए, और बाद में आकर सफ़ाई दी जाए, तो users आख़िरकार self-hosted models की ओर जाएँगे
    लगातार हिलती हुई नींव पर pipeline, workflow, और product स्थिरता से नहीं बनाए जा सकते

  • लगता है Anthropic की Claude Code टीम के लोग comments पढ़ रहे हैं, तो कुछ दिन पहले मैंने theo t3.gg का वह वीडियो देखा जिसमें बात थी कि Claude बेवकूफ़ हो गया है या नहीं
    tone कड़ा था और भाषा भी कभी-कभी ज़्यादा, लेकिन खासकर harness bloat वाला point काफ़ी सही लगा
    अब नई features जोड़ना थोड़ी देर रोककर polish और optimization पर ज़ोर देना चाहिए
    नहीं तो लोग हल्के और ज़्यादा optimized alternatives ढूँढेंगे, और असली बात harness को बेहतर बनाना और token usage घटाना है
    https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

    • बाकी सब छोड़िए, Pro plan में CC support हटाने वाले experiment भर ने मुझे alternatives के बारे में गंभीर बना दिया
      vendor lock-in को लेकर मैं पहले से सतर्क था, लेकिन वह घटना अच्छा warning signal थी, और शायद मैं opencode+openrouter पहले देखूँगा
    • theo की GPT 5 hype video और बाद में उसका पलटना कभी नहीं भूलना चाहिए
      कुछ content creators और OpenAI के बीच पैसे हों या influence, पर्दे के पीछे कुछ चल रहा है, ऐसा साफ़ लगता है
    • सच कहूँ तो यह बस git reset --hard से ठीक होने वाली बात भी लगती है

  • यह सब core product quality से ज़्यादा feature additions पर obsession का नतीजा लगता है
    अक्सर लगता है Anthropic को कुछ और senior product leaders की ज़रूरत है, और “Escaping the Build Trap” जैसी सोच काम आएगी
    सिर्फ़ इसलिए कि कोई feature जल्दी ship हो सकता है, यह ज़रूरी नहीं कि उसे ship करना ही चाहिए
    किसी मशहूर किताब का नाम लेने का मतलब यह नहीं कि मैं कोई घिसा-पिटा product-org talk कर रहा हूँ; अच्छी product sense, अच्छी engineering से अलग तरह की प्रतिभा होती है, और हाल में Anthropic उस हिस्से में कमज़ोर लगता है

    • demand के साथ चलने के लिए compute resources साफ़ तौर पर कम पड़ते दिख रहे हैं
      इसलिए शायद ऐसी features लगाए बिना system टूट जाता या वे नए customers नहीं ले पाते, और दोनों ही unacceptable हैं, तो शायद उनके पास बहुत विकल्प नहीं था
    • एक समय वहाँ करीब 100 developers को सालाना 600k डॉलर तक मिलते थे, इसलिए talent shortage असली समस्या नहीं लगती
      बल्कि समस्या शायद vibe coding narrative को ज़रूरत से ज़्यादा push करना है, और सुना है कुछ candidates इसी वजह से interviews ठुकरा देते हैं
    • लगता है वे पहले ही complexity trap में काफ़ी गहरे फँस चुके हैं
      model की probabilistic nature तो एक समस्या है ही, लेकिन अब हालात ऐसे लगते हैं कि वे अपने ही software को ठीक से reason नहीं कर पा रहे
      levers और dials इतने ज़्यादा हैं कि शायद codebase को कोई भी पूरा नहीं समझता
      इससे भी बुरा यह है कि Dario वगैरह की बातों से management इन quality concerns से ज़्यादा सहमत नहीं दिखता
      SWEs को replaceable मानने वाली सोच में, tools पर guard rails लगाने की माँग या तो अनसुनी हो रही है या दबाई जा रही है, और आखिर में Claude Code शुरू से ही science experiment जैसा लगा है, न कि ऐसा product जिसमें mature best practices की गंध हो