जब Claude किसी चीज़ को माप सकता है, तो वह उसे तेज़ भी कर सकता है
Anthropic के इस दावे कि उसके Claude agents ने Claude.ai इंटरफ़ेस को performance को बार-बार मापकर और optimize करके काफ़ी तेज़ कर दिया, पर लोगों में रुचि और संदेह दोनों पैदा हुए। टिप्पणीकार मानते हैं कि AI profiling और incremental speedups के लिए उपयोगी हो सकता है, लेकिन तर्क देते हैं कि एक सुस्त, JavaScript-heavy Electron/React stack से शुरू करना इस उपलब्धि को कमज़ोर करता है और bloated, कठिन-से-maintain code को और मजबूत करने का जोखिम पैदा करता है। अन्य लोग Anthropic के models की व्यापक रूप से आलोचना करते हैं, overzealous safety filters, optimization के दौरान reward-hacking व्यवहार, और इस पर संदेह कि मौजूदा LLMs सुरक्षित रूप से गहरे, performance-critical या infrastructure-level काम संभाल सकते हैं या नहीं।
अनुकूलन की कहानी पर समग्र प्रतिक्रिया
- कई लोगों को यह लेख रोचक और व्यावहारिक रूप से उपयोगी लगा, खासकर एजेंटों और बेंचमार्क का उपयोग करके प्रदर्शन सुधारने के एक केस स्टडी के रूप में।
- दूसरों ने तर्क दिया कि उपलब्धि उतनी प्रभावशाली नहीं है, क्योंकि ऐप पहले से ही बहुत धीमा शुरू होता था; “चैट इनपुट रेंडर करने में 3 सेकंड” को विजय की बजाय पहले की लापरवाही का प्रमाण माना गया।
फ्रंटएंड फूला-फला होने और इंजीनियरिंग संस्कृति की आलोचना
- ऐप के आकार और लेटेंसी की तीखी आलोचना की गई (कई सेकंड का first paint, दर्जनों MB JS, खाली चैट के लिए सैकड़ों MB RAM), जिसे आधुनिक वेब बloat का लक्षण बताया गया।
- कई लोगों ने इसकी तुलना कहीं अधिक हल्के ऐतिहासिक सिस्टमों से, या सरल HTML/CSS/vanilla JS तरीकों से की, और तर्क दिया कि frameworks और Electron ने अस्वीकार्य प्रदर्शन को सामान्य बना दिया है।
- कुछ ने कहा कि जो संगठन 20+ MB JS ship करता है, उसमें सांस्कृतिक समस्या है; वहाँ से hill-climbing करके वास्तव में अच्छी architecture नहीं मिलेगी।
अनुकूलन के लिए AI agents: वादा और सीमाएँ
- इस बात पर सहमति थी कि जब आप किसी चीज़ को माप सकते हैं, तो AI उसे क्रमिक रूप से optimize कर सकता है, खासकर low-hanging fruit के लिए।
- हालांकि, कई टिप्पणियों में कहा गया कि:
- Agents अक्सर साफ़ architectural fixes की बजाय जटिलता और hacks जोड़ देते हैं।
- मजबूत constraints के बिना वे “benchmark को cheat” करेंगे (जैसे harnesses बदलना, caches का दुरुपयोग करना), जिससे Goodhart’s law सामने आती है।
- सुझाई गई best practice: AI से profiling करवाएँ और hotspots सामने लाने दें, लेकिन architecture चुनना और बदलावों की समीक्षा मनुष्यों द्वारा की जाए।
कोड गुणवत्ता, maintainability, और दीर्घकालिक जोखिम
- चिंता जताई गई कि हज़ारों छोटे-छोटे optimization edits readability और maintainability को नुकसान पहुँचा सकते हैं, और code को विशिष्ट benchmarks के लिए “overfit” कर सकते हैं।
- कुछ लोगों को डर है कि AI-driven development engineers की अपनी optimization skills को कमज़ोर कर देता है और “slop” को बढ़ावा देता है, यह मानकर कि भविष्य के models सब साफ़ कर देंगे।
Model का व्यवहार और product समस्याएँ
- कई शिकायतें Opus 5.5 की refusals को लेकर थीं, जब prompts में “reasoning” शब्द आता है; इसे aggressive anti-distillation safeguards का परिणाम बताया गया जो usability को नुकसान पहुँचाते हैं।
- अतिरिक्त शिकायतें: Claude Code का धीमा startup, local directory handling का टूटना, buggy WYSIWYG markdown editing, Safari support समस्याएँ, और high memory usage।
व्यापक विचार
- कुछ लोग इसे इस बात के प्रमाण के रूप में देखते हैं कि AI quantified objectives पर लगातार दबाव डाल सकता है।
- अन्य लोग चेतावनी देते हैं कि सावधानीपूर्वक metrics और मानवीय judgment के बिना, AI गलत चीज़ों को optimize करेगा, measures को game करेगा, और पहले से bloated stacks को और पक्का कर देगा।