- OpenAI की एक आंतरिक टीम का 5 महीनों तक मैन्युअल कोड लिखे बिना एक सॉफ़्टवेयर प्रोडक्ट का internal beta बनाकर जारी करने का प्रयोग, जिसमें सारा कोड Codex एजेंट ने जनरेट किया
- 3 इंजीनियरों से शुरू होकर लगभग 10 लाख लाइनों का कोड और 1,500 pull request संभाले गए, और प्रति इंजीनियर प्रति दिन औसतन 3.5 PR मर्ज हुए
- इंजीनियर की भूमिका सीधे coding से बदलकर environment design, intent specification, feedback loop निर्माण की हो गई, और एजेंट के स्थिर रूप से काम करने लायक scaffolding बनाना मुख्य रहा
- AGENTS.md को विश्वकोश नहीं बल्कि table of contents की तरह इस्तेमाल किया गया, और structured docs, linter, तथा structural tests के जरिए architecture consistency को मशीन की मदद से लागू किया गया
- एजेंट की autonomy बढ़ने के साथ entropy management और garbage collection जैसी निरंतर सफ़ाई अनिवार्य हो जाती है, और software निर्माण का अनुशासन code से scaffolding की ओर खिसक रहा है
खाली git repository से शुरू किया गया प्रयोग
- 2025 के अगस्त के अंत में एक खाली repository में पहला commit किया गया, और शुरुआती scaffold (repository structure, CI config, formatting rules, package manager settings, application framework) मौजूदा template के आधार पर GPT-5 का उपयोग करके Codex CLI में जनरेट किया गया
- एजेंट को repository पर काम करने का तरीका बताने वाली शुरुआती AGENTS.md फ़ाइल भी Codex ने खुद लिखी
- शुरुआत से ही इंसानों द्वारा लिखा कोई मौजूदा code नहीं था; repository एजेंट द्वारा ही आकार ली गई
- 5 महीने बाद application logic, infra, tooling, documentation, और internal developer utilities समेत लगभग 10 लाख लाइनों का code शामिल था
- 3 लोगों की छोटी टीम ने लगभग 1,500 pull request खोले और मर्ज किए, जो प्रति इंजीनियर प्रति दिन औसतन 3.5 PR throughput के बराबर है
- टीम 7 लोगों तक बढ़ने पर throughput उल्टा और बढ़ गया
- सैकड़ों उपयोगकर्ता इसे रोज़ाना आंतरिक रूप से इस्तेमाल करते रहे, जिनमें internal power users भी शामिल थे
- पूरे development process में इंसानों ने code में सीधे कोई योगदान नहीं दिया
- "मैन्युअल रूप से लिखा गया code नहीं है" टीम का मुख्य दर्शन बन गया
इंजीनियर की भूमिका की पुनर्परिभाषा
- चूंकि इंसान सीधे code नहीं लिखते, इसलिए system, scaffolding और leverage-केंद्रित अलग तरह का engineering work ज़रूरी हुआ
- शुरुआती प्रगति उम्मीद से धीमी रहने की वजह Codex की क्षमता की कमी नहीं बल्कि environment की कमी थी
- एजेंट के पास high-level goals हासिल करने के लिए ज़रूरी tools, abstractions और internal structure की कमी थी
- engineering team का मुख्य काम एजेंट को उपयोगी काम करने लायक बनाना हो गया
- बड़े लक्ष्यों को छोटे building blocks (design, code, review, test आदि) में तोड़ना, और एजेंट से इन blocks को जोड़कर अधिक जटिल काम हल कराना एक depth-first workflow बन गया
- असफलता की स्थिति में सवाल "और ज़्यादा मेहनत करो" नहीं, बल्कि "कौन-सी capability गायब है, और इसे एजेंट के लिए पढ़ने व चलाने में आसान कैसे बनाया जाए" बन गया
- इंसान लगभग पूरी तरह prompts के जरिए system के साथ interact करते हैं
- task description देना, agent run शुरू करना, pull request खुलवाना आदि
- PR पूरा कराने के लिए Codex को निर्देश दिया जाता है कि वह local में अपने बदलावों की समीक्षा करे, local और cloud दोनों में agent review जोड़े, feedback का जवाब दे, और सभी agent reviewers के संतुष्ट होने तक दोहराए
- यह व्यवहारिक रूप से Ralph Wiggum Loop जैसा है
- Codex context इकट्ठा करने के लिए gh, local scripts और repository में बने skills जैसे standard developer tools सीधे इस्तेमाल करता है
- इंसानी pull request review संभव है, पर अनिवार्य नहीं; समय के साथ लगभग सारा review काम agents के बीच शिफ्ट हो गया
application की readability बढ़ाना
- code throughput बढ़ने के साथ human QA capacity bottleneck बन गई
- क्योंकि इंसानी समय और ध्यान fixed constraint हैं, इसलिए application UI, logs, app metrics आदि को Codex के सीधे पढ़ने और समझने लायक बनाकर एजेंट को नई capabilities दी गईं
- git worktree-आधारित app booting के जरिए Codex हर change के लिए अलग instance चला और नियंत्रित कर सकता है
- Chrome DevTools Protocol को agent runtime से जोड़ा गया, और DOM snapshots, screenshots, तथा navigation tasks के लिए skills बनाए गए
- इससे Codex bug reproduce कर सकता है, fix verify कर सकता है, और UI behavior पर खुद reasoning कर सकता है
- observability tooling पर भी यही तरीका लागू किया गया
- logs, metrics और traces को हर worktree के लिए अस्थायी रूप से बने local observability stack के जरिए Codex के सामने रखा गया
- काम पूरा होने के बाद logs और metrics हटा दिए जाते हैं
- एजेंट LogQL से logs और PromQL से metrics query कर सकता है
- इस तरह का context मिलने पर "service startup 800ms के अंदर पूरा हो" या "चार मुख्य user journeys में कोई span 2 seconds से ज़्यादा न हो" जैसे prompts संभालना आसान हो जाता है
- एक बार के Codex run में 6 घंटे से ज़्यादा तक (अक्सर इंसानों के सोने के दौरान) एक ही task पर काम हो सकता है
repository ज्ञान को record system की तरह इस्तेमाल करना
- context management, बड़े और जटिल tasks को प्रभावी ढंग से करवाने में एजेंट के लिए सबसे बड़ी चुनौतियों में से एक है
- शुरुआती सीख: Codex को 1,000 पन्नों की manual नहीं, एक map देना चाहिए
- "एक बड़ा AGENTS.md" वाला approach आज़माया गया, और वह अनुमान के मुताबिक असफल रहा
- context एक scarce resource है: बहुत बड़ी instructions file task, code और संबंधित docs को उलझा देती है, जिससे एजेंट मुख्य constraints मिस कर देता है या गलत constraints पर optimize करने लगता है
- बहुत ज़्यादा instructions, instructions नहीं रह जातीं: अगर सब कुछ "महत्वपूर्ण" है, तो कुछ भी महत्वपूर्ण नहीं रहता; एजेंट deliberate exploration के बजाय local pattern matching करता है
- यह बहुत जल्दी बिगड़ जाता है: एकसमान बड़ा manual जल्दी ही पुराने नियमों की कब्र बन जाता है, और एजेंट नहीं समझ पाता कि क्या अब भी valid है
- इसे verify करना कठिन है: एक single blob mechanical checks (coverage, freshness, ownership, cross-linking) के लिए उपयुक्त नहीं, इसलिए drift अपरिहार्य हो जाती है
- समाधान: AGENTS.md को विश्वकोश नहीं बल्कि table of contents की तरह मानना
- repository का knowledge base structured
docs/ directory में record system के रूप में मैनेज किया गया
- छोटा AGENTS.md (लगभग 100 lines) context में inject किया जाता है और मुख्यतः map की भूमिका निभाता है, जो अधिक गहरे और भरोसेमंद information sources की ओर निर्देशित करता है
- design documentation में validation state और agent-first operating principles को परिभाषित करने वाले core beliefs शामिल हैं, और उन्हें classify तथा index किया गया है
- architecture documentation domain और package layering का top-level map देती है
- quality documentation हर product domain और architecture layer को grade करती है और समय के साथ gaps को track करती है
- planning को first-class artifact माना गया
- अस्थायी और सरल plans छोटे changes के लिए इस्तेमाल होते हैं
- जटिल काम execution plans में शामिल होते हैं, जिनमें progress और decision logs के साथ उन्हें repository में सहेजा जाता है
- in-progress plans, completed plans, और ज्ञात technical debt सभी versioned रहते हैं और एक ही जगह रखे जाते हैं
- इससे progressive disclosure संभव होती है: एजेंट शुरुआत से ही बोझिल हुए बिना छोटे और स्थिर entry point से शुरू करके आगे बढ़ सकता है
- mechanical enforcement: dedicated linter और CI jobs validate करते हैं कि knowledge base up-to-date, cross-linked और सही तरह structured है
- बार-बार चलने वाला "doc-gardening" agent पुराने या invalid docs की समीक्षा करके fixes के लिए pull request खोलता है
लक्ष्य है एजेंट readability
- चूंकि repository पूरी तरह एजेंट द्वारा बनाई गई थी, इसलिए इसे प्राथमिक रूप से Codex की readability के लिए optimize किया गया
- मानव इंजीनियर का लक्ष्य यह बन गया कि एजेंट repository के भीतर से ही पूरे business domain पर reasoning कर सके
- एजेंट के नज़रिए से run-time context में जो उपलब्ध नहीं है, वह लगभग अस्तित्वहीन है
- Google Docs, chat threads, या लोगों के दिमाग में मौजूद ज्ञान system के लिए उपलब्ध नहीं है
- repository के भीतर के version-controlled artifacts (code, markdown, schema, execution plans) ही उपलब्ध हैं
- Slack चर्चा में तय architecture patterns भी अगर एजेंट खोज न सके तो उसके लिए अपठनीय हैं
- Codex को अधिक context देना मतलब उसे ad-hoc instructions से भर देना नहीं, बल्कि सही जानकारी को व्यवस्थित और सामने लाना ताकि एजेंट reasoning कर सके
- product principles, engineering norms, और team culture (emoji preferences तक) के बारे में एजेंट को ऐसे बताना जैसे किसी नए teammate को onboard किया जाता है, बेहतर परिणाम देता है
- उन dependencies और abstractions को प्राथमिकता दी गई जिन्हें repository के भीतर पूरी तरह internalize और reason किया जा सके
- "boring" tech coupling, API stability, और training setup में representation के कारण एजेंट के लिए model करना अपेक्षाकृत आसान होती है
- कुछ मामलों में public libraries के opaque upstream behavior के बजाय agent द्वारा functionality के किसी subset को खुद reimplement करना सस्ता पड़ता है
- उदाहरण: generic
p-limit-style package की जगह खुद का map-with-concurrency helper बनाना, OpenTelemetry instrumentation के साथ tightly integrate करना, 100% test coverage रखना, और runtime पर ठीक अपेक्षा के अनुसार चलना
- system को जितना ज़्यादा उस रूप में लाया जाए जिसे एजेंट inspect, verify और सीधे modify कर सके, उतना leverage सिर्फ Codex ही नहीं बल्कि दूसरे agents (जैसे Aardvark) पर भी बढ़ता है
architecture और preference को लागू कराना
- सिर्फ documentation से agent-generated codebase को पूरी तरह consistent नहीं रखा जा सकता
- implementation को micromanage किए बिना invariants लागू करके foundation मज़बूत रखी गई, ताकि एजेंट तेज़ी से ship कर सके
- उदाहरण: टीम चाहती थी कि Codex boundaries पर data shapes parse करे, लेकिन यह कैसे करे (किस specific library से) यह explicitly नहीं बताया गया; मॉडल स्वाभाविक रूप से Zod को पसंद करता है
- एजेंट strict boundaries और predictable structure वाले environment में सबसे प्रभावी होते हैं
- application को एक कड़े architectural model के आसपास बनाया गया
- हर business domain को fixed layers के सेट में अलग किया गया, जिनमें dependency directions का सख्त validation और allowed edges का सीमित set था
- code का प्रवाह Types → Config → Repo → Service → Runtime → UI क्रम में होता है
- cross-cutting concerns (auth, connectors, telemetry, feature flags) केवल Providers नाम के एक explicit interface से भीतर आते हैं
- इसके अलावा कुछ भी allowed नहीं है, और इसे मशीन की मदद से लागू कराया गया
- ये constraints Codex द्वारा बनाए गए custom linter और structural tests से लागू किए गए
- इस स्तर की architecture को आम तौर पर सैकड़ों इंजीनियरों वाली टीम तक टाल दिया जाता है, लेकिन coding agents के लिए यह शुरुआती पूर्वशर्त है
- custom linting के जरिए structured logging, schema और types की naming conventions, file size limits, और platform-specific reliability requirements को statically लागू किया गया
- क्योंकि lint custom है, error messages को इस तरह लिखा जा सकता है कि agent context में fix instructions inject हो जाएं
- human-centric workflows में ये नियम अत्यधिक बारीक या सीमित लग सकते हैं, लेकिन agents के साथ ये प्रभाव को कई गुना बढ़ा देते हैं
- constraints यह साफ करती हैं कि क्या महत्वपूर्ण है और क्या नहीं
- यह बड़े engineering platform संगठन चलाने जैसा है: केंद्र से boundaries तय करो, local स्तर पर autonomy दो
- परिणामस्वरूप code हमेशा मानव शैलीगत पसंद से मेल नहीं खा सकता, लेकिन अगर output सही, maintainable और agent runs के दौरान पढ़ने में आसान है, तो मानक पूरा है
- इंसानी पसंद को लगातार system में feedback किया जाता है
- review comments, refactoring PRs, और user-side bugs को documentation updates में दर्ज किया जाता है या सीधे tooling में encode किया जाता है
- जहाँ documentation कम पड़े, वहाँ rule को code में promote कर दिया जाता है
merge philosophy में बदलाव
- Codex की throughput बढ़ने पर पारंपरिक engineering norms उल्टा नुकसानदायक हो गए
- repository को minimum blocking merge gates के साथ चलाया गया
- pull requests की उम्र छोटी रखी गई, और test flakiness को progress अनिश्चितकाल तक रोकने के बजाय follow-up runs से सुलझाया गया
- ऐसे system में जहाँ agent throughput इंसानी ध्यान से बहुत आगे निकल जाती है, वहाँ fixing cost सस्ती और waiting cost महंगी होती है
- कम throughput वाले environment में यह उपयुक्त न भी हो, इसलिए सही trade-off ज़रूरी है
"agent-generated" का वास्तविक दायरा
- codebase का Codex agents द्वारा जनरेट होना मतलब codebase में मौजूद हर चीज़
- product code और tests
- CI config और release tooling
- internal developer tools
- documentation और design history
- evaluation harness
- review comments और responses
- repository को मैनेज करने वाली scripts
- production dashboard definition files
- इंसान हमेशा loop में रहते हैं, लेकिन पहले से अलग abstraction layer पर काम करते हैं
- काम की priority तय करना, user feedback को acceptance criteria में बदलना, और परिणाम validate करना
- जब एजेंट संघर्ष करता है, तो इसे signal माना जाता है कि tools, guardrails या documentation में क्या missing है; और fixes हमेशा Codex से ही लिखवाकर repository में वापस दी जाती हैं
- एजेंट review feedback लाने, inline responses देने, updates push करने, यहाँ तक कि अपने pull request squash और merge करने तक का काम करता है
autonomy level में वृद्धि
- जैसे-जैसे testing, validation, review, feedback handling, recovery आदि के अधिक development loops सीधे system में encode होते गए, एक महत्वपूर्ण threshold हासिल हुआ
- एक single prompt से एजेंट जो कर सकता है:
- codebase की current state validate करना
- reported bug reproduce करना
- failure दिखाने वाला video record करना
- fix implement करना
- application चलाकर fix verify करना
- समाधान दिखाने वाला दूसरा video record करना
- pull request खोलना
- agent और human feedback का जवाब देना
- build failures detect और fix करना
- सिर्फ तब escalate करना जब judgement की ज़रूरत हो
- changes merge करना
- यह व्यवहार इस repository की विशिष्ट structure और tooling पर बहुत निर्भर है; ऐसे निवेश के बिना इसे सामान्यीकृत मान लेना उचित नहीं
entropy और garbage collection
- एजेंट की पूर्ण autonomy नए प्रकार की समस्याएँ लाती है: Codex repository में पहले से मौजूद patterns (चाहे वे असमान हों या आदर्श न हों) को कॉपी करता है, और समय के साथ drift होना लगभग तय है
- शुरुआत में इंसानों ने इसे हाथ से संभाला, हर शुक्रवार (हफ्ते का 20%) "AI slop" साफ़ करने में समय लगाया
- जैसा उम्मीद थी, यह scalable नहीं निकला
- विकल्प के रूप में "golden rules" को सीधे repository में encode किया गया और नियमित cleanup process बनाया गया
- (1) invariants को centrally manage करने के लिए ad-hoc helpers की जगह shared utility packages को प्राथमिकता देना
- (2) "YOLO-style" data exploration से बचना, और boundaries validate करना या typed SDKs पर निर्भर रहना ताकि एजेंट अनुमानित shapes पर गलती से कुछ न बना दे
- deviation जाँचने, quality grades अपडेट करने, और targeted refactoring PRs बनाने के लिए Codex background jobs नियमित रूप से चलाई गईं
- इनमें से अधिकांश को 1 minute से कम में review करके auto-merge किया जा सकता है
- यह तरीका garbage collection जैसा काम करता है: technical debt ऊँचे ब्याज वाले कर्ज़ की तरह है, इसलिए ब्याज बढ़ने से पहले थोड़ा-थोड़ा और लगातार चुकाना सबसे प्रभावी है
- एक बार इंसानी preference capture हो जाने पर वह code की हर line पर लगातार लागू की जा सकती है, और खराब patterns को दिनों या हफ्तों तक फैलने देने के बजाय रोज़ पकड़ा और ठीक किया जा सकता है
चल रही सीख और आगे की चुनौतियाँ
- यह strategy OpenAI में internal release और adoption phase तक अच्छी तरह काम आई
- वास्तविक users के लिए वास्तविक product बनाकर इन investments को ज़मीन पर उतारा गया और long-term maintainability सुनिश्चित करने की कोशिश की गई
- जो अभी भी अज्ञात है: पूरी तरह agent-generated system में architecture consistency वर्षों में कैसे evolve होती है
- टीम अब भी सीख रही है कि मानव judgement सबसे ज़्यादा leverage कहाँ देती है, और उस judgement को encode करके compound कैसे किया जाए
- models की capabilities लगातार बढ़ रही हैं, इसलिए इस system की future direction भी अनिश्चित है
- software बनाना अब भी discipline माँगता है, लेकिन यह discipline code से ज़्यादा scaffolding में व्यक्त हो रहा है
- codebase consistency बनाए रखने के लिए tooling, abstractions और feedback loops लगातार अधिक महत्वपूर्ण होते जा रहे हैं
- फिलहाल सबसे कठिन समस्या यह है कि ऐसे environment, feedback loops और control systems कैसे design किए जाएँ जो agents को जटिल और विश्वसनीय software को बड़े पैमाने पर बनाना और maintain करना संभव बनाएं
अभी कोई टिप्पणी नहीं है.