एजेंट-प्रथम दुनिया में Codex का उपयोग: Harness engineering
OpenAI का यह दावा कि एक छोटी टीम ने AI “coding agents” का उपयोग करके महीनों में एक million-line internal product बनाया, इस पर बहस छेड़ता है कि यह उत्पादकता और software quality के बारे में वास्तव में क्या साबित करता है। टिप्पणीकार lines of code और PR counts को meaningful metrics मानने पर सवाल उठाते हैं, long-term maintainability, token costs, और job displacement की चिंता करते हैं, और नोट करते हैं कि AI-built systems अक्सर तेज़ तो लगते हैं लेकिन brittle या bloated होते हैं। अन्य लोग अपने harness और agent workflows साझा करते हैं, यह तर्क देते हुए कि मज़बूत architectural constraints, automated tests, और human oversight के साथ agents substantial speedups दे सकते हैं—हालाँकि मुख्यतः internal tools के लिए और अभी भी hands-off autonomy से बहुत दूर।
स्केल और थ्रूपुट के दावे
- कई लोग इस दावे से प्रभावित हैं: ~1M LOC, ~1,500 PRs, एक छोटी टीम, और “orders of magnitude” तेज़ velocity।
- कई इसे बड़े, परिपक्व प्रोजेक्ट्स (Firefox, Python stdlib) से तुलना करते हैं और LOC संख्या को अविश्वसनीय या कम-से-कम एक संदिग्ध bragging metric मानते हैं।
- कुछ इसे एक उपयोगी demo मानते हैं कि agents ~1M LOC codebase में काम कर सकते हैं, लेकिन product quality का प्रमाण नहीं।
कोड गुणवत्ता, maintainability, और technical debt
- इतनी तेज़, agent-driven output साफ़ या maintainable होगी, इस पर कड़ा संदेह; “spaghetti” और लंबे समय के decay की आशंका।
- अन्य लोग नोट करते हैं कि लेख systematic cleanup और debt paydown का दावा करता है, लेकिन repo access के बिना वे आश्वस्त नहीं हैं।
- चिंता यह है कि बड़े, verbose, agent-oriented codebases इंसानों के लिए समझना कठिन या बेकार हो जाएंगे, जिससे AI-only maintenance की ओर धक्का लगेगा।
Architecture, harnesses, और guardrails
- कई लोग “harness engineering” को असली innovation मानते हैं: strict layering, import rules, CI checks, और deterministic tools (linters, tests, dependency rules)।
- कई टिप्पणीकार समान setups की रिपोर्ट करते हैं: सभी plans/docs/logs को in-repo रखना, agents से docs अपडेट करवाना, भारी automated validation, और domain-driven या layered architectures का उपयोग।
- छोटे files, कम LOC, और अच्छी modularity को agent performance और context usage के लिए काफ़ी मददगार बताया गया है।
Metrics और LOC वास्तव में क्या दर्शाता है
- व्यापक सहमति है कि LOC productivity का खराब metric है और reward hacking को बढ़ावा देता है।
- कुछ का तर्क है कि यह अभी भी एक सरल, संप्रेषणीय proxy है यह दिखाने के लिए कि “बहुत कुछ बनाया गया,” खासकर non-technical audiences के लिए।
- अन्य लोग इस पर ज़ोर देते हैं कि अच्छी engineering को कम, घनी, अधिक coherent lines के लिए optimize करना चाहिए और बेहतर metrics सुझाते हैं (tests, reliability, feature correctness)।
आर्थिक और श्रम संबंधी चिंताएँ
- कुछ इसे इस संकेत के रूप में देखते हैं कि कम engineers अधिक ship कर सकते हैं, जिससे junior और senior दोनों भूमिकाएँ प्रभावित हो सकती हैं।
- अन्य लोग तर्क देते हैं कि senior engineers architecture, harness design, और domain understanding के लिए अब भी मूल्यवान रहेंगे; juniors पर सबसे अधिक असर पड़ सकता है।
- एक अल्पसंख्यक इस लेख को marketing मानकर खारिज करता है और ऐसे agentic systems की वास्तविक reliability, cost, और ROI पर सवाल उठाता है।
Adoption, limits, और cost
- कई practitioners कहते हैं कि उन्होंने इसी तरह के “agent-first” workflows आज़माए हैं; परिणाम प्रभावशाली से लेकर अव्यवस्थित “vibe coding” तक अलग-अलग रहे हैं।
- पूरी तरह autonomous approaches के लिए, well-funded environments के बाहर, cost और token limits को बड़े blockers बताया गया है।