बाहरी लूप का स्वामित्व लें

• भले ही एजेंट जांच·इम्प्लीमेंटेशन·वेरिफिकेशन को दोहराने वाले आंतरिक execution loop को संभालें, इंजीनियरों को बाहरी loop का स्वामित्व रखना चाहिए—यानी डिप्लॉय करना है या नहीं, यह तय करना और परिणाम की जिम्मेदारी लेना
• एजेंट सिस्टम गुणवत्ता (Quality), जो प्री-चेक्स को दर्शाती है, फ़ैसला (Verdict), जो तय करता है कि कुछ production में जाएगा या नहीं, और जवाबदेही (Answerability), जो निर्णय के कारण समझा सकने योग्य बनाती है, के आधार पर चलाए जाते हैं
• Sonar के 2026 सर्वे में पाया गया कि committed code का 42% AI-generated या AI से काफी हद तक assisted था; generation की गति control की गति से आगे निकलने पर review·verification·understanding·maintenance दुर्लभ संसाधन बन जाते हैं
• AI के उपयोग के साथ गलत जवाब को ज्यों-का-त्यों स्वीकार कर लेने वाली cognitive surrender, code की समझ को कमज़ोर करने वाला cognitive debt, और सीमित मानवीय attention से कई agents को संभालने की orchestration cost जुड़ी होती है
• scalable software factory तब संभव है जब agents को अधिकतम autonomy नहीं, बल्कि रोकने·समायोजित करने·सत्यापित करने योग्य autonomy दी जाए, और इंसान constraints·sample review·audit·ownership और अंतिम परिणाम की जिम्मेदारी लें

---

एजेंटिक इंजीनियरिंग का बाहरी लूप

• एजेंटिक इंजीनियरिंग की चर्चा अब agent harness और loop, fleet, और software factory की ओर बढ़ रही है
• Fable और GPT-5.6 जैसे शक्तिशाली models के आने के साथ, इंजीनियरों को सिस्टम के प्रति जिम्मेदारी वाले बाहरी loop का स्वामित्व सीधे अपने हाथ में लेना होगा
• एजेंट का ऊँचा leverage उतनी ही बड़ी जिम्मेदारी पैदा करता है
  • आपको ठीक-ठीक समझा सकना चाहिए कि क्या बदला है
  • आपको बताना चाहिए कि वह बदलाव सुरक्षित क्यों था
  • आपको पता होना चाहिए कि निर्णय गलत होने पर क्या होगा
• यदि ये शर्तें पूरी नहीं होतीं, तो एजेंट की कार्रवाई को उचित नहीं ठहराया जा सकता और संगठन के लिए ऐसे सिस्टम का उपयोग करना भी कठिन हो जाता है

गुणवत्ता·फ़ैसला·जवाबदेही

• गुणवत्ता (Quality) से मतलब उन सभी checks से है जो सिस्टम को खुला छोड़ने से पहले लगाए जाते हैं, और यहीं से मिला evidence फ़ैसले की नींव बनता है
• फ़ैसला (Verdict) वह अंतिम production निर्णय है जो किसी task के dependent system में जाने से पहले इंसान लेता है
  • model code लिख सकता है, लेकिन अपने नाम से काम deploy करने वाला व्यक्ति ही फ़ैसले की जिम्मेदारी उठाता है
  • उसे deploy, block, reroute, response scope कम करना, guardrail जोड़ना, या पूरी तरह reject करना—इनमें से एक तय करना होता है
• जवाबदेही (Answerability) यह आश्वासन है कि यदि कोई कारण पूछे, तो आप उस निर्णय को समझा सकें
• model code की एक line लिख सकता है, लेकिन उसे dependent system में भेजना है या नहीं, यह जिम्मेदारी वह अपने ऊपर नहीं लेता

model·harness·loop·factory

• agent सिर्फ एक model नहीं है; इसमें files·tools·memory·skills·sandbox·permissions·observability·recovery capabilities से जुड़ा harness भी शामिल होता है
• अगर model engine है, तो harness उस engine के चारों ओर बनाई गई कार है, जो असली काम को सुरक्षित ढंग से करने लायक बनाती है
  • tools और memory काम करने की क्षमता देते हैं
  • permissions और sandbox execution की सीमा तय करते हैं
  • tests और observability परिणाम की पुष्टि कराते हैं
• agent का execution loop जांच → इम्प्लीमेंटेशन → वेरिफिकेशन → दोहराव से बना होता है
  • repeatable cycle एक बार की सफलता को फिर से भरोसेमंद process में बदल देता है
  • task पूरा हुआ या नहीं, यह model की अपनी राय से नहीं बल्कि स्वतंत्र checks से तय होना चाहिए
• जब कई loops एक साथ चलते हैं, तो वह software factory बन जाता है
  • अंदर agents काम पैदा करते हैं
  • boundary पर इंसान production decision का स्वामित्व रखते हैं

सिस्टम के अंदर और बाहर को बाँटने वाली boundary

• software factory के केंद्र में वह boundary होती है जो सिस्टम के अंदर और बाहर को अलग करती है
• आंतरिक सिस्टम product team की intent, पिछली deployments का ज्ञान, हाल की outages, और ठोस user feedback को input के रूप में इकट्ठा करता है
• agent loop task की जांच करता है, plan को implement करता है, फिर result verify करता है
• जब verification से बना evidence सिस्टम boundary को पार करता है, तब dependent system का मालिक इंसान तय करता है कि आगे बढ़ना है या नहीं
• पहले agents execution process का सिर्फ एक हिस्सा संभालते थे; अब वे पूरा आंतरिक execution loop संभालते हैं और इंजीनियर बाहरी loop लेते हैं
• boundary के भीतर agent जो देता है, वह capability है
  • task की जांच
  • plan का implementation
  • result की testing
  • result की reporting
• boundary के बाहर इंसान जो लागू करते हैं, वह agency है
  • निर्णय
  • सत्यापन
  • अनुमोदन
  • स्वामित्व

AI code से बना trust·verification gap

• AI code का हिस्सा अब हाशिए की चीज़ नहीं रहा
• Sonar की 2026 State of Code report के अनुसार committed code का 42% AI-generated या काफी हद तक AI-assisted था, और respondents को उम्मीद है कि यह हिस्सा ठहरेगा नहीं बल्कि बढ़ता रहेगा
• code generation की लागत घटने से review·verification·understanding·maintenance और भी दुर्लभ संसाधन बन जाते हैं
• generation की गति control की गति से तेज़ बढ़ने पर trust·verification gap पैदा होता है
  • बहुत से लोग AI code पर अविश्वास जताते हैं
  • लेकिन उस अविश्वास को लगातार verification procedure में बदलने वाले उससे भी कम हैं
• AI code की reliability को और सस्ते व स्पष्ट तरीके से जांचने का तरीका चाहिए

बाद-की governance की सीमाएँ

• GitLab की जून 2026 AI responsibility research के अनुसार AI उपयोग की मौजूदा bottleneck review और verification है
• governance ज़्यादातर code बनने के बाद लागू होती है
  • उस समय तक संगठन जोखिम पहले ही स्वीकार कर चुका होता है
  • और task ownership पर control भी कमज़ोर हो चुका होता है
• AI governance को सिर्फ सिस्टम नियंत्रण से आगे बढ़कर यह तय करना होगा
  • सिस्टम पर कौन-से constraints लगाए जाएँ
  • किस evidence से task की जांच की जाए
  • टीम को कैसे accountable बनाया जाए
  • AI lifecycle के हर हिस्से का मालिक कौन होगा

गुणवत्ता बनाने वाला back pressure

• गुणवत्ता को सिस्टम पर काम करने वाले back pressure के रूप में समझा जा सकता है
• लक्ष्य agents को उनकी संभव अधिकतम autonomy देना नहीं है
• agents को उतनी ही autonomy दी जानी चाहिए जितनी उन्हें रोकने, नियंत्रित करने, उनके काम की जांच करने, और इंसानी भूमिका को सुरक्षित रखने के लिए पर्याप्त हो
• मौजूदा engineering में पहले से ऐसे signals मौजूद हैं जो बताते हैं कि काम सही दिशा में जा रहा है या नहीं
  • type checks
  • tests
  • hooks
  • sandbox limits
  • audit logs
  • monitors
• अगर agents भी यही signals छोड़ें, तो मौजूदा engineering framework के ज़रिए उचित back pressure दिया जा सकता है

चार loops जहाँ इंसान का होना ज़रूरी है

• सिस्टम पर भरोसा करने का मतलब इंसान को loop से बाहर करना नहीं है
• इंसान को आंतरिक execution loop के बजाय इन चार बाहरी control loops में होना चाहिए
  • constraint loop: कौन-से inputs, architecture, guidelines, और invariants सेट किए जाएँ, यह तय करता है
  • sample review loop: outputs में से कितना हिस्सा निकालकर review किया जाए, यह तय करता है
  • audit loop: कौन-सा evidence संरक्षित रखा जाए और audit log की validity कैसे सुनिश्चित की जाए, यह तय करता है
  • ownership loop: production boundary के किस हिस्से का मालिक कौन होगा, यह स्पष्ट करता है
• agents इंसानों की review क्षमता से अधिक काम पैदा कर सकते हैं
• इसलिए दुर्लभ संसाधन logs और tests जैसे quality signals के आधार पर काम करने वाली मानवीय मुख्य निर्णय-क्षमता है
• OpenAI की agents और work के future पर research में वर्णित experimental environment में घंटों के पैमाने पर agentic delegation पहले ही संभव स्तर तक पहुँच चुकी है
• सिस्टम review capacity से अधिक output देने लगे, उससे पहले ownership boundaries स्थापित करनी होंगी

long-running agents और जवाबदेही

• घंटों तक चलने वाले long-running agents जो भी चुनाव करते हैं, वे सभी निर्णय हैं
• हर निर्णय रिकॉर्ड नहीं होता, और हर एक को input token तक trace back भी नहीं किया जा सकता
• यदि हम सिर्फ यह मान लें कि result समस्या के लिए सही चुनाव था, तो उस नतीजे तक पहुँची decision chain को फिर से बनाने में सैकड़ों या हज़ारों घंटे का मानवीय श्रम लग सकता है
• क्योंकि ऐसी decision chains व्यावहारिक रूप से पुनर्निर्मित करना मुश्किल है, इसलिए जवाबदेही को सिस्टम design के केंद्र में रखना चाहिए

AI delegation की तीन छिपी लागतें

• cognitive surrender

  • cognitive surrender वह स्थिति है जिसमें AI के दिए हुए output को अंधाधुंध स्वीकार कर लिया जाता है
  • काम agent को सौंपने पर भी deliverable उपयोगकर्ता के काम, प्रतिष्ठा और जिम्मेदारी से जुड़ा रहता है
  • defect उपयोगकर्ता के software में ही रहते हैं
  • output के अनुरूप बदलने वाली चीज़ भी उपयोगकर्ता का software ही होता है
  • agent का जवाब आखिरकार उपयोगकर्ता का जवाब बन जाता है, और जिम्मेदारी भी साथ आती है
  • Wharton research में, AI गलत होने पर भी प्रतिभागियों के लगभग तीन-चौथाई ने उसका जवाब स्वीकार किया, और AI के बिना निर्णय लेने की तुलना में अधिक confidence दिखाया

• cognitive debt

  • cognitive debt वह स्थिति है जिसमें problem-solving की समझ और याददाश्त कमज़ोर हो जाती है
  • agent को task सौंपने पर thinking process भी बाहर चली जाती है
  • बड़े codebase को खुद समझने के लिए ज़रूरी समय और ऊर्जा learning process में निकाल पाना कठिन हो सकता है
  • नतीजतन, agent द्वारा बनाया गया output कभी-कभी उपयोगकर्ता की मौजूदा क्षमता से परे पहुँच जाता है
  • agent की planning time जितनी लंबी होती है, generated code और मानवीय समझ के बीच की खाई उतनी बढ़ती है
  • यह gap जमा होती जाती है, और learning curve पर वापस चढ़ने की लागत लगभग ज्यामितीय रूप से बढ़ जाती है
  • Anthropic के randomized controlled trial में AI की मदद से code लिखने वाले engineers का understanding quiz score 50% था, जो खुद code लिखने वाले समूह के 67% से 17 percentage points कम था

• orchestration cost

  • orchestration cost इस वजह से पैदा होती है कि आप भले बहुत सारे agents को एक साथ चला लें, लेकिन मानवीय cognitive bandwidth उसी तरह parallelize नहीं होती
  • इंसानों को ये काम सीधे करने पड़ते हैं
    • agents को इस तरह tune करना कि वे सबसे बुरे actions से बचें
    • outputs में से उन tasks को चुनना जिन पर ध्यान देना ज़रूरी है
    • यह निर्देश देना कि महत्वपूर्ण tasks पहले पूरे हों
    • execution से पहले core constraints और risky assumptions की जांच करना
  • यह काम automate नहीं किया जा सकता और मानवीय judgment का विकल्प नहीं बन सकता

brownfield में attention को सुरक्षित रखने के तरीके

• brownfield systems खास तौर पर जोखिम भरे होते हैं क्योंकि audit करने योग्य behavior सिर्फ code में नहीं बल्कि जमा हुई चोटों और इतिहास में भी रहता है
• architectural decisions में मानवीय attention को priority देनी चाहिए
• worktree·scope·evidence का उपयोग शुरुआती plan और execution के दौरान नए खुले tasks के बीच coupling को कम कर सकता है
• जिन steps को execute नहीं किया जा सकता, उन्हें हल करने की कोशिश पर time limit होनी चाहिए
• software बदलने की permissions सख्त opt-in तरीके से दी जानी चाहिए

Alpha·decay·taste

• करियर और कई क्षेत्रों की उपलब्धियों को आकार देने वाले तीन मुख्य patterns हैं: alpha·decay·taste
• Alpha वह अग्रणी क्षेत्र है जिसे प्रतिस्पर्धा में सबसे ऊँचा प्रदर्शन करने वाला व्यक्ति हासिल करता है, और वह स्थिति भी है जहाँ सबसे मूल्यवान चाल चली जाती है
• Decay वह स्थिर हो चुका pattern है जिसे दोहराव और अवलोकन के जरिए सभी सीख लेते हैं; इसे एक तरह का plateau zone समझा जा सकता है
• Taste वह judgment है जो evidence सामने आने से पहले alpha की दिशा या decay में बदलाव को महसूस कर लेती है
• Paul Graham की चर्चा का आशय यह है कि जब हर कोई कुछ भी बना सके, तो यह चुनना और महत्वपूर्ण हो जाता है कि क्या बनाया जाए
• Mitchell Hashimoto की परिभाषा में taste वह high-quality qualitative judgment है जो तब लिया जाता है जब अभी objective measurement standards मौजूद नहीं होते
• alpha की चाल taste में बदलाव से चलती है, और decay तब गायब होती है जब लोग कुछ और पसंद करने लगते हैं

Taste को operational capability बनाना

• जो taste पहले सिर्फ intuition थी, उसे conscious capability में बदलने के लिए पहले उसे नाम देना होगा
• critique और ठोस examples के जरिए उस judgment का अभ्यास करना होगा
• judgment के आधार को भी स्पष्ट रूप से व्यक्त करना होगा
• sustainable competitive advantage बढ़ाने के लिए role boundaries को लगातार ऊपर खिसकाना होगा
  • काम खुद करना
  • दूसरों या सिस्टम को वह काम सिखाना
  • उस काम को systematize करना
  • तय करना कि काम कब किया जाना चाहिए
  • परिणाम का स्वामित्व लेना

developer और engineer में अंतर

• हर कोई developer बन सकता है, लेकिन हर कोई engineer नहीं होता
• जब developer अधिक सख्त work discipline स्वीकार करता है, तब वह engineer बनता है
  • पूरी तरह और तार्किक रूप से वैध reasoning
  • constraints और trade-offs पर विचार
  • risk और exposure की समझ
  • वास्तविक जिम्मेदारी
• जब engineering अधिक कठिन होती जाती है, लोग manageable tasks से बाहर निकलकर craftsmanship से बंधी भूमिकाओं को अलग करते हैं और उनके functions को स्पष्ट करते हैं
  • prototype बनाने वाला
  • build करने वाला
  • व्यवस्थित करने वाला
  • growth कराने वाला
  • maintain करने वाला

वह सिस्टम boundary जिसे सिर्फ इंसान बचा सकते हैं

• इंसान सिस्टम की दूसरी तरफ की boundary पर भी alpha बढ़ाने की भूमिका निभाते हैं
  • क्या करना सार्थक है, यह चुनना
  • किन constraints के भीतर करना है, यह तय करना
  • आगे बढ़ने के लिए evidence पर्याप्त है या नहीं, यह परखना
  • परिणाम की देखभाल करना
• एक team हो या 100 teams, इस boundary का स्वामित्व सिर्फ इंसान कर सकते हैं
• attention·taste·जिम्मेदारी वे मुख्य तत्व हैं जो software factory को चलाते हैं
• जिम्मेदारी के बिना rules, सवालों के जवाब, trade-offs, risk, और safety net—कुछ भी टिकता नहीं
• यदि निर्णय के परिणाम का मालिक कोई नहीं है, तो ऊँची agency अराजकता में बदल जाती है

तकनीक से ज़्यादा समय तक टिकने वाला signature

• technical advantage का half-life एक release भर का हो सकता है, लेकिन काम पर छोड़े गए signature का half-life पूरे career तक चलता है
• signature का मतलब है कि आप deployed result पर अपना नाम लगाकर उसके पीछे खड़े हो सकें
• technology leverage बनाती है, और responsibility उस leverage को trust में बदल देती है
• चुनाव करना और उसके परिणाम को विरासत में लेना सिर्फ इंसान कर सकते हैं
• agents policy के भीतर selection, routing, merge, और escalation कर सकते हैं, लेकिन वे उसके परिणाम को विरासत में नहीं ले सकते

codebase का responsibility contract

• हर codebase को ऐसा responsibility contract चाहिए हो सकता है, जो यह स्पष्ट करे कि बदलाव स्वीकार करने की शर्तें क्या हैं
  • approval देते समय क्या समझा गया, इसकी checklist
  • निर्णय के लिए इस्तेमाल किया गया evidence
  • बदलाव की जिम्मेदारी लेने वाला व्यक्ति
  • बदलाव block होने के बाद सिस्टम की स्थिति
• contract में attention और taste, evidence·verdict·ownership, और alpha·decay·taste जैसे संबंधों को स्पष्ट रूप से शामिल करना चाहिए

high-agency की सीढ़ी

• agentic workflow में high agency का मतलब है यह जानना कि कब delegate करना है, कब inspect करना है, कब interrupt करना है, और कब परिणाम का स्वामित्व लेना है
• agency की सीढ़ी निचले स्तर से ऊँचे स्तर तक जाती है
  1. संभावित समस्या को flag करना
  2. समस्या की जांच करना
  3. response task चलाना
  4. कारण का diagnosis करना
  5. समाधान का प्रस्ताव देना
  6. fix की recommendation करना
  7. समस्या को solve करना
• ऊँचे स्तर में वह discernment भी शामिल है, जहाँ समस्या दिखने पर भी यह तय किया जाए कि उसे ठीक करना मूल्यवान नहीं है

brownfield software factory की अग्रिम पंक्ति क्यों है

• brownfield वही frontier है जहाँ scale चाहने वाली software factory सबसे पहले टकराती है
• greenfield systems में पूरे सिस्टम पर control होने के कारण पर्याप्त back pressure mechanisms की planning और implementation अपेक्षाकृत आसान होती है
• legacy systems में intelligent agents जोड़ते समय code के बाहर की complexity को भी संभालना पड़ता है
  • पूरा production behavior
  • ग्राहकों की future expectations
  • migration history
  • release और budget cycles
  • implicit assumptions
  • exception cases
  • data peculiarities
  • runbook procedures
  • बिना प्रबंधन के जमा हुई चोटें
• brownfield की देखभाल के लिए sustainable engineering चाहिए
  • tacit knowledge को explicit constraints में बदलना
  • teams और generations के पार knowledge को consistently बनाए रखना
  • उस knowledge को test procedures और feature specs में formalize करना
  • उस knowledge को objective evidence से जोड़ना
  • failures को अतिरिक्त learning के रूप में जमा करना
• अगर पहले से मिल रही management की वही स्तर की देखभाल टूट जाए, तो पूरा सिस्टम ढह सकता है

scale बढ़ने पर पैदा होने वाले नए काम

• जब मौजूदा components automate हो जाते हैं, तो लोग अपने craft experience से मिले alpha और taste का उपयोग कर नए काम design करते हैं
  • software factory में जोड़ने के लिए नए loops design करना
  • factory से मिले knowledge का उपयोग कर principled greenfield systems बनाना
  • नए systems को verify करने के लिए नए evidence formats बनाना
  • उन brownfield systems की देखभाल करना जो इतने जटिल हो चुके हैं कि dedicated management चाहिए
  • नए back pressure mechanisms design और manage करना
  • नए agents design करना
  • नई agency frameworks बनाना
• ये सब भी वास्तविक engineering work हैं, और scale बढ़ने के साथ ये और दिलचस्प समस्याएँ बन जाते हैं

automation bottleneck को स्थानांतरित करती है

• automation industrial scale पर control देती है, लेकिन साथ ही नए bottlenecks भी बनाती है
• पहले bottleneck यह था कि “क्या हम इसे बना सकते हैं?”, लेकिन आगे चलकर यह “क्या इसका अस्तित्व होना चाहिए, और क्या हम इसके परिणाम को समझा व उसके लिए जिम्मेदार ठहराए जा सकते हैं?” में बदल जाएगा
• production में बना यह नया bottleneck ऐसा है जिसका स्वामित्व इंसानों के पास होना चाहिए

agentic engineering का operating model

• आंतरिक loop वहीं है जहाँ वास्तविक काम होता है, और हर loop को जितना संभव हो उतना स्वतंत्र रूप से design किया जाना चाहिए
• सारी quality assurance और verification को आंतरिक loop के भीतर रखना चाहिए
• loop को design और verify करने के बाद, autonomy देने से पहले execution speed और task scope को नियंत्रित करने वाले back pressure mechanisms लगाने चाहिए
• इंसानों को हर आंतरिक step में दखल देने के बजाय सही decision points पर रखना चाहिए
• understanding को सिर्फ handoff या release gate की तरह न देखें; उसे ऐसे decision point की तरह देखें जहाँ इंसान insight देने के लिए तैयार हों
• जब भी outputs फिर से production और नई teams·engineers को feed किए जाएँ, तो पहले से बेहतर outputs और evidence छोड़े जाने चाहिए
• software factory बनाइए और उसे लगातार चलाइए, लेकिन काम को पढ़ने योग्य, verify करने योग्य, और मालिकाना जिम्मेदारी वाले रूप में बनाए रखिए
• भले agents code लिखें, users तक पहुँचने से पहले इंसान को इन सवालों का जवाब देना होगा
  • यह code अस्तित्व में क्यों होना चाहिए
  • इसे production में शामिल करना पर्याप्त रूप से सुरक्षित क्यों है
  • गलत होने पर क्या किया जाएगा
• यही निर्णय और जिम्मेदारी निभाने का काम agentic engineering का बाहरी लूप है