AI मौजूदा तकनीकी क्षमता को गुणक प्रभाव देता है

 (joshwcomeau.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI मॉडल कई प्रोग्रामिंग कार्यों में काफ़ी उपयोगी हैं, लेकिन डेवलपर्स को बदलने के बजाय वे मौजूदा तकनीकी क्षमता को बढ़ाने वाले टूल के अधिक क़रीब हैं
  • इस बात का कोई प्रमाण नहीं दिखता कि LLM हर आकार के प्रोजेक्ट को पूरी तरह डिज़ाइन और निर्माण कर देंगे और जल्द ही मानव डेवलपर्स की ज़रूरत खत्म हो जाएगी
  • Matt Perry ने Motion पर काम करते हुए Q1 के 60 issues के लक्ष्य से आगे बढ़कर 160 issues बंद किए, और Q2 के लिए तय बड़ा refactoring भी जनवरी की किसी दोपहर में पूरा कर दिया
  • कम डेवलपमेंट अनुभव वाले users का vibe-coding अक्सर MVP के बाद अटक जाता है, और architecture संबंधी निर्णय तथा domain knowledge ही नतीजों में फ़र्क पैदा करते हैं
  • AI, Iron Man के suit की तरह ताकतवर है, लेकिन अपने आप वैसी उपलब्धि हासिल नहीं करता; structured learning और कौशल ही उसके उपयोग की प्रभावशीलता तय करते हैं

Matt Perry की प्रोडक्टिविटी का उदाहरण

  • Matt Perry वह डेवलपर हैं जिन्होंने Popmotion, Motion One, Motion (पूर्व नाम Framer Motion) जैसी कई animation libraries बनाई हैं
  • Motion का layout projection engine बेहद परिष्कृत engineering का परिणाम है
  • Matt Perry ने 2026 में AI के उपयोग को और मजबूत किया, और Q1 में 60 issues बंद करने के लक्ष्य से आगे बढ़कर 160 issues बंद किए
  • Motion के लिए Q2 में किया जाने वाला बड़ा refactoring भी उन्होंने जनवरी की एक दोपहर में एक ही बार में पूरा कर दिया
  • यह दिखाता है कि LLM अपने आप सर्वश्रेष्ठ मानव डेवलपर से बेहतर नहीं है, बल्कि जब कोई skilled developer AI का उपयोग करता है तो उसकी productivity बहुत बढ़ सकती है

domain knowledge की कमी वाले vibe-coding की सीमाएँ

  • /r/vibecoding में लगभग बिना या बहुत कम डेवलपमेंट अनुभव वाले लोग अपने vibe-coding अनुभव साझा करते हैं, और अक्सर MVP के बाद के चरण में अटक जाते हैं
  • बिना मार्गदर्शन इस्तेमाल किए गए LLM अलग-अलग prompts के लिए code generation पर केंद्रित रहते हैं, और application architecture को समग्र रूप से नहीं देख पाते, इसलिए dead end में फँसना आसान हो जाता है
  • skilled developers AI से अपनी क्षमता को बढ़ा लेते हैं, लेकिन domain knowledge की कमी वाले users के लिए “MVP” चरण से आगे बढ़ना मुश्किल हो जाता है
  • एक ही AI tool इस्तेमाल करने पर भी नतीजे समान नहीं होते; user की judgment और structural understanding ही मुख्य अंतर पैदा करते हैं

AI को टूल की तरह देखने का दृष्टिकोण

  • AI एक टूल है, और टूल तभी असरदार होता है जब उसे कुशलता से इस्तेमाल किया जाए
  • सिर्फ Jimi Hendrix का guitar, Gordon Ramsey का kitchen, या Serena Williams का tennis racket होने से वैसा ही परिणाम नहीं मिल जाता
  • लोग अक्सर टूल के महत्व को ज़रूरत से ज़्यादा आँकते हैं, और marketing इस पूर्वाग्रह का उपयोग वैसे ही करती है जैसे Michael Jordan के “air technology” shoes मानो dunk करने की क्षमता दे देंगे
  • AI agents को मानवीय रूप दे दिया जाता है, इसलिए उन्हें टूल की तरह देखना और कठिन हो जाता है; अगर उन्हें autonomous robots की तरह माना जाए, तो लोग उनकी वास्तविक क्षमता से अधिक श्रेय देने लगते हैं
  • इससे अधिक उपयुक्त रूपक Iron Man का suit है: वह अद्भुत काम संभव बनाता है, लेकिन अपने आप चलकर वही उपलब्धि हासिल करने वाली इकाई नहीं है
  • Matt Perry अगर Motion repository की access और LLM tools मुझे दे भी दें, तो उसी रफ़्तार से काम करने की कोशिश में वैसा परिणाम आने के बजाय बड़ा भ्रम पैदा होने की संभावना ज़्यादा है
  • जब skilled developer द्वारा LLM से किए गए काम को देखते हैं, तो मुख्य कारक LLM नहीं बल्कि उस skilled developer की क्षमता होती है

Whimsical Animations और structured learning

  • Whimsical Animations हाल ही में लॉन्च किया गया web animation course है
  • लगभग 20 वर्षों तक websites और web applications बनाते हुए, यादगार और प्रभावशाली animations तथा interactions बनाने के तरीकों का अनुभव इसमें संचित है
  • web developers के लिए animation पर सामग्री बहुत कम है, इसलिए game development क्षेत्र की अवधारणाओं को web के अनुरूप लागू किया गया है
  • linear interpolation, simplex noise, delta time जैसी अवधारणाएँ आम web developer की सामान्य skill set में अक्सर शामिल नहीं होतीं, लेकिन वे किसी project को अलग पहचान दे सकती हैं
  • ChatGPT जैसे tools की मदद से नया विषय सीखना आसान हुआ है, लेकिन प्रभावी ढंग से सीखने के लिए यह जानना ज़रूरी है कि क्या पूछना चाहिए
  • यह course विभिन्न techniques का परिचय देने वाला curated curriculum प्रदान करता है
  • custom course platform को अपडेट किया गया है ताकि सभी exercises और code snippets को local में चलाया जा सके
  • local execution support की वजह से challenges को अपने रोज़मर्रा के coding environment और workflow में पूरा किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • पिछले हफ्ते UI डिज़ाइन की vibe coding करते हुए, बगल वाली स्क्रीन पर component tests खुले रखकर मुझे एक Iron Man जैसा पल महसूस हुआ
    मैं elements को इधर-उधर कर रहा था, emphasis कम करने और layout options explore करने के निर्देश दे रहा था, और यह लगभग real-time loop की तरह चल रहा था, जो कमाल था
    generated code भयानक था, लेकिन यह आसानी से उस डिज़ाइन पर पहुँच गया जिसे मैं अकेले नहीं बना पाता, और बाद में उस reference design को देखकर मैं उसे बेहतर code के साथ खुद implement कर सका

    • शायद यह संयोग नहीं था कि जिस क्षेत्र में मैं expert हूँ वह मुझे कचरे जैसा लगा, और जिस क्षेत्र में expert नहीं हूँ वह ठीक लगा
      designers उल्टा यह कह सकते हैं: “Claude Design Studio ने बेकार UI बनाया, लेकिन मैंने उसे खुद ठीक कर लिया, और बदले में उसने ऐसा शानदार code बना दिया जो मैं खुद नहीं लिख पाता”
    • कुछ दिन पहले Tailwind thread में मैंने सुना कि कई frameworks का intended experience write-only code है, तो शायद यही वह भविष्य है जिसे स्वीकार करना होगा
      मतलब यह कि यह कैसे जुड़ा है इसकी चिंता मत करो, बस काम कर रहा हो तो ठीक है, और रुक जाए तो AI से कहो कि इसे ठीक कर दे
      इसमें एक तरह की मुक्ति है, लेकिन मुझे नहीं पता कि मैं अभी इसे स्वीकार करने वाली AI निर्वाण अवस्था तक पहुँचा हूँ या नहीं, हालांकि वह पल करीब लगता है
    • मुझे जिज्ञासा है कि यह कितना ज्ञान की जड़ता पर टिका है
      अभी मैं उस चरण में हूँ जहाँ मैं बुनियादी तकनीक समझता हूँ और चीज़ें खुद बना भी सकता हूँ, लेकिन यह जानते हुए भी कि कहीं न कहीं एक व्यवस्थित किए जा सकने वाला भद्दा code पड़ा है, मैं तेज iteration चुनता हूँ
      यह इसलिए संभव है क्योंकि मुझे roughly पता है कि चीज़ “कैसी होनी चाहिए” और मैं automation framework को उस दिशा में ले जा सकता हूँ, खासकर अपने बनाए प्रोजेक्ट्स में
      अगर कंपनियाँ काफी लंबे समय तक टिक गईं, तो वह ज्ञान पूरी तरह गायब हो जाएगा और सिर्फ tools बचेंगे, और तब यह Iron Man नहीं बल्कि iron lung के ज़्यादा करीब होगा
    • अब हमें फिर से सीखना होगा कि कौन-सा काम महँगा है और कौन-सा सस्ता
      prototypes लगभग मुफ्त जैसे हो गए हैं, और आप AI से architecture या style के अलग-अलग options आज़मा सकते हैं, फिर देख सकते हैं कि कौन-सा code ज़्यादा पसंद आता है
      rewrite और redesign भी काफ़ी असरदार साबित हो रहे हैं, इसलिए मुझे वह pattern पसंद है जिसमें कई solutions vibe coding से बनाओ, फिर approach चुनो, tests मज़बूत करो, और बड़े refactor से उसे maintainable बनाओ
      यहाँ ज़रूरी क्षमता यह है कि आपको पता हो अच्छा architecture क्या है, और आप prompts और validation इस तरह design कर सकें कि feedback cycle तेज रहे या LLM के बदलावों को पढ़ना आसान हो
    • जिस model तक मैं पहुँचा हूँ वह भी ऐसा ही है: पहले मैं system architecture कैसा दिखना चाहिए इसका एक skill template बनाता हूँ, फिर LLM से कहता हूँ कि वह उन guidelines का पालन करे
      वह 100% पालन नहीं करता, लेकिन नतीजा काफी अच्छा आता है, और फिर मैं output की समीक्षा करके उसे template के अनुसार ढालता हूँ, और जो ideas पसंद आते हैं उन्हें skill template में वापस जोड़ देता हूँ
      यह सिर्फ system architecture पर नहीं, बल्कि backend, frontend, end-to-end tests और documentation पर भी लागू होता है
      क्योंकि मुझे वांछित लक्ष्य, code organization का तरीका, और tests लिखने का तरीका पता है, इसलिए LLM हर बार वही template follow करने की बोरियत कम करने का काम करता है
      लेकिन लगातार निगरानी ज़रूरी है, और कभी-कभी यह उन हिस्सों को छेड़ देता है जिन्हें न छूने को कहा गया था या निर्देशों का पालन नहीं करता, और output की मात्रा इतनी अधिक हो सकती है कि peer review अभी भी ज़रूरी है

  • AI tools से काम जितना तेज़ होता है, उतना ही मुझे महसूस होता है कि उपयोगी software ship करना वास्तव में कितनी कठिन कारीगरी है
    Claude Code और Codex अधिकांश code लिख सकते हैं, लेकिन क्या बनाना है और कैसे बनाना है यह तय करने के लिए जो technical knowledge चाहिए वह अब भी बहुत विशाल है
    अभी मैं Claude Artifacts जैसे custom HTML+JS apps को किसी बड़े application के भीतर iframe sandbox में सुरक्षित रूप से चलाने वाला system बना रहा हूँ, और यह क्यों उपयोगी है और क्यों संभव है इसे समझने के लिए sandboxing, security threats, browser security model, और दशकों में विकसित हुई कई platform features की गहरी समझ चाहिए
    ऐसी समझ के बिना सिर्फ vibe coding करने वाला व्यक्ति, LLM कितना भी guide करे, शायद ही ऐसी चीज़ को अस्तित्व में ला पाए
    जब मैं developers को AI की वजह से अपना career छोड़ने की बात करते देखता हूँ तो दुख होता है, क्योंकि यही वह समय है जब मौजूदा गहरा technical experience पहले से कहीं ज़्यादा मूल्यवान हुआ है

    • AI के साथ interaction का अनुभव ही भयानक है
      मुझे code लिखना पसंद है, लेकिन मशीन से सही code लिखवाने के लिए जादुई मंत्र ढूँढना, या उसके गलत होने पर उसे ठीक करना पसंद नहीं
      अगर मुझे बताया गया होता कि भविष्य ऐसा होगा, तो शायद मैं इस क्षेत्र में आता ही नहीं
      और ये tools जिस तरह बनाए गए हैं, वह मेरे हिसाब से चोरी है, और मुझे लगता है कि अनैतिक तरीके से बने tools का इस्तेमाल करना भी अनैतिक है
      ऊपर से यह भी निश्चित नहीं कि अधिक मूल्यवान skills के लिए मुझे ज़्यादा पैसे मिलेंगे, और engineering salaries कुल मिलाकर घट रही हैं
      अगर employer सारी value खुद ले जाएगा, तो मुझे इस बात में रुचि क्यों हो कि मैं ज़्यादा value पैदा कर रहा हूँ
    • यह दृष्टिकोण ताज़गी भरा है और मेरे अनुभव से मेल खाता है
      मेरे आसपास कई software engineers यह निष्कर्ष निकाल रहे हैं कि AI उनकी नौकरियाँ ले लेगा और वे पहले से ही career switch के बारे में सोच रहे हैं, लेकिन मुझे अभी फैसला देना जल्दबाज़ी लगता है
      मैं जो prompts इस्तेमाल करता हूँ वे सभी बहुत technical होते हैं, और मेरी expertise के बिना सिर्फ agents से बातचीत करके काम निकालना मुश्किल है
      जब भी मैं अपने विशेषज्ञता क्षेत्र के बाहर का काम करता हूँ, वह उतना तेज़ नहीं होता जितना लोग कल्पना करते हैं, और expertise व्यवस्था बनाए रखने में बहुत मदद करती है
    • लेकिन senior executives ऐसा नहीं सोचते
      अगर उन्हें लगता है कि AI engineers की जगह ले सकता है, तो संभावना है कि चीज़ें उसी दिशा में जाएँगी, और quality क्या होती है यह executives को ठीक से पता भी कम ही होता है
      वे सिर्फ revenue और profit देखते हैं, इसलिए यह सच हो सकता है कि गहरा technical experience अधिक मूल्यवान है, लेकिन हक़ीक़त दुखद रूप से वैसी न निकले
    • कोई भी कई साल लगाकर बनाई गई “career” को बस यूँ ही छोड़ नहीं सकता
      शायद धीरे-धीरे बेरोज़गारी की ओर धकेले जाने जैसा ही होगा
    • मैंने पहले लिखा था कि शानदार idea और शानदार product के बीच बहुत बड़ी कारीगरी की ज़रूरत होती है, और उसके लिए मुझे काफ़ी downvotes मिले थे
      LLMs वास्तविक दुनिया में इस तथ्य को नहीं बदलते
      इसी वजह से high-value products की बाढ़ नहीं आई, और शुरुआत से ही value पैदा करने वाले products बनाना बहुत, बहुत कठिन है
      सिर्फ इसलिए कि LLM मौजूद हैं, इसे हल्के में लेना मुझे हास्यास्पद लगता है

  • “AI tools Iron Man suit के ज़्यादा करीब हैं” वाली बात पर, GitHub पर 63,600 stars वाला एक दिलचस्प repository है
    developer GitHub के weekly trending contributors में नंबर 1 है, लेकिन application बताया गया जैसा नहीं दिखता, और developers भी शायद साफ़-साफ़ नहीं बता पा रहे कि यह असली है या नहीं
    अंततः यह सिर्फ गंदा LLM output ही लगता है, जो दिखाता है कि सिर्फ suit से कोई Iron Man नहीं बन जाता
    https://github.com/ruvnet/RuView
    https://github.com/trending/developers?since=weekly
    https://github.com/deletexiumu/wifi-densepose

    • इसमें एक पंक्ति है कि Claude, Codex/GPT-5.2, और Gemini जैसे तीन AI systems की cross-validation शामिल करने वाली independent code audit ने पुष्टि की कि यह project काम न करने वाला खोल है
      यानी AI द्वारा बनाए गए non-working project को AI ही non-working साबित कर रहा है, क्या ही शानदार नई दुनिया है
    • पूरा ruvnet थोड़ा डरावना लगता है
      कई projects हैं, लेकिन सब बस भारी मात्रा में AI output जैसे लगते हैं, मानो GitHub infrastructure पर बाढ़ ला रहे हों, इसलिए GitHub क्यों परेशान है यह समझना आसान है

  • एक गणितज्ञ के रूप में, पिछले हफ्ते मुझे भी एक Iron Man पल मिला
    मैं कई वर्षों से दो professor दोस्तों के साथ joint mathematics research कर रहा था, और मैंने research के एक हिस्से को ChatGPT के साथ explore किया
    जब भी कोई विचार आता, मैं उसे GPT के सामने रखता, उससे आसानी से prove किए जा सकने वाले theorem लिखवाता, और proof को LaTeX में बनवाता, फिर proofs को हमेशा बहुत सावधानी से जाँचता
    फिर मैं उससे Mathematica code generate करवाता, execution results के ज़रिए proof verify करता या और ideas पाता, और फिर यह चक्र दोहराता
    बीच में एक खास expression के upper bound को पकड़ नहीं पा रहा था, इसलिए जहाँ मेरी समझ कम थी वहाँ मैंने कागज़-कलम से खुद derivation दोबारा की, और उससे बहुत मदद मिली
    पूरा process GPT के बिना करने की तुलना में लगभग 10 गुना तेज़ था, और कुछ घंटों बाद मेरे पास लगभग 20 पन्नों का सही proof और संबंधित numerical simulations के लिए ज़रूरी code दोनों थे

  • मेरे हिसाब से AI क्षमता का गुणक नहीं, बल्कि समय घटाने वाला tool है
    कम अनुभव वाले developers के लिए यह project की शुरुआत से ही तुरंत समय बचाता है, लेकिन शुरुआती फैसले बाद में उनके लिए समस्या बन सकते हैं
    senior developers के लिए, अगर आप पर्याप्त समझा दें, तो यह उनकी क्षमता-सीमा के भीतर काम करने वाले junior या mid-level developer की तरह काम करता है
    लेकिन अगर आप इसे महत्वपूर्ण फैसले सौंप दें, तो यह पूरी तरह गलत या सूक्ष्म रूप से गलत हो सकता है, और खासकर सूक्ष्म गलतियाँ पकड़ना कठिन होने के कारण सबसे खतरनाक हैं
    अगर senior सही guidelines तय कर सके और समस्या पहचान सके, तो development speed सचमुच अविश्वसनीय रूप से तेज़ हो जाती है

    • ज़रूरी नहीं कि हमेशा ऐसा ही हो
      अगर सीखने की इच्छा हो, तो AI skills को निखारने और सीखने में लगने वाला समय घटा सकता है, और उसके परिणामस्वरूप यह वास्तव में क्षमता का गुणक भी बन सकता है
      अब मैं AWS का इस्तेमाल कुछ साल पहले की तुलना में बहुत बेहतर करता हूँ, और command line भी ज़्यादा प्रभावी ढंग से इस्तेमाल करता हूँ
      जानकारी पहले भी मिल सकती थी, लेकिन उसमें बहुत समय लगता था; अब मनचाहे उत्तर तक पहुँचने का समय बहुत कम हो गया है, जिससे वास्तविक output और क्षमता दोनों बदल गए हैं
    • छोटे Bash या Python utility scripts बिजली की गति से निकाल देना सचमुच game changer है
      मैं Raspberry Pi पर एक छोटा web server चलाना चाहता था, इसलिए मैंने Gemini से code और उसे systemd service के रूप में चलाने के लिए configuration Bash script लिखने को कहा
      यह ऐसा काम है जो मैं नींद में भी कर सकता हूँ, लेकिन इसमें समय और एकाग्रता लगती है, और इस comment को लिखने में जितना समय लग रहा है उतने में उसने मुझे ठीक वही बना दिया जिसकी ज़रूरत थी
      अपने-आप में यह बहुत बड़ी बात न हो, लेकिन दूसरी ज़िम्मेदारियों के कारण जिन home automation tasks को मैं टालता आ रहा था, अब उन्हें कर पा रहा हूँ

  • सही बात। AI शुद्ध क्षमता या प्रतिभा को पुराना नहीं बनाता, बल्कि उसे और मूल्यवान बनाता है
    गहरा technical knowledge वास्तविक दुनिया में और बड़ा leverage effect देता है, क्योंकि इससे AI को लागू करने के अधिक संपर्क-बिंदु मिलते हैं
    इसी एहसास की वजह से मैंने AWS जैसी cloud services की बजाय अपने tech SaaS को host करने के लिए खुद का homelab datacenter बनाना शुरू किया
    बुनियादी networking, DevOps, और server hardware सीखने का मूल्य AI की वजह से और तेज़ी से और व्यापक रूप से लागू किया जा सकता है
    पहले RouterOS सीखकर datacenter-grade Mikrotik router configure करने में घंटों या दिनों लग जाते, लेकिन Claude की मदद से यह 20 मिनट का काम बन गया, और routing configuration के बारे में भी बहुत कुछ सीखा
    इससे मुझे वह अनोखा control मिला जो सिर्फ cloud इस्तेमाल करने पर नहीं मिलता, और AI से पहले मैं जिस अपने operating system के बारे में सोचने की हिम्मत भी नहीं करता, उसे भी बनाना चाहता हूँ

    • मैं इतना आश्वस्त नहीं हूँ
      जब power tools और nail guns आए होंगे, तब भी शायद ऐसा ही लगा होगा, लेकिन घर बहुत तेज़ी से बनने लगे, जबकि मजदूरी घटी, काम की quality गिर गई, और skill तथा experience का मूल्य काफी कम हो गया
      दीवार पलस्तर पहले high-wage skilled trade था, और जब drywall आया, तो सोचा गया होगा कि लोग सपाट दीवारों पर कम समय लगाकर corners और decorative plastering पर ज़्यादा समय देंगे, लेकिन वे सजावटी चीज़ें गायब हो गईं
      सजावट में बाकी दीवार की तुलना में बहुत अधिक समय लगता था, और जो लोग वह skill बनाए रखते या सीखते थे वे अब भी decent मेहनताना चाहते थे
      साधारण drywall काम में भी production demands बढ़ीं और wages ठहरी रहीं; आजकल seams भी अक्सर खराब होती हैं, और पैसे लायक चीज़ सिर्फ तेज़ production और बिना शिकायत काम करना रह गया है

  • “कमरे में हाथी” का मतलब है कोई बड़ा मुद्दा जिस पर सब बात नहीं कर रहे हों, लेकिन AI पर तो सब बात कर रहे हैं
    बेहतर शीर्षक शायद “AI डेवलपर skills को replace करने के बजाय amplify क्यों करता है” के करीब होगा

    • संदर्भ में, यह लेख मेरे latest lecture के लिए marketing campaign की newsletter issue था
      उस समय तक उस marketing campaign में AI को कवर नहीं किया गया था, इसलिए उस अर्थ में यह “कमरे में हाथी” था
      यह link एक web view link है, जिसे इसलिए बनाया गया था कि अगर email client में ठीक से न दिखे तो लोग इसे पढ़ सकें; यह किसी व्यापक audience के लिए लिखा गया लेख नहीं था
    • नतीजा आखिरकार वही है
      अगर वही काम करने के लिए कम developers चाहिए, तो बहुत-से लोग बेरोज़गार होंगे
      जो बचेंगे उनकी salaries भी कम हो सकती हैं
      अगर आपको लगता है कि junior salary और AI subscription fee देकर “वही नतीजा” मिल सकता है, तो फिर senior salary क्यों दी जाएगी
      software developers के लिए समय कठिन लग रहा है, और मैं यह काम 15 साल से कर रहा हूँ, फिर भी उत्साहित नहीं हूँ
      सच कहूँ तो मैं किसी दूसरे industry में reskilling के बारे में सोच रहा हूँ, भले कम पैसे मिलें, लेकिन शायद इस अव्यवस्था से बचना बेहतर हो

  • मैं Josh के विचारों से मोटे तौर पर सहमत हूँ, लेकिन AI के साथ काम करते समय senior और junior अनुभव की बात करने वाले बहुत-से लेख मुझे कुछ बकवास से लगते हैं
    यह सही है कि senior AI tools से बेहतर परिणाम पाते हैं और juniors को ज़्यादा संघर्ष करना पड़ता है, लेकिन बदला सिर्फ इतना है कि वह अंतर और बढ़ गया है
    लोग जिस बात से बचते हैं, वह यह है कि juniors किसी भी क्षेत्र में AI research assistant के साथ बहुत तेज़ी से सीख सकते हैं, और जिनमें गहराई में जाने की ऊर्जा है वे expert भी तेज़ी से बन सकते हैं
    मैं AI tools से “इसे बना दो” या “इसे ठीक कर दो” जितना कहता हूँ, उतना ही “यह कैसे काम करता है?”, “क्या कोई दूसरा tool सुझा सकते हो?” जैसे सवाल भी पूछता हूँ
    बहुत लोग AI को सिर्फ input/output संबंध की तरह देखते हैं, लेकिन AI हो या न हो, बीच में हाथ लगाकर चीज़ों से जूझने की प्रक्रिया हमेशा महत्वपूर्ण रही है
    beginners शुरू में नहीं कर पाएँगे, लेकिन पहले भी ऐसा ही था, और अच्छे लोग शायद मेरी तुलना में बहुत कम समय तक उस न कर पाने वाले चरण में रहेंगे
    हालांकि AI जो instant gratification देता है, वह friction से जूझने की प्रक्रिया को कमजोर कर सकता है, और AI-native लोग शायद friction को समझेंगे ही नहीं और उस पर सवाल उठाएँगे

    • यह साफ़ नहीं दिखता कि junior AI research assistant की मदद से बहुत तेज़ सीखते हैं
      university स्तर पर जो स्थिति दिखती है, उसे देखकर ऐसी उम्मीद करना भी मुश्किल है
    • मुझे लगता है कि असली बात यह है कि AI की instant gratification friction से जूझने की प्रक्रिया को कमजोर कर सकती है
      लोग बेकार vibe coding या 10x speed जैसी बातों पर नाराज़ होते हैं, और इस वजह से यह हिस्सा दब जाता है
      सबसे महत्वपूर्ण सीख तब नहीं होती जब आप सवाल पूछते हैं और तुरंत जवाब पा लेते हैं, बल्कि तब होती है जब आप जवाब खोजने में जूझते हैं, कुछ बार असफल होते हैं, गहराई से सोचते हैं, थोड़ा विराम लेते हैं, और फिर समस्या हल करते हैं
      ऐसी knowledge सिर्फ answer नहीं देती, बल्कि भविष्य में बचने लायक गलत रास्तों और अपनी सोच पर भरोसा भी देती है, इसलिए उसका मूल्य बहुत अधिक है
      अगर अगली पीढ़ी इस चरण को छोड़ देगी, तो वह सोचेगी कि जवाब आसानी से मिल जाने चाहिए, और धीरे-धीरे AI पर ज़्यादा निर्भर होती जाएगी जबकि अपने दिमाग़ पर भरोसा कम होता जाएगा
    • सिर्फ पढ़ने से नहीं, खुद करके सीखा जाता है
      इस मामले में सिर्फ LLM output पढ़ लेने से असल शिक्षा नहीं होती
    • बल्कि यह तो जहाँ तक संभव हो, आपको और आलसी बनाता है
      मैंने किसी को AI tools की वजह से और गहराई में जाते नहीं देखा
    • सच कहूँ तो मुझे लगता है AI junior developers को और मूर्ख बना रहा है
      senior developers ने अपने असंख्य असफल projects के पहाड़ पार करके सीखा है
      अगर कोई flat-file database बनाने या 50 से ज़्यादा Lambda के साथ microservice architecture बनाने को कहे, तो मैंने यह सब पहले किया है और जानता हूँ कि तकनीकी रूप से संभव होने पर भी ऐसा क्यों नहीं करना चाहिए
      मेरे लिए AI मुझे सही दिशा में 100 मील प्रति घंटा की रफ्तार से ले जाता है, लेकिन juniors को मैं समुद्र या दीवार की ओर 100 मील प्रति घंटा से भागते देखता हूँ
      जैसे AWS ने हमें और मूर्ख बनाया और ऐसे juniors पैदा किए जिन्हें reverse proxy तक नहीं पता, और high-level languages ने memory management की समझ कम कर दी, AI भी उसी कड़ी की अगली कड़ी है
      10 साल बाद शायद ज़्यादातर developers code पढ़ भी नहीं पाएँगे

  • कई, शायद अधिकांश software engineers अपने codebase के expert होते हैं, इसलिए काफी engineers AI से ऊँची value पा रहे हैं
    असली अनिश्चितता यह है कि अगर हर engineer ज़्यादा code लिख सके, तो क्या developers की संख्या घटेगी, या फिर UX, testing, developer experience, और documentation जैसे पारंपरिक रूप से पीछे छूटे क्षेत्रों में और ज़्यादा software बनेगा
    शायद baseline ही ऊपर उठ जाए

  • Claude से बात करते हुए मैंने ऐसी चीज़ देखी
    मैंने कहा, “क्या यह चौंकाने वाला नहीं कि X, Y से बेहतर है?” तो Claude ने इसे “सूझबूझ भरी आलोचना” कहकर जवाब दिया और अच्छी तरह व्यवस्थित कारण बताए कि Y, X से बेहतर क्यों है
    जवाब अपने-आप में अच्छा, विचारशील और तार्किक था, लेकिन वह मेरी बात के उलट था, इसलिए मैंने सुधारते हुए कहा, “नहीं, मेरा मतलब यह counterintuitive दावा है कि X, Y से बेहतर है”
    तब Claude ने फिर कहा, “सही बात, X, Y से बेहतर है,” और इस बार भी अच्छे से व्यवस्थित कारण दे दिए
    यह किसी तरह के बेवकूफ-पर-चालाक-जीनियस meme जैसा लगता है
    यह “यह सिर्फ autocomplete है” और “नहीं, इसके दिमाग़ में एक model है” के बीच झूलता रहता है, लेकिन अंततः यह Babel की लाइब्रेरी जैसा है: दुनिया की सारी प्रतिभा मौजूद हो सकती है, पर उसका उपयोग तभी है जब आपके पास सही indexing key हो

    • यह बात अच्छी तरह जानी जाती है कि LLM एक prediction engine है, लेकिन उसे ठीक से इस्तेमाल करने के लिए यह सोचना पड़ता है कि छोटे स्तर पर इसका मतलब क्या है
      first approximation में, LLM यह predict करता है कि user क्या चाहता है या क्या उम्मीद करता है
      पहले prompt का जवाब इसलिए मज़ाकिया नतीजा बन गया क्योंकि LLM ने user को पूरी तरह गलत समझा और उसी आधार पर भविष्यवाणी की जो उसे लगा कि user ने लिखा है
      दूसरे prompt का जवाब यह और साफ़ करता है कि LLM का लक्ष्य यह predict करना है कि user क्या चाहता है या क्या उम्मीद करता है
      hallucination का एक बड़ा कारण यह है कि LLM द्वारा समझी गई user expectation वास्तविकता से मेल नहीं खाती, और LLM वास्तविकता को अपनी समझी हुई expectation के अनुसार ढालने की कोशिश करता है
      hallucinations कम करने का एक अच्छा तरीका यह है कि prompt में assertive statements को जितना हो सके कम किया जाए
      “क्या यह चौंकाने वाला नहीं कि X, Y से बेहतर है” में एक स्पष्ट assertion है, और LLM ने दिशा तो गलत समझी, लेकिन यह समझ लिया कि assertion मौजूद है, इसलिए उसने कारण दिए कि वास्तविकता उस assertion से कैसे मेल खाती है
      वकीलों का fake case citations में फँस जाना भी ऐसा ही है: “मुझे X दिखाने वाले case ढूँढो” खतरनाक है, जबकि “X के बारे में कौन-से case हैं” बेहतर शुरुआत है