अभी तक किसी को नहीं पता कि AI के साथ कैसे बनाया जाए

 (worksonmymachine.substack.com)
20 पॉइंट द्वारा GN⁺ 2025-07-20 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • फिलहाल AI development methodology अभी स्थापित नहीं हुई है, इसलिए हर कोई प्रयोग कर रहा है
  • AI के दौर में पारंपरिक expert की अवधारणा अपना अर्थ खो देती है, और हर कोई हमेशा के लिए beginner है
  • वास्तविक development process तुरंत बनते दस्तावेज़ों के संचय और बार-बार के trial and error के ज़रिए आगे बढ़ती है
  • AI के साथ collaboration करने पर कम समय की गहरी एकाग्रता और बहुत कम input से भी बहुत बड़े नतीजे पैदा हो जाते हैं
  • अपना document system भी अस्थायी है, और हर कोई एकबारगी प्रयोगों की कड़ी आगे बढ़ा रहा है

The Great Experiment Nobody's Running the Same Way

  • AI development में किसी को भी तय तरीका नहीं पता
  • Malcolm Gladwell के 10,000-hour सिद्धांत की तरह संचित expertise यहाँ बेअसर हो जाती है
    • AI tools इतनी तेज़ी से आगे बढ़ रहे हैं कि उनमें महारत बनाना मुश्किल है
  • AI pair programming का अनुभव भी 2 साल से कम पुराना है, इसलिए हर कोई लगातार beginner ही है

My Current Experiment (Subject to Change)

  • काम शुरू करने से पहले मैं 4 मुख्य दस्तावेज़ों को संदर्भ के तौर पर रखता हूँ
    • pair_programming.md
    • project_plan_{some extension}.md
    • technical_considerations.md
    • mcp-browser-architecture.md
  • यह document system भी शुरू से डिज़ाइन नहीं किया गया था, बल्कि तुरंत-तुरंत बनते हुए जमा हुआ परिणाम है
    • शुरुआत में सिर्फ architecture से जुड़ा एक दस्तावेज़ था, लेकिन बार-बार आने वाली समस्याओं और जानकारी पहुँचाने की दिक्कतों के कारण यह धीरे-धीरे चार दस्तावेज़ों तक बढ़ गया
    • इन चार दस्तावेज़ों को किसी optimised नतीजे के रूप में तय नहीं किया गया, बस इसलिए कि लगा अब और जोड़ना ज़रूरी नहीं है
  • कभी-कभी ऐसा लगता है जैसे मैं खुद से role-play कर रहा हूँ: "यह architecture है" और "यह process official है"
  • असली software काम करता है, और यही बात महत्वपूर्ण है कि ऐसी अस्थायी व्यवस्था भी नतीजे दे सकती है
  • हर दस्तावेज़ की भूमिका इस प्रकार है
    • Architecture Overview: README से शुरू होकर, यह दर्ज करता है कि 'यह software क्या करता हुआ लगता है'
    • Technical Considerations: बार-बार होने वाली निराशाओं या समस्याओं को document करता है; जब भी Claude उलझता है, इसमें और विवरण जोड़े जाते हैं
    • Workflow Process: बार-बार अपनाई गई प्रक्रिया का दस्तावेज़; वास्तव में यह कोई official rule या अटूट दस्तावेज़ नहीं, बल्कि उन तरीकों का संग्रह है जो इस बार संयोग से काम कर गए
    • Story Breakdown: 15-30 मिनट के छोटे task chunks। Claude बहुत जल्दी भूल जाता है, इसलिए conversation history को बार-बार refresh करने के लिए

Time Dilation in the Age of AI - AI के युग में समय का विकृति-बोध

  • हाल में Protocollie development पर काम करते हुए, AI के साथ collaboration पारंपरिक software development की समय-समझ को पूरी तरह हिला देने वाला अनुभव रहा
  • Claude को किसी feature पर काम सौंपने के बाद, उस दौरान निजी जीवन जीते रहना और बीच-बीच में जाँच तथा छोटा feedback देना — इसी तरह project आगे बढ़ता रहा
  • वास्तव में ध्यान लगाकर "काम" करने का समय दिन में लगभग 90 मिनट ही था, लेकिन AI इस दौरान भी तेज़ी से हज़ारों lines of code बना रहा था
  • input की तुलना में output इतना तेज़ और बड़ा है कि input-output, effort-result, time-progress जैसी पुरानी धारणाएँ टूट जाती हैं
  • कभी-कभी इतनी तेज़ development से अपराध-बोध तक होता है; यह पारंपरिक development paradigm में फिट नहीं बैठता, इसलिए उलझन होती है और कभी-कभी ऐसा लगता है जैसे cheating कर रहे हों

"Spaghetti experiment" चरण

वर्तमान AI development environment को "spaghetti experiment" चरण कहा गया है

  • यानी दीवार पर प्रयोग के तौर पर spaghetti फेंकने की प्रक्रिया अपने आप में मायने रखती है; क्या चिपकता है या क्या बचता है, यह उतना महत्वपूर्ण नहीं। फेंकने की क्रिया ही प्रयोग है
  • हर तरह की कोशिशें, असफल प्रयोग, और संयोग से चल पड़ी प्रक्रियाएँ सामूहिक प्रयोग के data points की तरह काम करती हैं
  • लेखक का 4-document system भी कभी भी अर्थहीन हो सकता है, और प्रयोगधर्मिता बनाए रखना ही महत्वपूर्ण है

प्रोग्रामिंग आखिर अब है क्या? - What Even Is Programming Anymore?

coding के इतिहास को देखें तो, abstraction के विकास के साथ हम उस दौर में पहुँच गए हैं जहाँ "मैं जो चाहता हूँ उसे बताऊँ और वह बन जाए"

  • AI का उपयोग सिर्फ एक नई abstraction layer नहीं, बल्कि एक बिल्कुल अलग प्रकृति की चीज़ बनता जा रहा है
  • आज की programming में syntax knowledge, algorithm की समझ, या system design ability से ज़्यादा, 'ठोस कल्पनाशीलता' और 'सटीक इरादा व्यक्त करने की क्षमता' जैसी नई क्षमताएँ चाहिए
  • "आप जो चाहते हैं उसे लगातार स्पष्ट रूप से समझा पाने की क्षमता" अब सबसे महत्वपूर्ण हो गई है

4-document system का दार्शनिक अर्थ - The Four-Document System as Accidental Philosophy

  • यह 4-document system आखिरकार याद और भूल, तथा "उन अनुभवों का रिकॉर्ड जिन्हें दोहराना नहीं चाहते" है
    • Architecture Overview: "अगर मुझे memory loss हो जाए, तो मैं क्या जानना चाहूँगा"
    • Technical Considerations: "वे समस्याएँ जिन्हें मैं दोबारा नहीं झेलना चाहूँगा"
    • Workflow Process: "वे patterns जिन्हें मैं खोना नहीं चाहता"
    • Story Breakdown: "हर बार नए सिरे से शुरू होने जैसी स्थिति में प्रगति कैसे करें"
  • सभी दस्तावेज़ अंततः भविष्य के अपने-आप को भेजे गए संदेश हैं
    • यानी सूचना के खो जाने की आशंका के विरुद्ध खुद के लिए छोड़े गए मार्गदर्शक नोट्स

असहज ठहराव और स्थायी beginner - The Uncomfortable Plateau

अभी ऐसा समय है जैसे हर कोई junior developer बन गया हो और हमेशा अस्थिर beginner अवस्था में हो

  • पारंपरिक junior की तरह नहीं, बल्कि बदलती तकनीक की रफ़्तार के कारण expert बनने का समय ही नहीं मिलता
  • लगातार बदलते 'physics laws' के बीच, स्थिर दक्षता से अधिक adaptation और प्रयोगधर्मिता महत्वपूर्ण हो जाती है
  • अगर किसी में control के प्रति लगाव है तो यह अनिश्चितता डरावनी लग सकती है, लेकिन इसे स्वीकार कर लिया जाए तो इसमें मुक्ति भी है

Where This All Goes

आगे क्या बनाया जाएगा, कौन-सी process अपनाई जाएगी, या इस बार के चार दस्तावेज़ आगे भी चलते रहेंगे या नहीं — कुछ भी निश्चित नहीं

  • हर developer एक साथ अपनी routine में expert और नई परिस्थितियों में पूरी तरह beginner है
  • सिर्फ 4 दिनों का काम अतीत के कई महीनों के बराबर हो सकता है, इसलिए 'जो चाहिए उसे समझा पाने की क्षमता' निर्णायक skill बनकर उभरती है
  • लेखक के ये चार दस्तावेज़ भी किसी recommendation या template की तरह नहीं, बल्कि सामूहिक प्रयोग का एक निशान भर हैं
  • दस्तावेज़, process, और method — सब अस्थायी उत्पाद हैं, और किसी दूसरे का तरीका आपके लिए जवाब न भी हो सकता है

आखिरकार हम सब भाटा के समय रेत के किले (software) बना रहे हैं, यह जानते हुए कि प्रगति की लहर जल्द ही उन्हें फिर बहा ले जाएगी
जल्द ही कोई 3-document system, 5-document system, या बिल्कुल अलग approach आज़माएगा, और वह भी प्रभावी हो सकती है

निष्कर्ष

  • AI के साथ development सामूहिक प्रयोग भी है और रचनात्मक trial and error की निरंतर प्रक्रिया भी
  • एक हफ़्ते की process भी इतनी तेज़ी से पुरानी हो सकती है कि वह बीते समय का अवशेष बन जाए
  • किसी और के छोड़े हुए निशान मददगार हो सकते हैं, लेकिन वास्तव में महत्वपूर्ण यह है कि हर व्यक्ति अपना रास्ता खुद बनाए

अंत में, लेखक द्वारा इस्तेमाल किए गए ये चार दस्तावेज़ इस समय GitHub पर सार्वजनिक हैं

  • इन्हें किसी अंतिम सही जवाब या template की तरह नहीं, बल्कि एक खास समय के एक प्रयोगात्मक उदाहरण की तरह देखना चाहिए
  • दूसरे लोगों के रास्तों से सीखें, लेकिन उन्हें ज्यों का त्यों अपनाना ज़रूरी नहीं है
  • अपना-अपना प्रयोग और methodology विकसित करना ही AI युग का नया development ecosystem है

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

4 टिप्पणियां

 
laeyoung 2025-07-22

मैंने सोचा था कि वीकेंड में इसका अनुवाद करके पोस्ट करूँगा, लेकिन GN+ ने मुझसे पहले ही यह काम छीन लिया 🥲
 
truestar 2025-07-22

"डॉक्यूमेंट सिस्टम भी शुरू से डिज़ाइन किया हुआ नहीं था, बल्कि जैसे-तैसे जमा होता गया उसका नतीजा है" वाले हिस्से पर ज़ोरदार सहमति और हल्की हँसी निकल गई। हाहा
 
sinbumu 2025-07-22

क्या अजीब ढोंगी जैसा कमेंट कर रहा है, जैसे कोई कमरा-वैरा शिक्षक हो।
 
GN⁺ 2025-07-20
Hacker News राय

  • इस लेख से सच में बहुत सहमति है। मुझे संयोग से Kidlin’s Law मिला, यानी “अगर आप किसी समस्या को स्पष्ट रूप से लिख सकते हैं, तो वह आधी हल हो चुकी है।” आज के AI युग में यह बहुत शक्तिशाली सिद्धांत है। जब natural language तकनीक के साथ संवाद का मुख्य माध्यम बनती जा रही है, तब यदि आप समस्या को स्पष्ट रूप से परिभाषित कर सकें, तो AI की क्षमता को भी अधिकतम किया जा सकता है। asynchronous coding approach भी बहुत दिलचस्प है। मैं व्यक्तिगत रूप से Repl.it बहुत बार इस्तेमाल करता हूँ, और यह हैरान करने वाला बदलाव है क्योंकि इससे समस्या-समाधान पर ध्यान केंद्रित कर पाता हूँ। coding tools इस्तेमाल करते समय ऐसा लगता है जैसे Mario Kart में star या mushroom मिल गया हो। बहुत रोमांचक है, लेकिन कभी-कभी AI पूरी तरह अजीब दिशा में भी चला जाता है, इसलिए real-time decision intervention की ज़रूरत पड़ती है। पहले एक stack संभालना भी मुश्किल था, अब ऐसा लगता है जैसे अनंत stacks से निपटना पड़ रहा है

    • मैं भी अक्सर सोचता हूँ कि software engineer के रूप में बढ़ते समय मैंने काफी वक्त सिर्फ software दुनिया की terminology सीखने में लगाया, ताकि मैं जो करना चाहता हूँ उसे ठीक से समझा सकूँ

    • Repl.it कभी-कभी इतना अच्छा काम करता है कि जो चीज़ मिनटों में हो जानी चाहिए, वही पूरे दोपहर भर ले लेती है। लेकिन कभी-कभी prompt box के नीचे दिए गए suggestions आज़माने पर भी वे ठीक से काम नहीं करते, तो बहुत निराशा होती है

    • सच कहें तो समस्या को स्पष्ट रूप से बयान करना पहले भी हमेशा कठिन था, और अब भी है। ऐसा tool आ जाना जो साफ natural language को code में बदल दे, बहुत शानदार बात है, लेकिन AGI आ जाने पर भी स्पष्ट spec बनाना नहीं बदलेगा। tools की वजह से coding से जूझने में लगने वाला समय कम हो सकता है, लेकिन अंत में सबसे कठिन हिस्सा वास्तव में साफ specification लिखना ही रहेगा

  • मुझे programming का यह नया तरीका बहुत पसंद है। यह कहाँ जाएगा, पता नहीं, लेकिन अभी के लिए मैं इससे संतुष्ट हूँ। मैं आजकल उस समय में भी code बना रहा हूँ जो पहले आराम का समय होता था, और यह खुद आराम जैसा लगता है। लंबे समय से काम कर रहे senior developers के लिए यह खास तौर पर अच्छा है। आजकल editing का काम ज्यादातर उबाऊ लगता है। code देखकर अगर कोई गलत pattern दिख जाए, तो नए ideas आज़माने के लिए बहुत कुछ बदलना पड़ता है; पहले जिन चीज़ों के लिए Stack Overflow खंगालना और सोचना पड़ता था, अब वे Copilot hint या Claude से ही हल हो जाती हैं। उदाहरण के लिए, मैंने एक mock stock exchange बनाया, और असली exchange से जोड़ने वाला हिस्सा पहले अक्सर टल जाता था। अब Claude ने HN पढ़ते-पढ़ते वह सब बना दिया। इसमें strategy implementation जोड़नी हो तो जो repetitive काम पहले बस उबाऊ था, वह भी तुरंत हो जाता है। typos, dependencies जोड़ना जैसी चीज़ों में बहुत समय जाता था, अब उसकी ज़रूरत नहीं है। कोई चिंता कर सकता है कि इससे code गड़बड़ हो जाएगा, लेकिन मैं हमेशा Claude से बातचीत करते हुए changes को आलोचनात्मक नज़र से review करता हूँ। अनुभव मदद करता है, और AI गलत दिशा में जा रहा हो तो वह भी जल्दी पकड़ में आ जाता है। इसलिए ऐसा लगता है कि ये tools मेरे career के बिल्कुल सही समय पर आए हैं। सवाल junior developers को लेकर है। जैसे बिना सीढ़ी के सीधे पहाड़ की चोटी पर पहुँचना, तो वे कैसे बढ़ेंगे यह सोचने वाली बात है

    • junior developers के भविष्य को लेकर मैं सहमत हूँ। मैं लगभग 50 साल का हूँ और 30 साल से ज़्यादा समय से अलग-अलग क्षेत्रों में programming कर रहा हूँ, इसलिए अपने अनुभव के आधार पर agents को ठीक से संभालना और architecture को मज़बूत रखना जानता हूँ। अगर अनुभव के बिना सब कुछ AI बनाकर परोस दे, तो अगली पीढ़ी कैसे बढ़ेगी, यह सच में जिज्ञासा की बात है। समय ही बताएगा

    • मैं भी large language models का आनंद लेकर इस्तेमाल करता हूँ, लेकिन लगातार सिर्फ prompts डालते रहना उबाऊ और थोड़ा अस्थिर महसूस कराता है। ऐसा लगता है मानो मुझे ठीक से पता ही नहीं कि program कैसे चल रहा है। खुद कुछ बनाना वाकई मज़ेदार है, और जो दोहराव वाला काम मैं पहले कर चुका हूँ या जिसकी मुझे परवाह नहीं, वह LLM को दे देता हूँ। मैंने Claude से terminal-based snake game भी बनवाया, और वह सच में कमाल था

    • क्या आपने खुद महसूस किया है कि अब पुराने छोटे-मोटे कामों पर लौट पाना संभव नहीं? LLM आने के बाद काम करते समय बाहर निकल जाने का मन ज़्यादा करता है। नए developers को अब यह झेलना नहीं पड़ेगा कि वे 12 घंटे monitor के सामने बैठकर सिर्फ दो black boxes को जोड़ने की कोशिश में समय बर्बाद करें; इस बात से थोड़ा ईर्ष्या भी होती है

    • क्या implementation करते समय आप सच में सब कुछ शुरू से अंत तक एक ही बार में करवाते हैं? मैं हमेशा iterative और incremental तरीके से लिखते और सुधारते हुए बनाता हूँ। drawing की तरह, पहले पूरा ढाँचा मोटे तौर पर बनाता हूँ, फिर धीरे-धीरे उसे बारीक करता हूँ। हर चरण में मुझे थोड़ा और स्पष्ट होता जाता है कि मैं क्या चाहता हूँ, और कम से कम मेहनत में ज़्यादा असर मिलता है। coding में भी मेरी शैली refactoring-केंद्रित है: पहले minimum working code, फिर TODO comments, और फिर लगातार सुधार

    • यह सच में रोमांचक है कि ऐसे tools उन उबाऊ कामों को सँभाल लेते हैं जिन्हें हम पहले हज़ारों बार कर चुके हैं

  • मेरी नज़र में AI इंटरनेट पर मौजूद सारी जानकारी के ऊपर बातचीत करने वाली next-generation Google Search है। जैसे search engines के लोकप्रिय होने से कई industries—newspapers, phone books, encyclopedias, travel agencies वगैरह—में नौकरियाँ खत्म हुईं, वैसे ही AI भी ऐसे बदलाव लाएगा। लेकिन मुझे नहीं लगता कि यह उतना बड़ा अस्तित्वगत संकट है जितना लोग मानते हैं। AI बस एक tool है। बुद्धिमान और रचनात्मक लोग इस tool का उपयोग करके बहुत शानदार काम करेंगे। आखिरकार यह उपयोगकर्ता पर निर्भर है। search अब chat बन गई है। पहले हम खुद ढूँढ़ते थे, अब हम chat करते हैं और AI हमारे लिए ढूँढ़ देता है, और उससे भी आगे जाकर मदद करता है

    • मुझे यकीन नहीं कि chat-based LLM interface सबसे अच्छा तरीका है। लगता है हमें कुछ और स्मार्ट approach चाहिए

    • Google के स्वर्णकाल से अलग, अब signal की तुलना में noise ज़्यादा हो गया है, और data sources भी धुंधले हो गए हैं

    • अब तो Google search results में उपयोगी जानकारी से पहले AI द्वारा बना कचरा ऊपर दिखता है

    • आधुनिक search engines सिर्फ जवाब देते हैं, जवाब तक पहुँचने की प्रक्रिया नहीं दिखाते, और इससे सही तरीके से जानकारी खोजने और दर्ज करने वाले लोगों की भूमिका गायब हो रही है। अगर यह हिस्सा खत्म हो गया, तो अंत में सब दिशा खो देंगे। AI मौजूदा जानकारी को फिर से इस्तेमाल करता है, इसलिए creators—खासकर अच्छे journalism करने वाले reporters—को revenue लौटाने का तरीका होना चाहिए। नहीं तो लोकतांत्रिक समाज की बुनियाद टूटने का बड़ा खतरा है। news industry पहले से कई सालों से संकट में है, और उसके नतीजे में हम अविश्वास, विभाजन, misinformation और बाहरी manipulation देख चुके हैं। AI शायद इस industry को आखिरी घातक चोट दे सकता है। यह सिर्फ नौकरी बदलने का सवाल नहीं, बल्कि हम जिस रास्ते पर जा रहे हैं वह बहुत अँधेरा है

    • search के अलावा भी कई दूसरे क्षेत्रों में यह साफ तौर पर उपयोगी है

  • मैं चाहता हूँ कि Claude Code को phone से cloud VM पर चलाऊँ, ताकि टहलते हुए या साइकिल चलाते समय भी feedback देता रहूँ और काम चलता रहे

    • लगता है vibetunnel जैसे tool से ऐसा कुछ अभी से किया जा सकता है
      https://vibetunnel.sh

  • input और output का अनुपात दिलचस्प है। हम आम तौर पर output की मात्रा अधिकतम करने की कोशिश करते हैं, लेकिन अब मामला उल्टा है। मैं अधिकतम मात्रा से ज़्यादा यह चाहता हूँ कि काम की प्रक्रिया ठोस और सत्यापित किए जा सकने वाले चरणों में बँटी हो। Cursor के साथ requirements लिखते समय शुरुआत में चीज़ें अच्छी चलती हैं, लेकिन समस्या यह है कि वह गलती से plan से हटकर बहुत सारा code बना देता है। Markdown headings के बाद खाली पंक्ति जोड़ने जैसी छोटी बात भी कई बार याद दिलानी पड़ती है। मुझे लगता है कि iteration process, quality और consistency पर मेरा नियंत्रण थोड़ा और होना चाहिए। जब किसी open problem को testable closed problem में बदला जा सकता है, तभी AI अपनी असली ताकत दिखाता है। मुझे ऐसे tool की ज़रूरत है जो open problem को closed problem में बदलने में मेरी मदद करे

  • “ऑफिस पहुँचकर Claude द्वारा बनाई चीज़ को test करना, अगर सही चले तो commit और push कर देना” — इस तरह का अनुभव बार-बार हो रहा है, इसलिए एक cyber security consultant के रूप में लगता है कि आगे मैं बहुत पैसा कमाऊँगा

    • संभावना है। लेकिन self-driving cars की चर्चा की तरह यह भी याद रखना चाहिए कि गलतियाँ इंसानों से कम हो सकती हैं, पूरी तरह खत्म नहीं

  • मुझे नहीं लगता कि यह vibe coding है; यह पूरी तरह कुछ नया है। मैं इसे “flex coding” कहता हूँ। मैंने एक दोपहर में पूरा app बना लिया और साथ ही एक अच्छे पिता की भूमिका भी निभाई। मैं कहता हूँ “अब server connection UI बना दो,” फिर Claude coding करता रहता है और मैं अपनी दिनचर्या में लौट जाता हूँ। नाश्ता बनाता हूँ, बेटे के साथ खेलता हूँ, TV देखता हूँ, और बीच-बीच में Claude coding करता रहता है। हर एक-दो घंटे में लौटकर बस test करता हूँ और feedback दे देता हूँ

    • भावनात्मक रूप से यह बहुत आकर्षक है, और बहुत लोगों का सपना जैसा lifestyle होगा, लेकिन क्या Claude का code सच में इतना भरोसेमंद है? क्या इसे ग्राहकों से पैसे लेकर या अपनी प्रतिष्ठा दाँव पर लगाकर बने product में इस्तेमाल किया जा सकता है? मेरा जवाब “नहीं” है। मैंने खुद इस्तेमाल करके देखा है: reference errors, मौजूदा types को copy-paste करके सिर्फ नाम बदल देना, और ऐसे type errors जिन्हें वह पकड़ता ही नहीं—यह सब बहुत देखा है। जब मैंने उससे tests लिखवाए, तो कभी-कभी fail होने के बजाय वह ऐसे अजीब tests बना देता था जो बस self-validation पास कर लें। परिवार के साथ कीमती समय बिताना अच्छी बात है, लेकिन मैं अपने बनाए app को किसी महत्वपूर्ण जगह इस्तेमाल करने की सलाह नहीं दूँगा

    • इस तरह काम करने वाले व्यक्ति को वेतन क्यों दिया जाए, और जब मैं खुद कर सकता हूँ तो software पर पैसा क्यों खर्च करूँ—ऐसा सवाल उठता है

    • सावधानी के तौर पर कहूँ तो, अब जल्द ही Claude शिकायत भी शुरू कर सकता है कि तुम भी थोड़ा काम करो

  • LLM-आधारित software tools की सीमाएँ महसूस होती हैं। ऐसा कोई तरीका नहीं है कि एक global system prompt को सभी OpenRouter Key-आधारित apps पर समान रूप से लागू किया जा सके, और एक app से दूसरे app में conversation ले जाना भी मुश्किल है। सभी apps को एक ही MCP tools access भी ठीक से नहीं दिया जाता। Claude Code का UX अभी सबसे अच्छा लगता है, लेकिन मैं Claude subscription में बँधना नहीं चाहता; मैं अपनी key के ज़रिए अपनी पसंद के provider से जुड़ना चाहता हूँ

  • लगता है कि security, internationalization, localization, accessibility, usability वगैरह जैसी चीज़ों को सफलतापूर्वक prompt करने वाला हिस्सा छूट गया है। समस्या यह है कि ऐसे बहुत से amateurs खुद को “software creators” कहते हैं जबकि इन quality factors का ध्यान ही नहीं रखते। अगर ये पहलू गायब हों, तो commercial software के रूप में कभी सफलता नहीं मिलेगी। अगर किसी को लगता है कि इन चीज़ों को आसानी से prompt से हल किया जा सकता है, तो इसका मतलब है कि उसे उस क्षेत्र का गंभीर अनुभव नहीं है

    • निष्पक्ष रूप से देखें तो commercial software में भी कई बार इन बातों पर ठीक से ध्यान नहीं दिया जाता

    • मैं भी संदेहशील हूँ, लेकिन linked documents चार हैं और उनमें कम से कम accessibility और usability वाले documents शामिल हैं। internationalization और localization दिखाई न भी दें, तो मुझे नहीं लगता कि वे मूल रूप से बहुत अलग होंगी। वहीं security issue सच में अलग ही क्षेत्र लगता है

    • यह सोचकर हैरानी होती है कि अब भी बहुत लोग मानते हैं कि “मेरी चार-document system? आखिरकार वह भी pattern बना हुआ spaghetti ही है, और शायद कल तक सब ढह जाए। फिर से spaghetti फेंकेंगे।” इस तरह development scale होगा

  • हाल में मैं model-based development को प्रयोगात्मक रूप से देख रहा हूँ, और लेख में “programming आखिर है क्या?” वाला हिस्सा गहराई से जुड़ा लगा। मैं अपने 25 साल के अनुभव और computer science—दोनों का उपयोग कर रहा हूँ, लेकिन यह हाथ से code लिखने वाली पारंपरिक programming जैसा नहीं लगता। अभी ऐसा महसूस होता है जैसे मैं कुछ हाथ से बना नहीं रहा, बल्कि tools को उड़ाने वाला pilot हूँ। जो लोग हाथ से बनाने का आनंद लेते हैं, वे शायद अगले 5 साल में industry छोड़ देंगे। बेशक अब भी कुछ हिस्से ऐसे रहेंगे जहाँ manual work चाहिए होगा, लेकिन एक नई methodology खुल रही है। अभी सभी लोग इसमें निपुण नहीं हैं, लेकिन यह भी industry का हिस्सा बन जाएगी

    • एक समय था जब productivity बढ़ाने के लिए knowledge हासिल करना ज़रूरी था, लेकिन LLM की वजह से अब सीधे productivity stage पर छलाँग लगाई जा सकती है। यह सिर्फ knowledge का लोकतंत्रीकरण नहीं, बल्कि ऐसा है मानो knowledge खुद अनावश्यक होती जा रही हो