हार्नेस अभियांत्रिकी: एजंट-प्रथम जगात Codex चा लाभ घेणे

गेल्या पाच महिन्यांमध्ये, आमची टीम एक प्रयोग करत आहे: 0 lines of manually-written code सह सॉफ्टवेअर उत्पादनाचा एक अंतर्गत बीटा तयार करणे आणि वितरित करणे.

उत्पादनाचे अंतर्गत दैनंदिन वापरकर्ते आणि बाह्य अल्फा परीक्षक आहेत. ते शिप होते, डिप्लॉय होते, बिघडते आणि दुरुस्त होते. वेगळेपण हे आहे की कोडच्या प्रत्येक ओळी—अनुप्रयोग लॉजिक, चाचण्या, CI कॉन्फिगरेशन, दस्तऐवजीकरण, निरीक्षणक्षमता, आणि अंतर्गत साधने—Codex ने लिहिल्या आहेत. आमचा अंदाज आहे की हाताने कोड लिहिण्यास जितका वेळ लागला असता, त्याच्या सुमारे 1/10 वेळेत आम्ही हे तयार केले.

मानव चालवतात. एजंट कार्य करतात.

इंजिनिअरिंगचा वेग अनेक पटींनी वाढवण्यासाठी आवश्यक तेच तयार होईल यासाठी आम्ही ही मर्यादा जाणीवपूर्वक निवडली. आमच्याकडे शेवटी दशलक्ष कोड ओळींचे वितरण करण्यासाठी आठवडे होते. ते करण्यासाठी, आम्हाला हे समजून घ्यावे लागले की जेव्हा सॉफ्टवेअर अभियांत्रिकी टीमचे प्राथमिक काम कोड लिहिणे राहात नाही, तर वातावरणे डिझाइन करणे, उद्देश निर्दिष्ट करणे, आणि Codex एजंट्सना विश्वासार्ह काम करू देणारे फीडबॅक लूप्स तयार करणे होते, तेव्हा काय बदलते.

ही पोस्ट एजंट्सच्या टीमसह एक नवीन उत्पादन तयार करताना आम्ही काय शिकलो याबद्दल आहे—काय बिघडलं, काय अधिक गुंतागुंतीचं झालं, आणि आमचा एक खरोखरच दुर्मिळ संसाधन: मानवी वेळ आणि लक्ष याचा जास्तीत जास्त उपयोग कसा करायचा.

रिकाम्या रिपॉझिटरीमध्ये पहिली कमिट ऑगस्ट 2025 च्या उत्तरार्धात झाली.

प्रारंभिक स्कॅफोल्ड—रिपॉझिटरी संरचना, CI कॉन्फिगरेशन, फॉरमॅटिंग नियम, पॅकेज मॅनेजर सेटअप, आणि अ‍ॅप्लिकेशन फ्रेमवर्क—Codex CLI ने GPT‑5 चा वापर करून, विद्यमान टेम्पलेट्सच्या छोट्या संचाच्या मार्गदर्शनाखाली तयार केले गेले. एजंट्सना रिपॉझिटरीमध्ये कसे काम करायचे याचे मार्गदर्शन करणारी सुरुवातीची AGENTS.md फाईल Codex नेच लिहिली होती.

प्रणालीला आधार देण्यासाठी कोणताही पूर्व-लिखित मानवी कोड अस्तित्वात नव्हता. सुरुवातीपासूनच, रिपॉझिटरीला एजंटने आकार दिला.

पाच महिन्यांनंतर, रिपॉझिटरीमध्ये अनुप्रयोग लॉजिक, इन्फ्रास्ट्रक्चर, टूलिंग, दस्तऐवजीकरण, आणि अंतर्गत विकसक उपयुक्ततांमध्ये मिळून साधारणपणे दशलक्ष ओळींचा कोड आहे. त्या कालावधीत, Codex चालवणाऱ्या केवळ तीन अभियंत्यांच्या छोट्या टीमने सुमारे 1,500 pull request उघडल्या आणि विलीन केल्या आहेत. याचा अर्थ प्रति अभियंता प्रति दिवस सरासरी ३.५ PRs इतका थ्रुपुट होतो, आणि आश्चर्यकारकपणे संघ वाढून आता सात अभियंते झाल्यावरही थ्रुपुट वाढला आहे. महत्त्वाचे म्हणजे, हे केवळ आउटपुटसाठी आउटपुट नव्हते: उत्पादनाचा अंतर्गत शेकडो वापरकर्त्यांनी वापर केला आहे, ज्यामध्ये दररोजचे अंतर्गत पॉवर वापरकर्तेही समाविष्ट आहेत.

विकास प्रक्रियेच्या संपूर्ण कालावधीत, मानवांनी कधीही थेट कोणताही कोड योगदान दिला नाही. हे टीमसाठी एक मुख्य तत्त्वज्ञान बनले: मॅन्युअली लिहिलेला कोड नाही.

प्रत्यक्ष मानवी कोडिंगचा अभाव अभियांत्रिकी कामाचा एक वेगळा प्रकार घेऊन आला, जो प्रणाली, स्कॅफोल्डिंग, आणि लीव्हरेजवर केंद्रित होता.

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

प्रत्यक्षात, याचा अर्थ depth-first पद्धतीने काम करणे असा होता: मोठी उद्दिष्टे लहान घटकांमध्ये (डिझाइन, कोड, पुनरावलोकन, चाचणी, इ.) विभागणे, एजंटला ते घटक तयार करण्यास प्रवृत्त करणे, आणि त्यांचा वापर करून अधिक गुंतागुंतीची कामे सोडवणे. जेव्हा काहीतरी अयशस्वी झाले, तेव्हा उपाय जवळजवळ कधीच “अधिक प्रयत्न करा” असा नव्हता. कारण प्रगती करण्याचा एकमेव मार्ग Codex कडून काम करून घेणे हाच होता, मानवी अभियंते नेहमी त्या कार्यात सहभागी होत आणि विचारत: “कोणती क्षमता कमी आहे, आणि ती एजंटसाठी वाचनीय आणि अंमलबजावणीयोग्य कशी बनवायची?”

मानव प्रणालीशी जवळजवळ पूर्णपणे प्रॉम्प्टद्वारे संवाद साधतात: एक अभियंता कार्याचे वर्णन करतो, एजंट चालवतो, आणि त्याला pull request उघडण्याची परवानगी देतो. PR पूर्ण करण्यासाठी, आम्ही Codex ला त्याचे स्वतःचे बदल स्थानिक पातळीवर पुनरावलोकन करण्यास, स्थानिक आणि क्लाउडमध्ये अतिरिक्त विशिष्ट एजंट पुनरावलोकनांची विनंती करण्यास, मानव किंवा एजंटने दिलेल्या कोणत्याही अभिप्रायाला प्रतिसाद देण्यास, आणि सर्व एजंट पुनरावलोकक समाधानी होईपर्यंत लूपमध्ये पुनरावृत्ती करण्यास सांगतो (मुळात हे एक Ralph Wiggum Loop⁠(नवीन विंडोमध्ये उघडेल) आहे). Codex आमची मानक विकास साधने थेट (gh, स्थानिक स्क्रिप्ट्स, आणि रिपॉझिटरी-एम्बेडेड कौशल्ये) वापरून, माणसांनी CLI मध्ये कॉपी-पेस्ट न करता संदर्भ गोळा करते.

मानव pull request चे पुनरावलोकन करू शकतात, परंतु ते आवश्यक नाही. कालांतराने, आम्ही जवळजवळ सर्व पुनरावलोकन प्रयत्न एजंट-टू-एजंट पद्धतीने हाताळण्याकडे वळवले आहेत.

कोड थ्रुपुट वाढल्यामुळे, आमची अडचण मानवी QA क्षमतेमध्ये झाली. कारण स्थिर मर्यादा मानवी वेळ आणि लक्ष हीच राहिली आहे, म्हणून application UI, logs, आणि app metrics यांसारख्या गोष्टी Codex ला थेट वाचता येतील अशा करून आम्ही एजंटमध्ये अधिक क्षमता जोडण्यासाठी काम केले आहे.

उदाहरणार्थ, आम्ही git worktree नुसार ॲपला बूट करण्यायोग्य बनवले, त्यामुळे Codex प्रत्येक बदलासाठी एक instance सुरू करून चालवू शकत होते. आम्ही Chrome DevTools प्रोटोकॉलला एजंट रनटाइममध्ये समाकलित केले आणि DOM स्नॅपशॉट्स, स्क्रीनशॉट्स आणि नेव्हिगेशनसह काम करण्यासाठी कौशल्ये विकसित केली. यामुळे Codex ला बग्सचे पुनरुत्पादन करणे, फिक्सेसची पडताळणी करणे, आणि UI वर्तनाबद्दल थेट विचार करणे शक्य झाले.

आम्ही निरीक्षणक्षमता साधनांसाठीही तेच केले. लॉग्स, मेट्रिक्स आणि ट्रेसेस Codex ला स्थानिक निरीक्षण स्टॅकद्वारे उपलब्ध करून दिले जातात, जो कोणत्याही दिलेल्या वर्कट्रीसाठी तात्पुरता असतो. Codex त्या अ‍ॅपच्या पूर्णपणे वेगळ्या केलेल्या आवृत्तीवर काम करतो—त्यातील लॉग्स आणि मेट्रिक्ससह, जे काम पूर्ण झाल्यावर हटवले जातात. एजंट LogQL वापरून लॉग्सवर क्वेरी करू शकतात आणि PromQL वापरून मेट्रिक्सवर क्वेरी करू शकतात. हा संदर्भ उपलब्ध असल्याने, “ensure service startup completes in under 800ms” किंवा “no span in these four critical user journeys exceeds two seconds” यांसारखे प्रॉम्प्ट हाताळण्याजोगे होतात.

आम्ही नियमितपणे पाहतो की एकाच Codex रनमध्ये एकाच कार्यावर सहा तासांपेक्षा जास्त काळ काम चालू असते (अनेकदा माणसे झोपलेली असताना).

मोठ्या आणि जटिल कामांमध्ये एजंट्सना प्रभावी बनवण्यासाठी संदर्भ व्यवस्थापन हे सर्वात मोठ्या आव्हानांपैकी एक आहे. आम्ही शिकलेल्या पहिल्या धड्यांपैकी एक साधा होता: Codex ला 1,000-पानांच्या सूचना पुस्तिकेऐवजी एक नकाशा द्या.

आम्ही “one big AGENTS.md⁠(नवीन विंडोमध्ये उघडेल)” वापरून पाहिले दृष्टिकोन. ते अपेक्षित पद्धतींनी अयशस्वी झाले:

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

त्यामुळे AGENTS.md ला ज्ञानकोश म्हणून मानण्याऐवजी, आम्ही त्याला अनुक्रमणिका म्हणून पाहतो.

रिपॉझिटरीचा ज्ञानसंग्रह संरचित docs/ डिरेक्टरीमध्ये असतो, ज्याला 'system of record' म्हणून मानले जाते. एक लहान AGENTS.md (सुमारे 100 ओळी) संदर्भात समाविष्ट केला जातो आणि मुख्यतः नकाशा म्हणून कार्य करतो, ज्यामध्ये इतरत्र असलेल्या सत्याच्या अधिक सखोल स्रोतांकडे निर्देश असतात.

डिझाइन दस्तऐवजीकरणाचे कॅटलॉगिंग आणि अनुक्रमणिका तयार केली जाते, ज्यामध्ये पडताळणी स्थिती आणि एजंट-प्रथम कार्यपद्धतीची तत्त्वे परिभाषित करणाऱ्या मूलभूत विश्वासांचा संच समाविष्ट आहे. आर्किटेक्चर दस्तऐवजीकरण⁠(नवीन विंडोमध्ये उघडेल) डोमेन्स आणि पॅकेज लेयरिंगचा शीर्ष-स्तरीय नकाशा प्रदान करते. गुणवत्तेचा दस्तऐवज प्रत्येक उत्पादन डोमेन आणि आर्किटेक्चरल स्तराला श्रेणी देतो आणि कालांतराने अंतरांचा मागोवा घेतो.

योजनांना प्रथम श्रेणीतील कलाकृती म्हणून मानले जाते. लहान बदलांसाठी तात्पुरत्या हलक्या योजना वापरल्या जातात, तर गुंतागुंतीचे काम प्रगती आणि निर्णय लॉग्ससह अंमलबजावणी योजनांमध्ये⁠(नवीन विंडोमध्ये उघडेल) नोंदवले जाते, जे रिपॉझिटरीमध्ये चेक इन केले जातात. सक्रिय योजना, पूर्ण झालेल्या योजना, आणि ज्ञात तांत्रिक कर्जे सर्व आवृत्तीबद्ध आणि एकत्रित ठेवलेली असतात, ज्यामुळे एजंट्सना बाह्य संदर्भावर अवलंबून न राहता कार्य करता येते.

यामुळे टप्प्याटप्प्याने माहिती उघड करणे सक्षम होते: एजंट्स एका लहान, स्थिर प्रवेशबिंदूपासून सुरुवात करतात आणि सुरुवातीलाच भारावून न जाता पुढे कुठे पाहायचे ते त्यांना शिकवले जाते.

आम्ही हे यांत्रिक पद्धतीने अंमलात आणतो. समर्पित लिंटर्स आणि CI जॉब्स हे तपासतात की ज्ञान बेस अद्ययावत आहे, क्रॉस-लिंक केलेला आहे आणि योग्यरित्या संरचित आहे. पुन्हा-पुन्हा चालणारा “doc-gardening” एजंट वास्तविक कोडच्या वर्तनाचे प्रतिबिंब न दाखवणारे जुने किंवा कालबाह्य दस्तऐवजीकरण शोधण्यासाठी स्कॅन करतो आणि दुरुस्तीसाठी pull request उघडतो.

कोडबेस विकसित होत असताना, डिझाइन निर्णयांसाठी Codex चे फ्रेमवर्क देखील विकसित होणे आवश्यक होते.

रिपॉझिटरी पूर्णपणे एजंट-निर्मित असल्यामुळे, ती सर्वप्रथम Codex च्या वाचनयोग्यता साठी ऑप्टिमाईझ केलेली आहे. ज्या प्रकारे संघ नवीन अभियांत्रिकी भरतींसाठी त्यांच्या कोडची नेव्हिगेबिलिटी सुधारण्याचा प्रयत्न करतात, त्याचप्रमाणे आमच्या मानवी अभियंत्यांचे उद्दिष्ट असे होते की एखाद्या एजंटला संपूर्ण व्यवसाय डोमेनबद्दल थेट रिपॉझिटरीमधून विचार करता येईल.

एजंटच्या दृष्टीकोनातून, जे काही ते चालू असताना संदर्भात प्रभावीपणे प्रवेश करू शकत नाही, ते प्रत्यक्षात अस्तित्वातच नाही. Google Docs, चॅट थ्रेड्स किंवा लोकांच्या डोक्यात असलेले ज्ञान प्रणालीला प्रवेश करण्यायोग्य नाही. रिपॉझिटरी-लोकल, आवृत्तीबद्ध आर्टिफॅक्ट्स (उदा., कोड, मार्कडाउन, स्कीमा, कार्यान्वित योजना) एवढेच ते पाहू शकते.

आम्हाला हे शिकायला मिळाले की कालांतराने रेपोमध्ये अधिकाधिक संदर्भ पुश करणे आवश्यक होते. टीमला आर्किटेक्चरल पॅटर्नवर एकमत करून देणारी ती Slack चर्चा? जर एजंटला ते सापडत नसेल, तर ते वाचता येण्यासारखेच नाही—जसे तीन महिन्यांनी सामील होणाऱ्या नव्या कर्मचाऱ्याला ते अज्ञात राहील.

Codex ला अधिक संदर्भ देणे म्हणजे योग्य माहिती आयोजित करून ती उपलब्ध करून देणे, जेणेकरून एजंट त्यावर विचार करू शकेल, त्याला तात्पुरत्या सूचनांनी गोंधळून टाकण्याऐवजी. ज्या प्रकारे तुम्ही उत्पादन तत्त्वे, अभियांत्रिकी मानदंड, आणि टीम संस्कृती (emoji प्राधान्येही समाविष्ट) यांबद्दल नवीन सहकाऱ्याचे ऑनबोर्डिंग करता, त्याच प्रकारे एजंटला ही माहिती दिल्यास अधिक सुसंगत आउटपुट मिळते.

या फ्रेमिंगने अनेक तडजोडी स्पष्ट केल्या. आम्ही अशा अवलंबनांना आणि अमूर्ततांना प्राधान्य दिले ज्यांना रेपोमध्येच पूर्णपणे आत्मसात करून त्याबद्दल तर्क करता येऊ शकेल. “कंटाळवाणे” म्हणून अनेकदा वर्णन केली जाणारी तंत्रज्ञाने संयोज्यता, API स्थिरता, आणि प्रशिक्षण संचातील प्रतिनिधित्व यांमुळे एजंट्ससाठी मॉडेल करणे अधिक सोपे असते. काही प्रकरणांमध्ये, सार्वजनिक लायब्ररींमधील अस्पष्ट अपस्ट्रीम वर्तनाला टाळण्यापेक्षा एजंटकडून कार्यक्षमतेचे उपसंच पुन्हा अंमलात आणणे अधिक स्वस्त होते. उदाहरणार्थ, सर्वसाधारण p-limit-शैलीचे पॅकेज आणण्याऐवजी, आम्ही आमचा स्वतःचा map-with-concurrency सहाय्यक अंमलात आणला: तो आमच्या OpenTelemetry साधनांसोबत घट्टपणे एकत्रित आहे, त्याला १००% चाचणी कव्हरेज आहे, आणि तो आमच्या रनटाइमला जसा अपेक्षित आहे तसाच वागतो.

एजंट थेट तपासू, पडताळू आणि बदलू शकतो अशा स्वरूपात प्रणालीचा अधिक भाग आणल्याने लाभ वाढतो—फक्त Codex साठीच नाही, तर इतर एजंट्ससाठीही (उदा. Aardvark) जे कोडबेसवरही काम करत आहेत.

फक्त डॉक्युमेंटेशनमुळे पूर्णपणे एजंट-निर्मित कोडबेस सुसंगत राहू शकत नाही. अंमलबजावण्यांचे सूक्ष्म व्यवस्थापन न करता, अपरिवर्तनीय नियमांची अंमलबजावणी करून, आम्ही एजंटना पाया कमकुवत न करता वेगाने शिप करण्याची अनुमती देतो. उदाहरणार्थ, आम्हाला Codex कडून सीमेवर डेटा आकार पार्स करणे⁠(नवीन विंडोमध्ये उघडेल) आवश्यक आहे, परंतु ते कसे करावे याबद्दल आम्ही ठाम नाही (मॉडेलला Zod आवडते असे दिसते, परंतु आम्ही ती विशिष्ट लायब्ररी निर्दिष्ट केलेली नाही).

एजंट्स कडक सीमा आणि अंदाज करता येण्याजोगी रचना⁠(नवीन विंडोमध्ये उघडेल) असलेल्या वातावरणात सर्वाधिक प्रभावी असतात, म्हणून आम्ही अनुप्रयोग एका कठोर आर्किटेक्चरल मॉडेलवर आधारित तयार केला. प्रत्येक व्यवसाय डोमेनला निश्चित स्तरांच्या संचात विभागले जाते, ज्यामध्ये अवलंबित्वाच्या दिशांचे काटेकोरपणे प्रमाणीकरण केले जाते आणि अनुमत काठांचा संच मर्यादित असतो. ही बंधने कस्टम लिन्टर्स (Codex-जनरेटेड, अर्थातच!) आणि संरचनात्मक चाचण्यांद्वारे यांत्रिकरीत्या लागू केली जातात.

खालील आकृती नियम दर्शवते: प्रत्येक व्यवसाय क्षेत्रामध्ये (उदा. अ‍ॅप सेटिंग्ज), कोड फक्त लेयर्सच्या एका निश्चित संचामधून “फॉरवर्ड” दिशेनेच अवलंबून राहू शकतो (Types → Config → Repo → Service → Runtime → UI). क्रॉस-कटिंग बाबी (auth, connectors, telemetry, feature flags) एका एकमेव स्पष्ट इंटरफेसद्वारे प्रवेश करतात: प्रोव्हायडर्स. इतर काहीही अनुमत नाही आणि त्याची अंमलबजावणी यांत्रिक पद्धतीने केली जाते.

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

प्रत्यक्षात, आम्ही हे नियम कस्टम लिंटर्स आणि संरचनात्मक चाचण्यांद्वारे, तसेच “अभिरुची अपरिवर्तनीयता” च्या एका छोट्या संचाद्वारे अंमलात आणतो. उदाहरणार्थ, आम्ही संरचित लॉगिंग, स्कीमा आणि प्रकारांसाठी नामकरण परंपरा, फाइल आकार मर्यादा, आणि प्लॅटफॉर्म-विशिष्ट विश्वसनीयता आवश्यकता कस्टम लिंट्सच्या मदतीने स्थिरपणे अंमलात आणतो. लिंट्स सानुकूल असल्यामुळे, आम्ही त्रुटी संदेश असे लिहितो की एजंटच्या संदर्भात सुधारणा सूचना समाविष्ट करता येतील.

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

त्याच वेळी, बंधने कुठे महत्त्वाची आहेत आणि कुठे नाहीत याबाबत आम्ही स्पष्ट आहोत. हे मोठ्या अभियांत्रिकी प्लॅटफॉर्म संघटनेचे नेतृत्व करण्यासारखे आहे: केंद्रातून सीमा अंमलात आणा, स्थानिक पातळीवर स्वायत्तता द्या. तुम्ही सीमारेषा, अचूकता आणि पुनरुत्पादकता याबद्दल खूपच काळजी करता. त्या मर्यादांमध्ये, उपाययोजना कशा मांडल्या जातात याबाबत तुम्ही संघांना—किंवा एजंट्सना—लक्षणीय स्वातंत्र्य देता.

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

मानवी अभिरुची प्रणालीमध्ये सतत परत दिली जाते. पुनरावलोकन टिप्पण्या, refactoring pull requests, आणि वापरकर्त्यांसमोर दिसणारे बग्स दस्तऐवजीकरण अद्यतन म्हणून नोंदवले जातात किंवा थेट साधनांमध्ये एन्कोड केले जातात. जेव्हा दस्तऐवजीकरण अपूर्ण ठरते, तेव्हा आम्ही त्या नियमाला कोडमध्ये रूपांतरित करतो

Codex चा थ्रुपुट वाढल्यामुळे, अनेक पारंपरिक अभियांत्रिकी मानदंड प्रतिकूल ठरले.

हे रिपॉझिटरी कमीत कमी ब्लॉकिंग मर्ज गेट्ससह कार्य करते. pull request अल्पकालीन असतात. टेस्ट फ्लेक्सना प्रगतीला अनिश्चित काळासाठी अडथळा आणण्याऐवजी अनेकदा फॉलो-अप रनद्वारे सोडवले जाते. ज्या प्रणालीमध्ये एजंट थ्रुपुट मानवी लक्षापेक्षा खूपच जास्त असतो, तिथे दुरुस्त्या स्वस्त असतात आणि प्रतीक्षा करणे महाग असते.

कमी-थ्रुपुट वातावरणात हे बेजबाबदारपणाचे ठरेल. इथे, ही अनेकदा योग्य तडजोड असते.

जेव्हा आम्ही म्हणतो की कोडबेस Codex एजंट्सद्वारे तयार केला जातो, तेव्हा आमचा अर्थ कोडबेसमधील सर्वकाही होय.

एजंट उत्पादन करतात:

• उत्पादन कोड आणि चाचण्या
• CI कॉन्फिगरेशन आणि रिलीझ साधने
• अंतर्गत विकसक साधने
• दस्तऐवजीकरण आणि डिझाइनचा इतिहास
• मूल्यांकन हार्नेस
• रिव्ह्यू टिप्पण्या आणि प्रतिसाद
• स्वत:च रिपॉझिटरी व्यवस्थापित करणाऱ्या स्क्रिप्ट्स
• उत्पादन डॅशबोर्ड परिभाषा फाइल्स

मानव नेहमी लूपमध्ये राहतात, परंतु ते पूर्वी ज्या पातळीवर काम करत होते त्यापेक्षा वेगळ्या अमूर्ततेच्या स्तरावर काम करतात. आम्ही कामाला प्राधान्य देतो, वापरकर्त्यांचा अभिप्राय स्वीकृती निकषांमध्ये रूपांतरित करतो आणि निकालांची पडताळणी करतो. जेव्हा एजंट अडखळतो, तेव्हा आम्ही त्याला एक संकेत मानतो: काय कमी आहे ते ओळखा—साधने, गार्डरेल, दस्तऐवजीकरण—आणि ते परत रिपॉझिटरीमध्ये फीड करा, नेहमी Codex कडूनच दुरुस्ती लिहून घेऊन.

एजंट्स आमची मानक विकास साधने थेट वापरतात. ते पुनरावलोकन अभिप्राय घेतात, इनलाइन प्रतिसाद देतात, अद्यतने पुश करतात, आणि अनेकदा त्यांच्या स्वतःच्या pull request स्क्वॅश करून मर्ज करतात.

विकास लूपचा अधिक भाग थेट प्रणालीमध्ये एन्कोड केल्यामुळे—चाचणी, वैधता, पुनरावलोकन, अभिप्राय हाताळणी, आणि पुनर्प्राप्ती—रिपॉझिटरीने अलीकडेच एक अर्थपूर्ण टप्पा ओलांडला जिथे Codex एंड-टू-एंड नवीन वैशिष्ट्य चालवू शकतो.

एका प्रॉम्प्टसह, एजंट आता हे करू शकतो:

• कोडबेसची सध्याची स्थिती सत्यापित करा
• अहवाल दिलेल्या बगचे पुनरुत्पादन करा
• अपयश दाखवणारा व्हिडिओ रेकॉर्ड करा
• दुरुस्ती लागू करा
• अ‍ॅप्लिकेशन चालवून दुरुस्तीची पडताळणी करा
• रिझोल्यूशनचे प्रात्यक्षिक दाखवणारा दुसरा व्हिडिओ रेकॉर्ड करा
• pull request उघडा
• एजंट आणि मानवी अभिप्रायाला प्रतिसाद द्या
• बिल्ड अपयश शोधा आणि त्यांचे निराकरण करा
• निर्णय आवश्यक असेल तेव्हाच मानवी व्यक्तीकडे एस्केलेट करा
• बदल एकत्र करा

हे वर्तन या रिपॉझिटरीच्या विशिष्ट रचना आणि साधनांवर मोठ्या प्रमाणात अवलंबून आहे आणि तत्सम गुंतवणूक केल्याशिवाय ते सर्वसाधारणपणे लागू होईल असे गृहीत धरू नये—किमान, अजून तरी नाही.

पूर्ण एजंट स्वायत्तता नवीन समस्या देखील निर्माण करते. Codex रिपॉझिटरीमध्ये आधीपासून अस्तित्वात असलेल्या पॅटर्न्सची प्रतिकृती तयार करतो—असमान किंवा उप-इष्ट पॅटर्न्ससुद्धा. कालांतराने, यामुळे अनिवार्यपणे विचलन होते.

सुरुवातीला, मानवांनी हे हाताने हाताळले. आमची टीम दर शुक्रवारी (आठवड्याच्या २०%) 'AI स्लॉप' साफ करण्यात वेळ घालवत असे. नवल नाही, ते प्रमाणात वाढले नाही.

त्याऐवजी, आम्ही ज्यांना “सुवर्ण तत्त्वे” म्हणतो ती थेट रिपॉझिटरीमध्ये एन्कोड करायला सुरुवात केली आणि एक आवर्ती स्वच्छता प्रक्रिया तयार केली. ही तत्त्वे मताधारित, यांत्रिक नियम आहेत जी भविष्यातील एजंट रनसाठी कोडबेसला वाचनीय आणि सुसंगत ठेवतात. उदाहरणार्थ: (1) इनव्हेरिएंट्स केंद्रीकृत ठेवण्यासाठी आम्ही हाताने बनवलेल्या सहाय्यकांपेक्षा सामायिक उपयुक्तता पॅकेजेसना प्राधान्य देतो, आणि (2) आम्ही डेटा “YOLO-शैली” मध्ये तपासत नाही—आम्ही सीमारेषांची पडताळणी करतो किंवा टाइप्ड SDKs वर अवलंबून राहतो, त्यामुळे एजंट चुकूनही अंदाजे आकारांवर आधारित काहीतरी तयार करू शकत नाही. नियमित अंतराने, आमच्याकडे बॅकग्राउंड Codex कार्यांचा एक संच आहे जो विचलनांसाठी स्कॅन करतो, गुणवत्ता ग्रेड्स अद्यतनित करतो, आणि लक्षित रिफॅक्टरिंग pull request उघडतो. यापैकी बहुतेकांचे एका मिनिटापेक्षा कमी वेळेत पुनरावलोकन करता येऊ शकते आणि स्वयंचलितपणे मर्ज केले जाऊ शकते.

हे कचरा संकलनासारखे कार्य करते. तांत्रिक कर्ज हे उच्च व्याजाच्या कर्जासारखे आहे: ते चक्रवाढ होऊ देऊन वेदनादायक टप्प्याटप्प्याने हाताळण्यापेक्षा, सतत लहान टप्प्यांत ते कमी करत राहणे जवळजवळ नेहमीच अधिक चांगले असते. मानवी अभिरुची एकदाच टिपली जाते आणि नंतर कोडच्या प्रत्येक ओळीवर सतत लागू केली जाते. यामुळे आम्हाला वाईट पॅटर्न्स रोजच्या आधारावर पकडता येतात आणि त्यांचे निराकरण करता येते, त्यांना कोड बेसमध्ये दिवस किंवा आठवडे पसरू देण्याऐवजी.

ही रणनीती आतापर्यंत OpenAI मध्ये अंतर्गत लाँच आणि स्वीकारासाठी चांगली काम करत आली आहे. खऱ्या वापरकर्त्यांसाठी एक वास्तविक उत्पादन तयार केल्याने आमच्या गुंतवणुकीला वास्तवाशी जोडण्यास मदत झाली आणि आम्हाला दीर्घकालीन देखभालक्षमतेकडे मार्गदर्शन केले.

तुम्हाला अद्याप हे माहित नाही की पूर्णपणे एजंट-निर्मित प्रणालीमध्ये आर्किटेक्चरल सुसंगती वर्षानुवर्षे कशी विकसित होते. तुम्ही अजूनही शिकत आहोत की मानवी निर्णय कुठे सर्वाधिक प्रभाव टाकतो आणि तो निर्णय कसा एन्कोड करायचा जेणेकरून त्याचा प्रभाव वाढत जाईल. मॉडेल कालांतराने अधिक सक्षम होत राहिल्यामुळे ही प्रणाली कशी विकसित होईल हे आम्हाला देखील माहीत नाही.

जे स्पष्ट झाले आहे: सॉफ्टवेअर तयार करण्यासाठी अजूनही शिस्त आवश्यक आहे, परंतु ती शिस्त कोडपेक्षा अधिक सहाय्यक संरचनेत दिसून येते. कोडबेस सुसंगत ठेवण्यासाठी टूलिंग, अब्स्ट्रॅक्शन्स आणि फीडबॅक लूप्स अधिकाधिक महत्त्वाचे होत आहेत.

आमची सर्वात कठीण आव्हाने आता वातावरण, फीडबॅक लूप्स आणि नियंत्रण प्रणालींच्या डिझाइनवर केंद्रित आहेत जे एजंट्सना आमचे ध्येय साध्य करण्यात मदत करतात: मोठ्या प्रमाणावर जटिल, विश्वासार्ह सॉफ्टवेअर तयार करणे आणि टिकवून ठेवणे.

Codex सारखे एजंट सॉफ्टवेअर जीवनचक्रातील मोठे भाग हाताळू लागल्यावर, हे प्रश्न अधिक महत्त्वाचे ठरतील. आम्हाला आशा आहे की काही सुरुवातीचे धडे शेअर केल्याने तुम्हाला तुमचा प्रयत्न कुठे गुंतवायचा याबद्दल विचार करण्यास मदत होईल, जेणेकरून तुम्ही फक्त गोष्टी तयार करू शकता.