लेखक का संदेश थोड़ा कड़ा लग सकता है, लेकिन अगर आप लेख को ध्यान से पढ़ें, तो बात यह नहीं है कि "AI का उपयोग मत करो"। इसमें इस बात का सुझाव है कि इसका उपयोग कैसे किया जाए, और मुख्य संदेश यह है कि डेवलपर में खुद क्षमता की कमी नहीं होनी चाहिए.
अगर देखें कि लेखक का संदेश इतना कड़ा क्यों महसूस होता है, तो यह उस दृष्टिकोण के जवाब के रूप में बनाया गया है कि copilot के साथ development संभव हो जाएगा (यानि copilot पर development की निर्भरता अधिक होने वाली है)। इसी वजह से उन्होंने डेवलपर्स के लिए ऐसा रुख न अपनाने की बात कुछ तीखे अंदाज़ में रखी, जो उनकी अपनी मौजूदगी के मूल्य को नुकसान पहुँचाए.
लेखक का संदेश भी "AI का उपयोग मत करो" नहीं है, इसलिए अंत में अगर AI का उपयोग करना है, तो बात कहीं न कहीं एक समझौते के बिंदु पर ही आएगी; इस लिहाज़ से, आपने अभी जो जवाब दिया, उसका मूल संदेश भी लगभग उसी से मिलता-जुलता लगता है.
हालाँकि, आपने शुरुआत में जो 'पक्षपाती दृष्टिकोण' वाली बात लिखी थी, उससे सहमत होना मेरे लिए कठिन था, इसलिए पहले यह उत्तर दिया.
बनाना तो बस शुरुआत है, और अगर आप करीब 10 साल तक कोई सेवा चलाते हैं, तो बीच में हर तरह की चीज़ें होंगी; वहाँ टिके रहने के लिए बुनियाद चाहिए होगी... सीखना पड़ेगा।
सबसे पहले, मैंने जो "डोमेन के भीतर AI का उपयोग" कहा था, उसमें डिज़ाइन और समन्वय इंसान करता है—यह तो स्वाभाविक बात है...
दरअसल, भले ही पहले ऐसा न रहा हो, लेकिन अब जब हर कोई LLM की सीमाएँ जानता है, तो यह इतनी स्पष्ट बात हो गई है कि इसे अलग से कहने की भी ज़रूरत नहीं लगती।
इसके बाद, आपने जो कहा कि सामान्य लोग जिनके पास development knowledge नहीं है, वे LLM का उपयोग करते हैं—
ऐसा मामला न तो मूल लेख में, न Hacker News में, और न ही मैंने खुद कभी कहा था; लेकिन फिर भी, इस स्थिति में भी यूज़र्स जिस स्तर तक नतीजों से संतुष्ट हो सकें, वहाँ तक बात पहुँच चुकी है।
अगर ऐसा न होता, तो शायद Bolt.new, v0, और Cursor को आज जैसी प्रतिक्रिया नहीं मिल रही होती।
यह तय करना मुश्किल होता है कि कहाँ तक दोबारा खुद बनाना है और कहाँ तक बाहरी dependencies पर भरोसा करना है.
किसी भी स्थिति में, सिर्फ समय बचाने के लिए ऐसी dependency चुनना जिसे मैं खुद बना सकता हूँ, और उस dependency के बिना सेवा ही नहीं बना पाने के कारण उसी पर बंध जाना — ये दोनों बिल्कुल अलग बातें हैं.
यह हर तरह के code पर लागू नहीं हो सकता (जैसे operating system), लेकिन जितना हो सके उतना पहले वाले रुख की ओर बढ़ने की कोशिश करना system को समझने में मदद करेगा.
मुझे लगता है कि लेखक के अभिप्रेत अर्थ को समझने में थोड़ी गलतफहमी हुई है.
लेखक का फोकस उस प्रोजेक्ट के performance, stability, maintainability, architecture और code consistency पर है जिसे वह स्वयं मैनेज करते हैं, और खास तौर पर architecture तथा code consistency ऐसे क्षेत्रों में हैं जिनमें मौजूदा LLM वास्तव में बहुत कमजोर हैं.
खासतौर पर web में, डेवलपमेंट में आने वालों की संख्या बहुत अधिक है और 'किसी तरह चल जाए तो ठीक है' वाली सोच भी काफी मजबूत है, इसलिए बहुत बड़ी मात्रा में low-quality code deploy किया गया है. और LLM इन्हीं पर आधारित होकर train हुए हैं, इसलिए इनके outputs की quality हैरान कर देने वाली हद तक गिर जाती है.
बस, GPT से यह कहकर देखिए: 웹 프론트에 넣을껀데 js로 퀵소트 알고리즘 좀 구현해줘। अगर आप उसके output में समस्या नहीं ढूंढ पाते, तो मुझे नहीं लगता कि इस बातचीत का कोई खास मतलब बचेगा.
> लेखक की पुरानी पोस्टें देखें तो लगता है कि वह गेम डेवलपर हैं
> गेम डेवलपमेंट का ज्ञान या सामग्री LLM बड़े पैमाने पर सीख नहीं पाए हैं, इसलिए CRUD ऐप केस के विपरीत, मुझे लगता है कि मुख्य लेख के लेखक LLM की सीमाओं को ज़्यादा अच्छी तरह महसूस करते हैं
पूरा पढ़ा, और आखिरकार मुझे लगता है कि इसी वजह से लेखक ने थोड़ा पक्षपाती नज़रिया अपना लिया है.
बेशक, मुख्य लेख में जो कहा गया है वह लगभग पाठ्यपुस्तक जैसी बात है, इसलिए सही भी है, लेकिन
मेरा मानना है कि CRUD और फ्रंटेंड, जिनके लिए AI के पास सीखने की बहुत सामग्री है, उनमें यह पहले से ही काफी अच्छा काम कर रहा है.
लगता है कि हमें अपने-अपने domain के भीतर इसे जितना हो सके उतना अच्छी तरह उपयोग करना चाहिए.
GN+ मैंने AI बॉट से YouTube स्क्रिप्ट निकलवाकर उसका सारांश बनाने को कहा, तो इसकी परफ़ॉर्मेंस काफ़ी अच्छी लगी।
देखने के लिए वीडियो बहुत ज़्यादा थे, इसलिए मुश्किल हो रही थी, लेकिन यह अच्छा लग रहा है।
कहावतों में एक निहित अर्थ होता है, लेकिन अब बहुत लोग उन्हें सिर्फ शब्दशः ही समझते हैं
अगर ऐसी दलीलें ट्रेंड में आ जाएँ, तो फिर मीटिंग रूम बिना किसी झिझक के फिर से अराजकता का शिकार हो जाता है
पेपरवर्क वाले लोग उत्साह में उछलने लगते हैं और वही असफलता हर साल फिर दोहराई जाती है
यह काफ़ी हद तक उस देश के श्रम क़ानून के मानकों से जुड़ा होता है.. अमेरिका की बहुत-सी कंपनियाँ आम तौर पर इसे बस बारी-बारी से करती हैं, और जब किसी समय यह संभव नहीं होता तो क्रम बदल देती हैं। यह मुश्किल काम है, इसलिए.. कुछ कंपनियों में dedicated on-call टीम भी होती है.
यूरोप में तो सिर्फ़ काम की प्रकृति बदल जाने या overtime होने की वजह से ही लगभग अलग से compensation दिया जाता है.
हमारे यहाँ तो comprehensive wage system के जाल में फँसकर इसे बस जैसे-तैसे निपटा दिया जाता है। on-call भी साफ़ तौर पर काम ही है, लेकिन उस समय के लिए मिलने वाला भत्ता मानो कोई welfare benefit हो, ऐसा पैकेज करके पेश किया जाता है।
असल में उन सभी services को इस्तेमाल करना भी मुश्किल होगा, लेकिन इसमें MCP होना एक बड़ा फ़ायदा है।
आगे चलकर अगर API maintenance अच्छी तरह होती रही, तो यह उपयोगी लग रहा है।
Apple का hardware बेहतरीन है, लेकिन उसका software उपयोगकर्ताओं को बाँधकर रखने की मंशा से भरा हुआ है.
आप अपनी बनाई और build की हुई app को सिर्फ अपने ही device पर चलाना चाहें, तब भी 100 डॉलर का subscription चाहिए.
अगर आप छोटे या मध्यम स्तर के open source apps इस्तेमाल करते हैं और उन्हें खुद build करके चलाने वाले developer हैं,
तो Apple के device पर vulnerability का फायदा उठाकर jailbreak करके sideload करने से बेहतर है कि बस Android इस्तेमाल करें.
[लिंक हटाया गया] Android version का screenshot यहाँ डाल रखा है। जितना ज़्यादा इस्तेमाल करते हैं, यह उतना ही अजीब-सा लेकिन दिलचस्प tool लगता है। community भी geeky है और इसमें हैरान करने वाली कई बातें हैं।
सारांश,
लेखक: डेवलपर्स को खुद अपनी क्षमता बढ़ानी और उसे बनाए रखना चाहिए। यहाँ तक कि AI ठीक से काम भी नहीं करता।
crawler: अरे? मेरे लिए तो अच्छा काम करता है?
superscv: समस्याएँ बहुत हैं...
crawler: उसे सही तरह से ट्यून करके इस्तेमाल करना चाहिए
superscv: लगता है कि यह मूल लेखक जो संदेश देना चाहता था, उससे बहुत दूर निकल आया है..
लेखक का संदेश थोड़ा कड़ा लग सकता है, लेकिन अगर आप लेख को ध्यान से पढ़ें, तो बात यह नहीं है कि "AI का उपयोग मत करो"। इसमें इस बात का सुझाव है कि इसका उपयोग कैसे किया जाए, और मुख्य संदेश यह है कि डेवलपर में खुद क्षमता की कमी नहीं होनी चाहिए.
अगर देखें कि लेखक का संदेश इतना कड़ा क्यों महसूस होता है, तो यह उस दृष्टिकोण के जवाब के रूप में बनाया गया है कि copilot के साथ development संभव हो जाएगा (यानि copilot पर development की निर्भरता अधिक होने वाली है)। इसी वजह से उन्होंने डेवलपर्स के लिए ऐसा रुख न अपनाने की बात कुछ तीखे अंदाज़ में रखी, जो उनकी अपनी मौजूदगी के मूल्य को नुकसान पहुँचाए.
लेखक का संदेश भी "AI का उपयोग मत करो" नहीं है, इसलिए अंत में अगर AI का उपयोग करना है, तो बात कहीं न कहीं एक समझौते के बिंदु पर ही आएगी; इस लिहाज़ से, आपने अभी जो जवाब दिया, उसका मूल संदेश भी लगभग उसी से मिलता-जुलता लगता है.
हालाँकि, आपने शुरुआत में जो 'पक्षपाती दृष्टिकोण' वाली बात लिखी थी, उससे सहमत होना मेरे लिए कठिन था, इसलिए पहले यह उत्तर दिया.
बनाना तो बस शुरुआत है, और अगर आप करीब 10 साल तक कोई सेवा चलाते हैं, तो बीच में हर तरह की चीज़ें होंगी; वहाँ टिके रहने के लिए बुनियाद चाहिए होगी... सीखना पड़ेगा।
सबसे पहले, मैंने जो "डोमेन के भीतर AI का उपयोग" कहा था, उसमें डिज़ाइन और समन्वय इंसान करता है—यह तो स्वाभाविक बात है...
दरअसल, भले ही पहले ऐसा न रहा हो, लेकिन अब जब हर कोई LLM की सीमाएँ जानता है, तो यह इतनी स्पष्ट बात हो गई है कि इसे अलग से कहने की भी ज़रूरत नहीं लगती।
इसके बाद, आपने जो कहा कि सामान्य लोग जिनके पास development knowledge नहीं है, वे LLM का उपयोग करते हैं—
ऐसा मामला न तो मूल लेख में, न Hacker News में, और न ही मैंने खुद कभी कहा था; लेकिन फिर भी, इस स्थिति में भी यूज़र्स जिस स्तर तक नतीजों से संतुष्ट हो सकें, वहाँ तक बात पहुँच चुकी है।
अगर ऐसा न होता, तो शायद Bolt.new, v0, और Cursor को आज जैसी प्रतिक्रिया नहीं मिल रही होती।
यह तय करना मुश्किल होता है कि कहाँ तक दोबारा खुद बनाना है और कहाँ तक बाहरी dependencies पर भरोसा करना है.
किसी भी स्थिति में, सिर्फ समय बचाने के लिए ऐसी dependency चुनना जिसे मैं खुद बना सकता हूँ, और उस dependency के बिना सेवा ही नहीं बना पाने के कारण उसी पर बंध जाना — ये दोनों बिल्कुल अलग बातें हैं.
यह हर तरह के code पर लागू नहीं हो सकता (जैसे operating system), लेकिन जितना हो सके उतना पहले वाले रुख की ओर बढ़ने की कोशिश करना system को समझने में मदद करेगा.
मुझे लगता है कि लेखक के अभिप्रेत अर्थ को समझने में थोड़ी गलतफहमी हुई है.
लेखक का फोकस उस प्रोजेक्ट के performance, stability, maintainability, architecture और code consistency पर है जिसे वह स्वयं मैनेज करते हैं, और खास तौर पर architecture तथा code consistency ऐसे क्षेत्रों में हैं जिनमें मौजूदा LLM वास्तव में बहुत कमजोर हैं.
खासतौर पर web में, डेवलपमेंट में आने वालों की संख्या बहुत अधिक है और 'किसी तरह चल जाए तो ठीक है' वाली सोच भी काफी मजबूत है, इसलिए बहुत बड़ी मात्रा में low-quality code deploy किया गया है. और LLM इन्हीं पर आधारित होकर train हुए हैं, इसलिए इनके outputs की quality हैरान कर देने वाली हद तक गिर जाती है.
बस, GPT से यह कहकर देखिए:
웹 프론트에 넣을껀데 js로 퀵소트 알고리즘 좀 구현해줘। अगर आप उसके output में समस्या नहीं ढूंढ पाते, तो मुझे नहीं लगता कि इस बातचीत का कोई खास मतलब बचेगा.> लेखक की पुरानी पोस्टें देखें तो लगता है कि वह गेम डेवलपर हैं
> गेम डेवलपमेंट का ज्ञान या सामग्री LLM बड़े पैमाने पर सीख नहीं पाए हैं, इसलिए CRUD ऐप केस के विपरीत, मुझे लगता है कि मुख्य लेख के लेखक LLM की सीमाओं को ज़्यादा अच्छी तरह महसूस करते हैं
पूरा पढ़ा, और आखिरकार मुझे लगता है कि इसी वजह से लेखक ने थोड़ा पक्षपाती नज़रिया अपना लिया है.
बेशक, मुख्य लेख में जो कहा गया है वह लगभग पाठ्यपुस्तक जैसी बात है, इसलिए सही भी है, लेकिन
मेरा मानना है कि CRUD और फ्रंटेंड, जिनके लिए AI के पास सीखने की बहुत सामग्री है, उनमें यह पहले से ही काफी अच्छा काम कर रहा है.
लगता है कि हमें अपने-अपने domain के भीतर इसे जितना हो सके उतना अच्छी तरह उपयोग करना चाहिए.
क्या कंपनी सीखने की जगह है? या वह जगह जहाँ दूसरों के बनाए पहिए को लेकर मूल्य को फिर से रचा जाता है?
https://hi.news.hada.io/topic?id=21091
इसे यह लेख पढ़ने के बाद पढ़ा, तो लगा कि क्या सच में यही सही है।
नंबर 1 तो सचमुच किसी दुःस्वप्न जैसा है, ऐसा बदलाव जिसे मैं बिल्कुल स्वीकार नहीं करना चाहता। source code history tracking का बेमानी हो जाना।
GN+ मैंने AI बॉट से YouTube स्क्रिप्ट निकलवाकर उसका सारांश बनाने को कहा, तो इसकी परफ़ॉर्मेंस काफ़ी अच्छी लगी।
देखने के लिए वीडियो बहुत ज़्यादा थे, इसलिए मुश्किल हो रही थी, लेकिन यह अच्छा लग रहा है।
लगता है आपने कोई बढ़िया Electron प्रोजेक्ट देखा ही नहीं, इसलिए ऐसा कह रहे हैं ~
... शायद बात कुछ ऐसी ही है, हाहा
कहावतों में एक निहित अर्थ होता है, लेकिन अब बहुत लोग उन्हें सिर्फ शब्दशः ही समझते हैं
अगर ऐसी दलीलें ट्रेंड में आ जाएँ, तो फिर मीटिंग रूम बिना किसी झिझक के फिर से अराजकता का शिकार हो जाता है
पेपरवर्क वाले लोग उत्साह में उछलने लगते हैं और वही असफलता हर साल फिर दोहराई जाती है
यह काफ़ी हद तक उस देश के श्रम क़ानून के मानकों से जुड़ा होता है.. अमेरिका की बहुत-सी कंपनियाँ आम तौर पर इसे बस बारी-बारी से करती हैं, और जब किसी समय यह संभव नहीं होता तो क्रम बदल देती हैं। यह मुश्किल काम है, इसलिए.. कुछ कंपनियों में dedicated on-call टीम भी होती है.
यूरोप में तो सिर्फ़ काम की प्रकृति बदल जाने या overtime होने की वजह से ही लगभग अलग से compensation दिया जाता है.
हमारे यहाँ तो comprehensive wage system के जाल में फँसकर इसे बस जैसे-तैसे निपटा दिया जाता है। on-call भी साफ़ तौर पर काम ही है, लेकिन उस समय के लिए मिलने वाला भत्ता मानो कोई welfare benefit हो, ऐसा पैकेज करके पेश किया जाता है।
असल में उन सभी services को इस्तेमाल करना भी मुश्किल होगा, लेकिन इसमें MCP होना एक बड़ा फ़ायदा है।
आगे चलकर अगर API maintenance अच्छी तरह होती रही, तो यह उपयोगी लग रहा है।
Apple का hardware बेहतरीन है, लेकिन उसका software उपयोगकर्ताओं को बाँधकर रखने की मंशा से भरा हुआ है.
आप अपनी बनाई और build की हुई app को सिर्फ अपने ही device पर चलाना चाहें, तब भी 100 डॉलर का subscription चाहिए.
अगर आप छोटे या मध्यम स्तर के open source apps इस्तेमाल करते हैं और उन्हें खुद build करके चलाने वाले developer हैं,
तो Apple के device पर vulnerability का फायदा उठाकर jailbreak करके sideload करने से बेहतर है कि बस Android इस्तेमाल करें.
हमारे यहाँ ऑन-कॉल के लिए प्रति घंटा वेतन का आधा, communication खर्च के लिए सहायता, और सपोर्ट के समय को overtime मानकर 1.5 गुना भुगतान किया जाता था।
बीच में C# गैंग छिपा हुआ है।
> साफ़ कहें तो आज Java development करते समय ज़रूरी नहीं कि JetBrains के products ही इस्तेमाल किए जाएँ, लेकिन
इस हिस्से से... थोड़ी सहमति जताना मुश्किल है, हाय...
[लिंक हटाया गया] Android version का screenshot यहाँ डाल रखा है। जितना ज़्यादा इस्तेमाल करते हैं, यह उतना ही अजीब-सा लेकिन दिलचस्प tool लगता है। community भी geeky है और इसमें हैरान करने वाली कई बातें हैं।