- Claude या Codex जैसे LLM के साथ लंबे समय तक सहयोग करने पर थकान जमा होती जाती है और उत्पादकता तेज़ी से गिरती है
- थकान के कारण prompt की गुणवत्ता में गिरावट परिणामों की गुणवत्ता को खराब करती है, और बीच में मॉडल को रोकने या सुधारने से प्रदर्शन और बिगड़ता है
- धीमे feedback loop और context के अत्यधिक बड़े हो जाने की समस्या दोहराए जाने वाले experiments को कठिन बना देती है, जिससे काम की दक्षता घटती है
- प्रभावी तरीका है prompt लिखने का आनंद और लक्ष्य की स्पष्ट समझ बनाए रखना, और धीमे loop को ही समस्या के रूप में परिभाषित करके उसे सुधारना
- LLM उपयोग का मूल है तेज़ feedback और स्पष्ट success criteria तय करना, जिससे debugging समय घटता है और अधिक समझदार नतीजे मिलते हैं
थकान और धीमी प्रयोग गति
- मानसिक थकान बढ़ने पर prompt की गुणवत्ता गिरती है, और उसके परिणामस्वरूप LLM के जवाबों की गुणवत्ता भी कम हो जाती है
- थकी हुई स्थिति में मुख्य context छोड़े हुए prompt भेज दिया जाता है, और बाद में बार-बार सुधार या रोकने से परिणाम और खराब हो जाते हैं
- Claude Code या Codex में इस तरह का ‘बीच में हस्तक्षेप’ स्थिरता तोड़ देता है और और भी खराब परिणाम देता है
- feedback loop की गति में गिरावट को एक समस्या माना गया है
- बड़े file parsing जैसे समय लेने वाले कामों में हर बार दोबारा चलाना धीमा होता है, इसलिए experiment cycle लंबा हो जाता है
- जब context लगभग भर जाता है, तो मॉडल ‘सुस्त’ पड़ जाता है या हाल के experiments को ठीक से reflect नहीं कर पाता
AI के साथ प्रभावी सहयोग का रास्ता
- खराब prompt से पैदा होने वाले दुष्चक्र (‘doom-loop psychosis’) से बचना चाहिए
- अगर prompt लिखना आनंददायक नहीं लग रहा हो, या बार-बार छोटे और बिना सोच-विचार वाले inputs दिए जा रहे हों, तो आराम की ज़रूरत है
- समस्या पर पर्याप्त सोच के बिना यह उम्मीद करना कि AI सारी कमी पूरी कर देगा, एक खतरनाक जाल है
- स्पष्ट लक्ष्य और भरोसे के साथ लिखे गए prompt सफलता की कुंजी हैं
- जिस परिणाम को आप चाहते हैं, उसे ठोस रूप से सोचकर लिखा गया prompt उच्च-गुणवत्ता वाले जवाबों तक ले जाता है
- इसके उलट, अनिश्चितता या अधीरता में लिखा गया prompt संतोषजनक परिणाम नहीं देता
धीमे feedback loop को समस्या के रूप में परिभाषित करना
- feedback loop की गति को ही सुधार का लक्ष्य बनाना चाहिए
- उदाहरण के लिए, parsing समस्या पर काम करते समय loop time को 5 मिनट से कम करने का लक्ष्य स्पष्ट रूप से तय करें, और failure case को जल्दी reproduce करने के लिए कहें
- यह test-driven development (TDD) जैसी पद्धति है, जो दोहराए जाने वाले experiments की रफ्तार बढ़ाती है
- स्पष्ट success criteria देना LLM की दक्षता को अधिकतम करता है
- “5 मिनट के भीतर failure case reproduce करो” जैसी ठोस शर्त देने पर, LLM code path को optimize करता है और अनावश्यक हिस्सों को हटाता है
- इस तरह तेज़ feedback loop सुनिश्चित होने पर context की खपत घटती है और मॉडल अधिक ‘स्मार्ट’ तरीके से काम करता है
निष्कर्ष
- LLM के साथ काम करते समय होने वाली थकान अक्सर तकनीकी समस्या नहीं बल्कि ‘skill issue’ हो सकती है
- संज्ञानात्मक थकान और requirements का बाहरीकरण (cognitive outsourcing) उत्पादकता घटाने वाले जाल हैं
- prompt लिखने की प्रक्रिया आनंददायक हो, और परिणाम से 95% से अधिक संतुष्ट होने का भरोसा हो, तभी उसे जारी रखना बेहतर है
- अगर धीमी प्रगति और context overload महसूस हो, तो उसे ही समाधान योग्य समस्या मानकर LLM के साथ और तेज़ iteration structure तैयार करना चाहिए
अभी कोई टिप्पणी नहीं है.