- आंतरिक बीटा सॉफ़्टवेयर प्रोडक्ट पर किया गया एक प्रयोग, जिसमें हाथ से लिखी गई कोड की 0 लाइनें एक स्थिर बाधा थीं और Codex ने application logic, tests, CI configuration, documentation, observability और internal tools तक सब कुछ लिखा
- खाली git repository से शुरू हुआ codebase लगभग 5 महीनों बाद लगभग 10 लाख लाइनों तक पहुँचा, और तीन इंजीनियरों ने Codex चलाकर लगभग 1,500 PR खोले और merge किए — यह एक उल्लेखनीय PR throughput था
- इंजीनियरों का मुख्य काम कोड लिखने से हटकर environment design, intent specification, और ऐसे feedback loops बनाने की ओर चला गया जिनसे agent विश्वसनीय तरीके से काम कर सके
- repository knowledge को छोटे
AGENTS.md, संरचितdocs/, execution plans, linter और CI के ज़रिये प्रबंधित किया गया, और UI·logs·metrics·traces को ऐसी application readability में बदला गया जिसे Codex सीधे पढ़ और verify कर सके - throughput बढ़ने के साथ merge gates को न्यूनतम रखना और बाद की runs के आधार पर fixes करना एक व्यावहारिक विकल्प बन गया, लेकिन दीर्घकालिक architectural consistency और human judgment को encode करना अभी भी सीखने का विषय है
हाथ से लिखी गई 0 लाइन कोड वाला आंतरिक बीटा
- पिछले 5 महीनों में एक आंतरिक बीटा सॉफ़्टवेयर प्रोडक्ट को हाथ से लिखी गई कोड की 0 लाइनें के साथ बनाकर जारी करने का प्रयोग किया गया
- प्रोडक्ट के आंतरिक दैनिक users और बाहरी alpha testers हैं, और यह release, deployment, outage और fix के पूरे वास्तविक चक्र से गुजर रहा है
- application logic, tests, CI configuration, documentation, observability और internal tools तक हर कोड लाइन Codex ने लिखी, और अनुमान है कि इसे हाथ से कोड लिखने की तुलना में लगभग 1/10 समय में बनाया गया
- मनुष्य नियंत्रण करते हैं, एजेंट निष्पादन करते हैं
- कुछ ही हफ्तों में अंततः 10 लाख लाइनों के स्तर तक पहुँचे परिणाम को ship करना था, इसलिए engineering team का मुख्य काम coding से हटकर environment design, intent specification और feedback loop निर्माण पर चला गया
खाली git repository से शुरुआत
- खाली repository का पहला commit अगस्त 2025 के अंत में हुआ
- शुरुआती scaffold जैसे repository structure, CI setup, formatting rules, package manager settings और application framework, GPT-5 का उपयोग करने वाले Codex CLI ने कुछ मौजूदा templates के मार्गदर्शन में बनाए
- repository में agent कैसे काम करे, यह बताने वाली शुरुआती
AGENTS.mdफ़ाइल भी Codex ने लिखी - सिस्टम को संभालने वाला कोई मौजूदा human-written code नहीं था; repository शुरू से ही agents द्वारा आकार दी गई
- 5 महीने बाद repository application logic, infrastructure, tools, documentation और internal developer utilities सहित लगभग 10 लाख लाइनों तक पहुँची
- तीन इंजीनियरों ने Codex चलाकर लगभग 1,500 PR खोले और merge किए, यानी प्रति इंजीनियर प्रतिदिन औसतन 3.5 PR throughput
- टीम अब सात इंजीनियरों तक बढ़ चुकी है, और throughput भी बढ़ा है
- यह आउटपुट सिर्फ आउटपुट के लिए नहीं था; प्रोडक्ट का उपयोग आंतरिक power users सहित सैकड़ों आंतरिक users कर रहे हैं
- पूरे development process में मनुष्यों ने सीधे कोड contribute नहीं किया, और कोई हाथ से लिखा कोड नहीं टीम का मुख्य दर्शन रहा
इंजीनियर की भूमिका की पुनर्परिभाषा
- मनुष्यों द्वारा सीधे coding न करने की यह बाधा engineering work का एक अलग प्रकार लाती है, जो systems, scaffolding और leverage पर केंद्रित है
- शुरुआती प्रगति अपेक्षा से धीमी थी, लेकिन यह Codex की क्षमता की कमी नहीं बल्कि environment के पर्याप्त रूप से specified न होने के कारण था
- agents के पास high-level goals की ओर बढ़ने के लिए ज़रूरी tools, abstractions और internal structure की कमी थी
- engineering team का मुख्य काम agents को उपयोगी काम करने योग्य बनाना था
- वास्तविक काम एक depth-first तरीके जैसा था, जिसमें बड़े goals को design, code, review, test जैसे छोटे building blocks में बाँटा गया, agents को उन blocks को बनाने के लिए prompt दिया गया, और फिर उन्हें अधिक जटिल कामों की नींव बनाया गया
- असफलता की स्थिति में समाधान “और मेहनत से कोशिश करो” नहीं, बल्कि यह खोजने का तरीका था कि Codex को काम करने योग्य बनाने के लिए कौन-सी क्षमता गायब है, और उसे इस तरह उपलब्ध कराना कि agent उसे पढ़ और follow कर सके
- मनुष्य अधिकतर prompts के माध्यम से सिस्टम के साथ interact करते हैं: engineer काम का वर्णन करता है, agent चलाता है, और PR खुलवाता है
- PR पूरा करने की प्रक्रिया में Codex स्थानीय स्तर पर अपने changes की review करता है, local और cloud में अतिरिक्त agent reviews मांगता है, human या agent feedback का जवाब देता है, और Ralph Wiggum Loop जैसी प्रक्रिया में तब तक दोहराता है जब तक सभी agent reviewers संतुष्ट न हो जाएँ
- Codex
gh, local scripts और repository-embedded skills जैसे standard development tools का सीधे उपयोग करके बिना human copy-paste के context एकत्र करता है - मनुष्य PR review कर सकते हैं, लेकिन यह अनिवार्य नहीं है; समय के साथ लगभग सारा review काम agent-to-agent flow में चला गया
application readability बढ़ाना
- code throughput बढ़ने के साथ bottleneck human QA क्षमता की ओर शिफ्ट हो गया
- क्योंकि स्थिर बाधा human time और attention थी, इसलिए agents की क्षमता बढ़ाने के लिए application UI, logs और app metrics को इस तरह बनाया गया कि Codex उन्हें सीधे पढ़ सके
- application को प्रत्येक git worktree के लिए boot होने योग्य बनाया गया, ताकि Codex हर change पर एक instance चला और चला सके
- Chrome DevTools Protocol को agent runtime से जोड़ा गया और DOM snapshots, screenshots तथा navigation tasks के लिए skills बनाए गए
- इससे Codex bugs को reproduce कर सकता है, fixes को verify कर सकता है, और UI behavior पर सीधे reasoning कर सकता है
- logs, metrics और traces को एक विशेष worktree के लिए अस्थायी local observability stack के माध्यम से Codex के सामने उजागर किया गया
- Codex logs और metrics सहित पूरी तरह isolated app version पर काम करता है, और काम पूरा होते ही संबंधित logs और metrics हटा दिए जाते हैं
- agents LogQL से logs query करते हैं और PromQL से metrics query करते हैं
- “service startup 800ms से कम में पूरा होना सुनिश्चित करो” या “चार core user journeys में किसी भी span को 2 सेकंड से ज़्यादा न होने दो” जैसे prompts executable tasks में बदल जाते हैं
- अक्सर एक single Codex run किसी एक task पर 6 घंटे से अधिक काम करता है, और यह समय कई बार तब होता है जब मनुष्य सो रहे होते हैं
repository knowledge को system of record बनाना
- बड़े और जटिल tasks में agents को प्रभावी बनाने की मुख्य कठिनाइयों में से एक context management है
- Codex को 1,000 पन्नों की निर्देश-पुस्तिका नहीं, एक नक्शे की ज़रूरत होती है
- context एक दुर्लभ संसाधन है, और विशाल निर्देश फ़ाइलें tasks, code और relevant documents को बाहर धकेल देती हैं, जिससे agent मुख्य constraints चूक सकता है या गलत constraints के लिए optimize कर सकता है
- अत्यधिक मार्गदर्शन, मार्गदर्शन नहीं रह जाता; जब सब कुछ महत्वपूर्ण हो जाता है, तो कुछ भी महत्वपूर्ण नहीं रहता, और agent जानबूझकर खोजबीन करने के बजाय local pattern matching में फँसा रह सकता है
- एक विशाल manual जल्दी पुराना हो जाता है, पुराने rules की कब्र बन जाता है, और ऐसा आकर्षक distraction बनता है जिसे मनुष्य maintain नहीं करते
- एक single monolithic file में coverage, freshness, ownership और cross-links जैसी चीज़ों की mechanical verification कठिन होती है, इसलिए drift लगभग तय है
AGENTS.mdको encyclopedia नहीं, बल्कि table of contents माना जाता है- repository knowledge base एक structured
docs/directory में रहता है, जिसे system of record माना जाता है - लगभग 100 लाइनों का छोटा
AGENTS.mdcontext में inject किया जाता है और गहरे truth sources की ओर इशारा करने वाले नक्शे का काम करता है - design documents को core beliefs के एक सेट के साथ catalog और index किया गया है, जो verification status और agent-first operating principles को परिभाषित करता है
- architecture document domain और package layers का top-level map देता है
- quality documents हर product domain और architecture layer को grade करते हैं और समय के साथ gaps को track करते हैं
- plans को first-class artifact माना जाता है; छोटे changes के लिए ephemeral lightweight plans उपयोग किए जाते हैं, और जटिल कार्यों को progress और decision logs सहित execution plans के रूप में repository में commit किया जाता है
- active plans, completed plans और known technical debt सभी version control में साथ रखे जाते हैं, ताकि agents बाहरी context पर निर्भर हुए बिना काम कर सकें
- यह संरचना incremental disclosure को संभव बनाती है; agent शुरुआत से overwhelmed होने के बजाय छोटे और स्थिर entry point से शुरू करता है और आगे कहाँ देखना है, यह सीखता है
- dedicated linter और CI jobs knowledge base की freshness, cross-linking और structural correctness को verify करते हैं
- बार-बार चलने वाला documentation gardening agent ऐसे पुराने या obsolete documents खोजता है जो वास्तविक code behavior को प्रतिबिंबित नहीं करते, और उनके लिए fix PR बनाता है
agent readability ही लक्ष्य है
- क्योंकि पूरा codebase agent-generated है, इसलिए सर्वोच्च optimization target Codex की readability है
- जैसे नए engineers के लिए code explore करना आसान बनाया जाता है, उसी तरह human engineers का लक्ष्य agents को पूरे business domain की reasoning repository से सीधे करने योग्य बनाना है
- agent के दृष्टिकोण से, जो run-time context के भीतर उपलब्ध नहीं है, वह व्यावहारिक रूप से मौजूद ही नहीं है
- Google Docs, chat threads या लोगों के दिमाग में मौजूद ज्ञान सिस्टम के लिए सुलभ नहीं है; केवल repository-local versioned artifacts जैसे code, markdown, schema और execution plans ही agent देख सकता है
- भले ही टीम ने किसी architecture pattern पर Slack चर्चा में सहमति बनाई हो, अगर agent उसे खोज नहीं सकता तो वह वैसा ही अज्ञात ज्ञान है जैसा 3 महीने बाद जुड़ने वाले किसी नए सदस्य के लिए होता
- Codex को अधिक context देने का अर्थ यह नहीं कि उस पर मनमाने निर्देश उड़ेल दिए जाएँ, बल्कि यह कि सही जानकारी इस तरह संगठित और उजागर की जाए कि agent reasoning कर सके
- जैसे नए team members को product principles, engineering norms, team culture और emoji preferences तक onboard किया जाता है, वैसे ही agents को भी यह जानकारी देना अधिक aligned output देता है
- dependencies और abstractions में repository के भीतर पूरी तरह internalized और reason-able विकल्पों को प्राथमिकता दी जाती है
- अक्सर “उबाऊ” तकनीकें composability, API stability और training data में representation के कारण agents के लिए model करना आसान होती हैं
- कुछ मामलों में public library के opaque higher-level behavior को bypass करने की तुलना में agent से functionality का कुछ हिस्सा दोबारा implement करवाना सस्ता पड़ता है
- generic
p-limitशैली के package लाने के बजाय टीम ने अपना map-with-concurrency helper implement किया, जो OpenTelemetry instrumentation के साथ क़रीबी रूप से integrated है, 100% test coverage रखता है, और runtime expectations से बिल्कुल मेल खाता है - सिस्टम के अधिक हिस्सों को ऐसे रूप में लाने से जिन्हें agents सीधे inspect, verify और fix कर सकें, केवल Codex ही नहीं बल्कि इसी codebase पर काम करने वाले Aardvark जैसे अन्य agents का leverage भी बढ़ता है
architecture और पसंद लागू कराना
- केवल documentation पूरी तरह agent-generated codebase में consistency बनाए रखने के लिए पर्याप्त नहीं है
- implementation को बारीकी से नियंत्रित करने के बजाय invariants enforce करके agents को foundation कमजोर किए बिना तेज़ी से ship करने दिया जाता है
- Codex से boundaries पर data shapes parse करने की अपेक्षा की जाती है, लेकिन यह नहीं बताया जाता कि ठीक कैसे करना है
- agents strict boundaries और predictable structure वाले environment में सबसे प्रभावी होते हैं, इसलिए application को एक मजबूत architectural model के आसपास संगठित किया गया है
- प्रत्येक business domain को fixed layers के एक set में बाँटा गया है, और dependency direction तथा allowed connections को सख्ती से verify किया जाता है
- इन constraints को Codex-generated custom linter और structural tests द्वारा mechanically enforce किया जाता है
- हर business domain में code केवल
Types → Config → Repo → Service → Runtime → UIकी fixed layer chain में आगे की ओर depend कर सकता है - auth, connectors, telemetry और feature flags जैसी cross-cutting concerns केवल
Providersनामक एक explicit interface के माध्यम से ही प्रवेश कर सकती हैं - इसके अलावा कोई dependency allowed नहीं है और उन्हें mechanically block किया जाता है
- ऐसी architecture आम तौर पर तब तक टाली जाती है जब तक सैकड़ों engineers न हो जाएँ, लेकिन coding-agent environment में speed बनाए रखते हुए corruption और architectural drift रोकने के लिए यह शुरुआती पूर्वशर्त है
- व्यवहार में rules को custom linter, structural tests और छोटे “taste invariants” के set से लागू किया जाता है
- structured logging, schema और type naming rules, file size limits तथा platform-specific reliability requirements को custom linting के ज़रिए statically enforce किया जाता है
- custom lint की error messages ऐसे लिखी जाती हैं कि agent context में fix instructions inject हो जाएँ
- human-first workflow में ये rules अत्यधिक बारीक या restrictive लग सकते हैं, लेकिन agent environment में एक बार encode किया गया rule पूरे सिस्टम पर एक multiplier की तरह काम करता है
- केंद्र में boundaries, correctness और reproducibility को मज़बूती से नियंत्रित किया जाता है, और उनके भीतर teams या agents को solution expression में काफ़ी स्वतंत्रता मिलती है
- परिणामस्वरूप code हमेशा human style preferences से मेल नहीं खा सकता, लेकिन अगर वह correct, maintainable और future agent runs द्वारा readable है, तो मानक पूरा है
- human preferences को review comments, refactoring PRs और user-facing bugs के माध्यम से लगातार docs updates या tools में वापस feed किया जाता है
- जहाँ documentation कम पड़ती है, वहाँ rules को code में promote कर दिया जाता है
throughput ने merge दर्शन बदला
- Codex throughput बढ़ने के साथ पारंपरिक engineering norms का एक बड़ा हिस्सा उलटा असर देने लगा
- repository को न्यूनतम blocking merge gates के साथ चलाया जाता है
- PRs को छोटा रखा जाता है
- test flakes को progress अनिश्चितकाल रोकने के बजाय अक्सर बाद की runs में संभाला जाता है
- ऐसे सिस्टम में जहाँ agent throughput human attention से बहुत अधिक हो, fixes की लागत कम और प्रतीक्षा की लागत अधिक होती है
- यह low-throughput environment में गैर-जिम्मेदाराना लग सकता है, लेकिन इस environment में यह अक्सर सही trade-off है
“agent-generated” का वास्तविक दायरा
- जब कहा जाता है कि codebase Codex agents द्वारा generated है, तो इसका मतलब codebase के भीतर लगभग सब कुछ है
- agents जिन चीज़ों को बनाते हैं
- product code और tests
- CI configuration और release tools
- internal developer tools
- documentation और design history
- evaluation harnesses
- review comments और responses
- repository को स्वयं manage करने वाले scripts
- production dashboard definition files
- मनुष्य हमेशा loop में रहते हैं, लेकिन पहले की तुलना में कहीं ऊँचे abstraction layer पर काम करते हैं
- मनुष्य task prioritization करते हैं, user feedback को acceptance criteria में बदलते हैं, और outcomes को validate करते हैं
- जब agent संघर्ष करता है, तो इसे इस संकेत की तरह लिया जाता है कि tools, guardrails या documentation में क्या कमी है, और उसका fix भी Codex से लिखवाकर repository में वापस डाला जाता है
- agents standard development tools का सीधे उपयोग करते हैं, review feedback लाते हैं, inline जवाब देते हैं, updates push करते हैं, और कई बार अपने ही PRs को squash करके merge भी करते हैं
autonomy का स्तर बढ़ाना
- जैसे-जैसे testing, validation, review, feedback handling और recovery का अधिक हिस्सा सिस्टम के भीतर encode हुआ, Codex हाल ही में उस threshold को पार कर गया जहाँ वह नई feature को शुरुआत से अंत तक आगे बढ़ा सकता है
- केवल एक single prompt से agent जो काम कर सकता है
- वर्तमान codebase state को verify करना
- reported bug को reproduce करना
- failure दिखाने वाला video रिकॉर्ड करना
- fix implement करना
- application को सीधे operate करके fix verify करना
- समाधान दिखाने वाला दूसरा video रिकॉर्ड करना
- PR खोलना
- agent और human feedback का जवाब देना
- build failures detect और fix करना
- केवल judgment की ज़रूरत होने पर human तक escalate करना
- change merge करना
- यह behavior उस repository की विशिष्ट structure और tooling पर बहुत निर्भर है; समान निवेश के बिना इसे generalize मान लेना उचित नहीं होगा
entropy और garbage collection
- पूरी agent autonomy नई समस्याएँ भी लाती है
- Codex repository में पहले से मौजूद patterns की नकल करता है, भले ही वे uneven हों या optimal न हों
- समय के साथ यही पुनरावृत्ति drift की ओर ले जाती है
- शुरुआत में मनुष्य इसे manually संभालते थे, और टीम हर शुक्रवार, यानी प्रति सप्ताह 20% समय, “AI slop” साफ़ करने में लगाती थी
- यह तरीका scalable नहीं था, इसलिए “golden principles” को सीधे repository में encode किया गया और repeatable cleanup process बनाई गई
- golden principles वे मज़बूत mechanical rules हैं जो भविष्य के agent runs के लिए codebase को readable और consistent रखते हैं
- एक उदाहरण principle यह है कि invariants को centralize करने के लिए hand-rolled helpers की जगह shared utility packages को प्राथमिकता दी जाए
- एक और उदाहरण यह है कि data को “YOLO style” में explore न किया जाए, बल्कि boundaries validate की जाएँ या typed SDKs पर निर्भर रहा जाए, ताकि agents अनुमानित shapes पर दुर्घटनावश निर्माण न कर दें
- नियमित background Codex jobs deviations को scan करते हैं, quality grades update करते हैं, और targeted refactoring PRs generate करते हैं
- अधिकांश refactoring PRs 1 मिनट के भीतर review किए जा सकते हैं और auto-merge हो सकते हैं
- यह प्रक्रिया garbage collection की तरह काम करती है
- technical debt उच्च-ब्याज वाले कर्ज़ जैसी है; उसे जमा होने देकर बाद में एक बार में दर्दनाक तरीके से चुकाने के बजाय छोटे हिस्सों में लगातार चुकाना लगभग हमेशा बेहतर होता है
- human preferences एक बार capture होने के बाद हर code line पर लगातार लागू की जा सकती हैं
- खराब patterns को codebase में कई दिनों या हफ्तों तक फैलने से पहले रोज़ाना पकड़ा और सुधारा जा सकता है
अभी भी सीख जारी है
- यह रणनीति अब तक OpenAI के आंतरिक launches और adoption phase तक अच्छी तरह काम कर चुकी है
- वास्तविक users के लिए वास्तविक products बनाना निवेश को वास्तविकता से बाँधे रखता है और दीर्घकालिक maintainability की ओर धकेलता है
- पूरी तरह agent-generated systems में architectural consistency कई वर्षों में कैसे बदलती है, यह अभी अज्ञात है
- human judgment सबसे बड़ा leverage कहाँ जोड़ता है, और उस judgment को कैसे encode किया जाए ताकि उसका compounding effect बने, यह भी अभी सीखा जा रहा है
- जैसे-जैसे models समय के साथ अधिक सक्षम होंगे, यह सिस्टम कैसे विकसित होगा, यह भी अभी खुला प्रश्न है
- अब तक जो स्पष्ट हुआ है वह यह कि software बनाना अब भी discipline मांगता है, लेकिन यह discipline code की तुलना में scaffolding में अधिक दिखाई देता है
- codebase consistency बनाए रखने वाले tools, abstractions और feedback loops का महत्व लगातार बढ़ रहा है
- वर्तमान में सबसे कठिन चुनौती ऐसे environments, feedback loops और control systems design करना है जो agents को बड़े पैमाने पर जटिल और विश्वसनीय software बनाने और बनाए रखने में मदद करें
- Codex जैसे agents सॉफ़्टवेयर lifecycle का जितना बड़ा हिस्सा संभालेंगे, ये प्रश्न उतने ही अधिक महत्वपूर्ण होते जाएँगे
- शुरुआती सीख यह समझने में मदद करती है कि प्रयास कहाँ निवेश करना चाहिए ताकि कुछ बस बनाया जा सके
1 टिप्पणियां
Hacker News की टिप्पणियाँ
थ्रूपुट बेहिसाब लग रहा है। सोच रहा हूँ कि baseline किसे मानना चाहिए। agent coding से पहले आम तौर पर एक engineer से कितने PR की उम्मीद की जाती थी? क्या लगभग 2~10 प्रति दिन?
यह भी जानना चाहूँगा कि पिछले 6 महीनों में software सच में बेहतर लगा है या नहीं। अगर engineers की संख्या लगभग समान है, तो बड़े software apps की iteration cycle लगभग 5 गुना तेज हो जानी चाहिए थी, लेकिन ऐसा दिखता नहीं है। AI apps बहुत तेज़ी से बदल रहे हैं, पर वह इतना नया क्षेत्र है कि यह अपेक्षित है; उसके बाहर यह बदलाव ज़्यादा महसूस नहीं होता
यहाँ 1,500 PR में 10 लाख lines हैं, यानी PR per net increase लगभग 650 lines है। इसका मतलब यह नहीं कि हर PR कुल 650 lines का है, बल्कि additions में से deletions घटाने के बाद net increase +650 lines है
बारीकी से पढ़ने वालों के लिए कुछ सवाल हैं। जो project एक साल में Firefox codebase जितनी lines बढ़ा देता है, वह 10 साल बाद कैसा दिखेगा? lines की संख्या tools की verbosity के बारे में क्या बताती है, और project का उद्देश्य साफ़ तौर पर सार्वजनिक न किया गया हो तो उससे outcome के बारे में क्या समझना चाहिए? अगर दुनिया ऐसी हो जाए जहाँ इंसान सीधे code न लिखें, तो क्या lines की संख्या की परवाह करने का कोई कारण बचेगा? codebase बहुत बड़ा होने पर token usage का क्या होगा? अगर यह पक्का हो जाए कि LLM usage lines की संख्या को विस्फोटक रूप से बढ़ाता है, तो कुछ महीनों तक इसका इस्तेमाल करने के बाद लागत की वजह से manual coding पर लौटने वाले codebase के लिए इसका क्या मतलब होगा?
अजीब तरह से, “agents” का ज़्यादातर उपयोग एक और AI product बनाने में हो रहा है। मानो कछुओं की अंतहीन परतें हों। शायद यह “agents” की ताकत से ज़्यादा Harness के domain के बारे में बताता है
MS Office को देखें तो हाल में बहुत-से छोटे बदलाव दिखे हैं, और उनमें से ज़्यादातर परेशान करने वाले हैं। जैसे Word comments में किसी colleague को @tag करने पर focus गायब हो जाना, Outlook search box में टाइप करने के लिए दो बार click करना पड़ना, या Outlook mobile date picker में मेरी availability और attendees की availability दिखाने वाली सुविधा जैसे खो गई हो
इसलिए थ्रूपुट तो ज़्यादा दिखता है, लेकिन अफसोस की बात है कि इससे वे features टूट रहे हैं जो पहले ठीक काम करते थे। या फिर समय ऐसी गैर-ज़रूरी चीज़ों पर जा रहा है, जैसे OneDrive search status bar का input box के आसपास घूमते रहना
मेरा मतलब है कि ज़्यादातर code मैं खुद driver seat में बैठकर control करूँ, और AI का उपयोग flow state बनाए रखने और blockers हटाने के लिए करूँ। मैं चाहता हूँ कि tool असली code generation बहुत कम से कम करे
पिछले 5 महीनों से tsz[1] में हम भी ऐसा ही experiment कर रहे हैं, और लगभग वही निष्कर्ष निकाला है। अच्छी architecture separation लागू करवाने के लिए बहुत harness चाहिए, और बहुत testing व CI भी चाहिए
tsz बनाने का उद्देश्य यह सीखना है कि AI के साथ बहुत बड़े projects कैसे किए जाएँ। अंततः यही workflow और mindset UI वाले customer-facing product apps बनाने में भी इस्तेमाल हो सकते हैं। लगता है OpenAI automated browser testing और video तक को workflow के हिस्से के रूप में इस्तेमाल कर रहा है। models जितने बेहतर होंगे, software development की यह दिशा उतनी समझदारी भरी लगेगी, लेकिन मुझे नहीं लगता कि हम अभी वहाँ पहुँचे हैं। फिर भी, OpenAI के अस्पष्ट दावों के विपरीत, यहाँ output साझा किया गया है ताकि उसे सीधे देखा जा सके
Lovable जैसी बहुत high-level automation देने वाली solutions शायद कुछ ज़्यादा ही आशावादी हैं, और बहुत-सी automated testing के साथ कसकर जुड़ी हुई नहीं हैं
[1] https://github.com/tsz-org/tsz
यह मेरे काम करने के तरीके से बिल्कुल मेल खाता है। Claude/Codex आपको अपने काम को verify करने के साधन देता है। जैसे browser, smoke tests, end-to-end tests, और high-fidelity local environment
मैं सारा context — issue tracking, docs, ideas, plans, work logs — repository के अंदर रखता हूँ(https://github.com/shepherdjerred/monorepo/tree/main/package...)
मैं Claude/Codex को Grafana, Prometheus, Tempo, PagerDuty जैसे observability tools का access देता हूँ, और उन्हें fast failure, type safety, boundary parsing जैसी अच्छी engineering guidelines का पालन करने देता हूँ
लेकिन home lab में cost और CI load की वजह से अभी तक पूरी autonomy हासिल नहीं कर पाया हूँ
कुछ समय पहले मैंने e-cigarette factory workers का एक video देखा था। वे conveyor belt से e-cigarette के बंडल उठाते हैं, एक को मुँह में लगाकर लगभग 5 सेकंड ज़ोर से खींचते हैं, फिर अगला बंडल test करते हैं। इंसान द्वारा AI-लिखे PR में सैकड़ों lines के बदलाव review करना इससे बहुत अलग नहीं है
PR ऐसे नहीं होते। एक खराब PR business के लिए घातक हो सकता है, जबकि एक खराब e-cigarette आम तौर पर वैसा नहीं होता
और software engineers जब AI output को sampling से देखते हैं, तो अभी की quality लगातार उस standard को पूरा नहीं करती जो वे product में चाहते हैं। इसलिए हर PR review करना पड़ता है और उनमें से काफ़ी को ठीक भी करना पड़ता है
अगर change impact का दायरा सीमित किया जा सके, और output आम तौर पर बिना निगरानी के भी स्वीकार्य होने लगे ताकि factory में बस यह दोबारा जाँचना हो कि regression नहीं है, तब sampling approach काम कर सकती है
मैं उन तीन इंजीनियरों में से एक हूँ जिन्होंने यह लिखा। सवाल हों तो जवाब दे सकता हूँ
मैं AI skeptic नहीं हूँ, लेकिन इस लेख की मंशा संदिग्ध लगती है। यह agent-first engineering के बारे में बड़े दावे करता है और उन्हें असली case study जैसा दिखाता है—असली product, असली users, और बढ़ती हुई असली team का हवाला देकर—लेकिन यह न तो बताता है और न दिखाता है कि बनाया क्या गया। बाकी हर AI hype लेख जैसा ही है
यह सिर्फ अनंत computing resources और अनंत tokens होने पर ही काम कर सकता है
$20 plan इस्तेमाल करने के अनुभव से कहूँ तो ऐसा शुद्ध agent-style approach संभव नहीं है। बहुत जल्दी limits लग जाती हैं और नतीजे भी कम मिलते हैं
जो तरीका बहुत अच्छा चला, वह था इंसानों द्वारा लिखा गया code reference के रूप में देना और उसे expand करने के लिए कहना। पहले overall structure तय करें, architecture design करें, और controller, service, model, component, database schema, authentication method जैसी sample code की कुछ चीजें लिख दें ताकि LLM के पास ध्यान केंद्रित करने के लिए एक आधार हो
आमतौर पर मैं implementation details के साथ stubs लिखता हूँ। यह किसी ऊँचे abstraction level के pseudocode जैसा होता है। फिर LLM से implementation करने को कहता हूँ
अगर यह fail हो जाए, तो अक्सर पूरा change revert करना बेहतर होता है, फिर stubs को इस तरह adjust करना कि पिछली failure पकड़ी जा सके, और दोबारा कोशिश करना
या changes commit करके उसे नए context में सिर्फ गलत हिस्सों से निपटने देना
अगर शुरुआत से ही agent-style तरीके से जाओ, तो limits और results दोनों में लगभग हमेशा निराशा मिलती है। कभी-कभी एक घंटे के भीतर ही limit लग जाती है
महीने के $200 पर upgrade करने से ज़्यादा इस्तेमाल मिल सकता है, लेकिन मेरे जैसे heavy user के लिए तब भी usage हमेशा कम पड़ती है
सिर्फ OpenAI party में RSVP करने की वजह से 200x usage पाने वाले लोगों से अब भी जलन होती है
यह एक और हाँफता हुआ sales लेख है। जैसे खनिकों को pickaxe बेचना—लेकिन सोना कहाँ है? Git पर एक-दूसरे से बात करने वाले chatbots जो code की लाइनें उगलते रहें, उनसे वास्तव में बने हुए शानदार products कहाँ हैं? कहीं दिखाई नहीं देते
काश ऐसे उत्साहित blog posts थोड़े और शिक्षाप्रद होते
उदाहरण के लिए, वे step-by-step दिखाते कि जिस workflow को इतना शक्तिशाली बताया जा रहा है, उसे वास्तव में कैसे सेट up करें, और उसका ठोस demo देते
मैं AI skeptic नहीं हूँ। उल्टा, अगर इसमें सचमुच कोई superpower है, तो मैं उसे मिस नहीं करना चाहता
नई features के लिए Gherkin feature specs लिखता हूँ, improvements के लिए उन्हें update करता हूँ, और refactoring के लिए उन्हें नहीं छूता। PRs पर इन्हीं संज्ञाओं से label लगाता हूँ
push से पहले hook में type checking, linting, unit tests, और दूसरी तेज़ तथा scriptable validations चलाता हूँ
repository के भीतर एक VitePress subsite बनाता हूँ और उसे agent से maintain करवाता हूँ। महत्वपूर्ण principles, architecture वगैरह को document करता हूँ
एक CLI command बनाता हूँ जो सभी pages और YAML frontmatter descriptions की सूची दे, ताकि agent context window उड़ाए बिना चुन सके कि क्या पढ़ना है
domain-driven design और monorepo का इस्तेमाल करता हूँ। logic को headless layers में लिखता हूँ और उन layers को apps में compose करता हूँ। agent layers को बहुत अच्छी तरह navigate करता है
zod या उस भाषा के equivalent tool के साथ contract-first API development का इस्तेमाल करता हूँ। व्यक्तिगत रूप से यह हिस्सा मुझे सबसे ज़्यादा पसंद है, और मैं orpc इस्तेमाल करता हूँ
सिर्फ “code” नाम की एक skill बनाता हूँ और उसमें lifecycle समझाता हूँ। worktree खोलना, दूसरे agents से टकराव न हो इसलिए
.envसेट करना, unused ports चुनना—यहाँ Docker काम आता है। feature file लिखना या update करना, यहीं spec को align करना, फिर implement करना, playwright mcp जैसी किसी चीज़ से validate करना, pre-push checks चलाना, push के बाद review का इंतज़ार करना, cleanup करना, और फिर main को fast-forward merge करनाकई agents बिना टकराव के tests चला सकें, यह सुनिश्चित करने में testcontainers अच्छे हैं
सच कहूँ तो skill सिर्फ एक ही है। बाकी सब documentation में है। lines of code के अर्थ में नहीं, बल्कि “अच्छा software बनाना” के अर्थ में यह बहुत productive लगता है
इसके लिए, जब भी agent किसी समस्या से टकराता, मैं उससे पूछता कि उसे हल करने के लिए किस validation tool या script की ज़रूरत है। audit process के दौरान मैंने उससे ऐसे tools भी खुद code करवाए। नतीजा यह है कि अब commit validation के लिए 30 से ज़्यादा rules हैं[2], और वे काफ़ी अच्छा काम करते हैं
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (“demo” mode देखने के लिए timer खत्म होने तक छोड़ दें)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
शुरुआत में मैंने यह कोशिश की थी। कोड लिखने से पहले ChatGPT को “project manager” की तरह इस्तेमाल किया, ताकि वह पूरा harness सेटअप कर दे। एक हफ्ते बाद rules, architecture और framework के 140 से ज़्यादा दस्तावेज़ बन गए थे, और कोड की 0 लाइनें थीं
बाद में जब इसे किसी दूसरे tool से review कराया गया, तो फैसला था: “पूरी तरह सुरक्षित खाली तिजोरी।” harness बेदाग था, लेकिन उसके अंदर कुछ भी नहीं था
harness महत्वपूर्ण है, लेकिन अगर इसे कोड रिलीज़ के साथ-साथ नहीं चलाया जाए, तो आप बस fiction ही लिख रहे हैं