- हाल के coding education माहौल में “ट्यूटोरियल नर्क” की जगह “vibe coding नर्क” एक नई समस्या के रूप में उभरा है
- अगर ट्यूटोरियल नर्क वह स्थिति थी जहाँ "ट्यूटोरियल के बिना कुछ भी नहीं बनाया जा सकता", तो vibe coding नर्क का मतलब है "AI के बिना coding नहीं कर पाना, और AI द्वारा बनाए गए code के काम करने का तरीका समझ न पाना"
- AI tools का अत्यधिक उपयोग सीखने की motivation को कम कर रहा है, और paradoxically जिन लोगों की AI literacy कम है वे AI का ज़्यादा उपयोग कर रहे हैं
- AI tools का सही तरीके से उपयोग किया जाए तो वे learning support में बहुत मददगार हो सकते हैं, लेकिन बिना सोचे-समझे सिर्फ ‘answer पाने’ के लिए उनका उपयोग रचनात्मक समझ बनाने में बाधा बनता है
- सीखने की प्रक्रिया में खुद सोचना और स्वयं समाधान निकालने की कोशिश करना सबसे अहम है, और ट्यूटोरियल या AI सहायता के बिना problem-solving का अनुभव बनाना ज़रूरी है
समस्या की पृष्ठभूमि: ट्यूटोरियल नर्क से vibe coding नर्क तक
- 2019 में coding education की मुख्य समस्या "ट्यूटोरियल नर्क" थी
- ट्यूटोरियल को follow करने में सफलता मिलती थी, लेकिन अकेले कुछ भी नहीं बनाया जा सकता था
- असली programming से ज़्यादा समय programming से जुड़े videos देखने में खर्च होता था, और core concepts समझ में नहीं आते थे
- नतीजतन केवल सतही ज्ञान इकट्ठा होता था, और अंदरूनी working principles समझ में न आने से वास्तविक परिस्थितियों में code खुद नहीं लिखा जा पाता था
- Boot.dev ने इसे हल करने के लिए तीन चीज़ों पर ध्यान दिया
- गहन curriculum: पारंपरिक university के बाहर भी CS fundamentals सीखने की ज़रूरत पर ज़ोर
- hands-on approach: हर concept सीखते समय code सीधे खुद लिखना
- video की जगह rich text पर ज़ोर: video passive consumption तक सीमित हो सकता है
- 2019 में लाखों views पाने वाली लंबी YouTube lectures अब 50 हज़ार views तक पहुँचना भी मुश्किल पा रही हैं
- FreeCodeCamp, Traversy Media, Web Dev Simplified जैसे channels में यह रुझान दिखता है
- लेकिन "learn to code" के लिए Google Trends data अब भी ऊँची रुचि दिखाता है
- Boot.dev पर हर दिन लगभग 1,300 नए users register करते हैं, और पिछले 18 महीनों में ट्यूटोरियल नर्क की शिकायतें घटी हैं, लेकिन मुश्किल का एक नया रूप सामने आया है
vibe coding नर्क की परिभाषा
- ट्यूटोरियल नर्क की विशेषताएँ
- "ट्यूटोरियल के बिना मैं कुछ भी नहीं बना सकता"
- "documentation समझ में नहीं आता, इसलिए video चाहिए"
- "छोटे काम के लिए भी complex framework चाहिए"
- vibe coding नर्क की विशेषताएँ
- "Cursor की मदद के बिना मैं कुछ नहीं कर सकता"
- "मैंने एक शानदार tower defense game बना लिया है। यह रहा लिंक http://localhost:3000";
- "मुझे नहीं पता कि image lazy-load के लिए Claude ने 6,379 lines क्यों जोड़ दीं"
- आज के self-directed learners बहुत कुछ बना रहे हैं, लेकिन ऐसे projects तैयार कर रहे हैं जिनसे software कैसे काम करता है इसका mental model विकसित नहीं होता
- वे AI hallucination से लड़ते हैं, test pass कराने पर ही केंद्रित bots से जूझते हैं, और वास्तविक problem-solving की बजाय AI-generated code पर आँख बंद करके भरोसा करते हैं
AI coding का भविष्य और वास्तविकता
- मेरा short term में यह सकारात्मक मानना है कि AI developers को पूरी तरह replace नहीं करेगा
- "AI jobs छीनने में सिर्फ 6 महीने दूर है" जैसी बात कहे 3 साल हो चुके हैं, लेकिन अब भी developers hire किए जा रहे हैं
- GPT-5 जारी हो चुका है, लेकिन GPT-4 की तुलना में यह केवल incremental improvement रहा, और इसे इस बात के सबूत के रूप में देखा जा सकता है कि AGI अभी तुरंत नहीं आने वाला
- मैं रोज़ AI tools का उपयोग करता हूँ, लेकिन वास्तव में productivity कितनी बढ़ती है, इस पर मुझे यक़ीन नहीं
- यह साफ़ नहीं कि AI हमें ज़्यादा productive बना रहा है या ज़्यादा lazy
- 2025 के research result: developers ने मान लिया था कि AI productivity को 20-25% बढ़ाएगा, लेकिन वास्तव में वे 19% धीमे हो गए
- 7 trillion dollar के investment की तुलना में यह निराशाजनक नतीजा है
AI और सीखने की motivation घटने का जोखिम
- AI के उपयोग की संस्कृति learners की motivation पर नकारात्मक असर डाल सकती है
- AI hype (bubble?) की सबसे बड़ी चिंता यह है कि "क्यों सीखें? AI को सब पता है" जैसी सोच वाली पीढ़ी उभर रही है
- अगर AI वास्तव में सभी white-collar jobs को replace नहीं कर पाया, तो stock market bubble के साथ-साथ trained talent की कमी भी पैदा हो सकती है
- तकनीकी पृष्ठभूमि न रखने वाले investors “AI ने coding को पहले ही पूरी तरह replace कर दिया है” यह गलतफहमी पाल रहे हैं, जबकि senior developers अब भी AI tools को रोज़मर्रा के काम में उपयोगी ढंग से integrate करने का तरीका नहीं खोज पाए हैं
- जिन लोगों की AI literacy कम है, वे AI का ज़्यादा उपयोग करते हैं, और यह चिंताजनक है
- यह एक तरह का ultimate ‘Dunning-Kruger’ trap बन जाता है — कम ज्ञान वाला व्यक्ति उल्टा यह मान लेता है कि वह बहुत अच्छी तरह जानता है
- learners यह निष्कर्ष निकाल लेते हैं कि "AI को पहले से सब पता है", इसलिए self-improvement का कोई मतलब नहीं
क्या AI सीखने के लिए फायदेमंद है?
- coding सीखने में सामाजिक रुचि अब भी बहुत अधिक है
- AI learning में मददगार हो सकता है, लेकिन दो structural problems मौजूद हैं
-
पहली समस्या: sycophant समस्या
- AI chatbots सवाल पूछने वाले की राय से हद से ज़्यादा सहमत होने की प्रवृत्ति रखते हैं
- “ROAS(विज्ञापन लाभ दर) के बारे में” पर chat करके देखें, तो वही data होने पर भी सवाल किस दिशा में पूछा गया है उसके आधार पर पूरी तरह उलटे निष्कर्ष निकलते हैं, और हर बार expert tone में पूरे confidence के साथ जवाब दिया जाता है
- इससे learners को verification, critical thinking, और गलती पकड़ने का अनुभव मिलने का मौका नहीं मिलता
- हम experts से इसलिए पूछते हैं क्योंकि जब हम गलत हों तो वे हमें बताएँ
- IRC chat या Stack Overflow यह काम अच्छी तरह करते थे (शायद ज़रूरत से ज़्यादा अच्छी तरह)
- LLM(large language model) chatbots अक्सर learners की बुनियादी गलतफहमी को ठीक नहीं कर पाते
- आज के students LLM के साथ आरामदायक बातचीत करते हुए वही सुनते हैं जो वे सुनना चाहते हैं, न कि जो उन्हें चाहिए
-
दूसरी समस्या: learners को वास्तविक ‘opinions’ चाहिए
- AI बहुत ज़्यादा balanced position पेश करता है
- "कुछ लोग X सोचते हैं और कुछ लोग Y सोचते हैं"
- इससे learners के लिए तय करना और मुश्किल हो जाता है कि किस पक्ष से सहमत हों
- "capitalist की भूमिका निभाओ" या "Marxist revolutionary की भूमिका निभाओ" जैसे prompts दिए गए, लेकिन संतोषजनक परिणाम नहीं मिले
- learners वास्तविक अनुभव से निकली राय और टिप्पणियाँ सुनना चाहते हैं
- DHH ने Turbo से TypeScript हटाने की वजह
- Anders Hejlsberg ने TypeScript JavaScript developers की कौन-सी समस्या हल करता है
- हर लेखक के bias और context साफ़ दिखने वाली वास्तविक राय के ज़रिए सूक्ष्म mental models बनते हैं
- LLM की विशिष्ट neutral और cautious responses वास्तविक knowledge internalize करने में बाधा बनती हैं
जब AI सच में सीखने में मदद करता है
- AI का सही उपयोग किया जाए तो यह learning के लिए एक अद्भुत tool है
- coding सीखने के लिए इससे आसान समय पहले कभी नहीं था
- Boot.dev के Boots(AI education support tool) का उदाहरण
- students instructor solution (आदर्श उत्तर) देखने की तुलना में AI tutor (Boots) से chat करने का लगभग 4 गुना अधिक उपयोग करते हैं
- Boots, सामान्य chatbot से अलग, इन तरीकों से learning में मदद करता है
- इसे पहले से इस तरह prompt किया गया है कि यह सीधे answer न बताए
- यह Socratic method का उपयोग करके student को समस्या पर और गहराई से सोचने के लिए प्रेरित करता है
- इसे instructor solution तक access है, इसलिए सही उत्तर के बारे में hallucination की संभावना बहुत कम है
- इसमें मज़ेदार character flavor है (जादुई भालू)
vibe coding नर्क से बाहर निकलने का तरीका
- निष्कर्ष यह है कि चाहे ट्यूटोरियल नर्क हो या vibe नर्क, ‘दूसरों पर छोड़े बिना खुद करके देखने’ का अनुभव बेहद महत्वपूर्ण है
- ट्यूटोरियल नर्क: video बंद करके खुद code लिखने का अनुभव जमा करना
- vibe नर्क: Copilot जैसे AI autocomplete को बंद करके, खुद problem-solving का अनुभव बनाना
- जिनसे बचना चाहिए:
- editor के अंदर AI autocomplete
- agent mode और AI automation tools से पूरे project को निपटाना
- जिनका उपयोग किया जा सकता है:
- ऐसे chatbots जो सवालों के जवाब दें, concepts समझाएँ, और examples दें
- ऐसे system prompts जो Socratic method से सवाल पूछने के लिए प्रेरित करें, ताकि गहरी सोच विकसित हो
- ऐसे system prompts जो दावे करते समय sources cite करने और documentation से link देने को कहें, ताकि जानकारी की reliability बनी रहे
मुख्य सिद्धांत
- सीखना असुविधाजनक होना ही चाहिए
- ट्यूटोरियल नर्क आपको दूसरे लोगों को coding करते हुए देखकर उस असुविधा से बचने देता है
- vibe coding नर्क AI से code लिखवाकर उस असुविधा से बचने देता है
- असली learning तब होती है जब आप अटकते हैं, निराश होते हैं, और सबसे महत्वपूर्ण बात, आपको problem-solving करने के लिए मजबूर होना पड़ता है
- इंसानी neural network के rewiring का यही तरीका है
- "सीखना कठिन होना चाहिए" इस विचार को बहुत बढ़ा देने पर यह खराब education design का बहाना बन सकता है
- लेखक इसका समर्थन नहीं करता
- चाहे concepts को सबसे अच्छे तरीके से समझाया जाए, student को फिर भी उससे जूझना होगा और उसे नए context में खुद इस्तेमाल करना होगा, तभी वास्तविक समझ बनेगी
- असली learning खुद अटकने, निराश होने और अपनी ताकत से आगे बढ़ने की प्रक्रिया में पूरी होती है
3 टिप्पणियां
थोड़ा अलग संदर्भ है, लेकिन tutorial hell होने का एक कारण यह भी है कि framework tutorials का इस्तेमाल बुनियादी CS शैक्षिक सामग्री के रूप में नहीं किया गया।
Django tutorial देखकर poll app बना चुका कोई शुरुआती व्यक्ति अपने दम पर blog नहीं बना पाता, क्योंकि django tutorial इस बात के लिए लिखा गया होता है कि जिसे पहले से http क्या है, template क्या है, ws क्या है, db क्या है वगैरह सब पता है, उसे django समझाया जा सके; यह web को समझाने वाला लेख नहीं होता। Django tutorial में बहुत सारा context छोड़ा हुआ होता है, और मुझे लगता है कि यही tutorial hell पैदा होने का कारण है.
Django tutorial को आज पहली बार programming करने वाले व्यक्ति के लिए फिर से लिखकर देखना भी एक अच्छा काम हो सकता है। जैसे पहले Http की संरचना समझाई जाए, और फिर बताया जाए कि django हर तत्व को कैसे handle करता है।
बहुत बढ़िया राय है!
Hacker News की राय
"Tutorial Hell" शब्द से बहुत जुड़ाव महसूस होता है। 6 घंटे का लेक्चर देखकर साथ-साथ कोड तो लिख लेते हैं, लेकिन जब सच में शुरुआत से कुछ बनाने को कहा जाए तो हाथ रुक जाते हैं। यही असली tutorial hell है। इसी वजह से ऐतिहासिक रूप से apprenticeship सबसे असरदार सीखने का तरीका रहा है। जूनियर, सीनियर के साथ काम करता है, और master craftsman ऊपर से पूरी दिशा देता है। कारीगर खुद प्रोजेक्ट मैनेजमेंट और मार्गदर्शन दोनों करता है। अफसोस है कि हमारा developer समुदाय लंबे समय तक guild की तरह संचालित नहीं हुआ। मेरा मानना है कि 1980 के दशक के अंत से ही ऐसा नहीं होना चाहिए था। अगर guilds होतीं, तो शायद developers की संख्या काफी कम होती और पूरी इंडस्ट्री का विकास ही अलग दिशा में जाता।
सिर्फ नए लोग ही नहीं, अनुभवी developers भी अगर कहा जाए कि शून्य से project शुरू करो, तो मुश्किल महसूस करते हैं। ज़्यादातर लोग मौजूदा codebase पर काम करते हैं, और नई app की ज़रूरत पड़े तो template या copy-paste से शुरुआत करते हैं। सचमुच पूरी तरह नया कुछ एकदम शुरुआत से बनाना आम बात नहीं है। जैसे कोई electrician नई building में wiring करे, वैसे किसी कंपनी के developer को असल में सब कुछ बिल्कुल शुरुआत से सेट करना बहुत कम पड़ता है। apprenticeship भी मूल रूप से इस संरचना को बहुत नहीं बदलती।
मेरे अनुभव में, अच्छे universities छात्रों को क्रमिक और practical assignments के ज़रिए प्रशिक्षित करते हैं। शुरुआत में आसान data structures, algorithms और puzzles हल कराए जाते हैं, फिर OS, databases, persistent data structures, compilers, CPU, simulations, machine learning models तक बनवाए जाते हैं। एक function से शुरू करके धीरे-धीरे खुद बड़ी चीज़ें बनानी पड़ती हैं, और मैं इस तरह की training के लिए सच में आभारी हूँ। संबंधित लिंक देखें।
मैं coding सीखने में LLM को apprentice-master रिश्ते की तरह इस्तेमाल करता हूँ। LLM तभी आगे बढ़ता है जब मैं कहूँ, वह सिर्फ समझाता और दिशा देता है, लिखता मैं खुद हूँ। यह नई lectures या tutorials खोजने से कहीं बेहतर है। सच कहूँ तो tutorial hell उन लोगों ने बनाया है जो खुद को teacher समझते हैं। ढेर सारी किताबें और courses भी अंततः व्यावहारिक रूप से कुछ सिखा नहीं पाते। मुझे लगता है कि मौजूदा coding education model पूरी तरह गलत है। आजकल मैं LLM से नई language या library के ताज़ा docs का सार निकलवाना पसंद करता हूँ, या फिर खुद plan बनाता हूँ। बस LLM hallucinate कर रहा है या नहीं, इस पर भरोसा नहीं होता, इसलिए थोड़ी असंतुष्टि रहती है।
मैंने स्कूल बहुत जल्दी छोड़ दिया था, वजह थी बोरियत और पुराना पढ़ाने का तरीका। मैं software engineer apprentice के रूप में सीधे काम में उतर गया, और स्कूल का curriculum मेरे किसी काम नहीं आया। 90 के दशक के आख़िर में सब कुछ गलतियों और trial-and-error से भरा था, और मैं, मेरा master, और उसके master तक सब कुछ खुद टकराकर सीख रहे थे। Linux से ISDN router बनाया, website servers सेट किए, HTML, Perl, PHP के साथ काम किया, और असली DevOps व engineering का अनुभव लिया, भले उस समय ऐसे शब्द भी नहीं थे। लगभग बिना documentation के, सिर्फ रचनात्मकता और चुनौती लेने की भावना से सीमाएँ आगे बढ़ाने का दौर था। आज के AI युग की vibe coding से उसकी एक समानता महसूस होती है। दबाव अब कहीं ज़्यादा है, लेकिन वह सचमुच मज़ेदार याद है।
tech industry में पेशे से जुड़ी gatekeeping को नकारात्मक नज़र से देखा जाता है। इसके पीछे इंडस्ट्री का अहंकार भी है, और capital की वह ताकत भी जो workforce बढ़ाकर wages नीचे रखना चाहती है। इसका नतीजा यह हुआ कि ठीक-ठाक professional standards गायब हो गए, और leetcode जैसे अपमानजनक interviews, पेशे से असंबंधित gatekeeper बन गए।
मैं Zed Pro और GPT का हर दिन coding में इस्तेमाल करता हूँ, और मुझे लगता है कि ऐसे tools की प्रगति modern programming की inefficiency को उजागर करती है। आधुनिक web एक साथ अद्भुत भी है और भयावह भी। अगर bureaucracy का मतलब जटिल नियमों के जाल में उलझना है, तो modern development उसका सबसे बड़ा उदाहरण है। अगर सबसे आसान काम के लिए भी probability-based automation tools के मार्गदर्शन की ज़रूरत पड़े, तो यह कुछ उदास करने वाली बात है। पहले मैं juniors से कहता था, "किसी खास language को जानना महत्वपूर्ण नहीं है, लगातार नई चीज़ें सीखने की क्षमता ही असली बात है।" कुछ trends लंबे समय तक रहेंगे, लेकिन अंततः नए tools और languages लगातार सीखने ही पड़ेंगे। शायद यह उम्र का असर हो, पर मुझे लगा कि एक बिंदु के बाद यह complexity हद से ज़्यादा बढ़ने लगी। पहले programming बहुत electrical engineering जैसी या गणित जैसी लगती थी, अब उस पर एक अलग तरह की complexity चढ़ गई है।
मुझे भी यह एहसास समझ आता है। SF फिल्मों की तरह मैं कभी ऐसा computing environment चाहता था जहाँ बस "ऊर्जा आगे भेजो!" कहो और parts या systems आसानी से interchangeable और reusable हों। लेकिन हकीकत में Android phone का camera iPhone में बदलना भी लगभग असंभव काम है।
आप क्या कहना चाह रहे हैं, यह पूरी तरह स्पष्ट नहीं है, लेकिन bureaucracy वाला इस्तेमाल अजीब लगता है। असल में search skill ही मुख्य क्षमता है, इसलिए जो चीज़ें ढूँढ सकता है, वह कुछ भी कर सकता है। automation tools भी मूल रूप से किताब या teacher से अलग नहीं हैं। कुछ लोगों में यह क्षमता कम होना तो मानव स्वभाव की स्थायी बात है, इसलिए tools के बेहतर होने को दोष नहीं देना चाहिए।
documentation को ठीक से लिखना, ढूँढना और पढ़ना सचमुच बहुत कठिन है, यही बड़ी समस्या है। इसलिए सीखना मुश्किल है, लेकिन AI की वजह से सीखना आसान भी हुआ है। उदाहरण के लिए Unreal Engine जैसी चीज़ों को भी AI आश्चर्यजनक रूप से अच्छी तरह समझता है।
जिन कई समस्याओं का बोझ हम उठा रहे हैं, वे सब Brooks की 'No Silver Bullet' में बताई गई accidental complexity हैं। LLM ऐसी complexity को भेदते हैं और languages व frameworks के हिसाब से बने knowledge silos को भी तोड़ देते हैं।
अगर यह speculative industry कुछ समय और ऐसे ही चलती रही, तो शायद ऐसा समय भी आए जब programming खुद ही गायब हो जाए।
आजकल हर कोई code लिख सकता है, इसलिए संगठन स्तर पर code की मात्रा शायद 10 गुना बढ़ गई है। लेकिन reviewers की संख्या वही है, इसलिए यह संभल नहीं रहा। अगर LLM code sanity check भी इस्तेमाल न कर सकें, तो फिर आखिर किया क्या जाए? सच में कल ही एक गैर-विशेषज्ञ ने Codex से optimization algorithm बनाया, और मुझसे उसे बेहतर करने को कहा गया। समस्या यह थी कि वह code पूरी तरह बिखरा हुआ था। वह हज़ारों integer combinations पर brute-force जैसा search कर रहा था, constraints भी ठीक से नहीं मान रहा था, इसलिए नतीजे भरोसेमंद नहीं थे। अंत में मुझे पूरा दिन code review में लगाना पड़ा, और फिर executives के सामने presentation देनी पड़ी कि यह चीज़ मूल रूप से बेकार है।
"LLM code sanity check" का जवाब unit tests हैं। LLM test code और testable code भी बहुत अच्छी तरह बना सकता है, अगर आप कहें तो। अगर tests सच में code को call करें और edge cases तक जाँचें, तो यह code review से कहीं तेज़ हो सकता है। इसमें performance tests वगैरह भी शामिल हो सकते हैं। आगे चलकर शायद काम definitions और tests-केंद्रित हो जाएगा, और function के अंदर implementation कैसे है यह कम महत्वपूर्ण होता जाएगा। यह एक बड़ा mindset shift होगा।
Excel programming वाले हालात को देख लीजिए। शुरुआत में सब उसे नज़रअंदाज़ करते हैं, और जब वह फट पड़ता है तो फिर बहुत देर से जागते हैं और लाखों रुपये खर्च कर कंपनी डूबने से पहले उसे संभालने की कोशिश करते हैं।
'reviewers की संख्या वही है' वाली बात पर, LLM code review में भी मदद कर सकते हैं। GPT-5 भी off-by-one जैसी स्थानीय errors या missing return values पकड़ने में काफ़ी अच्छा है। लेकिन जहाँ पूरे structure की ऊँचे स्तर की समझ चाहिए, वहाँ अभी इसकी सीमाएँ हैं। भविष्य में शायद बड़े codebases को नियमित रूप से LLM पर fine-tune करके, हर बदलाव के लिए first-pass reviewer की तरह इस्तेमाल करना संभव हो।
OR (combinatorial optimization) समस्याओं में दिक्कत यह भी है कि ad-hoc coding करने वाले लोग समझ नहीं पाते कि वे मूल रूप से एक विशेष algorithmic domain में फँस गए हैं। यहाँ तक कि बता भी दो, तो अक्सर वे mathematical theory समझ नहीं पाते और बस अपने ही तरीके से कोशिश करते रहते हैं।
ऐसी स्थिति में कंपनी के leaders को technical presentation देकर मौजूदा स्थिति का सही बोध कराना शायद व्यावहारिक रूप से एकमात्र प्रतिक्रिया हो सकती है।
मुझे लगा था कि फिर वही बात होगी कि AI junior developers को खराब कर रहा है और इसलिए senior replacement crisis आएगा। इस लेख में वह बात अप्रत्यक्ष रूप से कुछ हद तक है भी, और कुल मिलाकर मैं सहमत हूँ। लेकिन sycophancy वाला हिस्सा खास तौर पर प्रभावशाली लगा। पहले मुझे लगता था कि ChatGPT जैसी interfaces सीखने में मददगार हैं, लेकिन YouTube ROAS वाला उदाहरण बहुत ज़ोर से लगा। अगर सवाल पूछने का तरीका ही teacher के निष्कर्ष को छात्र की पसंद की दिशा में मोड़ सकता है, तो अनगिनत नए developers गलत दिशा में ले जाए जाएँगे। यहाँ तक कि AI "Boot" पर लागू अलग-अलग prompting पर्याप्त हैं या नहीं, यह भी नहीं पता। आखिरकार AI के युग में भी बढ़ने के लिए ज़रूरी है कि "कोई" बार-बार मेरा PR reject करे। वह "कोई" अभी AI नहीं हो सकता।
मेरे अनुभव में, चाहे आप Scathing critique माँगें, AI फिर भी मुझे अच्छा महसूस कराने की कोशिश करता है। GPT के पुराने versions हों या नए, यह लगभग एक जैसा है। एक अजीब-सा अधूरापन महसूस होता है। अंत में यह tool सिर्फ उन्हीं के हाथ में सबसे उपयोगी बनता है जो सच में मदद लेना जानते हों और LLM की खास कमज़ोरियों से परिचित हों।
sycophancy से बचने के लिए मैं हमेशा उलटा bias डालकर दो बार पूछता हूँ। लेकिन AI मेरे भीतर मौजूद छिपे biases को भी मज़बूत कर रहा है या नहीं, यह मैं नहीं जान सकता।
मैं beginner नहीं हूँ, लेकिन नए frameworks, languages और algorithms लगातार सीखता रहता हूँ, इसलिए मुझे AI autocomplete बुरा नहीं लगता। पहले का IntelliSense या ReSharper autocomplete भी नई libraries या language features सीखने में बहुत मददगार था। ReSharper पुराने तरीके से code लिखने पर नए features सुझाता था, और मैंने उससे बहुत कुछ सीखा। AI-based autocomplete इससे काफ़ी आगे बढ़ा हुआ लगता है। यह चीज़ें स्वाभाविक रूप से सुझाता है, और आप चाहें तो उपयोग करें, चाहें तो न करें, इसलिए सीखने में भी मदद मिलती है। अंततः अगर आपके भीतर जिज्ञासा है और आप सुझाव पढ़कर समझना चाहते हैं, तो AI की वजह से सीखना आसान हो जाता है। पहले तो लोग बस Stack Overflow से copy-paste करते थे।
पारंपरिक autocomplete उस scope के सभी methods, variables, constants वगैरह दिखाता था, और docs से भी जोड़ता था। मैं खुद देख सकता था कि कौन-कौन से options हैं, इसलिए यह सीखने के लिए बहुत अच्छा था। AI autocomplete दरअसल Stack Overflow का जवाब बिना context समझाए चिपका देने जैसा है। अगर आप सीख रहे हैं, तो बेहतर है खुद Stack Overflow खोजें, या ज़रूरत हो तो chatbot से पूछकर यह भी समझें कि वह code ऐसा क्यों है।
मुझे लगता है इसमें थोड़ा फ़र्क है। अगर कुछ अनुभव हो, तो नई language में autocomplete इस्तेमाल करना स्वाभाविक लगता है। लेकिन बुनियाद के बिना कोई beginner पहली बार for loop ही सीख रहा हो, तो वह अलग बात है।
मुझे AI agentic programming पसंद है। कुछ बनाना मुझे खुशी देता है, और यह ideas को परखने का हिस्सा है। मैं code को production में deploy नहीं कर रहा, इसलिए दूसरे क्या सोचेंगे इसकी परवाह नहीं करता। तकनीकी रूप से शानदार लोगों से बात करने के लिए खुद कोशिश करना और सीखना ज़रूरी है। मुझे 10 साल की उम्र से programming पसंद थी, लेकिन मैं पेशेवर developer नहीं बना। AI युग आने पर coding और experimentation के लिए मेरा प्रेम फिर जाग गया। WASM जैसी future web technologies, अलग-अलग systems, bugs ढूँढना, और चीज़ों को अपने तरीके से करना मुझे बहुत आनंद देता है। Cursor AI जैसे tools मेरे git setup तक automate कर देते हैं, इसलिए ssh से push करना भी आसान हो जाता है। मैं खुद भी कर सकता हूँ, लेकिन AI से करवाता हूँ। बचपन में C syntax से शुरुआत करने के कारण कुछ आदतें पक्की हो गई हैं, लेकिन python backend, flask web server, और JavaScript frontend के साथ काम करने में बहुत मज़ा आता है। WASM Python अभी काफ़ी अधूरा है, पर मैं प्रयोग जारी रखे हुए हूँ। fundamentals मज़बूत करना और अपने तरीके से सीखना ही मुझे पसंद है। मुझे अक्सर लगता है कि engineers ज़रूरत से ज़्यादा चीज़ों को complex बना देते हैं।
AI autocomplete सबसे बेहतरीन tools में से एक है। बिना documentation खोले मनचाहा code suggestion मिल जाता है, और चूँकि वह कुछ ही lines का होता है, review करना भी आसान है। यह अपने-आप बड़े chunks नहीं बना देता, इसलिए सीखने को नुकसान भी नहीं पहुँचाता।
मैं beginner नहीं हूँ, लेकिन Copilot की वजह से Rust सीखना निश्चित रूप से आसान हुआ। Intellisense के साथ मिलाकर इस्तेमाल करने से syntax का बोझ कम हो जाता है और language के महत्वपूर्ण हिस्सों को सीखने पर ध्यान दिया जा सकता है। Rust की किताब खोलने से लेकर एक हफ्ते के अंदर चलने वाला tool बनाने तक पहुँच गया। बेशक इससे मैं senior engineer नहीं बन गया, लेकिन '0 से 1' का hurdle यह साफ़ तौर पर कम कर देता है। मैं Copilot को code लिखने का आदेश नहीं देता, बस इसे बेहतर autocomplete की तरह उपयोग करता हूँ और सुझाव स्वीकार करना है या नहीं, यह खुद तय करता हूँ।
यहाँ बार-बार लौटने वाला विषय यह है कि अनुभवी seniors, चाहे नई language न जानते हों, फिर भी 'code करना' जानते हैं, इसलिए वे ऐसे tools से मूल्य निकाल सकते हैं। language बदल जाए, code smells वही रहते हैं। beginners को तो अक्सर 'code smell' की अवधारणा भी नहीं पता होती।
मुझे भी पहले लगता था कि Copilot Rust सीखने में बहुत मदद करता है, लेकिन AI के बिना खुद code लिखकर देखा तो वह सचमुच कठिन था। AI बंद करके सीखने से ही इस भ्रम से बाहर निकला जा सकता है कि आप सच में जानते हैं।
पढ़ाई के अलग-अलग shortcuts में भी यही समस्या है। छात्र tuition में किसी से homework करवाते हैं, या सिर्फ explanation सुनकर मान लेते हैं कि अब exam में आत्मविश्वास रहेगा। सच तो यह है कि सुनते समय चीज़ें आसान लगती हैं, लेकिन उन्हें सच में खुद करके दिखाना बिल्कुल अलग क्षमता है।
अगर AI सचमुच कुछ सालों में सभी white-collar jobs को replace नहीं करता, तो मुझे लगता है कि हमें सिर्फ stock market bubble ही नहीं, बल्कि शिक्षित workforce की कमी का भी सामना करना पड़ेगा। मेरे लिए यह उस झटके जैसा लगता है जैसे "मैं अपनी पीढ़ी की सबसे प्रतिभाशाली क्षमताओं को यूँ बिखरते देख रहा हूँ"।
मैंने लेख के शीर्षक के लिए कोई ठीक-ठाक प्रतिनिधि वाक्यांश ढूँढने की कोशिश की, लेकिन उपयुक्त कुछ नहीं मिला, इसलिए अपनी ओर से सबसे अच्छा किया। अगर कोई अधिक सटीक और neutral शीर्षक सुझाव हो, तो बदला जा सकता है। संबंधित निर्देश
"समझ तो लिया, लेकिन अगर शुरुआत से खुद लिखने को कहो तो पूरी तरह रुक जाता हूँ" — इस हिस्से से मैं बहुत गहराई से जुड़ता हूँ। शुरू में tutorial के पीछे-पीछे चलने के बाद जब वैसी ही कोई चीज़ खुद बनाने की कोशिश की, तब जो रुकावट आई वही सबसे तकलीफ़देह और कठिन अनुभव था। लेकिन वही दर्दनाक प्रक्रिया सीखने की सबसे अधिक सघन और प्रभावी अवस्था भी थी। बाद में मैंने कहीं ज़्यादा जटिल और विविध चीज़ें सीखीं, लेकिन उस स्तर की learning density दोबारा कभी नहीं मिली। यह कुछ वैसा था जैसा high school maths के दौरान सिर भारी होने और stress महसूस होने का अनुभव। मुझे लगता है कि यह हर किसी का आम अनुभव नहीं होगा।