कोडेक्स और मल्टी-एजेंट वर्कफ़्लो: नियंत्रण खोए बिना एजेंटों के साथ काम करें

spinny:~/writing $ less codex-multi-agent-workflows.md

1 
2पहली बार जब कोई कोडिंग एजेंट वास्तव में आपके लिए बग ठीक करता है, तो प्रतिक्रिया लगभग हमेशा एक जैसी होती है: उत्साह और संदेह का मिश्रण। अच्छा, निश्चित। लेकिन फिर आप अंतर को देखते हैं और खुद से पूछते हैं: "ठीक है, लेकिन उसने वास्तव में क्या छुआ? क्या मैं उस पर भरोसा कर सकता हूं? क्या वह कल फिर से उसी तरह से ऐसा करेगा?"
3 
4मुझे लगता है कि दिलचस्प हिस्सा यहीं से शुरू होता है। तब नहीं जब एजेंट कोई फ़ंक्शन लिखता है, बल्कि जब वह काम के पूरे हिस्से को लेने में सक्षम हो जाता है: रिपॉजिटरी पढ़ें, पैच बनाएं, परीक्षण चलाएं, पीआर खोलें, समीक्षा टिप्पणी के बाद वापस आएं। कोडेक्स ठीक उसी दिशा में आगे बढ़ रहा है: पृष्ठभूमि कार्य, अलग वर्कट्री, एकीकृत ब्राउज़र, ऑटोमेशन, प्लगइन्स, मेमोरी और अधिक स्पष्ट अनुमति नियंत्रण।
5 
6मुद्दा ऐसे भविष्य की कल्पना करने का नहीं है जहां अब कोई भी कोड नहीं पढ़ेगा। यह एक भयानक भविष्य होगा, साथ ही काफी अनुभवहीन भी। मुद्दा यह पता लगाना है कि उन एजेंटों के साथ कैसे काम किया जाए जो उन्हें सब कुछ करने दिए बिना भी बहुत कुछ कर सकते हैं।
7 
8## आदत का बदलाव
9 
10पारंपरिक स्वतः पूर्णता के साथ आप हमेशा गाड़ी चला रहे थे। एआई ने एक लाइन सुझाई, आपने फैसला कर लिया। हालाँकि, एक एजेंट के साथ रिश्ता बदल जाता है: आप उसे एक लक्ष्य देते हैं और वह अपने दम पर कई कदम उठाता है।
11 
12यह शक्तिशाली है, लेकिन यह समस्या को बदल देता है। प्रश्न अब केवल "क्या मॉडल प्रोग्राम कर सकता है?" नहीं है। प्रश्न बन जाता है:
13 
14- क्या मैंने उसे पर्याप्त छोटा दायरा दिया?
15- क्या आप जानते हैं रिजल्ट कैसे चेक करें?
16- क्या मैं एक अलग वातावरण में काम कर रहा हूँ?
17- क्या अंतिम समीक्षा अभी भी मानवीय और सावधान है?
18 
19एक स्वस्थ वर्कफ़्लो किसी जादू की छड़ी से अधिक इस तरह दिखता है:
20 
21```mermaid
22flowchart LR
23    Idea[मानवीय कार्य] --> Scope[छोटा, सत्यापन योग्य उद्देश्य]
24    Scope --> Agent[वर्कट्री में एजेंट अलग-थलग]
25    Agent --> Checks[टेस्ट, लिंट, बिल्ड, ब्राउज़र]
26    Checks --> Review[मानव समीक्षा]
27    Review --> Merge[विलय या नया पुनरावृत्ति]
28    Review --> Iterate[अंतर पर सटीक टिप्पणियाँ]
29    Iterate --> Agent
30```
31 
32यह "एजेंट सब कुछ बनाता है" की तुलना में कम रोमांटिक लगता है, लेकिन यह बहुत बेहतर काम करता है। और यह भी है कि जो टीमें इंसानों के साथ अच्छी हैं वे कैसे काम करती हैं: स्पष्ट कार्य, त्वरित प्रतिक्रिया, स्पष्ट जवाबदेही।
33 
34## अच्छा संकेत लगभग एक अच्छा टिकट है
35 
36सबसे खतरनाक संकेत अस्पष्ट लेकिन आश्वस्त संकेत है: "चालान पृष्ठ को ठीक करें", "वास्तुकला में सुधार करें", "ऑथ मॉड्यूल को साफ करें"। ये ऐसे अनुरोध हैं जो उपयोगी लगते हैं और भारी मतभेद पैदा करते हैं। लेकिन फिर आप स्वयं को पुरातत्व करते हुए पाते हैं।
37 
38एक सहायक संकेत अधिक उबाऊ है. उदाहरण के लिए: इनवॉइस पृष्ठ के लिए CSV निर्यात लागू करें, यह जानते हुए कि तालिका `app/(dashboard)/invoices/page.tsx` में है, क्वेरीज़ `src/server/invoices.ts` में हैं और `app/(dashboard)/reports` में पहले से ही एक समान पैटर्न है।
39 
40फिर स्पष्ट बाधाएँ जोड़ें: डेटाबेस स्कीमा न बदलें, यदि छोटी उपयोगिता पर्याप्त है तो निर्भरताएँ न जोड़ें, मौजूदा यूआई शैली रखें। और सत्यापन के साथ बंद करें: `npm test -- invoices` और `npm run build`।
41 
42इस प्रकार का संक्षिप्त विवरण "एआई को बेहतर ढंग से समझाने" के लिए नहीं है। यह सबसे पहले आपको यह स्पष्ट करने का काम करता है कि आप क्या सौंप रहे हैं। यदि आप इसे ठोस रूप से नहीं लिख सकते हैं, तो शायद कार्य अभी एजेंट के लिए तैयार नहीं है।
43 
44## तीन नौकरियाँ जो मैं स्वेच्छा से सौंपता हूँ
45 
46पहला दोहराव वाला लेकिन सत्यापन योग्य कार्य है: परीक्षण जोड़ना, कॉल को एक नए आंतरिक एपीआई में स्थानांतरित करना, आयात अपडेट करना, अप्रचलित घटकों को बदलना, टाइपस्क्रिप्ट त्रुटियों को ठीक करना। यहां एजेंट घंटों बचा सकता है और जोखिम नियंत्रणीय है।
47 
48दूसरा खोजपूर्ण कार्य है: "पता लगाएं कि इस कुल की गणना कहां की गई है", "मुझे समझाएं कि यह परीक्षण नाजुक क्यों है", "बग को पुन: उत्पन्न करें और मुझे बताएं कि कौन सी फ़ाइलें प्रभावित होती हैं"। यहां तक कि जब यह तुरंत कोई पैच तैयार नहीं करता है, तब भी यह उपयोगी टोह ले सकता है।
49 
50तीसरा आवर्ती रखरखाव कार्य है: छोटे निर्भरता अद्यतन, पुराने फ़ीचर फ़्लैग की सफ़ाई, अवरुद्ध पीआर का सारांश, भूले हुए TODO की जाँच। यह ग्लैमरस नहीं है, लेकिन यह बिल्कुल उस तरह का काम है जो ढेर हो जाता है।
51 
52## तीन नौकरियाँ जिन्हें मैं मानव रखता हूँ
53 
54उत्पाद संबंधी निर्णय मानवीय बने रहते हैं। यदि कोई परिवर्तन उपयोगकर्ता के भुगतान करने के तरीके को बदलता है, डेटा हटाता है, कीमतें देखता है, या अनुमति को समझता है, तो मुझे एक जिम्मेदार व्यक्ति चाहिए।
55 
56सुरक्षा सीमाएँ भी मानवीय ध्यान देने योग्य हैं: प्राधिकरण, भूमिकाएँ, टोकन, संवेदनशील डेटा लॉगिंग, डेटाबेस माइग्रेशन। एक एजेंट कार्यान्वयन में मदद कर सकता है, लेकिन उसे एकमात्र निर्णय लेने वाला नहीं होना चाहिए।
57 
58अंत में, मैं वह सब कुछ रखता हूं जिसके लिए वास्तुशिल्पीय स्वाद की मानवीय आवश्यकता होती है। एक एजेंट एक रिफैक्टर का प्रस्ताव कर सकता है, लेकिन यह समझना कि क्या एक अमूर्तता वास्तव में आवश्यक है या क्या हम सिर्फ एक गैर-मौजूद समस्या को ठीक कर रहे हैं, एक काम बना हुआ है।
59 
60## समीक्षा वैकल्पिक नहीं है
61 
62जब कोई एजेंट अच्छा होता है, तो प्रलोभन सीआई के हरे रंग पर भरोसा करने का होता है। यह समझ में आता है। यह तब भी होता है जब समस्याएं शुरू होती हैं।
63 
64मैं हमेशा कम से कम पाँच चीज़ें देखता हूँ:
65 
661. क्या पैच केवल अनुरोधित कार्य को हल करता है?
672. क्या उसने ऐसी फ़ाइलें छुईं जिनका इससे कोई लेना-देना नहीं था?
683. क्या परीक्षण नवीन व्यवहार या केवल सुखद अवसर को कवर करते हैं?
694. क्या कोड स्थानीय पैटर्न का पालन करता है?
705. क्या त्रुटियों को प्रोजेक्ट के बाकी हिस्सों की तरह ही नियंत्रित किया जाता है?
71 
72जब कुछ गलत होता है, तो प्रतिक्रिया विशिष्ट होनी चाहिए। "इसे ठीक करो" आलसी है। बेहतर: यह उपयोगिता `parseMoney` को `src/lib/money.ts` में डुप्लिकेट करती है; उस फ़ंक्शन का पुन: उपयोग करें, EUR मामले के लिए एक परीक्षण जोड़ें और बिलिंग मॉड्यूल के सार्वजनिक एपीआई को न बदलें।
73 
74एजेंट छोटी, सत्यापन योग्य टिप्पणियों पर बेहतर प्रतिक्रिया देते हैं। दिलचस्प बात यह है कि लोग भी ऐसा ही करते हैं।
75 
76## प्रयास के लायक रेलिंग
77 
78यदि कोई एजेंट फ़ाइलें पढ़ सकता है, कोड लिख सकता है और कमांड निष्पादित कर सकता है, तो इसे एक शक्तिशाली प्रक्रिया के रूप में माना जाना चाहिए। व्यामोह की कोई आवश्यकता नहीं है, आपको स्वच्छता की आवश्यकता है।
79 
80अलग-अलग वर्कट्री या शाखाओं का उपयोग करें। तो आप अंतर की तुलना कर सकते हैं, असफल प्रयोगों को फेंक सकते हैं, और जो आप कर रहे थे उसके साथ एजेंट के काम को नहीं मिला सकते हैं।
81 
82अनुमतियाँ सीमित करें. `rg`, `git diff`, `npm test` और `npm run build` जैसे कमांड काफी मुफ़्त हो सकते हैं। तैनाती, डेटाबेस माइग्रेशन, रहस्यों तक पहुंच और विनाशकारी आदेश स्पष्ट रहने चाहिए।
83 
84जब आपको इसकी आवश्यकता न हो तो नेटवर्क एक्सेस कम करें। कई कार्यों के लिए, आधिकारिक दस्तावेज़ीकरण, पैकेज रजिस्ट्री और विशिष्ट आंतरिक सेवाएँ पर्याप्त हैं। कम सतह क्षेत्र, कम आश्चर्य।
85 
86गतिविधियों को ट्रैक करें. जब कोई पैच समीक्षा के लिए आता है, तो आपको संकेतों, निष्पादित आदेशों, उत्तीर्ण परीक्षणों और संशोधित फ़ाइलों को फिर से बनाने में सक्षम होना चाहिए। नौकरशाही बनाने के लिए नहीं, बल्कि यह समझने में सक्षम होने के लिए कि अगर कुछ गलत हुआ तो क्या हुआ।
87 
88## एक टीम के रूप में शुरुआत करने का आसान तरीका
89 
90यदि मुझे एजेंटों को एक छोटी टीम में शामिल करना होता, तो मैं बड़ी क्रांतियों के बिना शुरुआत करता।
91 
92मैं स्पष्ट दायरे वाले मुद्दों के लिए `agent-ready` लेबल बनाऊंगा। मैं संदर्भ, बाधाओं और सत्यापन आदेशों के साथ एक टेम्पलेट जोड़ूंगा। मैं छोटे पीआर के लिए कहूंगा, आदर्श रूप से कुछ सौ पंक्तियों के अंतर्गत। दृश्यमान परिवर्तनों के लिए मुझे परीक्षण या स्क्रीनशॉट की आवश्यकता होगी। और सबसे बढ़कर मैं इस मर्ज के लिए एक व्यक्ति को जिम्मेदार रखूंगा।
93 
94दो सप्ताह के बाद मैं डेटा देखूंगा: कौन से कार्यों में वास्तव में तेजी आई, कौन सी समीक्षाएँ भारी थीं, कौन से संकेत भ्रमित करने वाले थे, कोडबेस के कौन से हिस्से सौंपने के लिए बहुत नाजुक हैं।
95 
96यह "आज से हम एजेंटों के साथ सब कुछ करेंगे" की तुलना में कम शानदार दृष्टिकोण है, लेकिन यह वह तरीका है जो आपको बिना पछतावे के तीसरे सप्ताह तक पहुंचने की अनुमति देता है।
97 
98## सबसे मानवीय हिस्सा
99 
100मजेदार बात यह है कि जितने अधिक स्वायत्त एजेंट बनते हैं, क्लासिक कौशल फिर से उतने ही महत्वपूर्ण हो जाते हैं: एक अच्छा टिकट लिखना, छोटी कटौती करना, परीक्षण बनाना, अंतर पढ़ना, ट्रेड-ऑफ संचार करना। एजेंट उन लोगों को गति देता है जो पहले से ही अच्छी तरह से काम करना जानते हैं। यह उन लोगों की अराजकता को भी बढ़ाता है जो बुरी तरह से प्रतिनिधि करते हैं।
101 
102तो नहीं, मैं मल्टी-एजेंट वर्कफ़्लो को इंजीनियरिंग करना बंद करने के शॉर्टकट के रूप में नहीं देखता। मैं उन्हें उन हिस्सों में अधिक ऊर्जा स्थानांतरित करने के तरीके के रूप में देखता हूं जो मायने रखते हैं: यह तय करना कि क्या बनाना है, यह सुनिश्चित करना कि यह काम करता है, सिस्टम को समझने योग्य बनाए रखना।
103 
104एजेंट महान अतुल्यकालिक सहयोगी बन सकते हैं। लेकिन एक अतुल्यकालिक सहयोगी को उपयोगी होने के लिए संदर्भ, सीमाओं और समीक्षा की आवश्यकता होती है। सिर्फ दूसरों की तरह।
105 
106## उपयोगी स्रोत
107 
108- [(लगभग) हर चीज़ के लिए कोडेक्स - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [OpenAI पर कोडेक्स को सुरक्षित रूप से चलाना](https://openai.com/index/running-codex-safely/)
110- [कोडेक्स का परिचय - ओपनएआई](https://openai.com/index/introducing-codex/)
111- [GitHub Copilot कोडिंग एजेंट के साथ नया क्या है](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112

:कोडेक्स और मल्टी-एजेंट वर्कफ़्लो: नियंत्रण खोए बिना एजेंटों के साथ काम करेंlines 1-112 (END) — press q to close

2पहली बार जब कोई कोडिंग एजेंट वास्तव में आपके लिए बग ठीक करता है, तो प्रतिक्रिया लगभग हमेशा एक जैसी होती है: उत्साह और संदेह का मिश्रण। अच्छा, निश्चित। लेकिन फिर आप अंतर को देखते हैं और खुद से पूछते हैं: "ठीक है, लेकिन उसने वास्तव में क्या छुआ? क्या मैं उस पर भरोसा कर सकता हूं? क्या वह कल फिर से उसी तरह से ऐसा करेगा?"

4मुझे लगता है कि दिलचस्प हिस्सा यहीं से शुरू होता है। तब नहीं जब एजेंट कोई फ़ंक्शन लिखता है, बल्कि जब वह काम के पूरे हिस्से को लेने में सक्षम हो जाता है: रिपॉजिटरी पढ़ें, पैच बनाएं, परीक्षण चलाएं, पीआर खोलें, समीक्षा टिप्पणी के बाद वापस आएं। कोडेक्स ठीक उसी दिशा में आगे बढ़ रहा है: पृष्ठभूमि कार्य, अलग वर्कट्री, एकीकृत ब्राउज़र, ऑटोमेशन, प्लगइन्स, मेमोरी और अधिक स्पष्ट अनुमति नियंत्रण।

6मुद्दा ऐसे भविष्य की कल्पना करने का नहीं है जहां अब कोई भी कोड नहीं पढ़ेगा। यह एक भयानक भविष्य होगा, साथ ही काफी अनुभवहीन भी। मुद्दा यह पता लगाना है कि उन एजेंटों के साथ कैसे काम किया जाए जो उन्हें सब कुछ करने दिए बिना भी बहुत कुछ कर सकते हैं।

8## आदत का बदलाव

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

12यह शक्तिशाली है, लेकिन यह समस्या को बदल देता है। प्रश्न अब केवल "क्या मॉडल प्रोग्राम कर सकता है?" नहीं है। प्रश्न बन जाता है:

14- क्या मैंने उसे पर्याप्त छोटा दायरा दिया?

15- क्या आप जानते हैं रिजल्ट कैसे चेक करें?

16- क्या मैं एक अलग वातावरण में काम कर रहा हूँ?

17- क्या अंतिम समीक्षा अभी भी मानवीय और सावधान है?

19एक स्वस्थ वर्कफ़्लो किसी जादू की छड़ी से अधिक इस तरह दिखता है:

21```mermaid

22flowchart LR

23 Idea[मानवीय कार्य] --> Scope[छोटा, सत्यापन योग्य उद्देश्य]

24 Scope --> Agent[वर्कट्री में एजेंट अलग-थलग]

25 Agent --> Checks[टेस्ट, लिंट, बिल्ड, ब्राउज़र]

26 Checks --> Review[मानव समीक्षा]

27 Review --> Merge[विलय या नया पुनरावृत्ति]

28 Review --> Iterate[अंतर पर सटीक टिप्पणियाँ]

29 Iterate --> Agent

30```

32यह "एजेंट सब कुछ बनाता है" की तुलना में कम रोमांटिक लगता है, लेकिन यह बहुत बेहतर काम करता है। और यह भी है कि जो टीमें इंसानों के साथ अच्छी हैं वे कैसे काम करती हैं: स्पष्ट कार्य, त्वरित प्रतिक्रिया, स्पष्ट जवाबदेही।

34## अच्छा संकेत लगभग एक अच्छा टिकट है

36सबसे खतरनाक संकेत अस्पष्ट लेकिन आश्वस्त संकेत है: "चालान पृष्ठ को ठीक करें", "वास्तुकला में सुधार करें", "ऑथ मॉड्यूल को साफ करें"। ये ऐसे अनुरोध हैं जो उपयोगी लगते हैं और भारी मतभेद पैदा करते हैं। लेकिन फिर आप स्वयं को पुरातत्व करते हुए पाते हैं।

38एक सहायक संकेत अधिक उबाऊ है. उदाहरण के लिए: इनवॉइस पृष्ठ के लिए CSV निर्यात लागू करें, यह जानते हुए कि तालिका `app/(dashboard)/invoices/page.tsx` में है, क्वेरीज़ `src/server/invoices.ts` में हैं और `app/(dashboard)/reports` में पहले से ही एक समान पैटर्न है।

40फिर स्पष्ट बाधाएँ जोड़ें: डेटाबेस स्कीमा न बदलें, यदि छोटी उपयोगिता पर्याप्त है तो निर्भरताएँ न जोड़ें, मौजूदा यूआई शैली रखें। और सत्यापन के साथ बंद करें: `npm test -- invoices` और `npm run build`।

42इस प्रकार का संक्षिप्त विवरण "एआई को बेहतर ढंग से समझाने" के लिए नहीं है। यह सबसे पहले आपको यह स्पष्ट करने का काम करता है कि आप क्या सौंप रहे हैं। यदि आप इसे ठोस रूप से नहीं लिख सकते हैं, तो शायद कार्य अभी एजेंट के लिए तैयार नहीं है।

44## तीन नौकरियाँ जो मैं स्वेच्छा से सौंपता हूँ

46पहला दोहराव वाला लेकिन सत्यापन योग्य कार्य है: परीक्षण जोड़ना, कॉल को एक नए आंतरिक एपीआई में स्थानांतरित करना, आयात अपडेट करना, अप्रचलित घटकों को बदलना, टाइपस्क्रिप्ट त्रुटियों को ठीक करना। यहां एजेंट घंटों बचा सकता है और जोखिम नियंत्रणीय है।

48दूसरा खोजपूर्ण कार्य है: "पता लगाएं कि इस कुल की गणना कहां की गई है", "मुझे समझाएं कि यह परीक्षण नाजुक क्यों है", "बग को पुन: उत्पन्न करें और मुझे बताएं कि कौन सी फ़ाइलें प्रभावित होती हैं"। यहां तक कि जब यह तुरंत कोई पैच तैयार नहीं करता है, तब भी यह उपयोगी टोह ले सकता है।

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

52## तीन नौकरियाँ जिन्हें मैं मानव रखता हूँ

54उत्पाद संबंधी निर्णय मानवीय बने रहते हैं। यदि कोई परिवर्तन उपयोगकर्ता के भुगतान करने के तरीके को बदलता है, डेटा हटाता है, कीमतें देखता है, या अनुमति को समझता है, तो मुझे एक जिम्मेदार व्यक्ति चाहिए।

56सुरक्षा सीमाएँ भी मानवीय ध्यान देने योग्य हैं: प्राधिकरण, भूमिकाएँ, टोकन, संवेदनशील डेटा लॉगिंग, डेटाबेस माइग्रेशन। एक एजेंट कार्यान्वयन में मदद कर सकता है, लेकिन उसे एकमात्र निर्णय लेने वाला नहीं होना चाहिए।

58अंत में, मैं वह सब कुछ रखता हूं जिसके लिए वास्तुशिल्पीय स्वाद की मानवीय आवश्यकता होती है। एक एजेंट एक रिफैक्टर का प्रस्ताव कर सकता है, लेकिन यह समझना कि क्या एक अमूर्तता वास्तव में आवश्यक है या क्या हम सिर्फ एक गैर-मौजूद समस्या को ठीक कर रहे हैं, एक काम बना हुआ है।

60## समीक्षा वैकल्पिक नहीं है

62जब कोई एजेंट अच्छा होता है, तो प्रलोभन सीआई के हरे रंग पर भरोसा करने का होता है। यह समझ में आता है। यह तब भी होता है जब समस्याएं शुरू होती हैं।

64मैं हमेशा कम से कम पाँच चीज़ें देखता हूँ:

661. क्या पैच केवल अनुरोधित कार्य को हल करता है?

672. क्या उसने ऐसी फ़ाइलें छुईं जिनका इससे कोई लेना-देना नहीं था?

683. क्या परीक्षण नवीन व्यवहार या केवल सुखद अवसर को कवर करते हैं?

694. क्या कोड स्थानीय पैटर्न का पालन करता है?

705. क्या त्रुटियों को प्रोजेक्ट के बाकी हिस्सों की तरह ही नियंत्रित किया जाता है?

72जब कुछ गलत होता है, तो प्रतिक्रिया विशिष्ट होनी चाहिए। "इसे ठीक करो" आलसी है। बेहतर: यह उपयोगिता `parseMoney` को `src/lib/money.ts` में डुप्लिकेट करती है; उस फ़ंक्शन का पुन: उपयोग करें, EUR मामले के लिए एक परीक्षण जोड़ें और बिलिंग मॉड्यूल के सार्वजनिक एपीआई को न बदलें।

74एजेंट छोटी, सत्यापन योग्य टिप्पणियों पर बेहतर प्रतिक्रिया देते हैं। दिलचस्प बात यह है कि लोग भी ऐसा ही करते हैं।

76## प्रयास के लायक रेलिंग

78यदि कोई एजेंट फ़ाइलें पढ़ सकता है, कोड लिख सकता है और कमांड निष्पादित कर सकता है, तो इसे एक शक्तिशाली प्रक्रिया के रूप में माना जाना चाहिए। व्यामोह की कोई आवश्यकता नहीं है, आपको स्वच्छता की आवश्यकता है।

80अलग-अलग वर्कट्री या शाखाओं का उपयोग करें। तो आप अंतर की तुलना कर सकते हैं, असफल प्रयोगों को फेंक सकते हैं, और जो आप कर रहे थे उसके साथ एजेंट के काम को नहीं मिला सकते हैं।

82अनुमतियाँ सीमित करें. `rg`, `git diff`, `npm test` और `npm run build` जैसे कमांड काफी मुफ़्त हो सकते हैं। तैनाती, डेटाबेस माइग्रेशन, रहस्यों तक पहुंच और विनाशकारी आदेश स्पष्ट रहने चाहिए।

84जब आपको इसकी आवश्यकता न हो तो नेटवर्क एक्सेस कम करें। कई कार्यों के लिए, आधिकारिक दस्तावेज़ीकरण, पैकेज रजिस्ट्री और विशिष्ट आंतरिक सेवाएँ पर्याप्त हैं। कम सतह क्षेत्र, कम आश्चर्य।

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

88## एक टीम के रूप में शुरुआत करने का आसान तरीका

90यदि मुझे एजेंटों को एक छोटी टीम में शामिल करना होता, तो मैं बड़ी क्रांतियों के बिना शुरुआत करता।

92मैं स्पष्ट दायरे वाले मुद्दों के लिए `agent-ready` लेबल बनाऊंगा। मैं संदर्भ, बाधाओं और सत्यापन आदेशों के साथ एक टेम्पलेट जोड़ूंगा। मैं छोटे पीआर के लिए कहूंगा, आदर्श रूप से कुछ सौ पंक्तियों के अंतर्गत। दृश्यमान परिवर्तनों के लिए मुझे परीक्षण या स्क्रीनशॉट की आवश्यकता होगी। और सबसे बढ़कर मैं इस मर्ज के लिए एक व्यक्ति को जिम्मेदार रखूंगा।

94दो सप्ताह के बाद मैं डेटा देखूंगा: कौन से कार्यों में वास्तव में तेजी आई, कौन सी समीक्षाएँ भारी थीं, कौन से संकेत भ्रमित करने वाले थे, कोडबेस के कौन से हिस्से सौंपने के लिए बहुत नाजुक हैं।

96यह "आज से हम एजेंटों के साथ सब कुछ करेंगे" की तुलना में कम शानदार दृष्टिकोण है, लेकिन यह वह तरीका है जो आपको बिना पछतावे के तीसरे सप्ताह तक पहुंचने की अनुमति देता है।

98## सबसे मानवीय हिस्सा

100मजेदार बात यह है कि जितने अधिक स्वायत्त एजेंट बनते हैं, क्लासिक कौशल फिर से उतने ही महत्वपूर्ण हो जाते हैं: एक अच्छा टिकट लिखना, छोटी कटौती करना, परीक्षण बनाना, अंतर पढ़ना, ट्रेड-ऑफ संचार करना। एजेंट उन लोगों को गति देता है जो पहले से ही अच्छी तरह से काम करना जानते हैं। यह उन लोगों की अराजकता को भी बढ़ाता है जो बुरी तरह से प्रतिनिधि करते हैं।

101

102तो नहीं, मैं मल्टी-एजेंट वर्कफ़्लो को इंजीनियरिंग करना बंद करने के शॉर्टकट के रूप में नहीं देखता। मैं उन्हें उन हिस्सों में अधिक ऊर्जा स्थानांतरित करने के तरीके के रूप में देखता हूं जो मायने रखते हैं: यह तय करना कि क्या बनाना है, यह सुनिश्चित करना कि यह काम करता है, सिस्टम को समझने योग्य बनाए रखना।

103

104एजेंट महान अतुल्यकालिक सहयोगी बन सकते हैं। लेकिन एक अतुल्यकालिक सहयोगी को उपयोगी होने के लिए संदर्भ, सीमाओं और समीक्षा की आवश्यकता होती है। सिर्फ दूसरों की तरह।

105

106## उपयोगी स्रोत

107

108- [(लगभग) हर चीज़ के लिए कोडेक्स - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [OpenAI पर कोडेक्स को सुरक्षित रूप से चलाना](https://openai.com/index/running-codex-safely/)

110- [कोडेक्स का परिचय - ओपनएआई](https://openai.com/index/introducing-codex/)

111- [GitHub Copilot कोडिंग एजेंट के साथ नया क्या है](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112