एजेंट-आधारित AI अच्छे pair programmer क्यों नहीं हैं

• क्योंकि LLM एजेंट इंसानों की तुलना में बहुत तेज़ी से code लिखते हैं, pair programming का अनुभव उल्टा खराब हो सकता है
• बहुत तेज़ automation की वजह से user साथ नहीं चल पाता, और काम का context बार-बार छूट जाता है
• यह स्थिति अनुभवी developers के साथ pairing में महसूस हुए अलगाव जैसी है, और आखिरकार quality control तथा communication दोनों कमजोर हो जाते हैं
• समाधान के तौर पर asynchronous code review-केंद्रित collaboration और AI के साथ pairing की रफ्तार कम करके quality control व communication-केंद्रित workflow अपनाने का प्रस्ताव है
• AI एजेंटों को भी इंसानों की तरह “रुककर बात करने, और आत्मविश्वास से ज़्यादा संदेह व verification पर ध्यान देने” वाले design की ज़रूरत है

---

LLM एजेंट और pair programming की समस्याएँ

• AI एजेंट (जैसे Copilot Agent) इंसानी सोच की गति से कहीं तेज़ code लिखते हैं
• इसकी वजह से user के समझने से पहले ही code की बाढ़ आ जाती है, और context छूटने व काम में डूबाव कम होने जैसी समस्या पैदा होती है
• जब किसी समस्या में एजेंट मदद माँगता है, तब तक user अक्सर स्थिति समझ ही नहीं पाया होता और उसे “बाद की सफ़ाई” का काम संभालना पड़ता है; नतीजतन गलत दिशा में बढ़ चुके code को समेटने का बोझ बढ़ जाता है
• आखिरकार quality control, communication और सही दिशा बनाए रखना मुश्किल हो जाता है

• सबसे बेहतरीन AI एजेंट के साथ pair करने का अनुभव, अतीत में बेहद उत्कृष्ट human programmer के साथ pairing से जुड़ी नकारात्मक यादों को ताज़ा कर देता है
  • जब pair partner बहुत ज़्यादा रफ्तार से बिना कुछ बोले keyboard चलाता रहता है, तो code का पीछा कर पाना मुश्किल हो जाता है
  • मानसिक ऊर्जा पूरी तरह खत्म हो जाती है और धीरे-धीरे व्यक्ति काम से कटने लगता है
  • जब pair अटकता है और मदद माँगता है, तब स्थिति समझ न आने की असहजता पैदा होती है
  • काम आगे बढ़ते-बढ़ते लक्ष्य से अलग दिशा में implementation बन जाता है, और deadline के भीतर उसे ठीक करने का बोझ दूसरे पर आ गिरता है

The path forward: व्यावहारिक समाधान

• 1. asynchronous collaboration

  • जैसे human pair programming में एक व्यक्ति लीड लेकर आगे बढ़ता है, वैसे ही AI स्वतंत्र रूप से code लिखे और उसे Pull Request के रूप में review किया जाए, यह ज़्यादा प्रभावी हो सकता है
  • GitHub Coding Agent जैसे asynchronous workflow का उपयोग करके user review और quality control पर ध्यान केंद्रित कर सकता है

• 2. धीमी रफ्तार वाली “turn-based” pairing

  • AI के “Agent Mode” की जगह Edit/Ask Mode जैसे, एक बार में एक step आगे बढ़ने वाले तरीके का उपयोग
  • Ping-pong pairing (एक पक्ष प्रस्ताव दे, दूसरा मंज़ूरी दे) की तरह, AI द्वारा सुझाए गए बदलावों को user खुद accept/review करके रफ्तार नियंत्रित करे
  • सिर्फ problem solving/debugging के लिए ही नहीं, बल्कि एक consistent workflow के हिस्से के रूप में AI का उपयोग करना अधिक उचित है

एजेंट pairing को और अधिक मानवीय बनाने के विचार

• user को code output speed (lines/min, words/min) सीधे नियंत्रित करने की सुविधा देना
• एजेंट को अस्थायी रूप से pause करने की सुविधा, ताकि user सवाल पूछ सके या दिशा पर आपत्ति जता सके
• मौजूदा chatbot UI से आगे बढ़कर, काम की प्रगति से जुड़ी UI primitives (जैसे मौजूदा session को किसी खास GitHub issue से pin करना, built-in To-do list आदि) देना
• एजेंट को ज़्यादा बार रुककर बातचीत करने के लिए design करना: “यह क्यों किया जा रहा है” की पुष्टि, सलाह माँगना, दिशा की जाँच आदि के ज़रिए human collaboration जैसा माहौल बनाना
• advanced voice chat support जोड़ना, ताकि user की नज़र code पर रहे और वह आवाज़ के ज़रिए AI से संवाद कर सके

• अगर ये सुविधाएँ लागू हों, तो आज की तेज़ और एकतरफ़ा agent pairing के बजाय, सचमुच का human-agent collaborative experience संभव हो सकेगा

निष्कर्ष

• इस समय हम AI एजेंट-आधारित pair programming की सीमाओं और संभावनाओं दोनों को एक साथ देख रहे हैं
• AI agent pair programming केवल तेज़ होने से नहीं, बल्कि human collaboration की तरह communication, quality और verification-केंद्रित design होने पर ज़्यादा प्रभावी हो सकती है
• “धीरे चलना, बातचीत करना, verify करना, और स्थिति साझा करना” AI pairing की गुणवत्ता को बेहतर बनाता है

[panarch]

> 1. असिंक्रोनस सहयोग
> इंसानों के साथ pair programming में जब एक व्यक्ति पहल करके आगे बढ़ता है, उसी तरह AI का स्वतंत्र रूप से code लिखना और Pull Request के ज़रिए review करना अधिक प्रभावी है।

मैं पिछले कुछ दिनों से Codex इस्तेमाल कर रहा हूँ, और agent रूप की तुलना में मैं इससे ज़्यादा सहमत हूँ। एक साथ कई project tasks चलाना संभव होने के बाद, सच में ऐसा अनुभव हो रहा है जैसे मैं कई junior developers के साथ काम कर रहा हूँ।
AI को असिंक्रोनस तरीके से इस्तेमाल करना संभव होने से कई projects, और एक project के भीतर भी कई tasks एक साथ करवाना संभव हो गया है, और productivity में 3-10 गुना या उससे भी ज़्यादा बढ़ोतरी वास्तव में महसूस होती है।

[GN⁺]

Hacker News राय

• ऐसा लगा कि यह लेख बिल्कुल ठीक-ठीक समझाता है कि मैंने AI को इस तरह इस्तेमाल करना क्यों जल्दी छोड़ दिया। जब मैं कुछ बनाना चाहता हूँ, तब आम तौर पर मेरे मन में पहले से ही मोटे तौर पर <i>तरीका</i> तय होता है, लेकिन AI जिस तरह वास्तव में काम करता है, वह अक्सर मेरी चाहत से अलग होता है। और जब AI एक बार में 2,000 लाइनों का कोड बना देता है, तो उल्टा काम और बढ़ जाता है। फिर कहना पड़ता है, "पहले ये सारे comments हटा दो, इतने simple code में ये बेवजह की explanation दोगुनी है। X को ऐसे abstract मत करो, मुझे यह चाहिए..." और feedback देने पर अचानक 2,000 लाइनें 700 लाइनों में बदल जाती हैं, जिससे साथ बने रहना बहुत मुश्किल हो जाता है। यह भी बुरा लगता है कि codebase ऐसे scripts से भर जाता है जिन्हें मैं ठीक से नहीं जानता और जिनका तरीका भी एक-दूसरे से अलग होता है। मुझे ऐसा AI चाहिए जिसकी style और सोच मुझसे मिलती-जुलती हो, लेकिन वही सबसे मुश्किल बात है। AI के साथ काम करना ऐसा लगता है जैसे किसी अनुभवहीन व्यक्ति के साथ पहले दिन काम कर रहे हों। व्यक्तिगत रूप से मुझे यह tool के overconfidence की समस्या से ज़्यादा design process को और स्पष्ट कर देने वाली बात लगती है। आदर्श रूप में पहले ऐसी design doc दिखनी चाहिए: "मैं यह approach सोच रहा हूँ, इन functions या classes का इस्तेमाल करूँगा, state को इस तरह manage करूँगा," और अगर वह ठीक लगे, तभी implementation पर जाना चाहिए.

  • इंसानी engineer की तरह, पहले planning session होना सच में बहुत ज़रूरी है — इस बात पर ज़ोर। कोड लिखने से पहले discussion, और थोड़ा मोलभाव जैसा detail तय करना। मैं जानबूझकर पहला सवाल जितना हो सके उतना vague रखता हूँ, ताकि कोई अनपेक्षित recommendation आती है या नहीं, यह देख सकूँ, और फिर धीरे-धीरे specific होता जाता हूँ। जब मैं पर्याप्त संतुष्ट हो जाता हूँ, तब LLM से initialprompt.txt और TODO.md नाम के दो documents बनवाने को कहता हूँ। initialprompt.txt में project summary, TODO.md पढ़ने का निर्देश, और हर step पूरा होने पर उसे check करने का command होता है। इससे LLM को overall goal और detailed tasks दोनों समझ में आ जाते हैं, और बाद में context limit के कारण बातचीत टूट जाए और दोबारा शुरू करनी पड़े, तब वह काम जल्दी याद भी करवा देता है.

  • लगा जैसे इसने मेरे अनुभव को भी हूबहू समेट दिया हो। AI द्वारा लिखा गया कोड मेरे लिए तभी सफल रहा जब सिर्फ output मायने रखता था और उस domain के बारे में मुझे लगभग कोई background knowledge नहीं था। लेकिन जब मेरे पास इस बात पर मजबूत राय होती है कि "अच्छा" नतीजा कैसा होना चाहिए, तब अंत में निराशा ही मिली और प्रोजेक्ट छोड़ना पड़ा। roo code के architect feature से पहले approach व्यवस्थित करने के बाद, code mode में actual implementation करते समय खुशी और निराशा आधी-आधी थीं। सबसे बड़ा सबक यह था कि हमेशा नया task शुरू करो, लंबी बातचीत मत घसीटो। मैं आम तौर पर problem को छोटे हिस्सों में बाँटकर result verify करने वाला व्यक्ति हूँ, लेकिन LLM के सामने पूरे problem space को एक साथ फेंक कर असफल होता रहा। अपनी method खोजने के लिए मैंने कई बार कोशिश की, और आज भी 30 मिनट में app feature जोड़ दिया। अगर खुद implement करता तो सच में कई दिन लगते। और मैंने log में सिर्फ 30 मिनट ही इसलिए लिखा क्योंकि मुझे साफ़ पता था कि मुझे क्या चाहिए, process में मेरी रुचि नहीं थी। ऐसे अनुभवों ने मुझे इस निष्कर्ष तक पहुँचा दिया कि ऐसा code जो बाद में किसी और को maintain करना पड़े, उसे AI पर छोड़ना हर वजह से असंभव है.

  • आखिरकार यह बस बहुत थका देने वाला और नतीजों से असंतोषजनक अनुभव रहा। यह उन लोगों से कही गई बात है जिनकी यही चिंता है। मेरे लिए भी agent coding तभी संतोषजनक रही जब वह code quality की परवाह न करने वाले short-term scripts हों या ऐसे leaf functions जो वास्तव में कहीं असर नहीं डालते.

  • Anthropic की Claude Code best practices में सुझाया गया workflow काफ़ी recommend करने लायक है। सार यह है: “पहले उसे code पढ़ने दो, फिर बदलाव की plan बनवाओ, और आखिर में execute करने दो।” AI एक लाइन code लिखने से पहले ही आप उसकी योजना देखकर उसे edit कर सकते हैं। अगर agent आपके मनचाहे तरीके से अलग चल रहा है — जैसे बिना design के सीधे coding शुरू कर दे — तो बस कह दीजिए, "इसे अलग तरह से करो।"

  • एक बार में 2,000 लाइन का code generate करने वाली बात सुनकर लगता है, कहीं आप उसे SNES पर पूरा Skyrim चलाने वाला prompt तो नहीं दे रहे। दोपहर का खाना खाकर वापस आओ और test करो, तो वह PS1-style वाला melee-only Fallout बना चुका हो — और फिर उस पर गुस्सा आना.

• जब भी HN के पहले पेज पर मेरी पोस्ट जाती है, मैं comments देखकर हमेशा डरता हूँ कि लोग मुझे कितना बेवकूफ़ साबित करेंगे और मेरी इज़्ज़त उतारने वाले आक्रामक comments करेंगे। लेकिन कभी-कभी अगर मैं title बहुत अच्छा रख दूँ, तो कोई मेरा लेख पढ़ता ही नहीं, सब लोग अपनी-अपनी बात करते रहते हैं, और मैं उस तरह की आलोचना से बच जाता हूँ.

  • मुझे यह मज़ेदार भी लगा और यथार्थवादी भी। दूसरे लेखों में भी ऐसा pattern अक्सर दिखता है। खैर, मुझे ऐसी discussions अपने आप में पसंद हैं, इसलिए यह दिलचस्प लगा.

  • लेख अच्छा लगा। थोड़ा “AI के साथ pair programming का आनंद कैसे लें” जैसी भावना थी। उपयोगी था, इसलिए धन्यवाद.

• जब मैंने पहली बार LLM agent इस्तेमाल किया, तो मुझे दो-तरफ़ा संवाद, यानी सचमुच collaborative pair programming की उम्मीद थी। लेकिन असल में एक ऐसा partner मिला जो हर चीज़ पूरी तरह अपने तरीके से ही हल करना चाहता है। मैंने थोड़ा-सा edit करना चाहा, तो AI द्वारा लिखे गए code का context टूट गया और अनुभव और भी असुविधाजनक हो गया। मैं चाहता था असली सहयोग — थोड़ा मैं, थोड़ा AI, बारी-बारी से काम.

  • पूछा कि क्या आपने हाल में फिर कोशिश की है। मेरा अनुभव अलग रहा। मैं AI द्वारा generated code को edit करने के बाद उसे file फिर से पढ़ने को कहता हूँ। तब वह आम तौर पर "file में changes हैं" जैसी प्रतिक्रिया देता है। AI code बदलता है, मैं tests चलाकर feedback देता हूँ, फिर वह iterative improvement करता है। Zed और Claude Sonnet में यह तरीका मेरे लिए अच्छी तरह काम करता है.

  • मेरा सामान्य तरीका यह है कि पहले AI का सुझाव लेता हूँ, फिर refactor करता हूँ या ज़रूरत हो तो prompt से दोबारा निर्देश देता हूँ। इस approach से acceptance rate कृत्रिम रूप से बढ़ जाती है, और वास्तव में AI कंपनियाँ इसी statistic को आधार बनाकर कह सकती हैं कि "AI बहुत अच्छा code लिखता है।" जबकि असलियत में कई बार मैं सिर्फ इस सोच के साथ आगे बढ़ता हूँ: “चलो, अब इसे मुझे खुद ही ठीक करना पड़ेगा।”

  • मैं आम तौर पर “पहले सिर्फ चर्चा करें। code modify मत करो” जोड़ दूँ, तो मनचाहे तरीके की बातचीत हो जाती है। पर्याप्त आगे-पीछे बात हो जाने के बाद अंत में कहता हूँ, “अब apply करो।”

  • अगर आपको सहयोग का कोई खास रूप चाहिए, तो सलाह यही है कि उसे LLM से स्पष्ट रूप से माँगिए। कुछ prompt documents तैयार रखिए जिन्हें हर बातचीत में फिर से इस्तेमाल किया जा सके.

  • हाल में context बनाए रखना ज़्यादा मुश्किल नहीं रहा, इसलिए code editing में भी दिक्कत नहीं होती। मैं सिर्फ Ask mode में इस्तेमाल करता हूँ, Claude Code में Opus और Cursor में o3 max। Agent mode से जानबूझकर बचता हूँ, क्योंकि मूल पोस्ट की तरह समय बीतने के साथ मुझे उससे कम फायदा मिलता है। Tab completion कम ही इस्तेमाल करता हूँ, और सुझाए गए code का 80~90% मैं edit करके खुद टाइप करता हूँ। इससे मैं 170wpm की गति से टाइप करता रह सकता हूँ। Opus और o3 max की output speed सीमित है, इसलिए पढ़ना भी भारी नहीं पड़ता; शुरुआत में यह बहुत तेज़ लगती थी, पर जल्दी आदत पड़ गई। मेरी निजी राय यह है कि अगर GitHub Copilot ही आपका पूरा LLM अनुभव है, तो वह बस motel-level अनुभव है.

• Pair programming भी हर स्थिति के लिए उपयुक्त नहीं है। बल्कि कई मामलों में यह उपयुक्त नहीं हो सकती। जैसा कहीं और भी कहा गया, LLM के autocomplete suggestions के कारण coding के दौरान focus flow टूट जाता है; बार-बार रुककर पढ़ना, review करना, accept/reject करना पड़ता है, जिससे programming flow पूरी तरह टूट जाता है। अपने workflow में AI autocomplete फिट करने की कोशिश मेरे लिए सच में कठिन रही.

  • मैं भी यही सोचता हूँ। समाधान यह है कि AI-रहित dedicated IDE और Cursor/VS Code दोनों रखें और बारी-बारी से इस्तेमाल करें। chatbot से बात करते हुए असली immersion/deep work संभव नहीं है.

  • हाल ही में मैंने नया laptop लिया और IDE नया install किया। कुछ घंटे coding के दौरान लग रहा था कि कुछ ‘अजीब’ है। बाद में पता चला कि मैं GitHub Copilot login करना भूल गया था और AI के बिना काम कर रहा था। code autocomplete का इंतज़ार किए बिना मैं कहीं ज़्यादा सक्रिय रूप से code लिख रहा था। Cursor तो खास तौर पर लगातार workflow बाधित करता है, इसलिए ‘next cursor position predict’ जैसी feature भी बिल्कुल अनावश्यक लगी। आगे से Copilot बंद रखूँगा, और boilerplate या repetitive कामों के लिए सिर्फ aider जैसे agent-style tools इस्तेमाल करूँगा.

  • AI autocomplete या code suggestion features खास तौर पर strongly typed languages में सबसे खराब हैं। उनमें से ज़्यादातर 80% सही होती हैं, जबकि IDE autocomplete लगभग 100% सटीक होती है। Agent-style तरीका इसलिए बेहतर है क्योंकि 1) वह लगातार आपके thinking flow को interrupt नहीं करता, 2) वह खुद compile और test चलाकर गलतियाँ सुधार सकता है, फिर सही code लौटा सकता है.

  • मुझे तो उल्टा autocomplete बहुत पसंद है। मुझे Go language में काम करना पड़ता है, जहाँ boilerplate बहुत होता है, और यह ऐसी समस्या है जिसे सिर्फ library जोड़कर हल नहीं किया जा सकता, इसलिए कई बार खुद टाइप करना ही तेज़ होता है। उबाऊ code लिखने में AI से ज़्यादा तेज़ मेरे हाथ हैं, फिर भी autocomplete सच में मदद करती है। एक लाइन के सुझाव तो मैं तुरंत पढ़ लेता हूँ, और लंबा सुझाव भी अगर वही हो जो मैं लिखने वाला था, तो आसानी से स्वीकार कर लेता हूँ। बार-बार ऐसा होने पर अंदाज़ा लग जाता है कि AI क्या predict करेगा। यह कोई जबरदस्त productivity boost नहीं है, लेकिन log messages या for loops जैसी झुंझलाने वाली चीज़ें निश्चित रूप से तेज़ हो जाती हैं। मेरी राय में यह तभी मददगार है जब मेरी reading speed मेरी typing speed से कहीं तेज़ हो.

  • Pair programming हमेशा सही नहीं होती, लेकिन ज़्यादातर परिस्थितियों में उपयोगी हो सकती है — ऐसी राय। यह आम तौर पर तब काम नहीं करती जब एक या दोनों लोग प्रक्रिया में सक्रिय रूप से शामिल न हों, या उनमें से कोई एक “यह नहीं चलेगा” कहकर विरोध करे, या pair programming के सिद्धांतों को बहुत कठोरता से लागू करने लगे.

• मेरा रुख थोड़ा जटिल है। कम-से-कम एक महीने से मैं कंपनी में उपलब्ध लगभग सभी LLM tools को सक्रिय रूप से इस्तेमाल कर रहा हूँ ताकि उन्हें सबसे प्रभावी ढंग से उपयोग करना सीख सकूँ। lines of code के हिसाब से productivity निश्चित रूप से बढ़ी है। लेकिन कुल मिलाकर मैं खुद को ज़्यादा productive नहीं कह सकता। हर पूरे हुए task के बाद अक्सर कोई अजीब, समझ न आने वाला behavior होता है, या कभी-कभी यह unrelated हिस्सों को भी छेड़ देता है, जिन्हें फिर revert करना पड़ता है। AI द्वारा auto-generated tests पहली नज़र में ठीक लगते हैं, लेकिन coverage जैसे दूसरे metrics से उनकी कमी साफ़ दिखाई देती है। मनचाहे result तक पहुँचने के लिए उल्टा कई steps पीछे जाना पड़ता है। यह किसी लाभ या सीख जैसा नहीं, बल्कि जैसे पूरी तरह regression हो। एक बार तो 50,000 लाइनों का बेकार import code चुपके से ऐसे module में जोड़ दिया गया जो मूल बदलाव के दायरे में भी नहीं था। किसी और बार मैंने rules साफ़ बताए थे, फिर भी उसने पूरा object-oriented structure बिगाड़कर ढेर सारे if/else से implementation कर दी। समस्या यह है कि परिस्थितियों के अनुसार नतीजे बहुत बदलते हैं; एक ही तरह के task में कभी यह बिल्कुल सही होता है, तो कभी सब कुछ तोड़ देता है। मैंने अलग-अलग तरीके आज़माए कि task कैसे दिया जाए, किस तरह guide किया जाए, लेकिन मिलते-जुलते कामों में भी behavior इतना अलग रहता है कि हर बदलाव को review करना पीड़ादायक हो जाता है। और अगर code लगभग सही भी हो, तो किसी एक हिस्से को ठीक करने को कहने पर पूरी चीज़ भटक जाती है। मेरे अनुभव में छोटे tools लिखने के स्तर पर यह प्रभावी है, लेकिन medium-to-large codebases में इससे consistent result की उम्मीद करना मुश्किल है.

• LLM agents बहुत ज़्यादा बोलते हैं और हमेशा मानते हैं कि उनका तरीका ही सही है। वे concise नहीं होते; एक लाइन में खत्म होने वाली बात भी बहुत लंबी समझाते हैं। मामूली बदलाव पर भी लंबी comments जोड़ देते हैं। वे मुझे सिखाने लगते हैं, और बहुत over-the-top हो जाते हैं.

  • लोगों को नापसंद आने वाले कुछ व्यवहार ("बहुत लंबा output, ज़रूरत से ज़्यादा comments" वगैरह) शायद इस वजह से हों कि LLM को दूसरे पहलुओं में efficiency बढ़ाने के लिए डिज़ाइन किया गया है। लंबे outputs का संबंध non-lazy code और बेहतर benchmark scores से हो सकता है। comments की भरमार local context मजबूत कर सकती है, जिससे अगले code की quality बेहतर हो और errors कम हों.

  • मैंने कल sonnet 4 आज़माया; सिर्फ एक setting value बदलने वाले task पर उसने 15 मिनट लगा दिए, लगातार testing और refactoring करता रहा। अंत में बेवजह 40 files बदल दीं। बार-बार ऐसे debugger को चलाने की कोशिश करता रहा जो मौजूद ही नहीं था, और authentication-required webpages खोलने की भी कोशिश करता रहा। साफ़ लगा कि यह पूर्णता से बहुत दूर है.

• मेरे अनुभव में समस्या तेज़ी नहीं, बल्कि उल्टा बहुत धीमी होने की है। और यह एक अजीब, बुरी तरह की धीमी गति है। अगर यह और तेज़ होता, तो मैं real time में code के साथ चल सकता था। अगर और धीमा होता, तो उस बीच दूसरा काम कर सकता था। लेकिन हक़ीक़त यह है कि यह 50 सेकंड से कुछ मिनट के चक्र में task पूरा करता है, इसलिए मैं किसी और काम पर ठीक से ध्यान भी नहीं दे पाता। मुझे लगता है कि छोटी-छोटी units में तेज़ iteration बेहतर होगी। आखिरकार, human review level की autonomy — जैसे merge request (PR) review करने जैसा स्वतंत्र काम — ज़्यादा अच्छा होगा। मौजूदा loop (task दो, 1~3 मिनट इंतज़ार करो, result देखो, feedback दो, फिर दोहराओ) मेरे लिए व्यक्तिगत रूप से सबसे बुरा case है.

  • यह सुनकर The Oatmeal की “slow internet vs no internet at all” comic याद आ गई.

  • अगर ध्यान भटक रहा हो, तो desk पर 30L का aquarium रखो — शून्य में घूरने के लिए बेहतरीन, ऐसा मज़ेदार सुझाव.

• एक developer के रूप में मैं AI लगभग इस्तेमाल ही नहीं करता; कभी-कभी बस non-project सवालों के लिए chat chatbot ले लेता हूँ। जिज्ञासा है कि क्या लोग client projects में भी AI इस्तेमाल करते हैं, या सिर्फ private/pet projects में। अगर client work में करते हैं, तो क्या contract में यह शामिल करते हैं कि code AI को भेजा जाएगा? ज़्यादातर clients NDA जैसे बाहरी disclosure-निषेध समझौते करते हैं, और कुछ clients ने तो AI उपयोग निषेध clause भी रखा था। जिज्ञासा है कि क्या किसी ने ऐसे clients देखे हैं जो AI coding tools को अपवाद के रूप में अनुमति देते हों.

  • मैं लगभग केवल in-house काम में इसका उपयोग करता हूँ, वह भी इसलिए कि कंपनी के पास AI उपयोग के स्पष्ट guidelines हैं। सच कहूँ तो इसने मुझे खास समय नहीं बचाया, इसलिए अपने निजी काम के लिए मैं इसके पैसे नहीं दूँगा। personal projects में outcome से ज़्यादा खुद बनाने का आनंद महत्वपूर्ण है, इसलिए prompting के बजाय खुद बनाना ज़्यादा सुखद है.

  • कुछ client पक्ष ऐसे भी हैं जो सक्रिय रूप से AI उपयोग की माँग करते हैं। उन्हें बेहतर quality और तेज़ development की उम्मीद होती है (अंततः cost cutting के लिए), हालांकि वास्तविकता अक्सर उस उम्मीद से अलग होती है — लेकिन वह अलग मुद्दा है.

  • OpenAI/Anthropic के साथ मैं सिर्फ वही code साझा करता हूँ जिसे web search box में भी बेझिझक paste किया जा सके.

  • मैं साझा नहीं करता। internal projects भी इसमें शामिल हैं, और बाहरी तौर पर code share करना केवल भुगतान लेकर ही संभव है। मैं personal data भी process करता हूँ, इसलिए अगर code अमेरिकी कंपनियों के सामने expose हो जाए, तो legal risk बहुत बड़ा है.

• आखिर किसी ने वह बात साफ़-साफ़ कही। AI design को लेकर ज़रूरत से ज़्यादा आत्मविश्वासी है, और detailed implementation बिना consultation के अपने मन से आगे बढ़ा देता है। Mocking APIs भी अक्सर structure बिगाड़ देते हैं, इसलिए rework ज़रूरी हो जाता है। मैं चाहता हूँ कि LLM का व्यवहार ज़्यादा collaborative हो, और details कम हों तो तुरंत पूछे। पहली prompt में सारी जानकारी देना संभव नहीं होता, और follow-up prompts शुरू की design context और thought flow को तोड़ देते हैं। शायद मैं इसे गलत तरीके से इस्तेमाल कर रहा हूँ; बेहतर तरीका जानना चाहता हूँ। चाहता हूँ कि LLM feedback को धीरे-धीरे लेकर reflect करे और उसी दिशा में सुधरे। यह भी जिज्ञासा है कि क्या context जोड़ना/अपडेट करना अपने आप में ही कठिन समस्या है, लेकिन सीखते रहने की इच्छा है.

  • आजकल ज़्यादातर tech stacks में “design/planning” sessions का समर्थन है, इसलिए पहले इसे आज़माने से सुधार हो सकता है। मेरा पसंदीदा workflow यह है: चाहे बड़ा model हो या छोटा, बातचीत की शुरुआत मैं इस तरह करता हूँ — “@file, @docs, @examples के आधार पर, @path में _ काम @module_requirements.md को refer करते हुए करना है — actual implementation से पहले जो कुछ ज़रूरी है, उस पर सब चर्चा करें।” आगे-पीछे बात करके जब सब सहमत हो जाएँ, तो उसे .md file वगैरह में save कर सकते हैं, या सीधे “अब आगे बढ़ो” कह सकते हैं। .rules या .md files, IDE snippets आदि में workflow register करके हर नए task में बार-बार इस्तेमाल किया जा सकता है। यह भी ध्यान रहे कि आधुनिक LLMs को कहीं ज़्यादा context चाहिए, इसलिए हर codebase (हर project) के लिए अलग flow आज़माना पड़ सकता है और नतीजे भी उसी से बदलते हैं.

  • लगता है कि जानकारी बढ़ने पर AI और उलझ जाता है। शायद इससे निपटने का कोई तरीका होगा। बहुत छोटे information fragments निकालने में यह सक्षम है, लेकिन यह अफ़सोस की बात है कि पूरी industry सिर्फ chatbot models पर केंद्रित लगती है। कभी-कभी सोचता हूँ, अगर हम keyboard, mouse, GUI, touch screen जैसी चीज़ें बनाते ही नहीं, तो दुनिया कैसी होती.

• AI को सहायक की तरह इस्तेमाल करने वाली collaborative style ही AI के उपयोग का सही तरीका है, और “AI सीधे code लिखे” वाली trend इस बात का उदाहरण है कि software industry गलत दिशा में जा रही है। मैं कभी AI से code नहीं लिखवाता। मैं उससे अपने लिखे code की आलोचना करवाता हूँ, या बड़े स्तर की code structure/design strategy बनवाने में उसका उपयोग करता हूँ। यानी उसे एक तरह के strategy consultant की तरह इस्तेमाल करता हूँ; अगर LLM का context अच्छी तरह बनाया जाए, तो उससे बहुत बेहतरीन guidance मिल सकती है। नियंत्रण हमेशा मेरे पास रहता है — समझना और लागू करना मेरी ज़िम्मेदारी है, और AI को मैं सलाहकार से अधिक ज़िम्मेदारी नहीं देता। मैं AI को “idiot savant” की तरह देखता हूँ, और उसी सावधानी से उससे पेश आता हूँ.