अगर इस पर पाबंदी लगानी ही थी, तो बेहतर होता कि फोन के अंदर टॉगल से इसे चालू न किया जा सके और सिर्फ adb से ही enable किया जा सके, यानी इसे थोड़ा और सख्ती से बांधा जाता।
व्यक्तिगत रूप से, मुझे लगता है कि इस स्तर तक तो फिर भी बात समझ में आती है।
क्या यह सांस्कृतिक अंतर की बात है? इस कदम पर आई कुछ नकारात्मक प्रतिक्रियाएँ मुझे समझना मुश्किल लगा।
शुरुआत से ही Pro/Max plan ऐसा प्लान है जिसमें Anthropic अपनी तरफ़ से घाटा सहकर lock-in करने की कोशिश कर रहा है, तो अगर इसे opencode में इस्तेमाल करने के लिए Anthropic ने मना किया है, तो फिर नहीं करना चाहिए। मुझे लगता है कि यह स्पष्ट ToS उल्लंघन है। ऐसी स्थिति पर विचार भी किए बिना Anthropic की आलोचना करना, सच कहूँ तो, ऐसा लगता है जैसे लोग पैसे बचाना चाहते हैं लेकिन Claude का इस्तेमाल भी करना चाहते हैं, इसलिए ज़िद कर रहे हैं।
अगर opencode इस्तेमाल करना है तो API से करें, और अगर Pro plan इस्तेमाल करना है तो Claude Code इस्तेमाल करें। अगर Anthropic का यह कदम पसंद नहीं है तो Claude का इस्तेमाल न करें (codex में third-party products पर भी auth संभव है, इसलिए मैं भी opencode और openclaw को codex auth से चलाता हूँ)।
Anthropic भी एक कंपनी है और आखिरकार उसे मुनाफ़ा कमाना ही है, इसलिए मैं इस चुनाव का सम्मान करता हूँ। बेशक यह ऐसा मुद्दा है जिसे नज़रिये के हिसाब से अलग तरह से देखा जा सकता है, इसलिए यह ज़रूरी नहीं कि मैं ही सही हूँ। लेकिन हाल की HN चर्चाओं को देखकर अफ़सोस होता है कि anti-corporate भावना की वजह से पहले की तुलना में अब बिना आधार के कंपनियों की आलोचना करने वाले या टेढ़े नज़रिये से देखने वाले लोग ज़्यादा हो गए हैं।
सांख्यिकीय रूप से अगर इसकी संभावना एक निश्चित स्तर से ऊपर है, expected value positive है, और expected value को बढ़ाने के लिए engineering तरीके लगातार सामने आ रहे हैं, तो क्या इसे जुआ कहना चाहिए? सामाजिक तौर पर लगता है कि हमने इसे निवेश कहने पर सहमति बना ली है।
प्रतिक्रिया देखकर लगता है कि शुरू से ही सबको पता था कि यह नहीं करना चाहिए था
, और अब जब इसे रोका गया है, तो अचानक Anthropic को कंजूस बताकर घेरना दुखद हक़ीक़त है. सज़ा नहीं मिली, इसी को गनीमत समझना चाहिए
C embedded डेवलपर के रूप में मैं Feature/Subfeature के लिए लगभग पूरे flow को chart में जाँच सकने लायक specification बनाता हूँ.
फिर specification की लंबे समय तक समीक्षा करके उसे अंतिम रूप देने के बाद,
मैं specification के साथ पूरी तरह 1:1 मेल खाने वाला code तैयार करके इस्तेमाल करता हूँ.
Specification के आधार पर review करने पर, code review की तुलना में readability कहीं बेहतर होती है.
लगता है कि Python या JavaScript-आधारित solutions में सिर्फ़ विस्तृत specification documents के आधार पर भी संतोषजनक implementation संभव है। मैं C/C++-आधारित game/medical क्षेत्र में हूँ, और आजकल मुझे यह ज़्यादा लगता है कि FULL AI AGENT को delegate करना तो दूर, सिर्फ़ विस्तृत specification documents के आधार पर automation करना भी बहुत बड़ा जोखिम है।
मान लीजिए, कोई software engineer या AI researcher है जिसकी सालाना सैलरी 5 लाख डॉलर है। हमारे यहाँ ऐसे मामले आम हैं।
साल के अंत में मैं उस 5 लाख डॉलर सालाना पाने वाले engineer से पूछूँगा:
“इस साल आपने tokens पर कितना खर्च किया?”
और अगर वह कहे, “मैंने 5,000 डॉलर खर्च किए,” तो मैं सच में हैरान रह जाऊँगा।
अगर उस 5 लाख डॉलर सालाना पाने वाले engineer ने कम-से-कम 2.5 लाख डॉलर के tokens भी इस्तेमाल नहीं किए, तो मैं इसे बहुत गंभीरता से लूँगा।
यह वैसा ही है जैसे हमारे chip designers में से कोई कहे,
“मैं तो बस कागज़ और पेंसिल ही इस्तेमाल करूँगा। मुझे CAD tools की ज़रूरत नहीं लगती।”
इसका मतलब है कि अब top talent को देखने का नज़रिया ही पूरी तरह बदल रहा है।
यह कुछ वैसा ही है जैसा हमने तब सीखा था जब NBA में LeBron James ने अपने शरीर की देखभाल और अपनी condition बनाए रखने पर
हर साल 10 लाख डॉलर खर्च करने शुरू किए थे।
तो फिर ऐसे बेहतरीन knowledge workers को superhuman capabilities क्यों न दी जाएँ?
तो 2–3 साल आगे देखकर सवाल यह है:
Nvidia का एक top talent कितना ज़्यादा efficiently काम करेगा?
और वह आखिर कितनी दूर तक जा सकेगा?
सबसे पहले, “वाह, यह बहुत मुश्किल है” वाला विचार गायब हो जाएगा।
“इसमें बहुत ज़्यादा समय लगेगा” वाला विचार भी गायब हो जाएगा।
“इसके लिए बहुत सारे लोगों की ज़रूरत है” वाला विचार भी गायब हो जाएगा।
बहुत बड़ा है, बहुत भारी है, बहुत समय लगता है।
ये सारे विचार खत्म हो जाएँगे।
आखिर में जो बचेगा, वह creativity होगी।
सिर्फ यही बचेगा कि आप क्या सोच सकते हैं।
तब सवाल यह होगा:
इन agents के साथ मिलकर काम कैसे किया जाए?
असल में, यही computer programming करने का नया तरीका है।
पहले हम खुद code लिखते थे।
आगे हम ideas लिखेंगे, architecture लिखेंगे, specifications लिखेंगे।
हम teams को organize करेंगे,
यह define करेंगे कि अच्छे और बुरे results का मूल्यांकन कैसे करना है,
यह तय करेंगे कि शानदार result किसे कहेंगे,
कैसे मिलकर iteration करना है,
और कैसे brainstorming करनी है।
वास्तव में महत्वपूर्ण काम यही है।
और मेरे विचार से,
आगे चलकर हर engineer के पास 100 agents होंगे।
सिर्फ 24 घंटे इंतज़ार करना पड़ेगा जैसी मनाने वाली बात मुझे नहीं चाहिए। जब मैंने डिवाइस खरीदा था, तब उसकी सुविधाओं को बेअसर करने की कोशिश मुझे पसंद नहीं है।
> यह पूरा फ्लो Android OS के बजाय Google Play Services के ज़रिए दिया जा रहा है, यानी Google किसी भी समय बिना OS update के और बिना किसी user consent के इसे बदल सकता है, सीमित कर सकता है, या हटा सकता है। यह advanced flow अब तक किसी भी Android beta, dev preview, या canary release में दिखाई नहीं दिया है। इस update की तारीख तक यह सिर्फ़ एक blog post और UI mockups के रूप में मौजूद है। समुदाय से कहा जा रहा है कि mandate लागू होने से पाँच महीने पहले एक product announcement को functional safeguard के रूप में स्वीकार कर लिया जाए।
> - https://keepandroidopen.org
इस सामग्री के अनुसार शीर्षक को संशोधित किया गया है।
संबंधित:
परफॉर्मेंस थोड़ी निराशाजनक है। GPU या किसी खास NPU का सपोर्ट अभी नहीं है, इसलिए धीमा है..
क्या spec-आधारित development SDD पहले से ही मौजूद नहीं था?
बताया जाता है कि यह Kimi k2 मॉडल पर reinforcement learning चलाकर बनाया गया मॉडल था
अगर इस पर पाबंदी लगानी ही थी, तो बेहतर होता कि फोन के अंदर टॉगल से इसे चालू न किया जा सके और सिर्फ adb से ही enable किया जा सके, यानी इसे थोड़ा और सख्ती से बांधा जाता।
व्यक्तिगत रूप से, मुझे लगता है कि इस स्तर तक तो फिर भी बात समझ में आती है।
क्या यह सांस्कृतिक अंतर की बात है? इस कदम पर आई कुछ नकारात्मक प्रतिक्रियाएँ मुझे समझना मुश्किल लगा।
शुरुआत से ही Pro/Max plan ऐसा प्लान है जिसमें Anthropic अपनी तरफ़ से घाटा सहकर lock-in करने की कोशिश कर रहा है, तो अगर इसे opencode में इस्तेमाल करने के लिए Anthropic ने मना किया है, तो फिर नहीं करना चाहिए। मुझे लगता है कि यह स्पष्ट ToS उल्लंघन है। ऐसी स्थिति पर विचार भी किए बिना Anthropic की आलोचना करना, सच कहूँ तो, ऐसा लगता है जैसे लोग पैसे बचाना चाहते हैं लेकिन Claude का इस्तेमाल भी करना चाहते हैं, इसलिए ज़िद कर रहे हैं।
अगर opencode इस्तेमाल करना है तो API से करें, और अगर Pro plan इस्तेमाल करना है तो Claude Code इस्तेमाल करें। अगर Anthropic का यह कदम पसंद नहीं है तो Claude का इस्तेमाल न करें (
codexमें third-party products पर भी auth संभव है, इसलिए मैं भीopencodeऔरopenclawकोcodexauth से चलाता हूँ)।Anthropic भी एक कंपनी है और आखिरकार उसे मुनाफ़ा कमाना ही है, इसलिए मैं इस चुनाव का सम्मान करता हूँ। बेशक यह ऐसा मुद्दा है जिसे नज़रिये के हिसाब से अलग तरह से देखा जा सकता है, इसलिए यह ज़रूरी नहीं कि मैं ही सही हूँ। लेकिन हाल की HN चर्चाओं को देखकर अफ़सोस होता है कि anti-corporate भावना की वजह से पहले की तुलना में अब बिना आधार के कंपनियों की आलोचना करने वाले या टेढ़े नज़रिये से देखने वाले लोग ज़्यादा हो गए हैं।
सांख्यिकीय रूप से अगर इसकी संभावना एक निश्चित स्तर से ऊपर है, expected value positive है, और expected value को बढ़ाने के लिए engineering तरीके लगातार सामने आ रहे हैं, तो क्या इसे जुआ कहना चाहिए? सामाजिक तौर पर लगता है कि हमने इसे निवेश कहने पर सहमति बना ली है।
पहले पॉइंट से ही बहुत मज़ेदार है।
प्रतिक्रिया देखकर लगता है कि शुरू से ही सबको पता था कि यह नहीं करना चाहिए था
, और अब जब इसे रोका गया है, तो अचानक Anthropic को कंजूस बताकर घेरना दुखद हक़ीक़त है. सज़ा नहीं मिली, इसी को गनीमत समझना चाहिए
हाल में लगभग हर वेबसाइट और सेवा विज्ञापनों से इतनी भर गई है कि चिढ़ होने लगती है।
C embedded डेवलपर के रूप में मैं Feature/Subfeature के लिए लगभग पूरे flow को chart में जाँच सकने लायक specification बनाता हूँ.
फिर specification की लंबे समय तक समीक्षा करके उसे अंतिम रूप देने के बाद,
मैं specification के साथ पूरी तरह 1:1 मेल खाने वाला code तैयार करके इस्तेमाल करता हूँ.
Specification के आधार पर review करने पर, code review की तुलना में readability कहीं बेहतर होती है.
लगता है कि Python या JavaScript-आधारित solutions में सिर्फ़ विस्तृत specification documents के आधार पर भी संतोषजनक implementation संभव है। मैं C/C++-आधारित game/medical क्षेत्र में हूँ, और आजकल मुझे यह ज़्यादा लगता है कि FULL AI AGENT को delegate करना तो दूर, सिर्फ़ विस्तृत specification documents के आधार पर automation करना भी बहुत बड़ा जोखिम है।
जुर्माना बहुत ही मामूली लगता है।
बहुत अच्छी तरह पढ़ा ^^
काश इसमें हिंदी subtitles होते, अफ़सोस है..
24:28 से आगे का हिस्सा प्रभावशाली है।
ज़रा एक thought experiment करते हैं।
मान लीजिए, कोई software engineer या AI researcher है जिसकी सालाना सैलरी 5 लाख डॉलर है। हमारे यहाँ ऐसे मामले आम हैं।
साल के अंत में मैं उस 5 लाख डॉलर सालाना पाने वाले engineer से पूछूँगा:
“इस साल आपने tokens पर कितना खर्च किया?”
और अगर वह कहे, “मैंने 5,000 डॉलर खर्च किए,” तो मैं सच में हैरान रह जाऊँगा।
अगर उस 5 लाख डॉलर सालाना पाने वाले engineer ने कम-से-कम 2.5 लाख डॉलर के tokens भी इस्तेमाल नहीं किए, तो मैं इसे बहुत गंभीरता से लूँगा।
यह वैसा ही है जैसे हमारे chip designers में से कोई कहे,
“मैं तो बस कागज़ और पेंसिल ही इस्तेमाल करूँगा। मुझे CAD tools की ज़रूरत नहीं लगती।”
इसका मतलब है कि अब top talent को देखने का नज़रिया ही पूरी तरह बदल रहा है।
यह कुछ वैसा ही है जैसा हमने तब सीखा था जब NBA में LeBron James ने अपने शरीर की देखभाल और अपनी condition बनाए रखने पर
हर साल 10 लाख डॉलर खर्च करने शुरू किए थे।
तो फिर ऐसे बेहतरीन knowledge workers को superhuman capabilities क्यों न दी जाएँ?
तो 2–3 साल आगे देखकर सवाल यह है:
Nvidia का एक top talent कितना ज़्यादा efficiently काम करेगा?
और वह आखिर कितनी दूर तक जा सकेगा?
सबसे पहले, “वाह, यह बहुत मुश्किल है” वाला विचार गायब हो जाएगा।
“इसमें बहुत ज़्यादा समय लगेगा” वाला विचार भी गायब हो जाएगा।
“इसके लिए बहुत सारे लोगों की ज़रूरत है” वाला विचार भी गायब हो जाएगा।
बहुत बड़ा है, बहुत भारी है, बहुत समय लगता है।
ये सारे विचार खत्म हो जाएँगे।
आखिर में जो बचेगा, वह creativity होगी।
सिर्फ यही बचेगा कि आप क्या सोच सकते हैं।
तब सवाल यह होगा:
इन agents के साथ मिलकर काम कैसे किया जाए?
असल में, यही computer programming करने का नया तरीका है।
पहले हम खुद code लिखते थे।
आगे हम ideas लिखेंगे, architecture लिखेंगे, specifications लिखेंगे।
हम teams को organize करेंगे,
यह define करेंगे कि अच्छे और बुरे results का मूल्यांकन कैसे करना है,
यह तय करेंगे कि शानदार result किसे कहेंगे,
कैसे मिलकर iteration करना है,
और कैसे brainstorming करनी है।
वास्तव में महत्वपूर्ण काम यही है।
और मेरे विचार से,
आगे चलकर हर engineer के पास 100 agents होंगे।
इसे इस्तेमाल करें तो लगता है full-permission request mode नहीं इस्तेमाल कर पाएंगे।
सिर्फ 24 घंटे इंतज़ार करना पड़ेगा जैसी मनाने वाली बात मुझे नहीं चाहिए। जब मैंने डिवाइस खरीदा था, तब उसकी सुविधाओं को बेअसर करने की कोशिश मुझे पसंद नहीं है।
> यह पूरा फ्लो Android OS के बजाय Google Play Services के ज़रिए दिया जा रहा है, यानी Google किसी भी समय बिना OS update के और बिना किसी user consent के इसे बदल सकता है, सीमित कर सकता है, या हटा सकता है। यह advanced flow अब तक किसी भी Android beta, dev preview, या canary release में दिखाई नहीं दिया है। इस update की तारीख तक यह सिर्फ़ एक blog post और UI mockups के रूप में मौजूद है। समुदाय से कहा जा रहा है कि mandate लागू होने से पाँच महीने पहले एक product announcement को functional safeguard के रूप में स्वीकार कर लिया जाए।
> - https://keepandroidopen.org