हार्नेस इंजीनियरिंग: एजेंट-प्रथम दुनिया में Codex का उपयोग करना

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

प्रोडक्ट के पास इंटर्नल डेली यूज़र्स और एक्सटर्नल अल्फ़ा टेस्टर्स हैं. यह शिप होता है, डिप्लॉय होता है, टूटता है, और ठीक हो जाता है. अलग बात यह है कि कोड की हर लाइन—एप्लिकेशन लॉजिक, टेस्ट्स, CI कॉन्फ़िगरेशन, डॉक्यूमेंटेशन, ऑब्ज़र्वेबिलिटी, और आंतरिक टूलिंग—Codex द्वारा लिखी गई है. हमारा अनुमान है कि हमने इसे हाथ से कोड लिखने में लगने वाले समय के लगभग 1/10वें हिस्से में बनाया है.

मनुष्य दिशा देते हैं. एजेंट निष्पादित करते हैं.

हमने जानबूझकर यह कंस्ट्रेंट चुना ताकि हम इंजीनियरिंग वेलोसिटी को कई गुना बढ़ाने के लिए ज़रूरी चीज़ें बना सकें. हमारे पास शिप करने के लिए कई हफ़्ते थे, जिसमें आखिर में कोड की दस लाख लाइनें थीं. ऐसा करने के लिए, हमें यह समझना था कि जब सॉफ्टवेयर इंजीनियरिंग टीम का मुख्य काम कोड लिखना नहीं, बल्कि एनवायरनमेंट डिजाइन करना, इंटेंट बताना और फीडबैक लूप बनाना होता है, जिससे Codex एजेंट भरोसेमंद काम कर सकें, तो क्या बदलाव होते हैं.

यह पोस्ट इस बारे में है कि हमने एजेंट्स की एक टीम के साथ एक नया प्रोडक्ट बनाकर क्या सीखा—क्या समस्याएँ आईं, क्या बढ़ा, और हमारे एकमात्र सचमुच दुर्लभ संसाधन: मानव समय और ध्यान को कैसे अधिकतम किया जाए.

एक खाली रिपॉज़िटरी में पहला कमिट अगस्त 2025 के अंत में किया गया.

शुरुआती स्कैफोल्ड—रिपॉजिटरी स्ट्रक्चर, CI कॉन्फ़िगरेशन, फ़ॉर्मेटिंग रूल्स, पैकेज मैनेजर सेटअप, और एप्लिकेशन फ्रेमवर्क—Codex CLI ने GPT‑5 का इस्तेमाल करके बनाया था, जो मौजूदा टेम्प्लेट्स के एक छोटे सेट से गाइडेड था. यहाँ तक कि शुरुआती AGENTS.md फ़ाइल, जो एजेंट्स को बताती है कि रिपॉजिटरी में कैसे काम करना है, वह भी Codex द्वारा ही लिखी गई थी.

सिस्टम को स्थिर करने के लिए कोई पहले से मौजूद मानव-लिखित कोड नहीं था. शुरुआत से ही, रिपॉजिटरी को एजेंट ने आकार दिया.

पांच महीने बाद, रिपॉजिटरी में एप्लिकेशन लॉजिक, इंफ्रास्ट्रक्चर, टूलिंग, डॉक्यूमेंटेशन और इंटरनल डेवलपर यूटिलिटीज़ में कोड की लगभग दस लाख लाइनें हैं. उस अवधि के दौरान, लगभग 1,500 pull request खोले और मर्ज किए गए, और Codex को आगे बढ़ाने के लिए केवल तीन इंजीनियरों की एक छोटी टीम थी. यह प्रति इंजीनियर प्रति दिन औसतन 3.5 PRs के थ्रूपुट में बदल जाता है, और हैरानी की बात है कि जैसे-जैसे टीम बढ़कर अब सात इंजीनियर हो गई है, थ्रूपुट बढ़ा है. महत्वपूर्ण बात यह है कि यह सिर्फ आउटपुट के लिए आउटपुट नहीं था: इस उत्पाद का आंतरिक रूप से सैकड़ों उपयोगकर्ताओं द्वारा उपयोग किया गया है, जिनमें दैनिक आंतरिक पावर उपयोगकर्ता भी शामिल हैं.

पूरे डेवलपमेंट प्रोसेस में, इंसानों ने कभी भी सीधे तौर पर कोई कोड नहीं दिया. यह टीम के लिए एक मुख्य दर्शन बन गया: कोई मैन्युअल रूप से लिखा कोड नहीं.

हाथों-हाथ मानव कोडिंग की कमी ने इंजीनियरिंग कार्य का एक अलग प्रकार प्रस्तुत किया, जो सिस्टम, स्कैफोल्डिंग, और लाभ पर केंद्रित था.

प्रारंभिक प्रगति हमारी अपेक्षा से धीमी थी, Codex अक्षम नहीं था, बल्कि वातावरण पर्याप्त रूप से निर्दिष्ट नहीं था. एजेंट के पास उच्च-स्तरीय लक्ष्यों की ओर प्रगति करने के लिए आवश्यक उपकरण, अमूर्तताएँ, और आंतरिक संरचना नहीं थी. हमारी इंजीनियरिंग टीम का मुख्य कार्य एजेंटों को उपयोगी कार्य करने में सक्षम बनाना बन गया.

असल में, इसका मतलब था गहराई से काम करना: बड़े लक्ष्यों को छोटे बिल्डिंग ब्लॉक्स (डिज़ाइन, कोड, रिव्यू, टेस्ट, वगैरह) में तोड़ना, एजेंट को उन ब्लॉक्स को बनाने के लिए कहना, और उनका इस्तेमाल करके ज़्यादा मुश्किल कामों को पूरा करना. जब कुछ विफल हो जाता, तो समाधान लगभग कभी भी 'और अधिक प्रयास करो' नहीं होता था. क्योंकि प्रोग्रेस करने का एकमात्र तरीका Codex से काम करवाना था, इसलिए इंसानी इंजीनियर हमेशा काम में आगे आते थे और पूछते थे: “कौन सी एबिलिटी मिसिंग है, और हम इसे एजेंट के लिए पढ़ने लायक और लागू करने लायक कैसे बना सकते हैं?”

मनुष्य सिस्टम के साथ लगभग पूरी तरह से प्रॉम्प्ट के माध्यम से इंटरैक्ट करते हैं: एक इंजीनियर एक कार्य का वर्णन करता है, एजेंट चलाता है, और उसे pull request खोलने की अनुमति देता है. PR को पूरा करने के लिए, हम Codex को निर्देश देते हैं कि वह अपने बदलावों की स्थानीय समीक्षा करे, स्थानीय और क्लाउड दोनों में अतिरिक्त विशिष्ट एजेंट समीक्षाओं का अनुरोध करे, किसी भी मानव या एजेंट द्वारा दिए गए फीडबैक का जवाब दे, और एक लूप में दोहराए जब तक कि सभी एजेंट समीक्षक संतुष्ट न हो जाएँ (असल में यह एक Ralph Wiggum Loop⁠(एक नई विंडो में खुलेगा) है). Codex हमारे स्टैंडर्ड डेवलपमेंट टूल्स (gh, लोकल स्क्रिप्ट्स, और रिपॉजिटरी-एम्बेडेड स्किल्स) का सीधे इस्तेमाल करता है ताकि बिना किसी इंसान के CLI में कॉपी और पेस्ट किए कॉन्टेक्स्ट इकट्ठा किया जा सके.

मनुष्य pull request की समीक्षा कर सकते हैं, लेकिन यह आवश्यक नहीं है. समय के साथ, हमने लगभग सभी समीक्षा प्रयासों को एजेंट-से-एजेंट के रूप में संभालने की दिशा में धकेला है.

जैसे-जैसे कोड थ्रूपुट बढ़ा, हमारी बाधा मानव QA क्षमता बन गई. क्योंकि तय रुकावट इंसानी समय और ध्यान रही है, इसलिए हमने एजेंट में और ज़्यादा क्षमताएं जोड़ने के लिए काम किया है, इसके लिए हमने एप्लिकेशन UI, लॉग और ऐप मेट्रिक्स जैसी चीज़ों को Codex पर सीधे पढ़ने लायक बनाया है.

उदाहरण के लिए, हमने ऐप को git worktree के अनुसार बूटेबल बनाया, ताकि Codex हर बदलाव के लिए एक इंस्टैंस लॉन्च और संचालित कर सके. हमने Chrome DevTools प्रोटोकॉल को एजेंट रनटाइम में जोड़ा और DOM स्नैपशॉट्स, स्क्रीनशॉट्स, और नेविगेशन के साथ काम करने के लिए कौशल विकसित की. इससे Codex बग्स को पुनः उत्पन्न करने, सुधारों को सत्यापित करने, और UI व्यवहार के बारे में सीधे तर्क करने में सक्षम हुआ.

हमने ऑब्ज़र्वेबिलिटी टूलिंग के लिए भी वही किया. लॉग्स, मेट्रिक्स, और ट्रेसेज़ Codex को एक स्थानीय निरीक्षण स्टैक के माध्यम से उपलब्ध कराए जाते हैं, जो किसी भी दिए गए वर्कट्री के लिए अस्थायी होता है. Codex उस ऐप के पूरी तरह से पृथक संस्करण पर काम करता है—जिसमें उसके लॉग्स और मेट्रिक्स भी शामिल होते हैं, जिन्हें वह कार्य पूरा हो जाने पर हटा दिया जाता है. एजेंट LogQL के साथ लॉग्स और PromQL के साथ मेट्रिक्स क्वेरी कर सकते हैं. इस संदर्भ के उपलब्ध होने पर, “ensure service startup completes in under 800ms” या “इन चार महत्वपूर्ण उपयोगकर्ता यात्राओं में से किसी का भी समय दो सेकंड से अधिक नहीं होना चाहिए” जैसे प्रॉम्प्ट व्यावहारिक हो जाते हैं.

हम नियमित रूप से देखते हैं कि एकल Codex रन एक ही कार्य पर छह घंटे से अधिक समय तक काम करता है (अक्सर तब, जब लोग सो रहे होते हैं).

बड़े और मुश्किल कामों में एजेंट्स को असरदार बनाने में कॉन्टेक्स्ट मैनेजमेंट सबसे बड़ी चुनौतियों में से एक है. हमने जो शुरुआती सबक सीखे, उनमें से एक सरल था: Codex को एक नक्शा दो, न कि 1,000-पृष्ठों की निर्देश पुस्तिका.

हमने “एक बड़ा AGENTS.md⁠(एक नई विंडो में खुलेगा)” का प्रयास किया दृष्टिकोण. यह अनुमानित तरीकों से विफल हुआ:

• संदर्भ एक दुर्लभ संसाधन है. एक विशाल निर्देश फ़ाइल कार्य, कोड, और प्रासंगिक दस्तावेज़ों को दबा देती है—इसलिए एजेंट या तो मुख्य बाधाओं को नज़रअंदाज़ कर देता है या गलत बाधाओं के लिए अनुकूलन शुरू कर देता है.
• बहुत अधिक मार्गदर्शन मार्गदर्शन नहीं रहता. जब सब कुछ “महत्वपूर्ण” होता है, तो कुछ भी महत्वपूर्ण नहीं होता. एजेंट जानबूझकर नेविगेट करने के बजाय लोकल लेवल पर पैटर्न-मैचिंग करते हैं.
• यह तुरंत खराब हो जाता है. एक विशाल मैनुअल बासी नियमों के कब्रिस्तान में बदल जाता है. एजेंट यह नहीं बता सकते कि क्या अब भी सही है, लोग इसका रखरखाव करना बंद कर देते हैं, और फ़ाइल चुपचाप एक आकर्षक परेशानी बन जाती है.
• सत्यापित करना कठिन है. एक अकेला ब्लॉब यांत्रिक जाँचों (कवरेज, ताज़गी, स्वामित्व, क्रॉस-लिंक्स) के लिए उपयुक्त नहीं होता, इसलिए विचलन अनिवार्य है.

तो AGENTS.md को विश्वकोश के रूप में मानने के बजाय, हम इसे सामग्री-सूची के रूप में मानते हैं.

रिपॉज़िटरी का ज्ञान आधार एक संरचित docs/ डायरेक्टरी में स्थित है, जिसे रिकॉर्ड की प्रणाली के रूप में माना जाता है. एक छोटा AGENTS.md (लगभग 100 पंक्तियाँ) संदर्भ में डाला जाता है और मुख्य रूप से एक नक्शे के रूप में कार्य करता है, जो अन्यत्र गहरे सत्य के स्रोतों की ओर संकेत करता है.

डिज़ाइन डॉक्यूमेंटेशन को कैटलॉग और इंडेक्स किया जाता है, जिसमें वेरिफिकेशन स्टेटस और कोर बिलीफ्स का एक सेट शामिल होता है जो एजेंट-फर्स्ट ऑपरेटिंग प्रिंसिपल्स को डिफाइन करते हैं. आर्किटेक्चर दस्तावेज़ीकरण⁠(एक नई विंडो में खुलेगा) डोमेन और पैकेज लेयरिंग का एक शीर्ष स्तर का नक्शा प्रदान करता है. एक गुणवत्ता दस्तावेज़ प्रत्येक उत्पाद डोमेन और आर्किटेक्चरल लेयर को ग्रेड करता है, और समय के साथ अंतराल को ट्रैक करता है.

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

यह प्रगतिशील प्रकटीकरण को सक्षम करता है: एजेंट एक छोटे, स्थिर प्रवेश बिंदु से शुरू करते हैं और उन्हें सिखाया जाता है कि आगे कहाँ देखना है, बजाय इसके कि शुरुआत में ही वे अभिभूत हो जाएँ.

हम इसे यांत्रिक रूप से लागू करते हैं. समर्पित लिंटर्स और CI जॉब्स यह सुनिश्चित करते हैं कि ज्ञान आधार अद्यतन, क्रॉस-लिंक्ड, और सही ढंग से संरचित है. एक आवर्ती “doc-gardening” एजेंट पुराने या अप्रचलित दस्तावेज़ों के लिए स्कैन करता है जो वास्तविक कोड व्यवहार को प्रतिबिंबित नहीं करते हैं, और सुधार के लिए pull request खोलता है.

जैसे-जैसे कोडबेस विकसित हुआ, वैसे-वैसे डिज़ाइन निर्णयों के लिए Codex के ढांचे को भी विकसित होना पड़ा.

क्योंकि रिपॉज़िटरी पूरी तरह से एजेंट-जनरेटेड है, इसे सबसे पहले Codex की पठनीयता के लिए ऑप्टिमाइज़ किया गया है. जिस तरह टीमें नए इंजीनियरिंग हायर के लिए अपने कोड की नेविगेबिलिटी बेहतर बनाने का लक्ष्य रखती हैं, वैसे ही हमारे मानव इंजीनियर्स का लक्ष्य यह संभव बनाना था कि एक एजेंट पूरे बिज़नेस डोमेन के बारे में सीधे रिपॉज़िटरी से ही समझ सके.

एजेंट के दृष्टिकोण से, जब वह चल रहा होता है, तो कॉन्टेक्स्ट में वह किसी भी चीज़ तक प्रभावी रूप से पहुँच नहीं सकता, तो वह चीज़ मौजूद नहीं मानी जाती. Google Docs, चैट थ्रेड्स, या लोगों के दिमाग में मौजूद ज्ञान सिस्टम के लिए उपलब्ध नहीं है. रिपॉज़िटरी-स्थानीय, संस्करणित आर्टिफैक्ट्स (जैसे, कोड, मार्कडाउन, स्कीमा, निष्पादन योग्य योजनाएं) ही वह सब कुछ हैं जो यह देख सकता है.

हमने सीखा कि समय के साथ हमें रिपो में अधिक से अधिक संदर्भ जोड़ने की आवश्यकता थी. वह Slack चर्चा जिसने टीम को एक आर्किटेक्चरल पैटर्न पर सहमति दी? अगर एजेंट इसे खोज नहीं सकता, तो यह उसी तरह से अपठनीय है जैसे तीन महीने बाद जुड़ने वाले नए कर्मचारी के लिए अज्ञात होगा.

Codex को अधिक संदर्भ देने का अर्थ है सही जानकारी को व्यवस्थित करना और उसे प्रस्तुत करना, ताकि एजेंट उस पर विचार कर सके, बजाय इसके कि उसे तदर्थ निर्देशों से भरकर अभिभूत किया जाए. जैसे आप किसी नए टीममेट को प्रोडक्ट प्रिंसिपल्स, इंजीनियरिंग नॉर्म्स और टीम कल्चर (इमोजी प्रेफरेंस शामिल) पर ऑनबोर्ड करते हैं, वैसे ही एजेंट को यह जानकारी देने से बेहतर अलाइन्ड आउटपुट मिलता है.

इस फ्रेमिंग ने कई विकल्पों को स्पष्ट किया. हमने उन निर्भरताओं और अमूर्तताओं को प्राथमिकता दी जिन्हें पूरी तरह से आंतरिक रूप से समझा जा सके और रिपॉजिटरी में उनके बारे में तर्क किया जा सके. अक्सर “boring” के रूप में वर्णित टेक्नोलॉजीज़ एजेंट्स के लिए composability, api stability, और training set में representation के कारण मॉडल करना आसान होती हैं. कुछ मामलों में, सार्वजनिक लाइब्रेरीज़ के अस्पष्ट अपस्ट्रीम व्यवहार के बजाय एजेंट से कार्यक्षमता के कुछ हिस्सों को फिर से लागू करवाना सस्ता था. उदाहरण के लिए, एक सामान्य p-limit-स्टाइल पैकेज को शामिल करने के बजाय, हमने अपना खुद का map-with-concurrency हेल्पर लागू किया: यह हमारे OpenTelemetry इंस्ट्रूमेंटेशन के साथ कसकर इंटीग्रेटेड है, इसमें 100% टेस्ट कवरेज है, और यह ठीक उसी तरह व्यवहार करता है जैसा हमारा रनटाइम अपेक्षा करता है.

सिस्टम के अधिक हिस्सों को ऐसे रूप में लाना जिसे एजेंट सीधे निरीक्षण, सत्यापित और संशोधित कर सके, लाभ बढ़ाता है—सिर्फ Codex के लिए नहीं, बल्कि अन्य एजेंटों के लिए भी (उदा. Aardvark) जो कोडबेस पर भी काम कर रहा है.

केवल दस्तावेज़ीकरण पूरी तरह से एजेंट-जनरेटेड कोडबेस को सुसंगत नहीं रखता है. इंवेरिएंट्स को लागू करके, इम्प्लीमेंटेशन्स की सूक्ष्म प्रबंधन नहीं करके, हम एजेंट्स को नींव को कमजोर किए बिना तेजी से काम करने देते हैं. उदाहरण के लिए, हमें Codex से बाउंड्री पर डेटा शेप्स को पार्स⁠(एक नई विंडो में खुलेगा) करने की ज़रूरत है, लेकिन हम यह नहीं बता रहे हैं कि यह कैसे होता है (मॉडल को Zod पसंद है, लेकिन हमने उस खास लाइब्रेरी के बारे में नहीं बताया).

एजेंट्स सख्त सीमाओं और पूर्वानुमेय संरचना⁠(एक नई विंडो में खुलेगा) वाले वातावरण में सबसे प्रभावी होते हैं, इसलिए हमने एप्लिकेशन को एक कठोर वास्तुशिल्प मॉडल के इर्द-गिर्द बनाया. प्रत्येक व्यवसाय डोमेन को एक निश्चित लेयर सेट में विभाजित किया जाता है, जिसमें निर्भरता दिशाओं का सख्ती से सत्यापन किया जाता है और अनुमत किनारों का एक सीमित सेट होता है. इन बाध्यताओं को यांत्रिक रूप से कस्टम लिंटर्स (बेशक, Codex-जनरेटेड!) और संरचनात्मक परीक्षणों के माध्यम से लागू किया जाता है.

नीचे दिया गया आरेख नियम दिखाता है: प्रत्येक व्यावसायिक डोमेन के भीतर (उदाहरण के लिए, ऐप सेटिंग्स), कोड केवल लेयर्स के एक निश्चित सेट के माध्यम से “फॉरवर्ड” निर्भर कर सकता है (टाइप्स → कॉन्फ़िग → रिपो → सर्विस → रनटाइम → यूआई). क्रॉस-कटिंग चिंताएँ (auth, connectors, telemetry, feature flags) एक ही स्पष्ट इंटरफ़ेस के माध्यम से प्रवेश करती हैं: Providers. इसके अलावा कुछ भी अनुमति नहीं है और इसे यांत्रिक रूप से लागू किया जाता है.

यह वह प्रकार की वास्तुकला है जिसे आप आमतौर पर तब तक टालते हैं जब तक आपके पास सैकड़ों इंजीनियर नहीं होते. कोडिंग एजेंट्स के साथ, यह एक प्रारंभिक आवश्यकता है: बाधाएँ ही वे तत्व हैं जो गिरावट या आर्किटेक्चरल बहाव के बिना गति को संभव बनाती हैं.

व्यवहार में, हम इन नियमों को कस्टम लिंटर और संरचनात्मक परीक्षणों के साथ-साथ "स्वाद अपरिवर्तनीयों" के एक छोटे से सेट के साथ लागू करते हैं. उदाहरण के लिए, हम कस्टम लिंट्स के साथ स्ट्रक्चर्ड लॉगिंग, स्कीमा और टाइप के लिए नेमिंग कन्वेंशन, फ़ाइल साइज़ लिमिट, और प्लेटफ़ॉर्म-स्पेसिफिक रिलायबिलिटी ज़रूरतों को स्टैटिकली लागू करते हैं. क्योंकि लिंट्स कस्टम हैं, हम त्रुटि संदेश लिखते हैं ताकि एजेंट के संदर्भ में सुधारात्मक निर्देश डाले जा सकें.

मानव-प्रथम कार्यप्रवाह में, ये नियम आपको कुछ हद तक बारीक या बाध्यकारी लग सकते हैं. एजेंट्स के साथ, वे गुणक बन जाते हैं: एक बार एन्कोड हो जाने पर, वे एक साथ हर जगह लागू होते हैं.

साथ ही, हम स्पष्ट रूप से बताते हैं कि कहाँ सीमाएँ महत्वपूर्ण हैं और कहाँ नहीं. यह एक बड़े इंजीनियरिंग प्लेटफ़ॉर्म संगठन का नेतृत्व करने जैसा है: सीमाओं को केंद्रीय रूप से लागू करें, स्थानीय स्तर पर स्वायत्तता की अनुमति दें. तुम सीमाओं, सही होने, और पुनरुत्पादन क्षमता की बहुत परवाह करते हो. उन सीमाओं के भीतर, तुम टीमों—या एजेंटों—को इस बात में पर्याप्त स्वतंत्रता देते हो कि समाधान कैसे व्यक्त किए जाएं.

इसके परिणामस्वरूप कोड हमेशा मानव शैलीगत प्राथमिकताओं से मेल नहीं खाता है, और यह ठीक है. जब तक आउटपुट सही, बनाए रखने योग्य, और भविष्य के एजेंट रन के लिए पढ़ने योग्य है, यह मानक पर खरा उतरता है.

मानव स्वाद को लगातार प्रणाली में वापस जोड़ा जाता है. समीक्षा टिप्पणियाँ, रिफैक्टरिंग pull request, और उपयोगकर्ता-सामना करने वाले बग्स को दस्तावेज़ीकरण अपडेट के रूप में कैप्चर किया जाता है या सीधे उपकरण में एन्कोड किया जाता है. जब दस्तावेज़ीकरण कम पड़ता है, तो हम नियम को कोड में बढ़ावा देते हैं

जैसे-जैसे Codex का थ्रूपुट बढ़ा, कई पारंपरिक इंजीनियरिंग नियम उलटे असरदार हो गए.

रिपॉज़िटरी न्यूनतम अवरोधक मर्ज गेट्स के साथ संचालित होती है. Pull request अल्पकालिक होते हैं. टेस्ट फ्लेक्स को अक्सर प्रगति को अनिश्चितकाल तक रोकने के बजाय फॉलो-अप रन के माध्यम से हल किया जाता है. एक ऐसे सिस्टम में जहाँ एजेंट थ्रूपुट मानव ध्यान से कहीं अधिक हो, सुधार सस्ते होते हैं, और इंतज़ार महँगा होता है.

कम थ्रूपुट वाले वातावरण में यह गैर-जिम्मेदाराना होगा. यहाँ, यह अक्सर सही समझौता होता है.

जब हम कहते हैं कि कोडबेस Codex एजेंट्स द्वारा जनरेट किया गया है, तो हमारा मतलब कोडबेस की हर चीज़ से है.

एजेंट्स उत्पादन करते हैं:

• उत्पाद कोड और परीक्षण
• CI कॉन्फ़िगरेशन और रिलीज़ टूलिंग
• आंतरिक डेवलपर टूल्स
• डॉक्यूमेंटेशन और डिज़ाइन हिस्टरी
• मूल्यांकन हार्नेस
• टिप्पणियों और प्रतिक्रियाओं की समीक्षा करें
• रिपॉज़िटरी को स्वयं प्रबंधित करने वाली स्क्रिप्ट्स
• उत्पादन डैशबोर्ड परिभाषा फ़ाइलें

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

एजेंट सीधे हमारे मानक विकास उपकरणों का उपयोग करते हैं. वे रिव्यू फीडबैक प्राप्त करते हैं, इनलाइन जवाब देते हैं, अपडेट्स पुश करते हैं, और अक्सर अपने ही pull request को स्क्वैश और मर्ज करते हैं.

जैसे-जैसे विकास चक्र का अधिक हिस्सा सीधे सिस्टम में एन्कोड किया गया—जाँच, सत्यापन, समीक्षा, प्रतिक्रिया प्रबंधन, और पुनर्प्राप्ति—रिपॉज़िटरी ने हाल ही में एक महत्वपूर्ण सीमा पार की, जहाँ Codex एंड-टू-एंड एक नई विशेषता चला सकता है.

एक सिंगल प्रॉम्प्ट दिए जाने पर, एजेंट अब यह कर सकता है:

• कोडबेस की वर्तमान स्थिति को सत्यापित करें
• रिपोर्ट किए गए बग को फिर से उत्पन्न करें
• विफलता को दिखाने वाला एक वीडियो रिकॉर्ड करो
• एक सुधार लागू करें
• एप्लिकेशन चलाकर सुधार को मान्य करें
• रिज़ॉल्यूशन का प्रदर्शन करने वाला दूसरा वीडियो रिकॉर्ड करें
• Pull request खोलें
• एजेंट और इंसानी फ़ीडबैक का जवाब दें
• बिल्ड विफलताओं का पता लगाओ और उन्हें ठीक करें
• निर्णय की आवश्यकता होने पर ही किसी इंसान तक आगे बढ़ाएं
• परिवर्तन को मर्ज करें

यह व्यवहार इस रिपॉज़िटरी की विशिष्ट संरचना और टूलिंग पर बहुत अधिक निर्भर करता है और समान निवेश के बिना इसे सामान्यीकृत नहीं माना जाना चाहिए—कम से कम, अभी नहीं.

पूर्ण एजेंट स्वायत्तता भी नई समस्याएँ प्रस्तुत करती है.Codex रिपॉज़िटरी में पहले से मौजूद पैटर्न्स को दोहराता है—यहाँ तक कि असमान या कम-उत्तम पैटर्न भी. समय के साथ, यह अनिवार्य रूप से विचलन की ओर ले जाता है.

शुरू में, इंसानों ने इसे हाथ से ठीक किया. हमारी टीम हर शुक्रवार (हफ्ते का 20%) “AI स्लॉप” साफ करने में समय बिताती थी. हैरानी की बात नहीं है, वह बढ़ा नहीं.

इसके बजाय, हमने जिन चीज़ों को हम “गोल्डन प्रिंसिपल्स” कहते हैं, उन्हें सीधे रिपॉज़िटरी में एन्कोड करना शुरू किया और एक नियमित क्लीनअप प्रोसेस तैयार किया. ये प्रिंसिपल्स स्पष्ट दृष्टिकोण वाले, मैकेनिकल नियम हैं जो भविष्य के एजेंट रन के लिए कोडबेस को पढ़ने योग्य और कंसिस्टेंट बनाए रखते हैं. उदाहरण के लिए: (1) हम इनवेरिएंट्स को सेंट्रलाइज़्ड रखने के लिए हाथ से बनाए गए हेल्पर्स की जगह शेयर किए गए यूटिलिटी पैकेजेस को प्राथमिकता देते हैं, और (2) हम डेटा को “YOLO-style” में प्रोब नहीं करते—हम बाउंड्रीज़ को वैलिडेट करते हैं या टाइप्ड SDKs पर भरोसा करते हैं, ताकि एजेंट गलती से अनुमानित शेप्स पर कुछ बना न दे. नियमित अंतराल पर, हमारे पास बैकग्राउंड Codex टास्क्स का एक सेट होता है जो डिविएशन्स को स्कैन करता है, क्वालिटी ग्रेड्स को अपडेट करता है, और टार्गेटेड रिफैक्टरिंग पुल रिक्वेस्ट्स खोलता है. इनमें से ज़्यादातर को एक मिनट से कम समय में रिव्यू किया जा सकता है और ऑटोमर्ज किया जा सकता है.

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

यह रणनीति अब तक OpenAI में आंतरिक लॉन्च और अपनाने तक अच्छी तरह से काम कर रही है. असली यूज़र्स के लिए एक असली प्रोडक्ट बनाने से हमें अपने निवेशों को वास्तविकता से जोड़े रखने में मदद मिली और हमें लॉन्ग-टर्म मेंटेनबिलिटी की ओर गाइड किया.

हम अभी तक यह नहीं जानते कि पूरी तरह से एजेंट-जनित सिस्टम में वर्षों के दौरान आर्किटेक्चरल समरसता कैसे विकसित होती है. हम अभी भी यह सीख रहे हैं कि मानव निर्णय सबसे अधिक प्रभाव कहाँ डालता है और उस निर्णय को कैसे इस तरह से संहिताबद्ध किया जाए कि वह बढ़ता रहे. हमें यह भी नहीं पता कि जैसे-जैसे मॉडल समय के साथ अधिक सक्षम होते जाएंगे, यह प्रणाली कैसे विकसित होगी.

यह स्पष्ट हो गया है: सॉफ़्टवेयर बनाना अब भी अनुशासन की मांग करता है, लेकिन अनुशासन कोड की बजाय अधिकतर सहायक संरचना में दिखाई देता है. कोडबेस को सुसंगत बनाए रखने के लिए टूलिंग, एब्स्ट्रैक्शंस, और फीडबैक लूप्स की बढ़ती हुई महत्ता है.

हमारी सबसे मुश्किल चुनौतियाँ अब ऐसे एनवायरनमेंट, फ़ीडबैक लूप और कंट्रोल सिस्टम डिज़ाइन करने पर हैं जो एजेंट्स को हमारा लक्ष्य पूरा करने में मदद करते हैं: बड़े पैमाने पर मुश्किल, भरोसेमंद सॉफ़्टवेयर बनाना और बनाए रखना.

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