प्लान मोड मर चुका है
जैसे-जैसे Claude और Codex जैसे AI coding assistants बेहतर होते जा रहे हैं, कई उपयोगकर्ता तर्क देते हैं कि एक अलग “plan mode” — जहाँ model कोड संपादित करने से पहले कदमों की रूपरेखा बनाता है — अब अनावश्यक हो गया है, क्योंकि नए models को conversational रूप से पहले प्लान करने और फिर कार्य करने के लिए कहा जा सकता है। दूसरे लोग explicit planning phases का ज़ोरदार बचाव करते हैं, उन्हें आवश्यक guardrails मानते हैं: वे design assumptions सामने लाते हैं, humans को इस बात के साथ aligned रखते हैं कि agent क्या बदलेगा, audit trail प्रदान करते हैं, और costly या dangerous edits (जैसे schemas या production databases) के जोखिम को कम करते हैं। दोनों दृष्टिकोणों में, जटिल या high-blast-radius काम के लिए planning को अत्यंत महत्वपूर्ण मानने पर व्यापक सहमति है; असली बहस यह है कि इसे एक dedicated mode में रखा जाए या prompts, spec files, और multi-agent review वाले अधिक flexible workflows का हिस्सा बनाया जाए.
प्लान मोड की भूमिका और मूल्य
- कई डेवलपर अभी भी प्लान मोड पर एक अलग “कार्रवाई से पहले विराम” चरण के रूप में निर्भर करते हैं:
- मॉडल को कोड को छूने से पहले संदर्भ इकट्ठा करने और बदलावों की रूपरेखा बनाने के लिए मजबूर करता है।
- इंसानों को महंगे या जोखिमपूर्ण संपादनों से पहले आर्किटेक्चरल निर्णयों, जोखिमों, और ट्रेडऑफ्स का पूर्वावलोकन करने देता है।
- उच्च-ब्लास्ट-रेडियस काम (auth, payments, schemas, prod DBs, जटिल refactors) के लिए ड्राई रन या “audit checkpoint” के रूप में काम करता है।
- कुछ लोग प्लान मोड का उपयोग स्पेक्स को क्रमिक रूप से मज़बूत करने के लिए करते हैं: जब तक सवाल खत्म न हों, तब तक फिर से चलाएँ, फिर निष्पादित करें।
- अन्य लोग प्लान्स को स्थायी आर्टिफैक्ट्स (plan.md, spec directories, AGENTS.md) मानते हैं जिन्हें version किया जा सकता है, कई agents द्वारा review किया जा सकता है, और sessions/models के बीच पुन: उपयोग किया जा सकता है।
तर्क कि प्लान मोड पुराना या ज़रूरत से ज़्यादा है
- कई उपयोगकर्ता कहते हैं कि नए models (जैसे recent Claude/Fable/Opus, कुछ GPT/Gemini setups) “बस समझ जाते हैं”:
- सामान्य मोड में “पहले प्लान करो, अभी कोड मत लिखो” जैसी साधारण निर्देश उनके लिए भरोसेमंद रूप से काम करती है।
- लंबा, generated planning prose review करने में कठिन और उस तरीके से असंगत माना जाता है जिससे इंसान वास्तव में समझ बनाते हैं।
- कुछ का दावा है कि मूल ज़रूरत—“loose cannon” agents को रोकना—instruction-following के सुधरने के साथ कम हो गई है।
- चिंता है कि built-in plan modes सिर्फ harness prompts हैं, true sandboxes या permission systems नहीं, और अनुपातिक लाभ के बिना लागत और latency बढ़ा सकते हैं।
वैकल्पिक वर्कफ़्लो और टूल्स
- सामान्य विकल्प:
- स्पष्ट “अभी कोई edit नहीं” के साथ conversational planning।
- agents द्वारा बनाए रखे गए dedicated plan documents, implementation के लिए fresh sessions के साथ।
- multi-agent setups: एक model plan करता है, दूसरे implement करते हैं, दूसरे review करते हैं (कभी-कभी plannotators, “grill me” skills, या MCP servers जैसे अलग tools के माध्यम से)।
- spec-driven या blueprint workflows जहाँ इंसान specs लिखते या कड़ाई से curate करते हैं और agents gaps भरते हैं।
नियंत्रण, सुरक्षा, और गुणवत्ता संबंधी चिंताएँ
- अनचाहे edits को लेकर तेज़ चिंता, खासकर databases और बड़े codebases पर; कुछ लोग स्पष्ट read-only या sandbox modes चाहते हैं।
- डर कि structured planning के बिना “vibe coding” tech debt को तेज़ी से बढ़ाता है और डेवलपर्स की अपने systems की समझ को कमजोर करता है।
- प्रत्युत्तर: भले ही समझ पीछे रहे, agents बाद में AI-लिखे code को explain, diagram, और refactor कर सकते हैं, जिससे emphasis manual ownership से हटकर verification और oversight पर आ जाता है।
समग्र भावना
- इस बात पर व्यापक सहमति है कि planning आवश्यक है।
- इस पर विभाजित राय है कि क्या एक dedicated “plan mode” UI/mechanism अभी भी इसे हासिल करने का सबसे अच्छा तरीका है।