कृपया मेरे workflow पर A/B test मत चलाइए

 (backnotprop.com)
4 पॉइंट द्वारा GN⁺ 2026-03-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code ने उपयोगकर्ता की सहमति के बिना A/B test चलाया, जिससे plan mode का व्यवहार बिना किसी पूर्व सूचना के बदल गया और काम की दक्षता घट गई
  • महीने के $200 देने वाले professional tool में core feature को पहले से बताए बिना बदलना transparency और user control, दोनों के लिहाज़ से समस्या है
  • एक test में plan को 40 लाइनों तक सीमित किया गया, context section पर रोक लगाई गई, और prose हटाकर सिर्फ file path छोड़ने का निर्देश दिया गया — यह एक बहुत आक्रामक variant था
  • यह test चलाने वाले Anthropic engineer ने कहा कि उद्देश्य rate-limit load कम करना था, लेकिन शुरुआती नतीजों में बड़ा असर न दिखने पर experiment बंद कर दिया गया
  • यह बात रेखांकित की गई कि AI tools की reliability और responsible deployment के लिए user control और transparent experiment management अनिवार्य हैं

Claude Code के A/B test से user experience में गिरावट

  • Claude Code को ऐसा tool मानने वाले एक उत्साही user, जिसने उनके काम करने का तरीका पूरी तरह बदल दिया था, ने पिछले एक हफ्ते में अपने workflow के खराब होने का अनुभव किया
  • Anthropic Claude Code में A/B test चला रहा था, और उसके कारण user workflow सक्रिय रूप से खराब हो रहा था
  • A/B test अपने आप में गलत नहीं है, और न ही Anthropic जानबूझकर experience खराब करना चाहता था, लेकिन test design मायने रखता है; plan mode जैसे core feature का अनुभवजन्य व्यवहार बिना कारण बताए बदलना ही समस्या है

Paid tool में transparency की मांग

  • यह $200 प्रति माह का professional work tool है, इसलिए इसके काम करने के तरीके पर transparency और configuration की क्षमता होनी चाहिए
  • core feature का बिना सूचना बदल जाना, या बिना सहमति destructive test में शामिल कर दिया जाना, स्वीकार करना मुश्किल है
  • AI tools को responsibly steer करने के लिए transparency और configurability बुनियादी हैं, और users को ऐसा करने में सक्षम बनाना चाहिए
  • हर दिन engineers Claude Code की regression को लेकर शिकायत कर रहे हैं, और कई बार उन्हें यह भी नहीं पता होता कि वे A/B test का हिस्सा हैं

Test की सामग्री और सबूत

  • लिखा गया plan context के बिना सिर्फ संक्षिप्त bullet list के रूप में लौटने लगा
  • जब Claude से पूछा गया कि वह इतना खराब plan क्यों लिख रहा है, तो उसने जवाब दिया कि वह एक खास system instruction का पालन कर रहा है: plan को 40 लाइनों पर hard cap करना, context section को प्रतिबंधित करना, और "prose हटा दो, सिर्फ file path छोड़ो"
  • ठोस सबूत जुटाने की विधि Hacker News पर ध्यान आकर्षित कर रही थी, इसलिए दूसरों को वही कोशिश न करने देने के लिए विस्तृत विवरण हटा दिए गए
  • लेखक ने कहा कि यह तरीका transparency और responsible AI deployment/use — दोनों के विपरीत है

Hacker News की प्रतिक्रिया और लागत का दृष्टिकोण

  • Hacker News की एक टिप्पणी में कहा गया कि Anthropic को Claude Code के हर चरण में throughput से जुड़े trade-off चुनने पड़ते हैं; अगर सब कुछ अधिकतम पर रखा जाए, तो प्रति user अधिक loss या कम profit हो सकता है
  • यह भी दृष्टिकोण सामने आया कि $200/माह की सेवा की वास्तविक लागत $400/माह तक हो सकती है, और process के अलग-अलग हिस्सों में A/B test करके baseline ढूँढना मनमाने limits तय करने से बेहतर तरीका हो सकता है

Anthropic engineer की प्रतिक्रिया

  • यह test चलाने वाले Claude Code engineer ने Hacker News thread में सीधे जवाब दिया
  • plan-mode prompt में 3.x series models के बाद से बड़ा बदलाव नहीं हुआ था, और 4.x model बहुत कम instructions के साथ भी सफलतापूर्वक काम कर सकते हैं
  • परिकल्पना यह थी कि plan छोटा रखने से rate-limit hit कम होंगे और फिर भी मिलते-जुलते नतीजे मिल सकते हैं
  • कई variants चलाए गए, और उस लेखक को — साथ ही हजारों अन्य users को — plan को 40 लाइनों तक सीमित करने वाले सबसे आक्रामक variant में रखा गया
  • शुरुआती नतीजों में rate limit पर कोई बड़ा असर नहीं दिखा, इसलिए experiment बंद कर दिया गया
  • planning के दो उद्देश्य हैं: model को सही दिशा में बनाए रखना, और user को model की अगली कार्रवाई पर भरोसा देने में मदद करना; engineer के अनुसार दोनों ही लक्ष्य धुंधले, जटिल और non-obvious क्षेत्र हैं

निष्कर्ष: AI tool experiments की जवाबदेही और user trust

  • लेखक ने Claude Code के इस मामले के ज़रिए दिखाया कि AI tool experiments सीधे user experience को प्रभावित कर सकते हैं
  • उन्होंने जोर दिया कि transparent experiment management और user choice की गारंटी professional tools में trust बनाए रखने के लिए आवश्यक है
  • भले ही AI systems आगे बढ़ते रहें, मानव-नियंत्रित संरचना बनाए रखना जरूरी है

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

1 टिप्पणियां

 
GN⁺ 2026-03-15
Hacker News की राय

  • मुझे लगता है कि A/B टेस्ट को "यूज़र्स पर चुपचाप किया गया प्रयोग" कहना और Meta का ज़िक्र करना कुछ ज़्यादा है
    A/B टेस्ट अपने-आप में बुरा नहीं है, मेरे हिसाब से टेस्ट डिज़ाइन ज़्यादा महत्वपूर्ण है
    लेकिन LLM की परफ़ॉर्मेंस को गंभीर रूप से गिराने वाले प्रयोग स्वीकार्य नहीं हैं

    • LLM के मामले में इसे अलग नज़रिए से देखना चाहिए
      यहाँ पहले से ही reproducibility और reliability की समस्या गंभीर है, और कंपनियाँ उसका बोझ यूज़र्स पर डाल रही हैं
      ऐसे हालात में अगर कंपनी चुपके से प्रयोग करे, तो रिसर्च की विश्वसनीयता पूरी तरह टूट जाती है
      Claude Code जैसे मामलों में, A/B टेस्ट की वजह से नकारात्मक नतीजे आए हों तब भी उन्हें यह कहकर नज़रअंदाज़ किया जा सकता है कि "शायद वह experiment group था"
      खासकर hiring जैसे संवेदनशील क्षेत्रों में अगर ऐसे प्रयोग चलें, तो नैतिक और कानूनी समस्याएँ बहुत गंभीर हो जाएँगी
    • मुझे लगता है कि टेक कंपनियाँ अब भी 'explicit consent' की अवधारणा को ठीक से नहीं समझतीं
    • मुझे A/B टेस्ट पसंद नहीं है
      अचानक UI या फ़ीचर बदल जाता है, और सहकर्मियों से पूछो तो किसी को कुछ पता नहीं होता
      आम तौर पर ऐसे बदलाव और खराब होते हैं, फिर भी उन्हें "objective data" के नाम पर थोप दिया जाता है
    • समझ नहीं आता कि A/B टेस्ट को "चुपचाप किया गया यूज़र प्रयोग" क्यों नहीं कहा जाए
      बटन के रंग जैसी मामूली चीज़ भी आखिरकार एक प्रयोग ही है, और ज़्यादातर यूज़र्स को यह तक नहीं बताया जाता कि उन पर प्रयोग हो रहा है
    • मूल पोस्ट के लेखक ने सहमति जताई और कहा कि वे शब्दावली बदल देंगे

  • यह टेस्ट मैंने खुद चलाया था
    3.x series से चले आ रहे plan-mode prompt को 4.x model में सरल बनाकर भी क्या वैसा ही परिणाम मिल सकता है, यही प्रयोग था
    मेरा अनुमान था कि plan को छोटा करने से rate-limit कम लगेगा, लेकिन कोई बड़ा फ़र्क नहीं पड़ा, इसलिए प्रयोग बंद कर दिया
    plan mode के दो उद्देश्य हैं: मॉडल को दिशा देना, और यूज़र को परिणाम पर भरोसा करने में मदद करना

    • 40-line limit का rate-limit पर असर न होना स्वाभाविक है
      लागत plan text से नहीं, बल्कि exploration stage (subagent) में आती है
      plan mode हमेशा 3 exploration agents चलाता है, और session state को ध्यान में नहीं रखता
      फ़ाइलें पहले से लोड हों तब भी उन्हें फिर से पढ़ता है, जिससे tokens की बर्बादी होती है
      session warm होने पर exploration छोड़ देने वाला conditional logic ज़्यादा असरदार होगा
    • मैं एक divergent thinker हूँ, और claude.mds में constraints सेट करने में सैकड़ों घंटे लगा चुका हूँ; ऐसे प्रयोग में मुझे random तरीके से शामिल किया जाना चौंकाने वाला था
      एक अप्रत्याशित व्यवहार कई दिनों तक मुझे अक्षम कर सकता है
      इस असर को नज़रअंदाज़ करना गैर-जिम्मेदाराना और आक्रामक है
    • क्या इस टेस्ट में इस्तेमाल हुए tokens refund नहीं किए जाने चाहिए?
    • ऐसे प्रयोगों के लिए opt-out option होना चाहिए
      हाल की अजीब हरकतें शायद experiments की वजह से रही हों, इसलिए यह बहुत असुविधाजनक है
      beta channel के बजाय इसे explicit opt-in होना चाहिए
    • पारदर्शिता के लिए धन्यवाद
      व्यक्तिगत रूप से, मुझे line count से ज़्यादा plan की narrative clarity महत्वपूर्ण लगती है
      ऐसा plan चाहिए जिससे समझ आए कि क्या और क्यों किया जा रहा है

  • LLM व्याकरण की दृष्टि से भले परफ़ेक्ट हो, लेकिन उसमें hallucination मिल जाती है, जो यूज़र्स को भ्रमित करती है
    फिर भी boilerplate काम या तेज़ी से ideas जोड़ने में यह उपयोगी है
    लेकिन इसे सही ढंग से इस्तेमाल करने के लिए बुनियादी ज्ञान ज़रूरी है

    • LLM को अच्छी तरह इस्तेमाल करने की कुंजी है उपयोगी output और AI कचरे में फर्क कर पाना
    • कुछ लोगों की राय है कि LLM की प्रगति की रफ़्तार को कम करके नहीं आँकना चाहिए
    • एक नज़रिया यह भी है कि आखिर में कुशल लोग टिकेंगे, और बाकी लोग replace हो जाएँगे

  • पोस्ट अचानक इसलिए खत्म होती है क्योंकि लेखक ने Claude Code binary decompilation पर लिखा हिस्सा ToS उल्लंघन की आशंका के कारण हटा दिया
    संबंधित चर्चा इस टिप्पणी में देखी जा सकती है

  • मेरे दो विचार हैं

    1. open source tools अनैच्छिक प्रयोगों या बिना सूचना वाले बदलावों की समस्या हल करते हैं
    2. लेकिन शायद इसी वजह से open source के लिए Claude Code स्तर की quality तक पहुँचना कठिन हो
      क्योंकि बड़े पैमाने के A/B टेस्ट से data-driven improvement संभव नहीं होता
    • open source होने का मतलब यह नहीं कि वह हमेशा reproducible भी होगा
      उदाहरण के लिए man-db का 'after midnight' easter egg जैसी अप्रत्याशित बदलाव भी हो सकते हैं
      dependencies भी बहुत होती हैं, इसलिए वास्तविक code audit करने वाले लोग लगभग नहीं के बराबर हैं
    • "चलो Linux kernel का A/B test करें" जैसी मज़ाकिया बात भी आई
    • A/B टेस्ट हमेशा यूज़र सुधार के लिए नहीं होता
      यह monetization experiment (enshittification) भी हो सकता है — YouTube इसका प्रमुख उदाहरण है

  • A/B टेस्ट में अपने-आप में समस्या नहीं है, लेकिन plan mode अच्छा नहीं लगता
    ज़्यादातर मामलों में नतीजे खराब होते हैं
    हाँ, compaction के बीच information retention अच्छी है
    अगर बातचीत को Markdown फ़ाइल में लिखकर हर compaction पर उसे refer कराया जाए, तो काफ़ी बेहतर नतीजे मिलते हैं

    • मेरा अनुभव बिल्कुल उलटा है
      plan mode कहीं ज़्यादा efficient है, इसलिए मैं लगभग हर काम से पहले इसका इस्तेमाल करता हूँ
      मॉडल के execute करने से पहले plan को review और discuss कर पाने का फ़ायदा है
    • मैं कुछ बार compaction limits से टकरा चुका हूँ, इसलिए उसके बाद से बचने की कोशिश करता हूँ
      अभी plan mode completion पर context reset कर देता है, इसलिए अगला plan साफ़-सुथरे तरीके से बनाया जा सकता है

  • अफ़सोस है कि ब्लॉग में decompilation details ToS कारणों से हटा दिए गए
    कहा गया कि Claude ने system instruction का पालन किया: "plan को 40 lines तक सीमित करो, context sections को मना करो, और prose हटाओ"
    अच्छा होता अगर ऐसी settings को सीधे देखा और बदला जा सकता

  • पेशेवर tools को reliability और reproducibility देनी चाहिए, लेकिन LLM ऐसा नहीं करते
    A/B टेस्ट तो सिर्फ उसका एक सबूत है

    • असली समस्या LLM नहीं, बल्कि ऐप का चुपचाप अपना व्यवहार बदलना है
      Photoshop अगर रंगत थोड़ी बदल दे, या Word heading style बदल दे, तो वह भी वही समस्या है
      बिना चेतावनी के A/B टेस्ट ही मूल समस्या है
    • Anthropic में पारदर्शिता की कमी गंभीर है
      quota limits और model quality अस्थिर रहती हैं, और नए model के आने से पहले पुराने model के बिगड़ने का दौर आता है
      यह प्रयोग भी यूज़र अनुभव सुधार से ज़्यादा cost-cutting experiment जैसा लगता है
      अगर यह business tool है, तो consistency और reliability ज़रूरी है
    • auto-update होने वाले tools का व्यवहार स्वभावतः बदलता रहता है
      विशेषज्ञों को tool की strengths और weaknesses समझकर उसका सही उपयोग करना चाहिए
      LLM output को आँख बंद करके मान लेना गैर-पेशेवराना है, लेकिन इसका मतलब यह नहीं कि विशेषज्ञ LLM इस्तेमाल ही नहीं कर सकते
    • reproducibility एक spectrum है
      पर्याप्त evaluation framework और prompt control हो, तो इसे काफ़ी deterministic बनाया जा सकता है
      finance sector के अस्थिर models भी आज ऑपरेशन में हैं, इससे लगता है कि अप्रत्याशितता कोई पूर्ण बाधा नहीं है
    • अगर LLM output पूरी तरह deterministic हो जाए, तो मैं अलग क्या करूँगा?
      मैं model के output को सहकर्मी code review की तरह verify करता हूँ

  • ऐसी स्थिति को बहुत पहले से vendor lock-in कहा जाता रहा है
    अगर आप किसी खास tool पर निर्भर हो जाएँ, तो उसके बदलने या गायब होने पर आप काम नहीं कर पाते

  • मैं CC से opencode पर चला गया
    CC बहुत closed है, और उसका prompt ज़रूरत से ज़्यादा opinionated है, इसलिए असुविधा होती थी
    web search path को control भी नहीं किया जा सकता था
    अभी मैं इसे सिर्फ शौकिया तौर पर इस्तेमाल करता हूँ, इसलिए open source चुना; लेकिन अगर पेशेवर काम होता, तो शायद अलग फ़ैसला करता

    • मैंने भी opencode इस्तेमाल किया है, लेकिन default version, CC से काफ़ी कमजोर है
      छोटे प्रोजेक्ट्स तक ही ठीक लगा
      अगर कोई अच्छा setup हो, तो साझा करना अच्छा रहेगा