यह लेख vibe coding के दौरान बनने वाली overfocus (tunnel) स्थिति को खुद पहचानने और छोटे execution-loop के जरिए फिर से intentional focus में लौटने के लिए एक practical protocol प्रस्तावित करता है.[1]
फोकस vs overfocus (tunnel)
- फोकस को ऐसी स्थिति के रूप में परिभाषित किया गया है जिसमें तीनों axis एक साथ सक्रिय हों: sense of control (यह महसूस होना कि मैं flow को संभाल रहा हूँ), recovery (काम खत्म होने के बाद भी फिर से शुरू करने की ऊर्जा बची हो), rhythm/feedback (स्पष्ट लक्ष्य और तुरंत feedback के कारण action→check का सिलसिला न टूटे).[1]
- overfocus (tunnel) वह स्थिति है जिसमें sense of control घट जाता है, recovery नहीं बचती, rhythm टूट जाती है और action→check loop रुक जाता है; समय तो बहुत निकल जाता है, लेकिन ऊर्जा उलटे कम हो जाती है.[1]
tunnel self-checklist
लेख का सुझाव है कि नीचे के सवालों में 2 या उससे अधिक का जवाब ‘नहीं’ हो, तो tunnel में होने की संभावना अधिक है.[1]
- क्या काम करते समय आप तुरंत अपनी शारीरिक स्थिति adjust कर सकते हैं (उठना/एक गिलास पानी पीना)?
- क्या खत्म होने के बाद clarity से ज्यादा exhaustion या regret बचता है?
- क्या आप तय की गई upper limit का पालन कर रहे हैं?
- क्या आप “अभी करने वाला एक काम / तुरंत जाँचने वाली एक चीज़ / अटकने पर अगला एक विकल्प” के बिना सिर्फ जवाब ही पढ़ते जा रहे हैं?
- क्या आप एक वाक्य में बता सकते हैं कि अभी आप क्या सीख रहे हैं?[1]
tunnel बनाने वाले 4 पैटर्न
लेख में overfocus को बार-बार दोहराने वाले चार typical patterns बताए गए हैं, और हर एक के लिए तुरंत corrective action तथा बचाकर रखने वाला output जोड़ा गया है.[1]
- अनंत खोज: जब आप सिर्फ “क्या इससे बेहतर तरीका हो सकता है?” खोजते रहते हैं → विकल्पों को 2 तक घटाइए, और उनमें से 1 को अभी करने वाले एक काम के रूप में execute कीजिए.[1]
- बातचीत को ही उपलब्धि समझ लेना: जब जवाब पढ़ने का समय ही progress जैसा लगे → जवाब को “अभी करने वाला एक काम / तुरंत जाँचने वाली एक चीज़ / अटकने पर अगला एक विकल्प” इन 3 पंक्तियों में फिर से लिखिए.[1]
- लक्षणों का इलाज: जब आप सिर्फ ऊपर-ऊपर patch लगाते रहें → failure को दोबारा reproduce किए जा सकने वाले ‘artifact’ में बदलिए, और एक hypothesis को minimal change के साथ verify कीजिए.[1]
- निर्णय से बचना: जब आप चुनाव टालते हुए सिर्फ options जोड़ते जाएँ → “आगे बढ़ने के 3 criteria + आगे बढ़ते समय पहली 1 action” तय कीजिए, और निर्धारित upper limit के भीतर उसे बंद कीजिए.[1]
5-step escape protocol
मुख्य विचार यह है कि direction को willpower से नहीं बल्कि situation→action rules के जरिए बदला जाए, और इसे 3 पंक्तियों में समेटा गया है: “signal पकड़ो → state adjust करो → अभी करने वाले एक काम से फिर शुरू करो”.[1]
- शुरू करने से पहले घोषणा: आज का लक्ष्य (completion criteria), दिखाई देने वाला output, और रुकने का मानदंड पहले से लिख लीजिए.[1]
- loop unit: समय को सिर्फ टुकड़ों में बाँटने के बजाय “अभी करने वाला एक काम → सिर्फ ज़रूरी minimum जानकारी पूछना → तुरंत execute करना → तुरंत check करना → फिर से अभी करने वाला एक काम” वाले event loop में चलिए.[1]
- tunnel signal पर state adjust करना: अगर लगातार 3 बार सिर्फ सवाल ही पूछे गए हों, तो पानी का एक गिलास → 3-line summary → अभी करने वाला एक काम; अगर वही failure 2 बार आए, तो 1 clue ढूँढना → hypothesis बदलना → minimal change; अगर एक वाक्य में समझाना मुश्किल हो, तो “मैं अभी क्या कर रहा हूँ” एक वाक्य में लिखना.[1]
- recovery block reserve करना: recovery कोई option नहीं बल्कि schedule में पहले से रखा जाने वाला default है, और walking, stretching, पानी पीना, बाहर देखना जैसी बहुत छोटी actions की सिफारिश की गई है.[1]
AI prompt patterns और उदाहरण
लेख का सुझाव है कि AI से conversation की मात्रा नहीं बल्कि loop की quality माँगी जाए, और common output format को “अभी करने वाला एक काम / तुरंत जाँचने वाली एक चीज़ / अटकने पर अगला एक विकल्प” इन 3 पंक्तियों पर fixed रखा जाए.[1]
- Pattern A: goal, observation, constraints, और k/N देकर यह कहें कि “अभी तुरंत किया जा सकने वाला सिर्फ एक काम सुझाइए, जो सीधे तुरंत verification तक जाए”.[1]
- Pattern B: hypothesis, observed clue, constraints, और k/N देकर “सिर्फ एक variable बदलने वाला 1 minimal experiment” माँगिए.[1]
- उदाहरण: जब error सिर्फ किसी खास case में आता हो, तो failure को reproduce किए जा सकने वाले test में बदलिए, फिर Pattern A से अभी करने वाला काम + एक check लीजिए; उसके बाद execute करना, clue नोट करना, और Pattern B से minimal experiment चलाकर hypothesis तय करने का flow दिखाया गया है.[1]
मूल लेख के अंत में लेखक overfocus को grit की समस्या नहीं बल्कि operating system की समस्या मानते हैं, और निष्कर्ष देते हैं कि इस protocol से जैसे ही आप फिर से steering wheel अपने हाथ में लेते हैं, focus सुरक्षित हो जाता है.[1]
अभी कोई टिप्पणी नहीं है.