एकल प्रॉम्प्ट बनाम एजेंट वर्कफ़्लो: कैसे चुनें

आप किसके बीच चयन कर रहे हैं

एकल प्रॉम्प्ट वह बड़ी निर्देशिका है जो आप मॉडल को देते हैं, और एक ही बार में पूरा आउटपुट मांगते हैं। आप लक्ष्य, प्रतिबंध और फ़ॉर्मेट बताते हैं और उम्मीद करते हैं कि परिणाम पूरा होगा: प्लान, कोड, कॉपी या कोई समाधान।

एक वर्कफ़्लो (अक्सर एजेंट वर्कफ़्लो कहा जाता है) वही काम छोटे-छोटे कदमों में बांट देता है। एक कदम योजना बनाता है, दूसरा कोड लिखता है, तीसरा चेक करता है, और चौथा रीफ़ैक्टर या समस्याएँ ठीक करता है। काम अभी भी AI द्वारा होता है, लेकिन इसे चरणबद्ध किया जाता है ताकि आप चलते-चलते समीक्षा और मार्गदर्शन कर सकें।

असल निर्णय "बेहतर AI" के बारे में नहीं है। यह उस ट्रेडऑफ़ के बारे में है जो आप गति, विश्वसनीयता और नियंत्रण के बीच चाहते हैं।

एक वन-शॉट प्रॉम्प्ट आम तौर पर सबसे तेज़ होता है। यह तब अच्छा फिट होता है जब आप परिणाम को जल्दी जज कर सकते हैं और थोड़ा गलत होना महंगा नहीं है। अगर यह कुछ छुटा दे, तो आप बेहतर प्रॉम्प्ट के साथ फिर चलाते हैं।

एक चरणबद्ध वर्कफ़्लो प्रति रन धीमा होता है, लेकिन जब गलतियाँ महँगी या नोटिस करना मुश्किल हों तो यह अक्सर जीतता है। काम को चरणों में तोड़ने से गैप पकड़ना, अनुमान पुष्टि करना और आउटपुट को आपके नियमों के अनुरूप रखना आसान होता है।

एक सरल तुलना:

• गति: एक बड़ा प्रॉम्प्ट आम तौर पर सबसे तेज़।
• विश्वसनीयता: स्टेज्ड स्टेप्स साइलेंट एरर्स कम करते हैं।
• नियंत्रण: चेकपॉइंट्स आपको ज़्यादा मौका देते हैं मोड़ने का।
• दोहरापन: वर्कफ़्लो को टीम और कार्यों के बीच फिर से उपयोग करना आसान होता है।

यह बिल्डर्स और टीमों के लिए सबसे महत्वपूर्ण है जो फीचर शिप करते हैं। अगर आप प्रोडक्शन कोड लिख रहे हैं, डेटाबेस बदल रहे हैं, या ऑथ और पेमेंट्स छू रहे हैं, तो वर्कफ़्लो से मिलने वाली अतिरिक्त पुष्टि आम तौर पर इसके लायक होती है।

अगर आप Koder.ai (koder.ai) जैसे vibe-coding प्लेटफ़ॉर्म का उपयोग करते हैं, तो यह विभाजन व्यावहारिक बन जाता है: आप पहले योजना कर सकते हैं, React और Go में परिवर्तन जनरेट कर सकते हैं, और फिर निर्यात या डिप्लॉय करने से पहले फोकस्ड समीक्षा या रीफ़ैक्टर कर सकते हैं।

कब एकल प्रॉम्प्ट अच्छा काम करता है

जब काम छोटा हो, नियम स्पष्ट हों, और आप जल्दी बता सकें कि आउटपुट सही है तो एकल प्रॉम्प्ट सबसे तेज़ विकल्प है।

यह तब चमकता है जब आप एक साफ़ परिणाम चाहते हैं, न कि एक प्रक्रिया। सोचें “किसी छोटे एडिट के साथ सॉलिड ड्राफ्ट,” जहाँ गलतियाँ सस्ती हों।

अच्छे फिट में छोटे लेखन कार्य (एक ईमेल, प्रोडक्ट ब्लर्ब, मीटिंग रीकैप), छोटे आइडिया-जनरेशन काम (नाम के आइडिया, किसी फ़ंक्शन के लिए कुछ टेस्ट केस, FAQ प्रश्न), या टेक्स्ट ट्रांसफ़ॉर्मेशन (राइवाइट, समरी, टोन बदलना) आते हैं। यह उन छोटे कोड स्निपेट्स के लिए भी अच्छा है जिन्हें आप आंखों से जल्दी देख सकते हैं, जैसे regex या छोटा helper फ़ंक्शन।

एक वन-शॉट प्रॉम्प्ट तब भी काम करता है जब आप पूरा संदर्भ पहले से दे सकते हैं: इनपुट, आवश्यक फॉर्मेट, और एक-दो उदाहरण। मॉडल को अनुमान लगाने की ज़रूरत नहीं रहती।

यहाँ यह भी टूटता है और यह अनुमानित है। एक बड़ा निर्देश कुछ अनुमानों को छिपा सकता है: कौन से प्रकार मान्य हैं, एरर्स पर क्या करना है, “सुरक्षित” का क्या मतलब है, और आप क्या "पूरा" मानते हैं। यह एज केस मिस कर सकता है क्योंकि यह एक ही बार में सब कुछ पूरा करने की कोशिश कर रहा है। और जब परिणाम गलत होता है, तो डीबग करना कठिन होता है क्योंकि आप नहीं जानते कि निर्देश का कौन सा हिस्सा गलती कर गया।

आप शायद एकल प्रॉम्प्ट को ओवरलोड कर रहे हैं अगर आप बार-बार “also” और “don’t forget” जोड़ रहे हैं, अगर आउटपुट को केवल पढ़ने से नहीं बल्कि सावधानी से टेस्ट करने की ज़रूरत है, या अगर आप पाते हैं कि आपको दो-तीन बार रीराइट माँगनी पड़ रही है।

एक व्यावहारिक उदाहरण के रूप में, “एक React लॉगिन पेज” के लिए पूछना अक्सर एक प्रॉम्प्ट में ठीक है। पर "validation, rate limiting, accessibility, tests, और rollback plan" वाले लॉगिन पेज के लिए कहा तो यह संकेत है कि आपको अलग स्टेप्स या रोल्स चाहिए।

कब वर्कफ़्लो बेहतर होता है

जब आपको सिर्फ़ उत्तर नहीं चाहिए बल्कि भरोसेमंद काम चाहिए तो वर्कफ़्लो बेहतर विकल्प होता है। अगर टास्क में कई हिस्से चल रहे हों, तो वन-शॉट प्रॉम्प्ट इरादा धुंधला कर सकता है और गलतियाँ अंत तक छुपी रह सकती हैं।

यह तब सबसे मजबूत होता है जब परिणाम को सही, लगातार और समीक्षा योग्य होना ज़रूरी हो। काम को छोटे रोल्स में बाँटने से हर स्टेप में “किया हुआ” का मतलब स्पष्ट होता है, जिससे आप जल्दी ही समस्याएँ पकड़ सकें बजाय कि बाद में सब कुछ फिर से लिखने के।

अलग करने से क्या मिलता है

हर स्टेप का लक्ष्य छोटा होता है, इसलिए AI फोकस कर सकता है। आपको स्कैन करने योग्य चेकपॉइंट भी मिलते हैं।

• Plan: स्कोप, प्रतिबंध, और acceptance criteria तय करें।
• Build: प्लान को पूरा करने वाले सबसे छोटे बदलाव लागू करें।
• Test: क्राइटेरिया के खिलाफ व्यवहार चेक करें, जिसमें एज केस और रिग्रेशन शामिल हों।
• Refactor: व्यवहार बदले बिना नामकरण और संरचना बेहतर करें।

सरल उदाहरण: आप एक ऐप में “टिम में किसी को इनवाइट करना” जोड़ना चाहते हैं। प्लानिंग निर्णय मजबूर करती है (कौन इनवाइट कर सकता है, ईमेल नियम, अगर यूज़र पहले से मौजूद हो तो क्या होगा)। बिल्डिंग उसे लागू करती है। टेस्टिंग परमिशन और फेल्योर केस सत्यापित करती है। रीफ़ैक्टरिंग अगले बदलाव के लिए कोड पढ़ने लायक बनाती है।

ट्रेडऑफ़ (और क्यों यह अक्सर वर्थ होता है)

वर्कफ़्लो में ज़्यादा स्टेप्स होते हैं, पर आम तौर पर कम रीवर्क होता है। आप शुरुआत में थोड़ा ज्यादा समय स्पष्टता और चेकों पर खर्च करते हैं, और बाद में उन बग्स के पीछे भागने में समय बचाते हैं।

प्लानिंग और सुरक्षित चेकपॉइंट्स सपोर्ट करने वाले टूल्स इसे हल्का महसूस कराते हैं। उदाहरण के लिए, Koder.ai में planning mode और snapshots/rollback होते हैं, जो आपको स्टेज में परिवर्तन समीक्षा करने और किसी स्टेप गलत होने पर जल्दी रिकवर करने में मदद करते हैं।

एक सरल निर्णय फ़्रेमवर्क (जटिलता, जोखिम, सत्यापन)

टूल से शुरू न करें। काम की आकृति से शुरू करें। ये फैक्टर आम तौर पर बताते हैं कि सबसे कम दर्द के साथ क्या काम करेगा।

1) जटिलता और परिवर्तन दर

जटिलता का मतलब है कितने चलते हिस्से हैं: स्क्रीन, स्टेट्स, इंटीग्रेशन, एज केस, और "अगर यह, तो वह" नियम। अगर आवश्यकताएँ काम के बीच बदल रही हों, तो कठिनाई बढ़ जाती है क्योंकि आप रिवीज़न भी मैनेज कर रहे होते हैं।

एकल प्रॉम्प्ट तब सबसे अच्छा है जब टास्क संकीर्ण और स्थिर हो। जब आपको पहले योजना करनी हो, फिर इम्प्लीमेंटेशन, फिर सुधार करने हों, तब वर्कफ़्लो अपनी जगह बनता है।

2) जोखिम और सत्यापन

जोखिम वह है जो होता है अगर परिणाम गलत हो: पैसा, सुरक्षा, यूज़र डेटा, अपटाइम और प्रतिष्ठा। सत्यापन वह है कि आप कितनी आसानी से साबित कर सकते हैं कि आउटपुट सही है।

उच्च जोखिम और कठिन सत्यापन सबसे मजबूत संकेत हैं कि काम को स्टेप्स में बाँटना चाहिए।

अगर आप आउटपुट मिनटों में चेक कर सकते हैं (एक छोटा ईमेल, एक स्लोगन, एक छोटा हेल्पर फ़ंक्शन), तो एक प्रॉम्प्ट अक्सर पर्याप्त है। अगर आपको टेस्ट, समीक्षा या सावधानीपूर्वक तर्क की ज़रूरत है, तो मल्टी-स्टेप फ्लो सुरक्षित होता है।

तेज़ी से निर्णय के लिए कुछ सवाल:

• यह कितने कॉम्पोनेंट्स या सिस्टम्स को छूता है?
• गलत होने पर सबसे बुरा असर क्या है?
• क्या मैं इसे जल्दी सत्यापित कर सकता हूँ, या मुझे टेस्ट और लॉग चाहिए?
• बनाते समय मैं कितनी बार अपना मन बदलूंगा?
• क्या मुझे अभी गति चाहिए, या बाद में कम फिक्स चाहिए?

एक सरल “reset password” ईमेल जनरेट करना कम जोखिम और आसान सत्यापन है। जबकि पासवर्ड रीसेट फीचर बनाना अलग है: token expiry, rate limits, audit logging और एज केस महत्वपूर्ण होते हैं।

चरण-दर-चरण: अपने अगले टास्क के लिए कैसे चुनें

शुरू में “किया हुआ” को ठोस बनाकर शुरू करें, फिर देखें कि कितनी अनिश्चितता बाकी है।

एक सरल 5-स्टेप मेथड

1. लक्ष्य एक वाक्य में लिखें, फिर बताएं कि “डोन” कैसा दिखता है (एक फ़ाइल, एक UI स्क्रीन, एक टेस्ट पास)।

2. इनपुट और प्रतिबंधों की सूची बनाएं। इनपुट वे हैं जो पहले से हैं (नोट्स, API डॉक, सैम्पल डेटा)। प्रतिबंध वे हैं जिन्हें आप बदल नहीं सकते (डेडलाइन, स्टैक, टोन, प्राइवेसी नियम)। कुछ non-goals भी जोड़ें ताकि मॉडल भटके नहीं।

3. अप्रोच चुनें। अगर यह छोटा, कम-रिस्की और निरीक्षण से जल्दी सत्यापित होने योग्य है, तो एक प्रॉम्प्ट आज़माएँ। अगर इसमें कई हिस्से हैं (डेटा परिवर्तन, एज केस, टेस्ट), तो स्टेजेस में बाँटे।

4. एक छोटा पहला पास चलाएँ। मिनिमम यूज़फुल स्लाइस माँगें, फिर बढ़ाएँ। पहले “हैप्पी पाथ” माँगें, फिर वैलिडेशन और एरर्स जोड़ें।

5. भरोसा करने से पहले चेक जोड़ें। स्वीकृति मानदंड परिभाषित करें, फिर सबूत माँगें: टेस्ट, सैम्पल इनपुट/आउटपुट, या एक छोटा मैनुअल टेस्ट प्लान।

उदाहरण: वेब ऐप में “एक सेटिंग्स टॉगल जोड़ें”। अगर यह सिर्फ शब्द और लेआउट है, तो एक प्रॉम्प्ट अक्सर काफी है। अगर इसमें डेटाबेस परिवर्तन, API अपडेट और UI स्टेट चाहिए, तो स्टेज्ड वर्कफ़्लो सुरक्षित है।

अगर आप Koder.ai में काम करते हैं, तो यह साफ़ मैप होगा: planning mode में स्कोप पर सहमति, छोटे स्टेप्स में लागू करें (React, Go, PostgreSQL), फिर सत्यापित करें। Snapshots और rollback आपको बिना प्रोग्रेस खोए एक्सपेरिमेंट करने में मदद करते हैं।

एक बुरी हैंडऑफ रोकने की आदत: अंतिम आउटपुट स्वीकार करने से पहले एक छोटी चेकलिस्ट माँगें जैसे “क्या बदला?”, “इसे कैसे टेस्ट करूँ?”, और “क्या टूट सकता है?”

रोल्स व्यवहार में कैसे दिखते हैं

मल्टी-रोल अप्रोच नौकरशाही नहीं है। यह उन तरह के सोच को अलग करती है जो अक्सर मिल जाते हैं।

एक व्यावहारिक सेट रोल्स का:

• Planner: एक अस्पष्ट अनुरोध को acceptance criteria में बदलता है, एज केस बताता है, और बाहर के दायरे को स्पष्ट करता है।
• Coder: वह सबसे छोटा बदलाव करता है जो फीचर को आगे बढ़ाए, diffs को समीक्षा योग्य रखता है।
• Tester: फीचर को तोड़ने की कोशिश करता है, हैप्पी पाथ और कुछ फेल्योर केस कवर करता है।
• Refactorer: नामकरण और संरचना साफ़ करता है, डुप्लिकेशन हटाता है, और एरर हैंडलिंग को स्टैंडर्ड बनाता है।
• Reviewer (optional): परिणाम की तुलना मानदंडों से करता है और गैप या रिस्की अनुमान फ्लैग करता है।

उदाहरण: “यूज़र्स अपनी प्रोफ़ाइल फोटो अपडेट कर सकते हैं।” Planner निर्धारित करता है अनुमति के फ़ाइल टाइप, साइज लिमिट, कहाँ दिखेगा, और अपलोड फेल होने पर क्या होगा। Coder अपलोड लागू करता है और URL सेव करता है। Tester ओवरसाइज़्ड फ़ाइलें, अमान्य फॉर्मैट और नेटवर्क फेल्योर चेक करता है। Refactorer रिपीटेड लॉजिक निकालता है और एरर मैसेज को कंसिस्टेंट बनाता है।

वास्तविक उदाहरण: एक छोटे ऐप फीचर की शुरुआत से अंत तक

मान लीजिए आपको एक बुकिंग फ़ॉर्म चाहिए जो नाम, ईमेल, तिथि और नोट्स लेता है। सबमिट के बाद उपयोगकर्ता को एक कांफ़र्मेशन दिखे। एक एडमिन पेज बुकिंग्स की सूची दिखाता है।

वन-शॉट प्रयास

एकल प्रॉम्प्ट अक्सर हैप्पी पाथ जल्दी बनाता है: एक फॉर्म कमपोनेंट, एक POST endpoint, और एक एडमिन टेबल। यह तब तक पूरा दिखता है जब तक कोई वास्तव में इसे उपयोग न करे।

आमतौर पर जो छूट जाता है वह वह बोरिंग चीज़ें हैं जो फीचर को वास्तविक बनाती हैं: वैलिडेशन (खराब ईमेल, मिसिंग डेट, भूतपूर्व तारीख), एरर स्टेट्स (टाइमआउट, सर्वर एरर, डुप्लीकेट सबमिट), खाली स्टेट्स (कोई बुकिंग नहीं), बेसिक सिक्योरिटी (कौन एडमिन लिस्ट देख सकता है), और डेटा विवरण (टाइमज़ोन, डेट फॉर्मैट, इनपुट ट्रिम करना)।

आप फॉलो-अप प्रॉम्प्ट्स के साथ इन्हें ठीक कर सकते हैं, पर अक्सर आप समस्याओं पर प्रतिक्रिया करते हुए अंततः पहुँचते हैं बजाय कि उन्हें पहले से रोकने के।

स्टेज्ड प्रयास

अब काम को रोल्स में बाँट दें: plan, build, test, refactor।

प्लान फील्ड नियम, एडमिन एक्सेस, एज केस, और डोन की स्पष्ट परिभाषा तय करता है। बिल्ड React फॉर्म और Go endpoint PostgreSQL के साथ लागू करता है। टेस्ट स्टेप खराब इनपुट आज़माता है और एडमिन सूची को खाली होने पर सत्यापित करता है। रीफ़ैक्टर स्टेप नाम साफ़ करता है और डुप्लिकेशन हटाता है।

फिर प्रोडक्ट कहता है, “सर्विस टाइप के लिए एक ड्रॉपडाउन जोड़ें और एक कांफ़र्मेशन ईमेल भेजें।” एक वन-शॉट फ्लो में आप फ़ील्ड जोड़ कर डेटाबेस, एडमिन लिस्ट और वैलिडेशन अपडेट करना भूल सकते हैं। स्टेज्ड फ्लो में आप पहले प्लान अपडेट करते हैं, फिर हर स्टेप अपने हिस्से को साफ़ तरीक़े से छूता है, जिससे परिवर्तन सुव्यवस्थित उतरता है।

सामान्य गलतियाँ और जाल

सबसे सामान्य विफलता मोड यह है कि सब कुछ एक निर्देश में जबरदस्ती डालना: फीचर की योजना बनाइए, कोड लिखिए, टेस्ट करिए, ठीक करिए और समझाइए। मॉडल अक्सर कुछ हिस्सों को ठीक करता है और बाकी का हवाले छोड़ देता है, और आप तब ही ध्यान देते हैं जब आप इसे रन करते हैं।

एक और जाल है “डोन” की अस्पष्ट परिभाषा। अगर लक्ष्य “इसे बेहतर बनाओ” है, तो आप अनंत संशोधनों में फँस सकते हैं जहाँ हर बदलाव नया काम पैदा करता है। स्पष्ट acceptance criteria अस्पष्ट फीडबैक को एक सरल चेक में बदल देते हैं।

सबसे ज़्यादा रीवर्क करने वाली गलतियाँ:

• एक पास में प्लानिंग, बिल्ड और वेरिफिकेशन मिलाना, जिससे गलतियाँ देर तक छुपी रहती हैं।
• बिना acceptance criteria के शिप करना, और फिर आउटपुट पर बहस करना बजाय कि उसे टेस्ट करना।
• टेस्ट को अंत में छोड़ना, फिर उन बग्स के पीछे भागना जो एक छोटा टेस्ट पहले पकड़ लेता।
• बीच में requirements बदलना पर प्लान या टास्क ब्रेकडाउन अपडेट न करना।
• बिना प्रतिबंध बताए “production-ready” कोड माँगना (सिक्योरिटी, प्रदर्शन, डेटा नियम, एज केस)।

एक ठोस उदाहरण: आप “validation के साथ login page” माँगते हैं और अच्छा React UI पाते हैं, पर पासवर्ड लंबाई, एरर मैसेज, या सफलता की परिभाषा के स्पष्ट नियम नहीं होते। अगर आप बाद में बोलते हैं “rate limiting भी जोड़ो” पर प्लान अपडेट नहीं करते, तो UI और बैकएंड बिहेवियर मेल नहीं खाएंगे।

अगर आप Koder.ai उपयोग करते हैं, तो planning mode, कोड जनरेशन, और टेस्टिंग को अलग चेकपॉइंट्स की तरह ट्रीट करें। Snapshots और rollback मददगार हैं, पर ये साफ़ मानदंड और शुरुआती सत्यापन की जगह नहीं लेते।

शुरू करने से पहले त्वरित चेकलिस्ट

अप Approach चुनने से पहले कुछ प्रैक्टिकल चेक्स से टास्क स्कोर करें। यह आम विफलता रोकता है: “तेज़” विकल्प चुनना और फिर उसे ठीक करने में इतना समय लगाना कि आप पहले योजना बनाने में ही लगा देते।

यदि आप पहले प्रश्नों में अधिकांश उत्तर “हाँ” देते हैं, तो एकल प्रॉम्प्ट अक्सर काफी है। अगर आप अंतिम प्रश्नों में अधिकांश उत्तर “हाँ” हैं, तो वर्कफ़्लो आम तौर पर समय बचाएगा。

• क्या आप टास्क को लगभग 5-8 बुलेट में साफ़ बता सकते हैं, बिना बड़े गैप छोड़े?
• क्या आप परिणाम को जल्दी और वस्तुनिष्ठ रूप से सत्यापित कर सकते हैं (सिर्फ़ “अच्छा दिखता है” नहीं)?
• क्या आपके पास acceptance criteria और कुछ टेस्ट केस/उदाहरण I/O हैं?
• क्या गलत उत्तर महँगा, शर्मनाक, या उलटने में मुश्किल होगा?
• क्या काम कई फाइलें, स्क्रीन, या इंटीग्रेशन (auth, payments, email, database, APIs) छुएगा?

अगर आप सत्यापन के बारे में सुनिश्चित नहीं हैं, तो इसे चेतावनी संकेत मानें। “कठिन सत्यापन” वाले टास्क (प्राइसिंग लॉजिक, परमिशन्स, माइग्रेशन, एज केस) आमतौर पर अलग किए गए स्टेप्स से लाभ उठाते हैं: plan, build, test, फिर refactor।

एक सरल तरकीब: अगर आप दो या तीन स्पष्ट acceptance criteria नहीं लिख पा रहे, तो पहले वही लिखें। फिर सबसे हल्का अप्रोच चुनें जो आपको परिणाम की पुष्टि करने देगा।

वर्कफ़्लो को धीमा न होने देने के तरीके

वर्कफ़्लो तब धीमा महसूस होता है जब वे पूरी समस्या को एक ही लंबे मैराथन में हल करने की कोशिश करते हैं। हर स्टेप को उसकी जगह कमाने दें: सिर्फ़ उतना ही प्लान करें जितना ज़रूरी हो, छोटे टुकड़ों में बनाएं, और चलते-चलते सत्यापित करें।

पहले एक पतला स्लाइस लें। प्लान केवल पहले यूज़र स्टोरी के लिए करें जो दिखाई देने वाली वैल्यू देता है, जैसे “यूज़र एक नोट सेव कर सके,” न कि “टैग, सर्च, शेयरिंग और ऑफ़लाइन के साथ नोट्स ऐप।”

अर्ली गार्डरेल्स जोड़ें ताकि आप बाद में रीवर्क के लिए भुगतान न करें। सरल प्रतिबंध जैसे नामकरण नियम, अपेक्षित एरर हैंडलिंग, और "मौजूदा endpoints में कोई ब्रेकिंग चेंज नहीं" यह रोकते हैं कि काम भटक जाए।

हल्के नियम जो गति बनाए रखते हैं:

• प्लानिंग को एक पेज तक टाइमबॉक्स करें, फिर बिल्ड करें।
• आउटपुट छोटे रखें: एक component, एक endpoint, या एक माइग्रेशन प्रति स्टेप।
• सुरक्षित बिंदु सेव करें: रिस्की संपादनों से पहले स्नैपशॉट लें ताकि आप जल्दी रोलबैक कर सकें।
• निबंध नहीं, सबूत माँगें: टेस्ट, सैम्पल I/O, या छोटा मैनुअल टेस्ट प्लान।
• कब रुकना है तय करें: acceptance criteria के खिलाफ फाइनल समीक्षा करें और पास होने पर लूप बंद करें।

सुरक्षित बिंदु परफेक्ट प्रॉम्प्ट से ज़्यादा मायने रखते हैं। अगर एक रीफ़ैक्टर गलत हो जाए, तो रोलबैक करना बहस करने से तेज़ है कि एजेंट ने क्या “मतलब” किया।

अगले कदम: एक अप्रोच चुनें और छोटा प्रयोग चलाएँ

जटिलता और जोखिम को प्राथमिकता दें न कि प्राथमिकता। अगर टास्क छोटा, कम-स्टेक्स और आंखों से देख कर सही होने योग्य है, तो एकल प्रॉम्प्ट आम तौर पर जीतता है। अगर काम कुछ तोड़ सकता है, यूज़र्स को प्रभावित कर सकता है, या यह साबित करने की ज़रूरत है कि यह काम करता है, तो अलग स्टेप अपने आप आप को फायदे देने लगते हैं।

एक ठोस डिफ़ॉल्ट: ड्राफ्ट और एक्सप्लोरेशन के लिए एक प्रॉम्प्ट का उपयोग करें, और शिप करने के लिए रोल्स का उपयोग करें। ड्राफ्ट में outlines, rough copy, quick ideas और throwaway prototypes शामिल हैं। शिपिंग में वे बदलाव आते हैं जो auth, payments, डेटा माइग्रेशन, reliability या जिन चीज़ों को आप maintain करेंगे, को छूते हैं।

इस सप्ताह आज़माने के लिए एक छोटा प्रयोग:

1. आधे दिन में फिट होने वाला एक फीचर चुनें।
2. एक छोटा प्लान पास करें: acceptance criteria, एज केस, और “डोन” क्या है।
3. बिल्ड पास करें: केवल वही लागू करें जो प्लान कहता है।
4. टेस्ट पास करें: फेल्योर केस आज़माएँ और क्राइटेरिया की पुष्टि करें।
5. रीफ़ैक्टर पास करें: नाम साफ़ करें, डुप्लिकेशन हटाएँ, संक्षेप में नोट्स जोड़ें।

स्कोप को तंग रखें ताकि आप वर्कफ़्लो सीखें, न कि वर्कलोड से जूझें। “एक सूची में सर्च फ़िल्टर जोड़ना” पूरे पेज बनाने से बेहतर टेस्ट है।

अगर आप पहले से Koder.ai में काम कर रहे हैं, तो प्लानिंग मोड में प्लान पास करें, चेकपॉइंट के तौर पर स्नैपशॉट लें, और जब एक्सपेरिमेंट गलत हो तो मुक्त रूप से रोलबैक करें। यदि परिणाम पसंद आए, तो स्रोत कोड एक्सपोर्ट कर लें और अपने सामान्य टूल्स में जारी रखें।

प्रयोग के बाद दो प्रश्न पूछें: क्या आपने समस्याएँ जल्दी पकड़ीं, और क्या आपको शिप करने में अधिक आत्मविश्वास महसूस हुआ? अगर हाँ, तो समान टास्क के लिए रोल्स रखें। अगर नहीं, तो फिर एकल प्रॉम्प्ट पर वापस जाएँ और स्ट्रक्चर को केवल उच्च-रिस्क काम के लिए रखें।