संपादकीय टिप्पणी: यह लेख OpenAI के डेवलपर रिलेशन्स के सदस्य डोमिनिक कुंडेल से आया है, जो Codex के 'goal mode / /goal' फ़ंक्शन के उपयोग के अनुभव का सारांश प्रस्तुत करता है। यह एक सामान्य prompt तकनीक पर चर्चा नहीं करता, बल्कि AI प्रोग्रामिंग उपकरणों में हो रहे एक भूमिका परिवर्तन पर केंद्रित है: Codex केवल एकल-चरण निर्देशों का प्रतिक्रिया देने वाला कोड सहायक नहीं रहा, बल्कि अब यह स्पष्ट लक्ष्य के चारों ओर निरंतर प्रगति करने वाला एक कार्यान्वयन एजेंट बन गया है।

/goal मोड में, आवश्यकताओं को जितना लंबा और विस्तार से लिखा जाए, उतना महत्वपूर्ण नहीं है; बल्कि Codex के लिए स्पष्ट, जांचने योग्य निकास मानदंड निर्धारित करना महत्वपूर्ण है। उदाहरण के लिए: "डिप्लॉयमेंट समय में 30% की कमी", "टेस्ट कवरेज 100% parity तक पहुंचे", "LCP 2.5 सेकंड से कम हो जाए"। ये मापदंड Codex को यह निर्णय लेने में सक्षम बनाते हैं कि कार्य पूरा हुआ है या नहीं, और इसे अस्पष्ट लक्ष्यों में अनंत प्रयासों से बचाते हैं। इसके साथ ही, उपयोगकर्ता को Codex को प्रगति को मापने और परिणामों की पुष्टि करने के लिए पर्याप्त दिशा, उपकरण और वास्तविक परिवेश प्रदान करना चाहिए, ताकि Codex केवल स्थानीय या कल्पित परिस्थितियों में एक ऐसा समाधान प्रस्तुत न करे जो केवल संभव प्रतीत हो।

लेख विशेष रूप से चेतावनी देता है कि दृश्य कार्य सबसे अधिक Codex को विवरण के गड़बड़ में फंसा देते हैं। '100% पिक्सेल-लेवल रिप्रोडक्शन' की मांग के बजाय, दृश्य लक्ष्यों को कार्य सूची, डिजाइन सिस्टम नियमों और मूल्यांकन योग्य सूचकों में विभाजित करें। कई घंटों या दिनों तक चलने वाले लंबे कार्यों के लिए, commit, draft PR, प्रगति दस्तावेज, Slack अपडेट या side chat के माध्यम से निरंतर ट्रैकिंग की आवश्यकता होती है, ताकि अंत में केवल अनुसरणयोग्य न होने वाले परिवर्तनों का ढेर न मिले।

इस लेख का मुख्य योगदान यह है कि यह /goal को एक “लंबी अवधि के कार्य प्रबंधन तंत्र” के रूप में पुनः परिभाषित करता है। जब AI लगातार कई दर्जन या सैकड़ों घंटे कार्य कर सकता है, तो डेवलपर्स की मुख्य क्षमता भी बदल जाती है: केवल AI को कोड जनरेट करने के लिए नहीं, बल्कि उसे लक्ष्य परिभाषित करना, मापन प्रणाली स्थापित करना, निष्पादन वातावरण कॉन्फ़िगर करना, और अंत में समीक्षा और समीक्षा पूरा करना। दूसरे शब्दों में, AI प्रोग्रामिंग “प्रॉम्प्ट लिखने” से “एक निरंतर कार्यरत इंजीनियरिंग एजेंट का प्रबंधन” की ओर बढ़ रहा है।

निम्नलिखित मूल पाठ है:

हमने लक्ष्य मोड (goal mode, या /goal) लॉन्च किया है, ताकि आप कोडेक को एक विशिष्ट परिणाम की ओर ले जाने में मदद कर सकें। जब आप एक लक्ष्य निर्धारित करते हैं, तो कोडेक उस लक्ष्य को प्राप्त करने तक लगातार काम करता रहेगा—चाहे इसमें कुछ घंटे लगें या कुछ दिन। कुछ उपयोगकर्ताओं ने कोडेक को एक ही लक्ष्य के लिए 120 घंटे से अधिक समय तक लगातार काम कराया है।

लक्ष्य पैटर्न बहुत शक्तिशाली है। इसका अधिकतम उपयोग करने के लिए, /goal का उपयोग करते समय 7 बातों पर ध्यान दें।

स्पष्ट, जांचने योग्य मानदंड निर्धारित करें

जब आप टारगेट मोड को सक्रिय करते हैं, तो आप जो प्रॉम्प्ट देते हैं, वह प्रारंभिक प्रॉम्प्ट के रूप में काम करता है, और महत्वपूर्ण रूप से, यह इस टारगेट के लिए एक निकास मानदंड बन जाता है। कोडेक प्रत्येक चक्र के बाद जांचता है: क्या यह टारगेट पूरा हो चुका है?

इसलिए, आपका लक्ष्य प्रॉम्प्ट बहुत लंबा नहीं होना चाहिए, बल्कि एक स्पष्ट मानदंड पर केंद्रित होना चाहिए: इस लक्ष्य को कब माना जाएगा कि यह पूरा हो गया है।

अधिकांश मामलों में, एक अच्छा लक्ष्य एक स्पष्ट संख्यात्मक सूचक शामिल करना चाहिए ताकि मॉडल यह निर्धारित कर सके कि क्या यह पूरा हो गया है। उदाहरण के लिए:

30% तक बनाने और डिप्लॉय करने का समय कम करें।

इस फ़ंक्शन को TypeScript से Rust में माइग्रेट करें और 100% टेस्ट कंसिस्टेंसी प्राप्त करें।

अप्लिकेशन स्कैफोल्डिंग को ऑप्टिमाइज़ करें ताकि उत्पादन पर्यावरण में सबसे बड़ी सामग्री चित्रण (Largest Contentful Paint, पेज की मुख्य सामग्री लोड होने की गति को मापने वाला मापदंड) 2.5 सेकंड से कम हो।

यह सुझाव हमेशा संख्याओं को शामिल करना आवश्यक नहीं है, लेकिन आमतौर पर, संख्याएँ अगले चरणों को आगे बढ़ाने में सुविधा प्रदान करती हैं।

अगर आप अभी तक अपना लक्ष्य कैसे परिभाषित करें, इसके बारे में अनिश्चित हैं, या इस प्रोजेक्ट के लिए पहले Codex के साथ ब्रेनस्टॉर्म करना चाहते हैं, तो आपको शुरुआत में ही लक्ष्य मोड के साथ बातचीत शुरू करने की आवश्यकता नहीं है।

Codex अपने लक्ष्य स्वयं निर्धारित कर सकता है। आप पहले एक सामान्य बातचीत शुरू कर सकते हैं, और जब आप तैयार हो जाएँ कि Codex कार्य करे, तो उसे पिछली चर्चा के आधार पर लक्ष्य निर्धारित करने के लिए कहें।

आप लक्ष्य को किसी भी समय संपादित कर सकते हैं: Codex ऐप में संपादन बटन पर क्लिक करें, या CLI में /goal का पुनः उपयोग करें।

जितना संभव हो उतना मार्गदर्शन प्रदान करें

जैसे "बिल्ड और डिप्लॉय समय को 30% कम करें" जैसे हिंट्स बहुत कूल लगते हैं और Codex को कुछ रचनात्मक समाधान ढूंढने में मदद कर सकते हैं। लेकिन अगर आप पहले से ही जानते हैं कि समस्या कहाँ हो सकती है, तो ऐसे हिंट्स Codex को गलत दिशा में ले जा सकते हैं।

इसलिए, जहाँ संभव हो, बेहतर होगा कि आप Codex को बताएँ कि समस्या की जाँच कहाँ से शुरू करनी है, लक्ष्य प्राप्त करने के लिए कौन से उपकरण उपयोग किए जा सकते हैं, या अन्य सुझाव दें, ताकि यह गलत दिशा में न जाए।

उदाहरण के लिए, मेरे सहकर्मी @reach_vb ने एक प्रयोग में ऐसा किया: उन्होंने Codex को बताया कि Google Colab तक पहुँचने के लिए Chrome ब्राउज़र का उपयोग किया जा सकता है, और कुछ स्वीकार्य सीमाओं का उल्लेख किया, जैसे कि Codex को मॉडल प्रशिक्षित करते समय अपना डेटासेट बनाने दिया जा सकता है।

इसी तरह, यदि आप बिल्ड समय को कम करना चाहते हैं और पहले से जानते हैं कि अधिकांश समय किस चरण में खर्च हो रहा है, तो बेहतर होगा कि आप Codex को प्रॉम्प्ट में पहले उस क्षेत्र की ओर इशारा करें।

एक अन्य दृष्टिकोण यह है कि आप पहले Codex को योजना मोड (plan mode) में प्रारंभिक शोध करने दें और इसे संभावित समाधानों को दर्ज करने के लिए एक योजना फ़ाइल बनाने दें। इसके बाद, अपने लक्ष्य को इस योजना का संदर्भ लेने के लिए निर्देशित करें।

Progress को मापने योग्य बनाएं

अगर आपका लक्ष्य बहुत लक्ष्यपूर्ण है, या कोडेक के पास लक्ष्य तक पहुँचने के लिए कई तरीके हैं, तो महत्वपूर्ण बात यह है कि आप कोडेक को प्रगति को मापने के लिए उपकरण प्रदान करें।

कुछ कार्यों के लिए यह स्वाभाविक रूप से सत्य हो सकता है। उदाहरण के लिए, बिल्ड समय को अनुकूलित करना या परीक्षण कवरेज को बढ़ाना, क्योंकि Codex आमतौर पर संबंधित उपकरणों का उपयोग कर सकता है या इन उपकरणों को स्वाभाविक रूप से बना सकता है।

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

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

कार्य के आधार पर, आपको यह भी विचार करना होगा कि क्या कुछ अतिरिक्त मानदंड हैं जिन्हें मापना या जांचना आवश्यक है। अन्यथा, कोडेक समझ सकता है कि कार्य पूरा हो गया है, लेकिन आपके दृष्टिकोण से यह अपूर्ण है।

उदाहरण के लिए, कोडेक किसी UI को "पिक्सेल-लेवल पर रीक्रिएट" करने के लिए डिज़ाइन रेफरेंस इमेज को काटकर पेज में एम्बेड कर सकता है; या फिर परीक्षण पास रेट को 100% तक पहुँचाने के लिए परीक्षण कवरेज को कम कर सकता है। ये आपकी वास्तविक रूप से चाही गई पूरी करने की विधि नहीं हैं।

एक वास्तविक वातावरण बनाएं

अगर आप चाहते हैं कि कोडेक अपने लक्ष्य की ओर वास्तविक प्रगति करे, तो इसे एक पर्याप्त रूप से वास्तविक वातावरण में चलना होगा।

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

उदाहरण के लिए, हमने developers.openai.com के बिल्ड और डिप्लॉयमेंट समय के अनुकूलन के लिए डीबगिंग की थी। उस समय हम पहले से ही डिप्लॉयमेंट प्रीव्यू का उपयोग कर रहे थे, इसलिए Codex इन प्रीव्यू वातावरणों का उपयोग करके डिप्लॉय कर सकता था और संबंधित लॉग देख सकता था। लेकिन समस्या यह थी कि हमारे प्रीव्यू डिप्लॉयमेंट में पूर्ण उत्पादन वातावरण की तुलना में कुछ बिल्ड पथों को अक्षम कर दिया गया था।

इसलिए, कोडेक को अंततः मैनुअल डिप्लॉय करना पड़ा, ताकि कोड को उत्पादन कॉन्फ़िगरेशन के अधिक समान वातावरण में डिप्लॉय करके समस्या का वास्तविक रूप से निदान किया जा सके।

इसी तरह, आप Codex को computer use (मॉडल को वास्तविक एप्लिकेशन इंटरफ़ेस को ऑपरेट करने की क्षमता) का उपयोग करके वास्तविक एप्लिकेशन का परीक्षण करने के लिए भी उपयोग कर सकते हैं। कुछ iOS प्रदर्शन समस्याओं को अनुकूलित करने के लिए, @dimillian ने सबसे सटीक परीक्षण वातावरण प्राप्त करने के लिए वास्तविक उपकरणों का उपयोग किया।

दृश्य लक्ष्यों को सावधानी से निर्धारित करें

कोडेक्स को एक दृश्य लक्ष्य देना, जैसे 'इस तस्वीर के आधार पर इस UI को 100% पिक्सेल-लेवल पर रीक्रिएट करें', वास्तव में आकर्षक है। लेकिन विशिष्ट सेटिंग के आधार पर, यह समस्याएँ भी पैदा कर सकता है।

अगर आप उपयुक्त निर्देश और सीमाएँ नहीं देते हैं, तो Codex कुछ विवरणों में इतना उलझ सकता है कि वह मुख्य लक्ष्य को नज़रअंदाज़ कर दे। उदाहरण के लिए, अगर संदर्भ चित्र में कुछ ग्राफ़िक तत्व हैं और आप चाहते हैं कि Codex इन तत्वों को जनरेट करे—चाहे वह SVG आइकन हों या इमेज—तो यह "इन सामग्रियों को सटीकता से पुनः बनाने" पर अपनी ऊर्जा खर्च कर सकता है, बजाय पूरी समस्या को सही ढंग से विघटित करने के।

इसके अलावा, कोडेक्स को सही ढंग से दृश्य तुलना करने के लिए उपकरणों की आवश्यकता होती है। इसका अर्थ है अधिक छवि इनपुट, उच्चतर कुल टोकन खपत, लेकिन यह जरूरी नहीं कि कोडेक्स को वास्तविक रूप से मूल्यवान सुधार के अवसरों की पहचान करने का सरल तरीका प्रदान करे।

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

अग्रगति का अनुसरण करें

अगर कोडेक्स बैकग्राउंड में कई घंटे या यहां तक कि कई दिनों तक, या एक अलग मशीन पर काम करता है, तो आप आसानी से भूल सकते हैं कि यह कहां तक पहुंच चुका है और क्या काम पूरा हो चुका है।

विभिन्न लक्ष्यों के आधार पर, मुझे नीचे दिए गए तरीके बहुत उपयोगी लगे:

· कोडेक को महत्वपूर्ण बिंदुओं पर कोड सबमिट करने और एक ड्राफ्ट PR पर पुश करने दें। खासकर जब आप वेबसाइट पर काम कर रहे हों और प्रीव्यू डिप्लॉयमेंट उपलब्ध हो, तो यह बहुत उपयोगी होगा।

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

Codex को आगे बढ़ने की प्रगति के बारे में सक्रिय रूप से अपडेट जारी करने के लिए निर्देश दें। आप इसे अपने लक्ष्य में भी शामिल कर सकते हैं: जब Codex महत्वपूर्ण प्रगति करता है, तो उसे Slack चैनल पर अपडेट भेजें, या जहां आप प्रगति को दर्ज करना चाहते हैं।

अन्य चैट विंडो का उपयोग करके स्थिति पूछें। यदि आप केवल वर्तमान स्थिति को जल्दी से जानना चाहते हैं, तो /side चलाएं ताकि एक नया साइड चैट शुरू हो सके, और वहां प्रश्न पूछें। क्योंकि यह वर्तमान थ्रेड से अलग हो जाएगा, इसलिए इसमें अब तक का संपूर्ण संदर्भ होगा, लेकिन इसकी अवधि बहुत कम होगी।

Codex ऐप में एक अन्य विकल्प है: एक सामान्य नया चैट शुरू करें, जिसमें Codex एक अन्य लक्ष्य थ्रेड को पढ़े और आपके प्रश्नों का उत्तर दे। यदि आप Codex को एक स्वचालित कार्य सेट करने के लिए कहते हैं, जो नियमित रूप से प्रगति की जांच करे, तो यह विधि विशेष रूप से शक्तिशाली होती है।

साफ करें और परिणाम की अंतिम पुष्टि करें

बहुत अच्छा, लक्ष्य अंततः पूरा हो गया! क्या अब हम सीधे परिणाम टीम को दे सकते हैं और काम खत्म कर सकते हैं?

आम तौर पर, खासकर अनुकूलन कार्यों में, मुझे लगता है कि Codex को अपने द्वारा पूरा किए गए कार्य को समीक्षा और समीक्षा करने देना उपयोगी होता है। आप पहले /review का उपयोग करके स्थानीय कोड समीक्षा चला सकते हैं, लेकिन यह भी मूल्यवान है कि Codex गहराई से प्रतिबिंबित करे: इसने लक्ष्य प्राप्त करने के लिए कौन-से मार्ग अपनाए? कौन-से प्रयास सफल रहे? कौन-से प्रयास असफल रहे? और फिर इसके आधार पर कोड को साफ़ करें।

चूंकि कोडेक लक्ष्य प्राप्त करने तक लगातार काम करता रहता है, इसलिए यह कुछ ऐसी विधियों का प्रयास कर सकता है जो पर्याप्त रूप से प्रभावी नहीं हैं या पूरी तरह से अक्षम हैं, और इन अवशेष परिवर्तनों को अंतिम कोड में छोड़ दिया जा सकता है।

अपने अगले कार्य के लिए एक लक्ष्य निर्धारित करें

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

आपने /goal का उपयोग क्या किया है?