OpenAI ने सिर्फ एजेंट्स से 10 लाख लाइन कोड कैसे बनाया: Harness Engineering के 5 सिद्धांत

हाल ही में “harness” शब्द बार-बार सामने आ रहा है। OpenAI द्वारा प्रकाशित एक ब्लॉग पोस्ट ने आखिरकार इस अवधारणा को स्पष्ट रूप से परिभाषित किया। एजेंट्स के युग में इंजीनियर्स को वास्तव में क्या करना चाहिए, आइए समझते हैं।

Harness वह टूल शेल है जो AI एजेंट को वास्तविक दुनिया पर प्रभाव डालने में सक्षम बनाता है। अगर रीज़निंग मॉडल दिमाग है, तो harness हाथ-पैर हैं। फ़ाइलें पढ़ना, कोड ठीक करना, टेस्ट चलाना, प्रोडक्शन में डिप्लॉय करना, यह सब harness के अंदर होता है।

OpenAI की एक आंतरिक टीम ने अगस्त 2025 के अंत में एक खाली रिपॉज़िटरी से शुरुआत की और केवल Codex एजेंट्स का उपयोग करके 10 लाख लाइन का प्रोडक्ट बनाया। शर्त सीधी थी: कोई भी इंसान कोड नहीं लिखेगा। उन्होंने बताया कि मैन्युअल डेवलपमेंट की तुलना में दसवां हिस्सा समय लगा। इस प्रक्रिया में उन्होंने जो पाँच सिद्धांत खोजे, वे नीचे दिए गए हैं।

जो ज्ञान एजेंट देख नहीं सकता, वह मौजूद नहीं है

Codex के नज़रिए से, रनटाइम पर जो जानकारी एक्सेस नहीं हो सकती, वह न होने के बराबर है। Google Docs में प्लानिंग डॉक्यूमेंट, Slack पर तय की गई आर्किटेक्चर दिशा, किसी के दिमाग में बंद tacit knowledge, कुछ भी दिखाई नहीं देता। यह वही स्थिति है जो तीन महीने बाद जुड़ने वाले नए कर्मचारी को झेलनी पड़ती।

इसलिए टीम ने हर फ़ैसले को रिपॉज़िटरी में markdown, schemas और execution plans (ExecPlans) के रूप में डाल दिया।

• ExecPlan PLANS.md में परिभाषित एक स्वयं-पूर्ण डिज़ाइन डॉक्यूमेंट है
• पास होने का मानदंड: एक शुरुआती व्यक्ति इसे पढ़कर पूरा फ़ीचर इम्प्लीमेंट कर सके
• ऐसे मामले हैं जहाँ Codex ने एक ही प्रॉम्प्ट पर 7 घंटे से अधिक लगातार काम किया
• यह संरचना matklad के ARCHITECTURE.md कॉन्सेप्ट को एजेंट उपयोग के लिए विस्तारित करती है

”और मेहनत करो” के बजाय पूछो “कौन सी क्षमता गायब है”

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

• बाहरी लाइब्रेरी के बजाय खुद बनाए गए concurrency helpers, OpenTelemetry के साथ 100% इंटीग्रेशन
• तथाकथित “बोरिंग टेक्नोलॉजी” एजेंट्स के लिए फ़ायदेमंद साबित होती है (API स्थिरता और ट्रेनिंग डेटा में उच्च प्रतिनिधित्व के कारण)

मैकेनिकल एनफ़ोर्समेंट, न कि डॉक्यूमेंटेशन, कोड की संगति बनाए रखता है

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

• प्रत्येक बिज़नेस डोमेन के लिए निश्चित लेयर्स: Providers → Service → Runtime → UI
• Cross-cutting concerns स्ट्रक्चर जहाँ Types, Config और Repo निचले स्तरों पर साझा होते हैं
• कस्टम linters और structural tests उल्लंघन पर तुरंत बिल्ड फ़ेल करते हैं
• Linters खुद भी Codex द्वारा लिखे गए

एजेंट को आँखें दो और वह 6 घंटे अकेले काम करता है

टीम ने Chrome DevTools Protocol को एजेंट रनटाइम से जोड़ा, जिससे Codex को DOM snapshots, screenshots और navigation की क्षमता मिली। संरचना टास्क से पहले और बाद के snapshots की तुलना करती है, runtime events को observe करती है, फिर सब कुछ साफ़ होने तक loop में fixes लागू करती है।

Observability tools भी उसी तरीके से जोड़े गए। हर git worktree के लिए एक अस्थायी observability stack शुरू होता है और काम पूरा होने पर गायब हो जाता है।

• Victoria Logs (LogQL) और Victoria Metrics (PromQL) से एजेंट सीधे logs और metrics query कर सकता है
• “सर्विस को 800ms से कम में स्टार्ट करवाओ” जैसे prompts executable बन गए
• एकल Codex रन नियमित रूप से एक टास्क पर 6 घंटे से अधिक फ़ोकस बनाए रखते हैं

नक्शा दो, 1,000 पेज का मैन्युअल नहीं

Context management एजेंट की प्रभावशीलता तय करता है। शुरू में टीम ने सब कुछ एक विशाल AGENTS.md फ़ाइल में ठूँसने की कोशिश की, विफल रहे। matklad द्वारा 2021 में लिखा गया ARCHITECTURE.md कॉन्सेप्ट यहाँ अपनी काबिलियत साबित करता है। सिद्धांत: प्रोजेक्ट संरचना का संक्षिप्त ऊँचाई से दृश्य दें, केवल वही शामिल करें जो शायद ही बदलता हो। एजेंट्स पर भी यही सिद्धांत लागू होता है।

• ARCHITECTURE.md एक code map है, code atlas नहीं
• Architectural invariants अक्सर “कुछ मौजूद नहीं है” के रूप में व्यक्त होते हैं
• Boundaries को स्पष्ट रूप से बताना downstream के सारे implementation को constrain करता है

अभी भी अनुत्तरित प्रश्न

Codex टीम के लिए भी कुछ प्रश्न अनुत्तरित हैं। कोई नहीं जानता कि पूरी तरह एजेंट्स द्वारा बनाई गई प्रणाली वर्षों तक architectural consistency बनाए रख सकती है या नहीं। मॉडल्स के सुधार के साथ यह फ़्रेमवर्क खुद कैसे बदलेगा, यह भी अनिश्चित है।

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