यूज़र साफ़ तौर पर चिढ़ रहे हैं.

 (pscanf.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कोडिंग एजेंट की विफलता साधारण टूल एरर से ज़्यादा चिढ़ पैदा करती है, क्योंकि संवादी UX इंसान के साथ काम करने जैसा एहसास बनाता है
  • एजेंट जवाब देता है कि वह भावनारहित AI assistant है, लेकिन दोस्ताना लहजा, तारीफ़, और नरम असहमति के ज़रिए सहकर्मी जैसा प्रभाव देता है
  • जब वही गलती बार-बार दोहरती है, तो माफ़ी, memory update, और “अब दोबारा ऐसा नहीं होगा” जैसे वादों के बाद भी यह probabilistic path से बाहर नहीं निकल पाता
  • इंसानी सहकर्मी पर गुस्सा जताने से लोग खुद को रोकते हैं, लेकिन एजेंट पर खुलकर गुस्सा निकाला जा सकता है, इसलिए हताशा कम होने के बजाय और साफ़ महसूस होती है
  • समाधान यह हो सकता है कि इंसान जैसा दिखने वाला व्यवहार कम किया जाए और अधिक clinical और robot-जैसा tone अपनाया जाए, हालांकि संवादी interface अपने आप में कई मायनों में अच्छी तरह काम करता है

संवादी UX से पैदा होने वाली हताशा

  • कोडिंग एजेंट probabilistic तरीके से patch बनाने वाली मशीन है, इसलिए वह अच्छे और बुरे दोनों नतीजे दे सकती है, लेकिन बुरा नतीजा किसी साधारण टूल की विफलता से कहीं ज़्यादा चिढ़ाने वाला लग सकता है
  • असली बात यह है कि संवादी UX इंसान के साथ interaction जैसा एहसास बनाता है और बार-बार की गलतियों पर यूज़र की सामाजिक और भावनात्मक प्रतिक्रिया को उकसाता है
  • सीधे पूछने पर एजेंट कहता है कि वह भावनाओं या subjective experience के बिना एक AI assistant है, लेकिन वास्तविक interaction में वह दोस्ताना और सहज लहजा अपनाता है, यूज़र की तारीफ़ करता है, और असहमति भी नरमी से संभालता है
  • यूज़र तर्क से जानता है कि वह “संभावना के आधार पर चुने गए text blocks” पढ़ रहा है, लेकिन टूल का व्यवहार मददगार सहकर्मी के साथ काम करने जैसा एहसास बनाता है, और समस्या आने तक वही एहसास बना रहता है
  • जब वही गलती दोहरती रहती है, तो यूज़र उसे इंगित करता है, एजेंट माफ़ी मांगता है, फिर दोबारा बताने पर memory update करता है और “अब दोबारा ऐसा नहीं होगा” का वादा करता है
  • फिर भी टूल सबसे अधिक संभावित रास्ते पर ही चलता रहता है, इसलिए कई बार HARD RULES के बावजूद वह समस्या वाले व्यवहार से बाहर नहीं निकल पाता

इंसान जैसा दिखने वाला, लेकिन जवाबदेही से रहित टूल

  • अगर कोई इंसानी सहकर्मी वही गलती बार-बार करे, तो असहज या नाराज़ महसूस करने की वजह होती है, लेकिन किसी algorithm पर गुस्सा करना बेतुका लग सकता है
  • फिर भी, क्योंकि कोडिंग एजेंट सहकर्मी की तरह व्यवहार करता है, यूज़र के भीतर वही भावनात्मक सर्किट सक्रिय हो जाता है, और दोहराई गई गलतियां किसी असली सहकर्मी की गैर-जिम्मेदारी जैसी महसूस हो सकती हैं
  • इंसानी सहकर्मी के सामने “मैं भयानक इंसान नहीं बनना चाहता” जैसी रोक गुस्सा जताने को दबाती है, लेकिन एजेंट के सामने यूज़र को लगता है कि वह खुलकर गुस्सा कर सकता है
  • ऐसा गुस्सा निकालना राहत नहीं देता; उलटे यूज़र को यह हताशा और साफ़ महसूस होती है कि वह जो भी करे या कहे, उसका कोई वास्तविक असर नहीं पड़ता
  • Claude Code हाल में सुधार करते समय कभी-कभी यह दोहराता है कि गलती कहाँ हुई और क्या किया जाना चाहिए था, लेकिन ऐसी बाद की व्याख्या इस बात का उपयोगी संकेत नहीं देती कि निर्देश कैसे बदलने चाहिए, और यह चुभने वाली फालतू बात जैसी लग सकती है
  • एक अधिक कट्टर समाधान यह हो सकता है कि इंसान जैसा दिखने की कोशिश छोड़ दी जाए, और एजेंट को clinical व robot-जैसे तरीके से बोलने के लिए बनाया जाए, ताकि यूज़र को इंसान से बातचीत होने का भ्रम कम हो
  • क्योंकि LLM की बुद्धिमत्ता “इंसान की तरह व्यवहार करने” वाले mechanism से आती है, इसलिए संवादी interface का डिफ़ॉल्ट तरीका बन जाना स्वाभाविक है, और कई मायनों में यह अच्छी तरह काम भी करता है
  • व्यावहारिक तौर पर यूज़र को खुद को इस तरह प्रशिक्षित करना पड़ सकता है कि वह इंसान से बात करने के भ्रम में न फँसे, लेकिन काम के टूल इस्तेमाल करते समय ऐसी मानसिक रक्षा की ज़रूरत पड़ने वाला भविष्य सुखद नहीं लगता

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

1 टिप्पणियां

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

  • आम लोगों पर थोपे जाने वाले ज़्यादातर AI use cases में conversational chatbot सही tool नहीं है, और आखिरकार अनुभव झुंझलाहट भरा ही बनता है।
    जब Copilot असल में एक बहुत स्मार्ट IntelliSense था, तब वह बेहतरीन था। अब जैसे prompt सोचकर टाइप करना पड़ता है, वह आसपास के code को context बनाकर खाली जगह भर देने वाले तरीके से बेहतर कैसे है, यह समझ नहीं आता। अच्छी तरह integrated tool हमेशा ऊपर से जोड़े गए chatbot से बेहतर होता है, और translation में भी Firefox की तरह text या page को सीधे translate करने का button है, लेकिन नए LLM में chatbot से कहलवाना पड़ता है, तो यह उलटा पीछे जाना लगता है।
    यह समझ आता है कि AI कंपनियाँ एक ही tool बनाकर सबको बेचना चाहती हैं, लेकिन आखिर में वे Swiss Army knife बना रही हैं। उससे बहुत कुछ किया जा सकता है, पर screw कसने में वह अच्छे screwdriver को नहीं हरा सकता। गैर-निर्णायक tool को text box से सेट मत कराइए; असली tool बनाने होंगे, तभी झुंझलाहट कम होगी

    • कई AI कंपनियाँ पहले से ही specific task के लिए dedicated model train करके जारी कर रही हैं।
      मैं ज़्यादातर Mistral इस्तेमाल करता हूँ; Codestral बातचीत में बहुत खराब है, लेकिन “जादुई autocomplete” में सबसे अच्छा है, और commit log लिखने जैसे one-shot prompt+context generation में भी अच्छा है। Document.AI बातचीत के लिए लगभग बेकार है, लेकिन OCR replacement या document semantic indexing pipeline में जोड़ो तो काफ़ी अच्छा है।
      इसलिए कमी model में कम और interface में ज़्यादा लगती है। उदाहरण के लिए, command-line interaction के लिए trained model के साथ कोई zsh/bash fork या wrapper हो तो अच्छा होगा। git commit --fixup=... की जगह अगर मैं कहूँ, “पूरा नाम ठीक करने वाले commit को fixup कर दो”, “ffmpeg से some.mov को बिना audio के mp4 में बदल दो, लेकिन quality और aspect ratio बनाए रखना”, और वह उसे command में बदलकर दिखाए, फिर allow/deny/allowlist/blocklist तय करने के बाद चलाए—तो यही सही होगा।
      translation, mail draft, document reading भी ऐसे ही बातचीत नहीं बल्कि button, shortcut, tab completion की तरह काम करने चाहिए। IDE में जो कंपनी इसे सही तरह सुलझाएगी, वही AI coding tool competition जीतेगी, और Zed का “git conflict found, resolve with AI” button, भले ही उसने conversation thread खोला, फिर भी सही दिशा में एक कदम लगता है
    • मैंने Copilot autocomplete सिर्फ C# में इस्तेमाल किया है, और वह IntelliSense तो छोड़िए, कल्पना की जा सकने वाली सबसे basic autocomplete algorithm से भी खराब था, इसलिए एक दिन में बंद कर दिया
    • मैंने non-conversational tool बनाया है, लेकिन सच कहूँ तो उसे बेचना मुश्किल है। लोग default रूप से conversational interface ही सोचते हैं, और ग्राहक भी असल में उन्हीं तक सीमित रहते हैं जिन्होंने सचमुच यह समस्या झेली हो। ज़्यादातर लोगों को अभी बातचीत वाले समझौते से खास दिक्कत महसूस नहीं होती लगती
    • chatbot टूटी हुई user experience पर लगाया गया अस्थायी पैबंद है। मैं कुछ समय से कंपनी में यह समझाने की कोशिश कर रहा हूँ, लेकिन सब लोग माहौल के नशे में हैं। अच्छा UX गहरी सोच और creativity माँगता है, लेकिन chatbot चिपकाना नहीं
    • गंभीरता से vibe coding एक बार करके देखना चाहिए। अब यह उस समय से बिल्कुल अलग स्तर पर है जब यह शब्द नया-नया आया था, और बहुत बेहतर हो चुका है।
      मैं editor के बिना, agent और web पर सिर्फ PR review के सहारे भी बहुत काम कर लेता हूँ, और ज़रूरत पड़ने पर ही कभी-कभी code . खोलता हूँ। किसी हल्के personal project पर इसे खेल की तरह सीखो, तो समय के साथ यह कम झुंझलाहट भरा लगता है। कुछ-कुछ ski या bowling सीखने जैसा है

  • model को गाली देने से उसे दोबारा सोचने और गलती सुधारने में काफ़ी असर दिखा। Codex, Claude, Qwen, Gemma/Gemini—सबमें कुछ ऐसा ही देखा।
    पता नहीं model इसे “ज़्यादा सख़्ती से ध्यान देना है” वाले signal की तरह लेता है, या provider उपयोगकर्ता की हताशा पहचानकर उसे और स्मार्ट model की तरफ route करता है। जब वही गलती बार-बार दोहराई जाती थी, तब गाली देने पर वह अक्सर अटकी हुई स्थिति से निकलकर सही रास्ते पर आ जाता था, या फिर शायद यह सिर्फ catharsis हो

    • यह research याद आती है: https://arxiv.org/pdf/2510.04950
      इसमें दिखाया गया है कि “rudeness” या “very rude” accuracy बढ़ा सकती है; थोड़ा अजीब है, लेकिन पढ़ने में मज़ेदार है। पेज 3 के ऊपर table 1 के prompts खास तौर पर शानदार हैं, और लगता है paper में शामिल न किए गए कुछ और prompts भी ज़रूर test किए गए होंगे
    • मैं ऐसी आदत नहीं डालना चाहता जो LLM से बाहर दूसरी interactions में भी फैल जाए
    • मुझे भी कुछ ऐसा ही लगता है। पक्का नहीं कह सकता कि यह सच में मदद करता है, लेकिन Opus ऐसी स्थितियों में जहाँ शांत समझाने से वह कभी सही नहीं करता, गाली देने पर अचानक हल निकाल देता है—ऐसा लगभग रोज़ होता है।
      कल भी Opus किसी field के न होने का दोष API पर डालता रहा, और JSON व logs दिखाने पर भी “शायद यह अस्थायी समस्या रही होगी” दोहराता रहा। गुस्से में मैंने एक ही वाक्य में खूब गालियाँ भर दीं, और अगला समाधान सही निकला; उससे पहले वह लगभग 10 बार वैसी ही गलती कर चुका था। ऐसे मामले अब कम होते जा रहे हैं, लेकिन यह वैसे भी वह स्थिति थी जहाँ मुझे खुद ही करना चाहिए था, और शुरू करने से पहले यह पता नहीं चलता कि model कितना बेकार कारण पकड़कर अड़ा रहेगा। /clear किए हुए Opus 4.7 xhigh 10 लाख context में लगभग 11 prompts के बाद जवाब मिला
    • leaked source code में यह सामने आने के बाद कि गालियों को किसी खास behavior trigger की तरह इस्तेमाल किया जाता है, अब जब reasoning की कमी या hallucination दिखती है तो मैं जानबूझकर गाली देता हूँ। बाद में यह analyze करना भी आसान हो जाता है कि यह कितनी बार हुआ, क्योंकि grep करना आसान रहता है
    • यह असल में Linus Torvalds तरीका है। शायद FOSS से सीखने लायक बात है

  • LLM का conversational स्वभाव लोगों को गैर-उत्पादक बातचीत वाले रास्तों पर खींच ले जाता है।
    “X मत करो” उतना ही उपयोगी है जितना रोते हुए बच्चे से कहना कि मत रोओ। जैसे बच्चा रोता है तो हम स्वाभाविक रूप से समझते हैं कि उसे खाना, diaper जैसी किसी असुविधा का हल चाहिए, वैसे ही LLM के fail होने पर मैं उसे code की architecture और structure में समस्या का संकेत मानता हूँ।
    अनुभवी developer आम तौर पर DRY या KISS तोड़ने वाले patterns देखकर encapsulation structure बनाकर समस्या सुलझा सकता है। LLM द्वारा बनाए गए code में भी परिणाम बेहतर करने के लिए उसी तरह के refactoring की ज़रूरत होती है, और code generation के बीच-बीच में बस “इसे साफ़ तरीके से refactor करो” कह देने से maintainability काफ़ी बेहतर हो जाती है

  • इस विषय के psychological और social effects को ज़्यादा गहराई से देखने वाला एक पुराना लेख भी है: https://medium.com/@livestock.dev/we-were-promised-liberatio...

  • समस्या इंसान जैसा व्यवहार करने में नहीं, बल्कि अप्रत्याशित तरीके से व्यवहार करने में है। यह परेशान करने वाली बात है कि यह तय ही नहीं किया जा सकता कि किस दायरे की उम्मीद की जाए।
    इससे भी बड़ी समस्या यह है कि हताशा तनाव पैदा करती है, सेहत के लिए खराब होती है, और शत्रुतापूर्ण कार्य-परिवेश बनाती है। मैं इस बात से सहमत हूँ कि AI टूल्स दर्द से ज़्यादा मदद दे सकते हैं, लेकिन मैं ऐसे दर्दनाक और शत्रुतापूर्ण कार्य-परिवेश में काम नहीं करना चाहता। मेरी सेहत और गरिमा कोई मोलभाव की चीज़ नहीं हैं, चाहे इसके कारण मुझे बहुत-सी नौकरियाँ छोड़नी पड़ें।
    यही कारण है कि मैं Windows पर काम नहीं करता। उससे भी कई मौके कम हो जाते हैं, लेकिन मैं अपनी गरिमा और मानसिक संतुलन बचाने का विकल्प चुनूँगा

    • शायद Windows इस्तेमाल करते समय ऐसा सिर्फ़ मेरे साथ नहीं होता। Windows अजीब है, और उसे इस्तेमाल शुरू करते ही हाथ जल्दी अकड़ जाते हैं और गुस्सा आने लगता है।
      LLM भी अभी मेरे लिए इस्तेमाल लायक स्तर पर नहीं है। मुझे जिस चीज़ की ज़रूरत है वह ऐसा LLM है जो कहे, “रुको, लगता है अभी तुम कुछ ग़लत कर रहे हो, ज़रा समझाओ कि क्या करने की कोशिश कर रहे हो,” लेकिन मौजूदा पीढ़ी के LLM ऐसे लगते हैं मानो मुझे गुस्सा दिलाने के लिए डिज़ाइन किए गए हों
    • अगर इसे बातचीत की तरह न देखकर, सभी संभावित दुनियाओं की पूरी इंटरनेट बातचीत के रूप में देखें, तो इसे पूर्वानुमेय भी कहा जा सकता है। हर Stack Overflow पोस्ट, हर GitHub issue मौजूद है, और मेरा जवाब व बोलने का अंदाज़ उन अनेक दुनियाओं में से एक चुनने जैसा है।
      अगर मैं गुरु की तरह व्यवहार करूँ तो मॉडल शिष्य की तरह व्यवहार करता है, और अगर मैं शिष्य की तरह व्यवहार करूँ तो मॉडल सिखाने लगता है। इसलिए लक्ष्य यह है कि इस बातचीत को तर्क और भाषा से लड़ने वाले विशेषज्ञों की भाषा की ओर खींचा जाए। ऐसा लगता है कि academic prompt जीतता है
    • मुझे नहीं पता कि इंसान जैसा व्यवहार और अप्रत्याशितता को पूरी तरह अलग किया जा सकता है या नहीं
    • यह कहना कि Windows इस्तेमाल करना किसी की “गरिमा” से नीचे है, बेहद विशेषाधिकारपूर्ण रवैया है। ज़रा सोचिए कि वास्तविक दुनिया में लोग किस तरह का काम करते हैं।
      बस कल्पना कीजिए कि बच्चों की देखभाल करने वाला कोई childcare worker या खाना ढोने वाला कोई truck driver यह कहे कि “हताशा तनाव पैदा करती है और शत्रुतापूर्ण कार्य-परिवेश बनाती है, इसलिए सेहत के लिए खराब है”

  • जो समस्या मैं हमेशा देखता हूँ, वह यह है कि AI किसी सुझाव के बाद reasoning loop से गुजरकर ठीक-ठीक ग़लत निष्कर्ष पर पहुँचता है, और फिर उसी निष्कर्ष के हिसाब से समाधान tokens की बाढ़ की तरह उगल देता है।
    काश, इसकी जगह यह ज़्यादा बार कहे, “मुझे ठीक से समझ नहीं आ रहा कि आपका मतलब क्या है, कृपया इस हिस्से को स्पष्ट करें।” ऐसा लगता है कि इसके पास अपनी ही निश्चितता को नियंत्रित करने के लिए कोई confidence slider होना चाहिए

    • “अपने निष्कर्ष के हिसाब से समाधान बना लेना” वाली समस्या को मैं कड़े context engineering से हल कर रहा हूँ। skills, MCP, और सबसे बढ़कर context window switching इसमें मुख्य हैं।
      उदाहरण के लिए, TDD में अगर उसी मॉडल से test और code दोनों लिखवाओ, तो वह लगभग हमेशा पहले समाधान तय कर लेता है, फिर अनमने ढंग से उसके हिसाब से test लिखता है। इसलिए मैं sub-agent इस्तेमाल करने का निर्देश देता हूँ, लेकिन agent और sub-agent के बीच कौन-सा context पास हो रहा है, यह समझने के लिए टूल्स बहुत कमज़ोर हैं।
      जो तरीका अच्छा चला, वह यह है कि एक thread सिर्फ़ test लिखे। उसे code पढ़ने न दिया जाए, और सिर्फ़ test directory या उसका कुछ हिस्सा ही पढ़ने दिया जाए। फिर दूसरे नए context वाला thread test चलाकर failure की पुष्टि करे, और जैसे ही test pass हो, implementation रोक दे तथा test बदलने न दे। फिर एक और नया context सख़्त refactoring skill के अनुसार refactor करे। काम बहुत है, और विडंबना यह है कि agent द्वारा लिखी गई skills भी काफ़ी खराब हैं, इसलिए हाथ से बहुत काम करना पड़ता है, लेकिन इनाम उम्मीद के लायक है

  • मुझे लगता है UX की समस्या कहीं और है। बहुत-से users शायद यह नहीं जानते कि agent की context window सीमित होती है, और उसे अनंत जैसा दिखाने के लिए लगातार समझदारी भरा compression होता रहता है। लेकिन इसका मतलब यह भी है कि agent को कुछ न कुछ तो भूलना ही पड़ेगा।
    नतीजा यह होता है कि users उसी coding session या chat session को बार-बार इस्तेमाल करते रहते हैं। अगर काम असंबंधित हो, तो नया शुरू करना बेहतर है

    • मुझे नहीं लगता कि यह context की समस्या है। Claude Opus 4.7 का context पहले से बहुत बड़ा है, लेकिन मेरे अनुभव में instructions follow करना सबसे खराब है, और बहुत छोटे preference prompts को भी वह पहले या दूसरे message में ही पूरी तरह नज़रअंदाज़ कर देता है। message कुछ शब्दों का ही क्यों न हो, इसलिए मुझे यह पूरी तरह training problem लगता है
    • मुझे नहीं लगता कि लेखक इतना भोला होगा कि उसे यह तक पता न हो।
      मैं आमतौर पर 3 लाख tokens से कम वाले session, Opus 4.7 xhigh के साथ काम करता हूँ, और ऐसा लगता है कि world model में कहीं छेद हैं या कुछ हिस्सों पर बहुत मज़बूत conditioning लगी हुई है, जो system prompt में नियमों को कितना भी मज़बूती और स्पष्टता से लिखो, फिर भी रिस जाती है। नया session हो तब भी अगर वह ऐसे बिंदु से टकरा जाए, तो उससे निकलना मुश्किल किसी चक्रीय अवस्था में फँस जाता है, और थोड़ी गाली-गलौज कुछ मदद करती है
    • लेखक और इस thread के पाठक शायद context window की सीमाएँ समझते हैं, फिर भी निराश हैं

  • LLM के साथ काम करना communication skill बढ़ाने के लिए अच्छा है। असरदार तरीके से संवाद करना सबसे कठिन skills में से एक है, और इंसान जो लगभग हर काम करता है उसमें यह शामिल है।
    सिद्धांततः, मुझे लगता है कि बेवकूफ़ LLM को दोष देने के बजाय इसे अपनी तरफ़ की communication failure मानना बेहतर है। क्योंकि असल में कुछ बदल सकने वाला पक्ष मैं ही हूँ। इसलिए मैं नहीं मानता कि यह AI को इंसान जैसा व्यवहार करना चाहिए या नहीं जैसी औपचारिक समस्या है

    • सहकर्मियों को “agentic” coding सीखते देखते हुए यह बात मुझे सबसे ज़्यादा फिर से समझ आई। बहुत-से लोग तुरंत “बस इसे ठीक करो” या “यह टूटा क्यों है” जैसे स्तर पर गिर जाते हैं।
      कहा जाता है कि agents को अस्पष्ट या द्विअर्थी syntax और खराब structure के बावजूद बेहतर काम करने के लिए train किया गया है, लेकिन अगर आप साफ़, संरचित अंग्रेज़ी में बात करें और काम की पर्याप्त पृष्ठभूमि दें, तो quality में साफ़ फ़र्क दिखता है। मेरे लिए यह स्वाभाविक है क्योंकि मुझे लिखना और समझाना पसंद है, लेकिन कुछ लोगों के लिए यह लगभग पार न की जा सकने वाली बाधा जैसा लगा। मुझे लगता है कि यह communication और writing skill software “engineering” के बदलते दौर में संसाधन रखने वालों और न रखने वालों को अलग करने वाला बड़ा कारक बनने वाला है
    • लेखक के रूप में, मैं निश्चित रूप से इस बात से सहमत हूँ कि अच्छे नतीजे पाने के लिए अच्छी तरह संवाद करना ज़रूरी है। लेकिन पूरी तरह स्पष्ट संवाद करने पर भी यह गारंटी नहीं होती कि LLM निर्देशों के अनुसार, या मेरी कल्पना के अनुसार, व्यवहार करेगा। निराशा अक्सर तब आती है जब मैंने बात बहुत साफ़ कही होती है, फिर भी agent किसी और दिशा में चला जाता है।
      और coding agent की कुछ उपयोगिता इस बात में भी है कि आपको हर चीज़ को पूरी तरह विस्तार से बताना न पड़े। अगर मुझे हर implementation detail LLM को देनी ही पड़े, तो मैं सीधे खुद code लिख लूँगा। बेशक, मैं “मेरे लिए पैसा कमाने वाला शानदार app बना दो” जैसी उम्मीद नहीं कर रहा, लेकिन missing pieces ढूँढ निकालने लायक कुछ intelligence की उम्मीद तो है
    • LLM एक tool है, यह communication failure की समस्या नहीं है। यह कुछ वैसा ही है जैसे null pointer को bypass या handle करना पड़े और उसे मेरे व software के बीच communication failure कह दिया जाए
    • और सटीक रूप से कहें तो यह बाहरी context को कुशलतापूर्वक पहुँचाने की समस्या है। चार चीज़ें AI का अच्छा इस्तेमाल करने में बाधा बनती हैं: धीमी typing, ज़रूरत से ज़्यादा छोटे और अस्पष्ट “वह/यह/उस” जैसे संकेत, यह मान लेना कि सामने वाला आपकी वास्तविकता और दिमाग़ का context साझा करता है, और सक्षम व्यक्ति को भी delegation देने में आने वाली मनोवैज्ञानिक बाधा

  • मेरे पास अब भी जो कौशल है और जिसे LLM अभी तक बदल नहीं पाया है, वह है अच्छे सवाल पूछने की क्षमता
    यानी मूल सवाल को फिर से अपने शब्दों में कहकर यह पक्का करना कि मेरी समझ सही है, सामने वाला कहाँ से शुरू कर रहा है यह समझने तक पर्याप्त "क्यों" पूछना, और ऐसी open-ended questions पूछना जो insight पैदा करें। LLM अक्सर सवाल की पृष्ठभूमि का गलत अनुमान लगा लेता है, फिर उसी अनुमान के आधार पर जवाब देता है, और अपने बनाए हुए पूर्वधारणा को छोड़ नहीं पाता

    • बिना lead किए सवाल पूछना एक कौशल है। कभी-कभी मन करता है कि AI से किसी सवाल या यूँ ही गुजरते-गुजरते किसी बात का ज़िक्र कर दूँ, लेकिन मैं रुक जाता हूँ क्योंकि मुझे पता है कि वह उसी से चिपक जाएगा और और भी बेवकूफ हो जाएगा
      आम तौर पर मैं नहीं चाहता कि AI मुझसे सवाल पूछे। क्योंकि जो बातें मैंने स्पष्ट नहीं की हैं, उनके बारे में मैं चाहता हूँ कि वह उचित अनुमान लगाए; अगर मैं उन्हें स्पष्ट करना चाहता, तो मैं खुद कर देता। इसलिए कभी-कभी मैं सीधे कह देता हूँ कि सवाल मत पूछो और जो हिस्से कम निर्दिष्ट हैं उनके बारे में उचित assumptions बना लो। लेकिन जब मुझे clarification questions चाहिए होते हैं, तो मैं ऐसा कह सकता हूँ। अगर आप ऐसा तरीका पसंद करते हैं, तो उसे prompt में डाल सकते हैं, या pi जैसे flexible coding tool में ऐसा skill या extension बनवा सकते हैं जो उसे उस तरह की exploratory दिशा में धकेले

  • हम tools बनाने के बजाय services बना रहे हैं। यह सिर्फ AI तक सीमित नहीं है, हर जगह ऐसा हो रहा है
    tools किसी समस्या को एक ही बार में पूरी तरह हल नहीं करते, लेकिन वे आपको छोटे-छोटे steps में आगे बढ़ने देते हैं, और वे steps अनुमानयोग्य और consistent होते हैं। services समस्या को एक ही बार में हल करने की कोशिश करती हैं, लेकिन उनका समाधान तभी अच्छा होता है जब user पहले से तय pattern में फिट बैठता हो। अगर ऐसा न हो, तो वे बेकार हो जाती हैं, और उन्हें जोड़कर अपनी ज़रूरत तक पहुँचने के लिए कोई छोटे steps भी नहीं होते। tools इस्तेमाल करने में आनंद देते हैं

    • इसलिए जब भी कोई कहता है कि “AI एक tool है”, तो मन करता है कि बीच में बोलूँ, “तकनीकी रूप से…”। क्योंकि वास्तव में इसका इस्तेमाल tool की तरह नहीं होता
      tool मेरा extension होता है, मेरी इच्छा के अनुसार नई क्षमताओं को मेरी पहुँच में रखता है, और शरीर के हिस्से की तरह चलता और इस्तेमाल होता है। दूसरी ओर, service वह चीज़ है जिसमें आप किसी काम के लिए कहते हैं और वह आपको तैयार नतीजा लौटा देती है