किसी चर्चा के तर्क के बारे में GPT से पूछा गया जवाब ज्यों-का-त्यों ले आकर रख देने वाले टीम के साथियों को देखते हुए मैं हर दिन आहें भरते हुए गुज़ार रहा हूँ।
काफी लोग ऐसे हैं.. थ्रेड्स पर घूमते-घूमते देखो तो सच में उम्मीद से ज़्यादा लोग हर तरह की चीज़ें ChatGPT से पूछते मिल जाते हैं। यहाँ तक कि ChatGPT ने जो आउटपुट दिया है उसकी जाँच तक किए बिना उसे सीधे पोस्ट कर देते हैं, और इसका सबसे प्रतिनिधि उदाहरण कानूनी मामलों से जुड़ी चीज़ें हैं। वे मिसाल के तौर पर अदालत के फैसले वगैरह धड़ल्ले से पोस्ट कर देते हैं, लेकिन जब वास्तव में खोजो तो या तो ऐसा केस नंबर होता ही नहीं, या कानून की धाराएँ भी अजीब सामग्री के साथ डाल देते हैं। और प्रोफ़ाइल पर क्लिक करो तो वहाँ खुद को expert लिखा होता है.
AI ज़ॉम्बी फैलते जा रहे हैं
बेहतर होगा कि base model की hallucination को 6-sigma स्तर तक काबू में लाकर ऐसी चीज़ बनाई जाए। क्या मतलब यह है कि managing भूमिका निभाने वाले agent या अन्य code-level सुधारों से इसे पर्याप्त रूप से नियंत्रित किया जा सकता है?
अगर एक ऐसा सीधा-सादा मैनेजर हो जो भावनाओं का ख़याल नहीं रखता, और दूसरा ऐसा सौम्य मैनेजर हो जो rapport बनाए रखता है, तो फीडबैक के ज़रिए टीम सदस्य की growth को आगे बढ़ाने में किस तरह का मैनेजर ज़्यादा मदद कर सकता है? पिछला लेख पढ़ते हुए मेरे मन में यही सवाल आया।
मेरे हिसाब से यह probability का खेल है। बेहद खराब odds को पार करके grow करने वाले लोग कहीं भी मिल जाते हैं। मुझे लगता है कि मैनेजर को ऐसे लोगों को अलग रखकर कुल probability बढ़ाने की कोशिश करनी चाहिए। जो मैनेजर अपने तरीके से probability बढ़ाने वाला रवैया मानकर काम करता है, वह सम्मान के योग्य है। बस इतना काफ़ी है कि वह यह सोचकर पुराने तरीके पर अड़ा न रहे कि वैसे भी चल ही जाएगा।
जब मैं पहली बार coding सिखाता हूँ, तो यह बात कि कोई व्यक्ति error messages को ध्यान से पढ़ सकता है या नहीं, वहीं से पहली बार यह दिखने लगता है कि उसमें programmer बनने की योग्यता है या नहीं।
मैंने कभी नहीं सोचा था कि यह हस्तशिल्प जैसा हो सकता है, लेकिन इससे बहुत सहमति महसूस होती है।
इस नज़रिए से सोचने पर लगता है कि कई घटनाएँ समझ में आ जाती हैं।
आलोचनात्मक टिप्पणियाँ देखकर मैंने बहुत सोचा। कुछ हिस्सों से सहमति है और कुछ पर मेरी अलग राय है।
अभी डेवलपर्स की स्थिति को लेकर कुछ हद तक बुलबुला हो सकता है, लेकिन मुझे लगता है कि यही बात दूसरे पेशों पर भी लागू होती है। अल्पसंख्या से बहुसंख्या की ओर। यानी जैसे-जैसे इस क्षेत्र में काम करने वालों की संख्या और विविधता बढ़ती है, यह एक स्वाभाविक घटना है। मैं यह नहीं कह रहा कि यह दिशा हमेशा सही ही है, लेकिन मुझे नहीं लगता कि सिर्फ डेवलपर्स के साथ ही ऐसा खास तौर पर हो रहा है।
सीखना आसान है। यह मानता हूँ, लेकिन प्रवेश बाधा कम होने का मतलब यह नहीं कि पेशेवर विशेषज्ञता भी कम है। दूसरे उद्योगों, खासकर manufacturing के अन्य तकनीकी पदों की तुलना में development सीखना अपेक्षाकृत आसान लगने का कारण शायद यह नहीं कि development खुद आसान है, बल्कि open source संस्कृति और कम जोखिम है। जैसा ऊपर डेवलपर्स की विविधता के बारे में कहा, वैसे ही कुछ काम ऐसे हैं जो जल्दी सीखकर किए जा सकते हैं, और कुछ काम ऐसे हैं जिनके लिए विशेषज्ञता की मजबूत बुनियाद चाहिए।
माहौल बदल गया है। मुझे नहीं लगता कि पहले की तुलना में बाज़ार में डेवलपर्स से अपेक्षाएँ और उन्हें मिलने वाला प्रतिफल सिर्फ उनकी तकनीक, कौशल या विशेषज्ञता की वजह से बढ़ा है। जितना IT मानव जीवन में गहराई से प्रवेश करता गया है, उतना software अधिक महत्वपूर्ण हुआ है, और वही बहुत-सी infrastructure को संभाले हुए है। हर डेवलपर की व्यक्तिगत क्षमता बढ़ने से प्रतिफल नहीं बढ़ा, बल्कि मुझे लगता है कि काम खुद ही महँगा हो गया है। क्योंकि अब यह पहले से कहीं अधिक महत्वपूर्ण है।
क्या manufacturing से सीधी तुलना सचमुच सार्थक है? उद्योग के पर्याप्त परिष्कृत न होने के नज़रिए से देखें तो तुलना का आधार manufacturing लगता है। अगर software उद्योग को manufacturing के paradigm से समझने की कोशिश करेंगे, तो वह हस्तकला या hobby development जैसा दिख सकता है। लेकिन उलटे, मुझे लगता है कि यही पहलू software development की अपनी लचीली और रचनात्मक संस्कृति बनाते हैं, और उसी के आधार पर यह क्षेत्र आगे बढ़ रहा है।
किसी चीज़ में हद से ज़्यादा डूब जाना खतरनाक है। इससे मैं पूरी तरह सहमत हूँ। दुनिया में सिर्फ development ही ऐसी चीज़ नहीं है जिसे पढ़ना-समझना चाहिए, और आज भी हम अपने पेशे के खाने में "कंपनी कर्मचारी" ही लिखते हैं। अगर समाज के माहौल में किसी पेशे को लेकर बुलबुला बन भी जाए, तब भी यह सोचने से बचना चाहिए कि वह दूसरे पेशों से बहुत अलग है। लेकिन यह बात किसी भी पेशे पर लागू होती है।
Toss के लिए UX सीधे तौर पर survival से जुड़ा है
लेकिन इस लेख से अलग नज़रिए से देखें, तो मुझे नहीं पता कि वह कंपनी revenue को अच्छी तरह pursue करती है या नहीं
किसी चर्चा के तर्क के बारे में GPT से पूछा गया जवाब ज्यों-का-त्यों ले आकर रख देने वाले टीम के साथियों को देखते हुए मैं हर दिन आहें भरते हुए गुज़ार रहा हूँ।
काफी लोग ऐसे हैं.. थ्रेड्स पर घूमते-घूमते देखो तो सच में उम्मीद से ज़्यादा लोग हर तरह की चीज़ें ChatGPT से पूछते मिल जाते हैं। यहाँ तक कि ChatGPT ने जो आउटपुट दिया है उसकी जाँच तक किए बिना उसे सीधे पोस्ट कर देते हैं, और इसका सबसे प्रतिनिधि उदाहरण कानूनी मामलों से जुड़ी चीज़ें हैं। वे मिसाल के तौर पर अदालत के फैसले वगैरह धड़ल्ले से पोस्ट कर देते हैं, लेकिन जब वास्तव में खोजो तो या तो ऐसा केस नंबर होता ही नहीं, या कानून की धाराएँ भी अजीब सामग्री के साथ डाल देते हैं। और प्रोफ़ाइल पर क्लिक करो तो वहाँ खुद को expert लिखा होता है.
AI ज़ॉम्बी फैलते जा रहे हैं
बेहतर होगा कि base model की hallucination को 6-sigma स्तर तक काबू में लाकर ऐसी चीज़ बनाई जाए। क्या मतलब यह है कि managing भूमिका निभाने वाले agent या अन्य code-level सुधारों से इसे पर्याप्त रूप से नियंत्रित किया जा सकता है?
RTFM: कृपया आधिकारिक दस्तावेज़ पढ़ें।
वास्तविक साइट डेवलपमेंट और ऑपरेशन तक, इतनी मूल्यवान सामग्री के लिए बहुत धन्यवाद। मैं इसे बहुत ध्यान से पढ़ रहा हूँ।
यह Toss से भी बड़ी कंपनी की कहानी है~
जैसा उम्मीद थी, benchmark में हेरफेर का मामला भी गायब नहीं रह सकता था।
अगर एक ऐसा सीधा-सादा मैनेजर हो जो भावनाओं का ख़याल नहीं रखता, और दूसरा ऐसा सौम्य मैनेजर हो जो rapport बनाए रखता है, तो फीडबैक के ज़रिए टीम सदस्य की growth को आगे बढ़ाने में किस तरह का मैनेजर ज़्यादा मदद कर सकता है? पिछला लेख पढ़ते हुए मेरे मन में यही सवाल आया।
मेरे हिसाब से यह probability का खेल है। बेहद खराब odds को पार करके grow करने वाले लोग कहीं भी मिल जाते हैं। मुझे लगता है कि मैनेजर को ऐसे लोगों को अलग रखकर कुल probability बढ़ाने की कोशिश करनी चाहिए। जो मैनेजर अपने तरीके से probability बढ़ाने वाला रवैया मानकर काम करता है, वह सम्मान के योग्य है। बस इतना काफ़ी है कि वह यह सोचकर पुराने तरीके पर अड़ा न रहे कि वैसे भी चल ही जाएगा।
Hacker News की राय तो डरावनी है... "एक करोड़? मज़ाक कर रहे हो?"
कहा तो गया है कि यह चेकलिस्ट नहीं है, लेकिन लगता है मुझे इसे अपनी चेकलिस्ट बना लेना चाहिए।
वाकई यह एक दिलचस्प प्रयोग है।
आजकल लग रहा था कि Gemini की Time to first token स्पीड बेहद तेज़ है, तो उसके पीछे यही वजह थी...
मैं इससे पूरी तरह सहमत हूँ कि आधिकारिक दस्तावेज़ ज़रूर देखने चाहिए।
जब मैं पहली बार coding सिखाता हूँ, तो यह बात कि कोई व्यक्ति error messages को ध्यान से पढ़ सकता है या नहीं, वहीं से पहली बार यह दिखने लगता है कि उसमें programmer बनने की योग्यता है या नहीं।
सभी नहीं, लेकिन ज़्यादातर बिंदु ऐसे हैं जिनसे सहमति बनती है।
मैंने कभी नहीं सोचा था कि यह हस्तशिल्प जैसा हो सकता है, लेकिन इससे बहुत सहमति महसूस होती है।
इस नज़रिए से सोचने पर लगता है कि कई घटनाएँ समझ में आ जाती हैं।
Hyperlight - हल्का Virtual Machine Manager (VMM) | GeekNews
Hyperlight WASM: तेज़, सुरक्षित और OS-Free | GeekNews
आलोचनात्मक टिप्पणियाँ देखकर मैंने बहुत सोचा। कुछ हिस्सों से सहमति है और कुछ पर मेरी अलग राय है।
Toss के लिए UX सीधे तौर पर survival से जुड़ा है
लेकिन इस लेख से अलग नज़रिए से देखें, तो मुझे नहीं पता कि वह कंपनी revenue को अच्छी तरह pursue करती है या नहीं