एजेंटिक इंजीनियरिंग में स्वायत्तता का पैमाना
एजेंटिक इंजीनियरिंग के बारे में ज़्यादातर चर्चाओं में, कार्रवाई प्रॉम्प्टिंग से ऑपरेटिंग में बदल गई है। यहाँ कोहरे में झाँकती एक सीमा है: सॉफ़्टवेयर फैक्ट्रियाँ, लक्ष्य, लूप, बैकग्राउंड सेशन, सबएजेंट, हुक, सैंडबॉक्स, एजेंट-अप्रूव करने वाले एजेंट। भविष्य के कई क्रिएटर्स के लिए, यह व्यवहार दिन-1 से ही प्रोडक्ट्स में शामिल होगा: Claude Code और Codex इस बदलाव को सीधे उजागर करते हैं।
इंजीनियर के नज़रिए से, आप कम स्वायत्तता का उपयोग जोखिम को सीमित करने और प्रतिवर्तीता बढ़ाने के लिए करेंगे, लेकिन स्पष्ट गतिविधियों के लिए उच्च स्वायत्तता का उपयोग करेंगे, और समानांतर एजेंटों के बेड़े सुरक्षित रूप से बड़े कोडबेस को रिफैक्टर करेंगे। किसी कार्रवाई के बारे में मुख्य प्रश्न हमेशा यह है: यह कार्य किस स्तर का हकदार है, और कौन सा सत्यापन उस स्तर को रक्षात्मक बनाता है?
सीमा का किनारा मैनेजर एजेंट है जो अपने ट्रिगर पर जागता है, अपने सहायकों को काम सौंपता है जबकि लगातार उनके आउटपुट को सत्यापित करता है, और केवल वे निर्णय लेकर लौटता है जो मानव द्वारा लिए जाने चाहिए। इस तरह के सेटअप का उपयोग करने वाले लोग शायद पहले से ही सैकड़ों या हज़ारों एजेंट चला रहे हैं, ज़्यादातर सदाबहार कोडबेस पर। स्वायत्तता के बारे में अधिकांश सोच की तरह, पैमाने को कैसे देखा जाए यह अभी भी सभी के लिए अलग है।
सबसे अधिक उल्लेखित पैमाना स्टीव येगे का एकल-अक्ष लैडर है जिसका उल्लेख "Welcome to Gas Town" और The Pragmatic Engineer में किया गया है। यह एक अच्छा संदर्भ है अगर आप एक ऐसा नंबर चाहते हैं जो बताए कि आप कितने AI-नेटिव हैं: लैडर आपको एक ही नंबर देता है जिससे आप माप सकते हैं कि एक ही एजेंट में आपका भरोसा कितना है। इसका एक संस्करण यहाँ है:

2026 की शुरुआत में, जबकि काम डेलिगेशन से ऑर्केस्ट्रेशन की ओर शिफ्ट होना शुरू हुआ था, यह जोखिम मापने के लिए काफी अच्छा प्रॉक्सी था। हालाँकि, आज, जब आप एक साथ कई एजेंट चला सकते हैं तो कई कौशल सेटों का महत्व और लीवरेज बढ़ सकता है। एक ही सीढ़ी आपको मल्टी-एजेंट कौशल को रखने में मदद नहीं कर सकती।
इसके बजाय, स्वायत्तता की लगभग हर बहस दो प्रश्नों को मिला देती है जिन्हें अलग किया जाना चाहिए: हम इस एक एजेंट को अपने से कितनी दूर जाने दे रहे हैं, और कई एजेंटों को समन्वित करने में हमारा कौशल क्या है?
इन दो आयामों को अलग-अलग कैप्चर करने के लिए, हम दो अक्षों का उपयोग करेंगे: एजेंसी और ऑर्केस्ट्रेशन।

एजेंसी अक्ष पर, निम्न में उम्मीदवार कार्रवाइयों का सुझाव देना और निर्णय की प्रतीक्षा करना शामिल है।
मध्य का मतलब है कि एजेंट किसी विशेष कार्य पर काम कर रहा है, लेकिन वह अपने काम का दायरा तय करता है, और लगातार रिपोर्ट करता है कि वह क्या कर रहा है और सबूत देता है, ताकि आप उसे दिशा देते रह सकें।
उच्च एजेंसी के अंत में, एजेंट किसी लक्ष्य की ओर काम कर रहा है, प्रयोग कर रहा है, सीख रहा है, परीक्षण कर रहा है, समस्या को हल करने के तरीके खोज रहा है, अटक रहा है, सवाल पूछ रहा है, अलग-अलग दृष्टिकोण आज़मा रहा है, और यह सारा काम सबूत के रूप में लौटाता है।
ऑर्केस्ट्रेशन अक्ष पर, निम्न का मतलब है एक एजेंट, एक थ्रेड। मध्य में, आपके पास कई एजेंट हैं, प्रत्येक अपने स्वयं के वर्कट्री में काम कर रहा है, संभवतः अलग-अलग लक्ष्यों की ओर काम कर रहा है, लेकिन अलग-थलग। उच्च अंत में, आपके पास एक ऑर्केस्ट्रेटर है जो बैकलॉग, इश्यू ट्रैकर, शेड्यूल या अन्य कतार ले सकता है, और इसे निरंतर काम में बदल सकता है, और आपको केवल तब हस्तक्षेप करने की आवश्यकता है जब चीज़ें विफल हों: "अपवाद द्वारा प्रबंधन।" इन विचारों को शामिल करने वाले प्रोडक्ट और फीचर्स में शामिल हैं:
- Claude Code के /plan, /goal, /loop, /background, /batch, /code-review, /security-review मोड, सबएजेंट, हुक, चेकपॉइंटिंग, एजेंट डेलिगेशन और मैनेजमेंट प्रैक्टिसेज़, बैकग्राउंड सेशन, एजेंट-टीम पैटर्न, /schedule आर्गुमेंट्स
- Codex के स्थानीय/क्लाउड थ्रेड, Goal मोड, वर्कट्री, ऑटोमेशन, सबएजेंट, रिव्यू पेन, GitHub कोड रिव्यू, हुक, सैंडबॉक्सिंग, ऑटो-रिव्यू और रिरन
ये क्षमताएँ एक ही लैडर पर फिट नहीं होतीं।
चढ़ाई: तीन युग और एक एकल स्टैक
यदि आप लैडर को नीचे से ऊपर पढ़ते हैं, तो आप एक साथ एजेंसी और ऑर्केस्ट्रेशन दोनों पर चढ़ने की कल्पना कर रहे हैं। प्रभाव में, छह स्तर तीन अलग-अलग युगों का प्रतिनिधित्व करते हैं जिनसे हम सभी गुज़रते हैं:
पहले, आप ड्राइवर की सीट पर हैं, और एक एजेंट ज़्यादातर सिर्फ मदद करता है, आपके द्वारा इसे निर्देशित करने की प्रतीक्षा करता है।
दूसरे, एजेंट एक सीमित कार्य या लक्ष्य का प्रभार लेता है, लेकिन आप अभी भी इसे निर्देशित करने और इसके काम को सत्यापित करने के लिए मौजूद हैं।
और तीसरे, ऑर्केस्ट्रेशन के युग में, सिस्टम शो चलाने में सक्षम है, कई एजेंटों में काम वितरित करता है, और आपको ज़्यादातर तब हस्तक्षेप करने की आवश्यकता होती है जब चीज़ें गलत हों: "अपवाद द्वारा प्रबंधन।"
यह चीज़ों को सरल बनाता है, क्योंकि लैडर पर ऊर्ध्वाधर स्थिति दो अक्षों को बड़े करीने से कैप्चर करती है (ऑर्केस्ट्रेशन केवल शीर्ष के पास सक्रिय होता है), इसे एक एकल स्थिर चढ़ाई के रूप में छोड़ देती है। और फिर भी, यह चढ़ाई अभी भी उस बदलाव का हिस्सा है जिससे हम सभी गुज़र रहे हैं।

एक अच्छे इंजीनियरिंग दिन में कई सीढ़ियों को छूना शामिल है, कभी-कभी उससे भी अधिक: किसी कार्य के दौरान युगों के बीच कुछ बार स्विच करना सामान्य है।
छह स्तर विस्तार से
स्तर 0: सहायता
एजेंट ऐसे सुझाव देता है जो ज़्यादातर अच्छे और अक्सर सही होते हैं, लेकिन आप हमेशा तय करेंगे कि क्या वे कार्रवाई करने के लिए पर्याप्त अच्छे हैं। ऑटोकम्प्लीट, इनलाइन एडिट सुझाव, या चैट सेशन में चर्चा करना जहाँ किसी ने बदलाव की ज़िम्मेदारी नहीं ली है, सोचें। महँगी त्रुटियों, छोटे बदलावों, या जब आप अपना निर्णय बना रहे हों, तब उपयोग करें। सत्यापन ज़्यादातर स्थानीय रूप से होता है।
स्तर 1: पर्यवेक्षित कार्रवाई
एजेंट आपकी ओर से संपादन करता है या कमांड चलाता है, कुछ भी महत्वपूर्ण निष्पादित करने से पहले आपसे पूछता है। यह ज़्यादातर लोगों के लिए डिफ़ॉल्ट स्थिति है। यह बदलाव लागू करने से पहले अनुमोदन के साथ स्थानीय सैंडबॉक्स में किया जा सकता है - जहाँ प्रत्येक अनुमोदन एक स्वतंत्र सत्यापन है कि बदलाव लागू करना ठीक है - या एक इंटरैक्टिव सेशन में। विफलता मोड अनुमोदन थकान है; सभी अनुमोदन समान महसूस होते हैं भले ही वे क्या अनुमोदित कर रहे हों। आप इसे डिफ को घूरकर, कुछ ह्युरिस्टिक्स का पालन करके, अनुमोदन से पहले किसी अन्य व्यक्ति से जाँच करके, या बस एजेंट को ज़िम्मेदार होने देने पर सहमत होकर हल कर सकते हैं। Codex ऑटो-रिव्यू इस समस्या को सीमा शर्तों के अंतिम अनुमोदन को एक अलग रिव्यूअर एजेंट को सौंपकर हल करता है।
स्तर 2: दायरा-बद्ध कार्य प्रत्यायोजन
एक सीमित कार्य एजेंट को सौंपें। उस कार्य का एक स्पष्ट लक्ष्य, बाधाएँ और एक कामकाजी परिभाषा होगी कि "हो गया" कैसा दिखता है। आप पास में रहेंगे, बीच में आ सकते हैं, लेकिन ज़्यादातर शामिल नहीं होंगे। यह सॉफ़्टवेयर इंजीनियरिंग दुनिया में गुरुत्वाकर्षण का केंद्र है। सत्यापन आपसे (आपको आराम और नींद की आवश्यकता हो सकती है) दूर एजेंट द्वारा उत्पादित सबूतों की ओर शिफ्ट हो रहा है: पास हुए ऑटोमेटेड टेस्ट, उचित टाइप, लिंट सुझाव, स्क्रीनशॉट, रिप्रो स्टेप्स, उदाहरण द्वारा प्रोवेनेंस, आदि।
स्तर 3: लक्ष्य-संचालित स्वायत्तता
एजेंट किसी लक्ष्य को प्राप्त करने के लिए जो कुछ भी करना पड़े करता है, केवल तब रुकता है जब कोई शर्त पूरी होती है। प्रॉम्प्ट मोड में, इसका मतलब है कि प्रॉम्प्ट ही लक्ष्य बन जाता है (जैसे, "क्या आप इस पेज के टाइम-टू-इंटरैक्टिव को 1 सेकंड से नीचे ला सकते हैं?")। Codex में, यह Goal मोड है: एजेंट plan->act->test->review चरणों के माध्यम से चक्र लगाता है जब तक कि वह सफलता मानदंड को पूरा करना बंद नहीं कर देता। Claude Code में, यह /goal, /loop और /schedule कमांड हैं। इस स्तर के उपयोगी होने के लिए, रुकने की शर्त को इस तरह से मापने योग्य होना चाहिए जिसे स्वचालित किया जा सके।
अपने एजेंट को अस्पष्ट, धुंधले लक्ष्यों जैसे "सामान्य रूप से उपयोगकर्ता अनुभव में सुधार करें" या "कोडबेस को अधिक परीक्षण योग्य बनाएं" में मदद करने के लिए न कहें। कुछ विशिष्ट, मापने योग्य और स्वचालित चुनें: उत्पादन में ऐसे बग खोजें जो स्थैतिक विश्लेषण से बच जाते हैं, लोड समय कम करें, सुनिश्चित करें कि हमारे पास बिना किसी explicit any के सख्त TypeScript बिल्ड है, सभी निर्भरताओं की जाँच करें ताकि केवल वही रखें जिन्हें हम समझते हैं और जो हमारे परीक्षण पास करते हैं, आदि। और, अंत में, उत्पादन में बग खोजने के लिए, एजेंट को उत्पादन-जैसे वातावरण में होना होगा।
स्तर 4: समानांतर प्रत्यायोजन
कई एजेंटों पर समानांतर रूप से काम करें। प्रत्येक एजेंट कार्य के एक अलग-थलग टुकड़े पर काम करता है। इस स्तर पर सबसे बड़ी बाधा डीकम्पोज़िशन है: प्रत्यायोजित करने के लिए सही टुकड़ों को परिभाषित करना। सहायक साधनों में शामिल हैं: सबएजेंट, बैकग्राउंड सेशन, /batch, वर्कट्री, एजेंट टीम, आदि। विफलता मोड झूठी समानांतरता है: एक साथ ओवरलैपिंग टुकड़ों पर कई एजेंट चलाना, जिससे अधिक काम के बजाय मर्ज कॉन्फ्लिक्ट और डुप्लिकेट निर्णय मिलते हैं। इसे अच्छी तरह से करने के लिए, एजेंटों को एक-दूसरे से अलग होना चाहिए, प्रत्येक अपनी स्वयं की फ़ाइलों और स्थिति का मालिक होना चाहिए। प्रत्येक के पास अपनी स्वयं की समीक्षा कतार भी होनी चाहिए। और अंत में, प्रत्येक एजेंट एक लागत वहन करता है - खपत किए गए टोकन के संदर्भ में - एक साथ चलने वाले एजेंटों की संख्या के अनुपात में। मानव पक्ष पर, ऑर्केस्ट्रेशन टैक्स एक एजेंट को जोड़ने की सीमांत लागत को कुछ के बाद बढ़ा देता है।
स्तर 5: अपवाद-द्वारा-प्रबंधित ऑर्केस्ट्रेशन
परिभाषित करें कि सफलता कैसी दिखती है, और कौन सी नीतियाँ लागू होनी चाहिए। एक मैनेजर एजेंट ट्रिगर (जैसे, नया इश्यू, नया कार्य, घड़ी) के आधार पर जागेगा, वर्कर एजेंट्स को तैनात करेगा, उनकी प्रगति की निगरानी करेगा, आउटपुट सत्यापित करेगा, विफलता पर पुनः प्रयास करेगा, शर्तें पूरी होने पर अधिक सक्षम एजेंटों या मनुष्यों को एस्कलेट करेगा, परिणाम एकत्र करेगा, और अंततः कार्य उत्पादों (जैसे PR) और सबूतों को बाहरी सिस्टम में लौटाएगा। फैक्ट्री के बारे में सोचें: इश्यू ट्रैकर या बैकलॉग इनपुट है, और फैक्ट्री का उत्पाद आउटपुट है (अर्थात, कई ठीक किए गए इश्यू, बग)। एजेंट उपयुक्त रूप से अलग-थलग वातावरण में काम करते हैं जिसमें बहुत सारी दीवारें (और यदि आवश्यक हो, भागने के रास्ते) होते हैं, और केवल एक ऑपरेटिंग सिस्टम - जो मैनेजर एजेंट द्वारा परिभाषित होता है - यह निर्धारित करता है कि फैक्ट्री से क्या अपेक्षित है।
इस ऑपरेटिंग सिस्टम का डिज़ाइन मानव पर छोड़ दिया गया है; OpenAI ने Symphony के लिए एक स्पेक प्रस्तावित किया है जिसके केंद्र में एक Linear बोर्ड है: प्रत्येक इश्यू को अपना स्वयं का एजेंट वर्कस्पेस मिलता है, और एजेंट लगातार सुनिश्चित करता है कि वह अपने स्वयं के वर्कस्पेस में एक स्पेक फ़ाइल में परिभाषित अपने लक्ष्य की ओर प्रगति कर रहा है। मानव समीक्षा उस ऊँचाई पर की जा सकती है जहाँ सबूत उत्पन्न होते हैं, लेकिन सीमा (अर्थात, ऑर्केस्ट्रेशन दुनिया में सबसे शक्तिशाली क्या है) सैकड़ों या हजारों एजेंटों के साथ निरंतर एजेंट फैक्ट्रियाँ बनाना है। चढ़ाई में इस बिंदु पर, स्वतंत्र सत्यापन होना तेजी से महत्वपूर्ण हो जाता है: अलग कार्यान्वयनकर्ता और समीक्षक, अलग टेस्ट रनर और QA, अलग सुरक्षा जाँच, स्वीकृति के लिए अलग प्रक्रिया गेट।
जोखिम और प्रतिवर्तीता छत निर्धारित करते हैं।
मुझे Claude Code के साथ कुछ सबसे कठिन कार्यों पर एक पहले का Anthropic अध्ययन पढ़ना याद है जहाँ उसने उपयोगकर्ताओं के बीच में टोकने की तुलना में दो बार से अधिक बार स्पष्टीकरण माँगा। अनुभवी उपयोगकर्ता (~750 सत्र बनाम 50 से कम) स्वचालित रूप से अनुमोदित करने और प्रगति पर नज़र रखने के लिए बीच में टोकने की अधिक संभावना रखते थे।
उन्होंने लोगों द्वारा Claude Code का उपयोग करने के तरीके का बहुत व्यापक विश्लेषण भी किया। उन्होंने अक्टूबर 2025 और अप्रैल 2026 के बीच ~235K लोगों के ~400K सत्र देखे। प्रत्येक सत्र से वे किसी व्यक्ति द्वारा लिए गए निर्णयों का पता लगा सकते थे जैसे कि वे प्रत्येक प्रॉम्प्ट में कितनी कार्रवाइयाँ माँगते हैं, वे इनमें से किसे स्वचालित रूप से अनुमोदित करना चुनते हैं, वे कितनी बार बीच में टोकते हैं, आदि। लोग ~70% योजना निर्णय लेते हैं, लेकिन Claude ~80% निष्पादन करता है। उच्च स्वायत्तता लोगों को लूप से बाहर निकालने के बारे में नहीं है, बल्कि उन्हें हर कदम करने से लेकर यह तय करने तक ले जाने के बारे में है कि आगे किस दिशा में जाना है।
यह निर्धारित करने के लिए कि क्या कोई बड़ा AI सिस्टम उच्च स्वायत्तता के साथ काम कर रहा है, तीन प्रश्न हैं जो हमें पूछने चाहिए:
- हमें कितनी जल्दी पता चलेगा कि हम इसके बारे में गलत हैं कि यह क्या कर रहा है?
- हम इसे कितनी सफाई से पूर्ववत कर सकते हैं कि यह क्या कर रहा है?
- क्या साबित करेगा कि हम इस बारे में सही हैं कि यह क्या कर रहा है?
यदि तीनों का उत्तर है: जल्दी नहीं, बड़ी कठिनाई से, और सारांश पर भरोसा करके, तो यह उच्च स्वायत्तता नहीं है।
एजेंट के प्रत्येक रन से पहले एक अनुबंध होना चाहिए जो परिभाषित करता है कि वह क्या करने का प्रयास कर रहा है।
लक्ष्य: हम क्या हासिल करने का प्रयास कर रहे हैं (कोई गतिविधि नहीं, कोई तकनीक नहीं, बल्कि एक परिणाम)।
दायरा: हम किस डोमेन में काम कर रहे हैं, और कौन सी तकनीकों की अनुमति है।
गैर-लक्ष्य: उद्देश्य का हिस्सा क्या नहीं है।
उपकरण और अनुमतियाँ: एजेंट दुनिया के साथ कैसे इंटरऑपरेट कर सकता है।
रुकने की शर्त: कब रुकना है; आदर्श रूप से, एक मापने योग्य चर।
सबूत: विशिष्ट परीक्षण, स्क्रीनशॉट, लॉग, डेटाबेस रिकॉर्ड या अन्य संकेतक जिनका उपयोग यह पुष्टि करने के लिए किया जा सकता है कि कुछ किया गया है (एजेंट से स्वतंत्र)।
एस्कलेशन: किन परिस्थितियों में कौन शामिल होता है (जिसमें एजेंट कौन चलाता है शामिल है)।
और बजट: कार्य पर कितना समय, प्रयास और टोकन खर्च करने की सीमा (टोकन बड़े AI मॉडल का बजट हैं - आप इसमें कार्य को प्रयास करने की संख्या और समानांतरता की डिग्री की सीमा भी शामिल कर सकते हैं)।
मीट्रिक्स स्वायत्तता को थोड़ा और विश्वसनीय बनाते हैं
बाद में मीट्रिक तय करना शायद पर्याप्त नहीं है। मीट्रिक्स को पहले से, एक संक्षिप्त दस्तावेज़ में रखा जा सकता है। और यह स्वायत्तता को अधिक विश्वसनीय महसूस कराता है और विश्वास की छलांग को थोड़ा आसान बनाता है।
सफलता को मापने के कई तरीके हैं, जबकि स्वायत्तता के प्रत्येक स्तर के लिए इन मीट्रिक्स के कुछ संस्करण पर विचार करें:
- हस्तक्षेपों के बीच औसत समय
- स्वीकृत कार्य के साथ सबसे लंबा सफल अप्राप्य रन
- सैंडबॉक्स में चलाई गई कार्रवाइयों का एस्कलेटेड बनाम हिस्सा
- स्वचालित रूप से अनुमोदित बनाम अस्वीकृत कार्रवाइयों का प्रतिशत
- प्रति मानव निर्देश एजेंट कार्रवाइयों की औसत संख्या
- स्पष्टीकरण अनुरोध दर / बीच में टोकने का अनुरोध दर
- प्रति स्वीकृत बदलाव समीक्षा समय
- आत्मविश्वास के प्रत्येक स्तर पर रीवर्क दर
- आत्मविश्वास के प्रत्येक स्तर पर दोष एस्केप दर
- प्रति स्वीकृत बदलाव टोकन लागत
ऐसे मीट्रिक्स एक कहानी बता सकते हैं: एक एकल एजेंट जो मानव द्वारा हैंडऑफ़ से व्यस्त रहता है, डैशबोर्ड के साथ स्तर 4 है। एक रूढ़िवादी एजेंट, जो स्वचालित इनटेक, रीट्राइ और सभ्य सबूतों के बिना आगे बढ़ने को तैयार नहीं है, एक वास्तविक गेट के साथ स्तर 5 है।
तैयारी के बारे में सोचें
काम को जोखिम और इसे पूर्ववत करने में आसानी के आधार पर वर्गीकृत करें। स्वायत्तता को रूढ़िवादी रूप से लागू करें, केवल तब बढ़ाएं जब उच्च स्तर का समर्थन करने वाले सबूत जमा हों। मजबूत परीक्षणों और समीक्षक एजेंटों द्वारा संरक्षित एक भुगतान इंजन रीफैक्टर, जिसमें साफ रोलबैक पथ हो, एक दस्तावेज़ीकरण ऑटोमेशन कार्य की तुलना में बहुत अधिक स्वायत्तता का समर्थन कर सकता है जिसमें कोई विहित सत्य नहीं है। स्वायत्तता स्तर को सत्यापन प्रक्रिया का पालन करना चाहिए, कार्य के नाम का नहीं।
चार एंटी-पैटर्न
हर सिस्टम आसानी से इन चार स्वायत्तता एंटी-पैटर्न का शिकार हो सकता है जब तक कि सतर्कतापूर्वक टाला न जाए।
स्वायत्तता प्रतिष्ठा के रूप में - एजेंट की स्वायत्तता रेटिंग प्रतिष्ठा का एक अर्थहीन बैज बन जाती है। उच्च स्वायत्तता को सुरक्षा के नहीं, बल्कि क्षमता के प्रमाण के रूप में माना जाता है, और एजेंटों को सत्यापन की तुलना में अधिक गर्म चलाया जाता है। समाधान: उन लोगों की प्रशंसा करें और पुरस्कृत करें जो स्वायत्तता के सही स्तर पर स्थिर होते हैं और सीमा पार करने से लगातार बचते हैं।
अनुमति मनी-लॉन्ड्रिंग - अनुमोदन थकान का अत्याचार हमें AI एजेंटों और टूल्स को आवश्यकता से कहीं अधिक व्यापक पहुँच प्रदान करने के लिए प्रेरित करता है। समाधान: बेहतर सीमाएँ हमेशा एक समाधान होती हैं, जैसे सैंडबॉक्स प्रोफाइल, दायरा-बद्ध राइटेबल रूट्स, अनुमत सूचीबद्ध कमांड, हुक और ऑटो-रिव्यू।
सारांश प्रतिस्थापन - एजेंट के कार्य का सारांश समीक्षा का विकल्प बन जाता है, यह मानते हुए कि सारांश पर्याप्त है। समाधान: पूरी तरह से मैन्युअल समीक्षाओं के समान सबूत पैकेज (डिफ, टेस्ट, लॉग, स्क्रीनशॉट, समीक्षक निष्कर्ष, जोखिम, अंतराल, आदि) बंडल करें, जबकि संज्ञानात्मक समर्पण से बचें।
फ्लीट कॉसप्ले - दर्जनों एजेंट समानांतर में चलते हैं, लेकिन एक मानव हर निर्भरता को मैन्युअल रूप से ऑर्केस्ट्रेट करने पर जोर देता है। समाधान: साझा स्थिति, स्वामित्व नियम और बेहतर निर्भरता ट्रैकिंग धीरे-धीरे मैन्युअल रूप से समन्वय करने की आवश्यकता को कम करते हैं। छोटी WIP सीमाएँ समन्वित चरणों को एन्कोड और दस्तावेज़ित करने पर ध्यान केंद्रित करने के लिए मजबूर करती हैं जब तक कि ऑर्केस्ट्रेशन स्वचालित न हो जाए।
एक कैलिब्रेशन व्यायाम
एजेंट सहायता से किए गए पिछले दस कार्यों की समीक्षा करें। प्रत्येक कार्य के लिए, स्वायत्तता स्तर, शामिल जोखिम, कार्य को कितनी आसानी से पूर्ववत किया जा सकता है, सत्यापन आवश्यकताओं को पूरा करने के लिए उत्पादित सबूत, समीक्षा समय, यदि कोई रीवर्क आवश्यक था, और क्या चुना गया स्वायत्तता स्तर अगली बार भी उपयुक्त होगा, रिकॉर्ड करें।
सुरक्षित रूप से कैसे चढ़ें
एक बार में एक अक्ष पर आगे बढ़ें। एक एकल पर्यवेक्षित एजेंट से शुरू करें जो एक एकल दायरा-बद्ध कार्य करता है जो सफलता के रक्षात्मक सबूत पैदा करता है (स्वायत्तता स्तर 1, यदि पर्याप्त साफ-सुथरा हो)। फिर धीरे-धीरे तीन ऑर्थोगोनल दिशाओं में विस्तार करें। पढ़ने-भारी अन्वेषण कार्यों को समानांतर करें (स्वायत्तता स्तर 4)। प्रतिबंधित फ़ाइल स्वामित्व नियमों के साथ अलग-अलग वर्कट्री पर काम करने वाले राइट एजेंट जोड़ें (स्वायत्तता स्तर 4)। आवर्ती ऑटोमेशन जोड़ें, फिर इश्यू, वॉयस आदि पर आधारित एजेंट-नेतृत्व वाला ऑर्केस्ट्रेशन जोड़ें। लीवर पर प्रत्येक कदम के लिए सुरक्षा तंत्रों का एक नया सेट आवश्यक है (जैसे नए विफलता मोड)।
उन्हें नाम दें: लंबे एकल-एजेंट रन ड्रिफ़्ट, संदर्भ सड़न, छोड़ा गया संचार या भटके हुए उद्देश्यों का कारण बन सकते हैं। बैकग्राउंड काम पुरानी धारणाओं और कमजोर हैंडऑफ़ का कारण बन सकता है। बहुत अधिक समानांतर काम मर्ज कॉन्फ्लिक्ट या डुप्लिकेट निर्णयों का कारण बन सकता है। बहुत अधिक आवर्ती काम मूक टोकन खर्च या पुराने प्रॉम्प्ट का कारण बन सकता है। अपवाद द्वारा प्रबंधन लंबी समीक्षा कतारों और अलर्ट थकान का कारण बन सकता है। कठिन भरोसा करके ठीक न करें; इसके बजाय, दायरा कम करें, बेहतर सबूत सुनिश्चित करें, सस्ते रोलबैक पथ सक्षम करें, गेट को मजबूत करें और स्पष्ट स्वामित्व नियम परिभाषित करें।
स्वायत्तता स्तर का उपयोग करें:
- स्तर 0 नाजुक काम और जब निर्णय अभी बन रहा हो, के लिए सबसे अच्छा है।
- स्तर 1 अधिकांश अन्वेषण के लिए सबसे अच्छा है, यदि कार्य अच्छी तरह से समझी जाने वाली सीमाओं के करीब किया जाता है।
- स्तर 2 अधिकांश दायरा-बद्ध कार्यों के लिए सबसे अच्छा है, यह जानते हुए कि अज्ञात निर्भरताएँ और अप्रत्याशित समस्याएँ हो सकती हैं।
- स्तर 3 सबसे अच्छा है जहाँ सफलता की शर्तों को पर्याप्त स्पष्टता के साथ बताया जा सकता है।
- स्तर 4 सबसे अच्छा है जब कार्य को इन सफलता शर्तों में साफ-साफ विभाजित किया जा सकता है।
- स्तर 5 सबसे अच्छा है एक बार विभिन्न सफलता शर्तों में आवश्यक समन्वय और संचार पूरी तरह से एन्कोड हो जाने के बाद।
सत्यापन हमेशा अड़चन होगा।
वर्तमान दिखावा और वर्तमान टूलिंग के बावजूद, AI एजेंटों के साथ काम करने वाली एक इंजीनियरिंग टीम की परिपक्व स्थिति कैलिब्रेटेड ऑटोनॉमी है।

अड़चनें समन्वय, सत्यापन, रखरखाव, उत्पाद निर्णय और घटना सीखना हैं
निकट भविष्य में, हम ऐसे लूप डिज़ाइन करना चाहेंगे जो जानते हों कि कब काम करना है, कब सत्यापित करना है और कब पूछना है - लेकिन इंजीनियर का कौशल अभी भी स्वायत्तता का सही स्तर चुनने और ऐसे पैटर्न और रक्षात्मक सबूत बनाने में निहित होगा जो इसके अंधेरे कोनों से बचाते हैं।
नोट: Pangram इस लेख को 100% मानव-लिखित के रूप में लेबल करता है: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26*





