🤖 AI

Agentic Coding Needs Proactivity, Not Just Autonomy

यह शोधपत्र तर्क देता है कि कोडिंग एजेंटों की अगली पीढ़ी को केवल स्वायत्तता से आगे बढ़कर वास्तविक सक्रियता (proactivity) की ओर विकसित होना चाहिए, जिसके लिए एक स्पष्ट वर्गीकरण (taxonomy) को परिभाषित करना, स्वीकृति मानदंड स्थापित करना और उनकी आवश्यकताओं का पूर्वानुमान लगाने तथा मिश्रित-पहल (mixed-initiative) अंतःक्रिया के माध्यम से सॉफ्टवेयर विकास में सुधार करने की क्षमता का मूल्यांकन करने के लिए 'इनसाइट डिसीजन क्वालिटी' (Insight Decision Quality) जैसे विशिष्ट मेट्रिक्स को पेश करना आवश्यक है।

मूल लेखक: Nghi D. Q. Bui, Georgios Evangelopoulos

प्रकाशित 2026-05-11

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Nghi D. Q. Bui, Georgios Evangelopoulos

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आपके पास एक अत्यधिक कुशल, सुपर-फास्ट सहायक है जो सॉफ्टवेयर लिखने में आपकी मदद करता है। अभी, इनमें से अधिकांश सहायक बहुत आज्ञाकारी पुस्तकालयाध्यक्ष (librarians) की तरह हैं। यदि आप डेस्क पर जाकर पूछते हैं, "क्या आप मुझे बिल्लियों के बारे में एक किताब ढूंढ कर दे सकते हैं?" तो वे तुरंत उसे ढूंढ लेते हैं। यदि आप कहते, "बिल्ली के बारे में एक कहानी लिखें," तो वे उसे लिख देते हैं। वे स्वायत्त (autonomous) हैं क्योंकि वे बिना आपके हाथ पकड़े काम कर सकते हैं, लेकिन वे प्रतिक्रियाशील (reactive) हैं क्योंकि वे केवल तभी चलते हैं जब आप उन्हें कुछ करने के लिए कहते हैं।

यह शोध पत्र तर्क देता है कि कोडिंग सहायकों की अगली पीढ़ी को केवल आज्ञाकारी पुस्तकालयाध्यक्षों से कहीं अधिक होने की आवश्यकता है। उन्हें सक्रिय भागीदार (proactive partners) होने की आवश्यकता है।

यहाँ सरल उपमाओं (analogies) का उपयोग करके इस शोध पत्र के मुख्य विचारों का विवरण दिया गया है:

1. "स्वायत्तता" (Autonomy) और "सक्रियता" (Proactivity) के बीच अंतर

स्वायत्तता (आज्ञाकारी पुस्तकालयाध्यक्ष): सहायक आपके पूछने का इंतज़ार करता है, और फिर काम करता है। यह बहुत अच्छा है, लेकिन यह तब तक नहीं बोलता जब तक आप पहले नहीं बोलते।
सक्रियता (अंतर्दृष्टि रखने वाला को-पायलट): सहायक आपके काम करते समय पूरी लाइब्रेरी (आपका कोड, आपका शेड्यूल, आपकी टीम की चैट) को देख रहा होता है। वह आपसे पूछने से पहले ही चीजों को भांप लेता है।
- उदाहरण: आप एक पेमेंट सिस्टम के लिए कोड लिख रहे हैं। सहायक देखता है कि एक समाचार अलर्ट आया है कि अगले सप्ताह भुगतान कंपनी अपने नियम बदल रही है।
- कठिन हिस्सा: एक सक्रिय एजेंट तुरंत चिल्लाकर, "हे, इसे देखो!" नहीं कहता। उसे यह तय करना होता है: क्या यह टोकने का सही समय है? क्या यह इतना महत्वपूर्ण है? क्या मुझे चुप रहना चाहिए और आपके वर्तमान विचार को पूरा होने का इंतज़ार करना चाहिए?

2. "स्मार्ट" सहायकों के तीन स्तर

लेखकों ने इन एजेंटों को समझाने के लिए एक "ट्रैफिक लाइट" प्रणाली बनाई है:

स्तर 1: प्रतिक्रियाशील (लाल बत्ती)
- यह कैसे काम करता है: एजेंट तब तक स्थिर रहता है जब तक आप कोई बटन नहीं दबाते (प्रॉम्प्ट नहीं देते)।
- उपमा: एक कैलकुलेटर। जब तक आप उसमें नंबर टाइप नहीं करते, वह कुछ नहीं करता।
स्तर 2: निर्धारित (पीली बत्ती)
- यह कैसे काम करता है: एजेंट विशिष्ट समय पर या किसी विशिष्ट घटना के होने पर जाग जाता है (जैसे कि एक निर्धारित मीटिंग या कोड अपडेट)। वह आपको रिपोर्ट भेज सकता है, लेकिन वह वास्तव में यह नहीं सोचता कि क्या आप व्यस्त हैं या क्या वह रिपोर्ट वास्तव में अभी उपयोगी है।
- उपमा: एक समाचार पत्र की डिलीवरी। वह हर दिन सुबह 7:00 बजे आता है, चाहे आप जाग रहे हों, सो रहे हों, या नहा रहे हों। उसे नहीं पता कि आपको इसकी ज़रूरत है या नहीं।
स्तर 3: स्थिति-जागरूक (हरी बत्ती)
- यह कैसे काम करता है: एजेंट लगातार सब कुछ देखता है। वह गणना करता है: "यदि मैं इस डेवलपर को अभी टोकता हूँ, तो क्या वे चिढ़ जाएंगे? क्या यह जानकारी महत्वपूर्ण है? यदि मैं चुप रहता हूँ, तो क्या वे कुछ महत्वपूर्ण मिस कर देंगे?"
- उपमा: एक व्यक्तिगत सहायक जो जानता है कि आपको गहरे काम (deep work) के दौरान टोकना पसंद नहीं है। यदि आग लगती है, तो वे चिल्लाते हैं। यदि कोई पैकेज आता है, तो वे आपके कॉफी ब्रेक लेने तक इंतज़ार करते हैं। वे आपसे सीखते भी हैं: "ओह, आपने पिछली बार बजट के बारे में मेरे सुझाव को अनदेखा किया था? अब मैं आपको अगले महीने तक बजट के बारे में परेशान नहीं करूँगा।"

3. "अंतर्दृष्टि" (Insight) ही असली उत्पाद है

शोध पत्र कहता है कि हमें इन एजेंटों को इस आधार पर नहीं मापना चाहिए कि उन्होंने कितने कार्य पूरे किए। इसके बजाय, हमें उनकी "इनसाइट पॉलिसी" (Insight Policy) को मापना चाहिए।

एक इनसाइट (Insight) को एक परिकल्पना (hypothesis) के रूप में सोचें: "मुझे लगता है कि आपको अभी X के बारे में जानने की आवश्यकता है।"
एजेंट के पास प्रत्येक इनसाइट के लिए चार विकल्प होते हैं:

सूचित करना (Notify): "हे, इसे देखो!" (उच्च तात्कालिकता)।
प्रश्न करना (Question): "क्या आपका मतलब यह था?" (अनिश्चितता)।
ड्राफ्ट बनाना (Draft): "मैंने आपके लिए एक फिक्स लिखा है, क्या आप देखना चाहेंगे?" (कम प्रयास, उच्च मूल्य)।
शांत रहना (Stay Silent): "मैंने इसे देखा, लेकिन यह बोलने का सही समय नहीं है।"

शोध पत्र का बड़ा दावा: स्तर 3 के एजेंट के लिए सबसे महत्वपूर्ण कौशल यह जानना है कि कब चुप रहना है। यदि एक एजेंट बहुत अधिक बोलता है, तो वह एक बाधा बन जाता है। यदि वह चुप रहता है जब उसे बोलना चाहिए, तो वह बेकार है।

4. हम इसका परीक्षण कैसे करेंगे? (नया स्कोरकार्ड)

वर्तमान में, हम कोडिंग एजेंटों का परीक्षण उन्हें एक कार्य देकर और यह देखकर करते हैं कि क्या वे उसे पूरा करते हैं। लेखकों का कहना है कि सक्रिय एजेंटों के लिए यह गलत है। इसके बजाय, वे ग्रेडिंग के तीन नए तरीके प्रस्तावित करते हैं:

IDQ (इनसाइट निर्णय गुणवत्ता - Insight Decision Quality): क्या एजेंट ने सही समय पर सही कार्रवाई चुनी?
- क्या उसने आपको तब टोका जब आप अपने काम में डूबे हुए थे? क्या उसने तब चुप रहकर मदद की जब आपको उसकी ज़रूरत थी?
CGS (संदर्भ ग्राउंडिंग स्कोर - Context Grounding Score): क्या एजेंट के पास सही प्रमाण था?
- यदि उसने कहा "आपका कोड टूटा हुआ है," तो क्या उसने आपको विशिष्ट एरर लॉग दिखाया, या वह केवल अनुमान लगा रहा था?
LL (लर्निंग लिफ्ट - Learning Lift): क्या एजेंट ने आपके फीडबैक के बाद खुद को बेहतर बनाया?
- यदि आपने उसे कहा, "मुझे इस बारे में परेशान करना बंद करो," तो क्या उसने वास्तव में बाद में परेशान करना बंद कर दिया?

5. वर्तमान वास्तविकता की जाँच

लेखकों ने आज उपलब्ध शीर्ष कोडिंग टूल्स (जैसे GitHub Copilot, Cursor, Claude Code, आदि) को देखा। उन्होंने पाया कि:

अधिकांश स्तर 2 (निर्धारित) पर अटके हुए हैं। वे टाइमर या ट्रिगर्स पर चलते हैं।
उनमें से किसी के पास भी वर्तमान में यह गणना करने का स्पष्ट तरीका नहीं है कि आपको टोकने की "लागत" (cost of interrupting) क्या है।
उनमें से कोई भी स्पष्ट रूप से "चुप रहने" को एक स्मार्ट, सीखी गई पसंद के रूप में नहीं मानता है। वे ज्यादातर केवल आपके पूछने का इंतज़ार करते हैं।

सारांश

यह शोध पत्र एक आह्वान (call to action) है। यह कहता है: "केवल ऐसे एजेंट बनाना बंद करें जो काम कर सकें। ऐसे एजेंट बनाना शुरू करें जो जानते हों कि कब काम करना है, कब बोलना है, और कब चुप रहना है।"

वहाँ पहुँचने के लिए, हमें उन्हें "पूर्ण किए गए कार्यों" से मापना बंद करना होगा और "अच्छे निर्णय", "प्रमाण", और "फीडबैक से सीखने" के आधार पर मापना शुरू करना होगा। लक्ष्य एक ऐसा कोडिंग पार्टनर है जो एक रोबोट के बजाय एक विचारशील टीम के साथी जैसा महसूस हो।

तकनीकी सारांश: एजेंटिक कोडिंग के लिए प्रोएक्टिविटी (सक्रियता) की आवश्यकता है, न कि केवल स्वायत्तता की

1. समस्या विवरण

सॉफ्टवेयर विकास का परिदृश्य इनलाइन कोड पूर्णता (inline code completion) से बदलकर स्वायत्त कोडिंग एजेंटों की ओर बढ़ रहा है जो रिपॉजिटरी को संपादित करने, पुल रिक्वेस्ट (pull requests) प्रबंधित करने और निर्धारित रूटीन चलाने में सक्षम हैं। वर्तमान प्रणालियाँ महत्वपूर्ण स्वायत्तता (बिना पर्यवेक्षण के कार्य करने की क्षमता) प्रदर्शित करती हैं, लेकिन वे प्रोएक्टिविटी (सक्रियता/पूर्वाभास) की एक स्पष्ट परिभाषा और मूल्यांकन ढांचे के बिना रह जाती हैं।

मूल समस्या एक ऐसे तंत्र की अनुपस्थिति है जिसके माध्यम से एजेंट यह तय कर सके कि कब कार्य करना है, क्या दिखाना है, और कब मौन रहना है। वर्तमान एजेंट अक्सर स्पष्ट प्रॉम्प्ट या निश्चित शेड्यूल्स (लेवल 2) पर कार्य करते हैं, जो "सक्रिय होने" और "उपयोगी होने" के बीच अंतर करने में विफल रहते हैं। यहाँ निम्नलिखित का कोई स्पष्ट विवरण नहीं है:

सॉफ्टवेयर विकास के संदर्भ में प्रोएक्टिविटी का क्या अर्थ है।
यह सरल स्वायत्तता से कैसे भिन्न है।
प्रोएक्टिव, दीर्घ-अवधि वाले कार्यों को किन स्वीकृति मानदंडों को पूरा करना चाहिए।
कौन से मेट्रिक्स यह निर्धारित करते हैं कि अनचाहा एजेंट व्यवहार लाभकारी है या केवल दखल देने वाला।

इन परिभाषाओं के बिना, क्षेत्र यह मूल्यांकन नहीं कर सकता कि क्या किसी एजेंट की "इनसाइट पॉलिसी" (अंतर्दृष्टि नीति)—अर्थात यह निर्णय लेने की प्रक्रिया कि आगे क्या महत्वपूर्ण है—प्रभावी है।

2. कार्यप्रणाली और ढांचा

लेखक मिक्स्ड-इनिशिएटिव इंटरैक्शन (Horvitz, 1999) और स्वायत्तता वर्गीकरण (Händler, 2023) पर आधारित एक सैद्धांतिक ढांचे का प्रस्ताव करते हैं। कार्यप्रणाली के तीन मुख्य घटक हैं:

A. निर्णय-सैद्धांतिक सूत्रीकरण (Decision-Theoretic Formulation)

पेपर प्रोएक्टिव व्यवहार को एक निर्णय-सैद्धांतिक समीकरण का उपयोग करके मॉडल करता है जहाँ एक एजेंट अपेक्षित उपयोगिता (expected utility) को अधिकतम करने और व्यवधान लागत (interruption cost) को न्यूनतम करने के लिए एक क्रिया $a^*$ का चयन करता है:
$a^* = \arg\max_{a \in A} \mathbb{E}_{p(o|a,s_t,E_t)} [U(o; \theta)] - \text{Cost}_{int}(s_t, a; \theta)$

एक्शन स्पेस ( $A$ ): इसमें notify (सूचित करना), question (प्रश्न पूछना), draft (ड्राफ्ट बनाना), और महत्वपूर्ण रूप से, stay silent (मौन रहना) शामिल है।
स्टेट ( $s_t$ ): डेवलपर की स्थिति (खुले बफर्स, कैलेंडर, स्प्रिंट डेडलाइन)।
इवेंट स्ट्रीम ( $E_t$ ): कोड, प्रोजेक्ट और संचार घटनाओं का निरंतर प्रवाह।
व्यवधान लागत ( $\text{Cost}_{int}$ ): डेवलपर के फोकस, वर्कफ़्लो चरण और रिकवरी समय के आधार पर एक परिवर्तनशील लागत।
इनसाइट (अंतर्दृष्टि): इसे एक संदर्भ-आधारित, समय-संवेदनशील परिकल्पना के रूप में परिभाषित किया गया है जो कार्य करने या मौन रहने के निर्णय के साथ जुड़ी होती है।

B. प्रोएक्टिविटी का तीन-स्तरीय वर्गीकरण (Three-Level Taxonomy)

लेखक कोडिंग एजेंटों को तीन स्तरों में वर्गीकृत करते हैं, जो निर्णय समीकरण के पदों की गणना करने की उनकी क्षमता पर आधारित है:

लेवल 1 (रिएक्टिव/प्रतिक्रियाशील): एजेंट केवल तभी चलते हैं जब उन्हें स्पष्ट रूप से प्रॉम्प्ट दिया जाता है। उनके पास अनुरोधों के बीच कोई निरंतर पर्यावरणीय उपस्थिति या टाइम मॉडल नहीं होता है।
लेवल 2 (शेड्यूल्ड/अनुसूचित): एजेंट शेड्यूल या पूर्वनिर्धारित ट्रिगर्स (जैसे वेबहुक्स, GitHub इवेंट्स) पर चलते हैं। वे आउटपुट को फ़िल्टर या रैंक कर सकते हैं लेकिन एक क्रॉस-कॉन्टेक्स्ट, प्रति-डेवलपर व्यवधान नीति नहीं सीख सकते। यहाँ मौन रहना एक सीखा हुआ विकल्प नहीं है; यह केवल एक ट्रिगर की अनुपस्थिति है।
लेवल 3 (सिचुएशन-अवेयर/परिस्थिति-जागरूक): एजेंट निरंतर इवेंट स्ट्रीम की निगरानी करते हैं, पूरे एक्शन स्पेस (मौन रहने सहित) में उपयोगिता और व्यवधान लागत की गणना करते हैं, और डेवलपर के फीडबैक के आधार पर अपनी नीति ( $\theta$ ) को अपडेट करते हैं। वे तय करते हैं कि क्या दिखाना है, कब दिखाना है, और क्या कुछ भी दिखाना ही सही क्रिया है।

C. मूल्यांकन प्रोटोकॉल (Evaluation Protocol)

पेपर सॉफ्टवेयर विकास के लिए एक्टिव यूजर सिमुलेशन (Nathani et al., 2026) को अनुकूलित करने का प्रस्ताव करता है। अंतिम कार्य पूर्णता (जैसा कि SWE-Bench में होता है) को स्कोर करने के बजाय, मूल्यांकन इनसाइट स्ट्रीम पर केंद्रित है।

ट्रेस कलेक्शन (Trace Collection): रिपॉजिटरी डिफ, CI लॉग्स, संचार और IDE स्टेट के साथ संरेखित टाइमस्टैम्प वाले, पुनरावृत्ति योग्य डेवलपर-वर्कफ़्लो ट्रेसेस।
परिदृश्य संरचना (Scenario Structure): दीर्घ-अवधि वाले परिदृश्यों में कमजोर संकेत (weak signals), विचलित करने वाले कारक (distractors), पुष्टिकारक साक्ष्य (confirming evidence), और वे क्षण शामिल हैं जहाँ मौन रहना सही क्रिया है।
मेट्रिक्स:
1. इनसाइट डिसीजन क्वालिटी (IDQ): यह स्कोर करता है कि क्या एजेंट ने सही समय पर सही क्रिया (नोटिफाई, प्रश्न, ड्राफ्ट, मौन) चुनी।
2. कॉन्टेक्स्ट ग्राउंडिंग स्कोर (CGS): मापता है कि क्या दिखाए गए इनसाइट्स को रिकवरेबल साक्ष्यों (फाइल्स, डिफ्स, लॉग्स) द्वारा समर्थित किया गया है और क्या संदेश उस साक्ष्य के प्रति निष्ठावान है।
3. लर्निंग लिफ्ट (LL): यह मापता है कि एक फ्रोजन (स्थिर) नीति की तुलना में डेवलपर फीडबैक के आधार पर अनुकूलित नीति में IDQ में कितना सुधार हुआ।

3. मुख्य योगदान

पेपर चार विशिष्ट योगदान देता है:

एक तीन-स्तरीय वर्गीकरण: स्वायत्तता से प्रोएक्टिविटी का एक औपचारिक अलगाव, जो रिएक्टिव, शेड्यूल्ड और सिचुएशन-अवेयर एजेंटों के बीच अंतर करता है।
तुलनात्मक ऑडिट: पांच समकालीन कोडिंग एजेंटों (Cursor, GitHub Copilot, Jules, Claude Code, और एक LangChain संदर्भ आर्किटेक्चर) का पांच व्यावहारिक मानदंडों (O1–O5) के विरुद्ध विश्लेषण।
- निष्कर्ष: वर्तमान तैनात एजेंट लेवल 2 के आसपास क्लस्टर करते हैं। कोई भी सार्वजनिक रूप से व्यवधान लागत गणना (O1), स्पष्ट मौन को एक सीखे हुए एक्शन के रूप में (O2), या प्रति-डेवलपर फीडबैक के आधार पर पॉलिसी अपडेट (O3) का दस्तावेजीकरण नहीं करता है।
प्रोटोटाइप लेवल 3 इंजन: एक वैचारिक आर्किटेक्चर जो "इनसाइट" इकाई पर केंद्रित है, जो डेवलपर के मेंटल मॉडल को बनाए रखता है और प्रतिक्रिया से सीखता है।
मूल्यांकन मेट्रिक्स: प्रोएक्टिव व्यवहार को मापने के लिए IDQ, CGS और LL को प्राथमिक इकाइयों के रूप में प्रस्तावित करना, जिससे ध्यान कार्य पूर्णता से हटकर इनसाइट पॉलिसी की गुणवत्ता पर केंद्रित होता है।

4. परिणाम और निष्कर्ष

पेपर में एक तैनात लेवल 3 सिस्टम से कोई मापा गया प्रायोगिक परिणाम प्रस्तुत नहीं किए गए हैं; यह एक पोजीशन और मेजरमेंट प्रस्ताव है। हालांकि, मौजूदा सिस्टम के ऑडिट से निम्नलिखित निष्कर्ष प्राप्त होते हैं:

"प्रोएक्टिविटी गैप": जबकि Cursor Automations और Claude Code Routines जैसे सिस्टम शेड्यूल्ड कार्यों (लेवल 2) का समर्थन करते हैं, उनमें व्यवधान लागत की गणना करने या मौन को एक स्पष्ट, सीखे हुए एक्शन के रूप में मानने के प्रमाण की कमी है।
O1-O5 ऑडिट:
- O1 (व्यवधान लागत): कोई भी तैनात एजेंट इसकी गणना का दस्तावेजीकरण नहीं करता है।
- O2 (स्पष्ट मौन): कोई भी एजेंट एक्शन स्पेस में मौन को एक सीखे हुए एक्शन के रूप में दस्तावेजीकृत नहीं करता है।
- O3 (फीडबैक अपडेट्स): साक्ष्य कमजोर हैं; कुछ सिस्टम मेमोरी एक्सपोज़ करते हैं, लेकिन सर्फेसिंग निर्णयों पर इसका प्रभाव स्पष्ट नहीं है।
- O4 (क्रॉस-कॉन्टेक्स्ट): कई संदर्भ श्रेणियों को ग्रहण करने के लिए आंशिक साक्ष्य मौजूद हैं।
- O5 (इनिशिएशन चैनल): व्यापक रूप से संतुष्ट; एजेंट अलग टूल्स के बिना संदेश दिखा सकते हैं।
वर्तमान स्थिति पर निष्कर्ष: सीमा (frontier) नई क्षमताओं को आविष्कार करने में नहीं है, बल्कि मौजूदा इंटरैक्शन पैटर्न को सॉफ्टवेयर विकास की विशिष्टताओं, विशेष रूप से हस्तक्षेप करने के कब और मौन रहने के कब के निर्णय के अनुकूल बनाने में है।

5. महत्व और दावे

पेपर का दावा है कि अगली पीढ़ी के कोडिंग एजेंटों का मूल्यांकन इस आधार पर नहीं किया जाना चाहिए कि वे कितना काम पूरा करते हैं, बल्कि उनकी इनसाइट पॉलिसी की गुणवत्ता और सुधार के आधार पर किया जाना चाहिए।

पैराडाइम में बदलाव: प्रोएक्टिविटी को केवल ऑटोमेशन के बजाय "मिक्स्ड-इनिशिएटिव सहयोग" के रूप में देखा जाना चाहिए। एक एजेंट तब प्रोएक्टिव है यदि वह सीखता है कि किन योगदानों पर ध्यान दिया जाना चाहिए, कौन सा साक्ष्य उन्हें विश्वसनीय बनाता है, और फीडबैक के बाद कैसे अनुकूलित होना है।
जवाबदेही: यह ढांचा प्रोएक्टिविटी को परीक्षण योग्य बनाता है। इनसाइट्स को परिभाषित करके और IDQ, CGS, और LL को मापकर, क्षेत्र उत्पाद लेबल से आगे बढ़कर मापने योग्य व्यवहार की ओर बढ़ सकता है।
डिज़ाइन निहितार्थ: एक वास्तविक लेवल 3 एजेंट के लिए ऐसे इंटरफ़ेस की आवश्यकता है जो विलंबित (deferred) इनसाइट्स को निरीक्षण योग्य (inspectable) बनाता है, जिससे डेवलपर्स को सुझावों को स्वीकार करने, संपादित करने या खारिज करने की अनुमति मिलती है, जिससे सीखने के लिए आवश्यक फीडबैक लूप मिलता है।
विनम्रता: लेखक स्वीकार करते हैं कि यह एक प्रस्ताव है। सिम्युलेटेड डेवलपर्स वास्तविक उपयोगकर्ताओं से भिन्न हो सकते हैं, और वास्तविक समय के कार्य से व्यवधान के निष्कर्ष एसिंक्रोनस संदेशों में पूरी तरह से स्थानांतरित नहीं हो सकते हैं। पेपर अनिश्चितता की रिपोर्ट करने और प्रोएक्टिविटी को एक एकल बेंचमार्क स्कोर के बजाय वास्तविक डेवलपर्स से जुड़ी एक संपत्ति के रूप में मानने की वकालत करता है।

संक्षेप में, पेपर का तर्क है कि एजेंटिक कोडिंग को परिपक्व होने के लिए, इसे "अधिक करने" से "बेहतर निर्णय लेने" की ओर विकसित होना चाहिए, जिसमें मौन के रणनीतिक मूल्य और व्यवधान नीतियों के निरंतर अनुकूलन पर विशेष ध्यान दिया गया है।