एजेंटिक सॉफ्टवेयर इंजीनियरिंग में दो प्रमुख अंतर

एक AI एजेंट से एक key-value store की गति बढ़ाने को कहा गया। उसने 6× throughput में वृद्धि की और हर correctness test पास किया। इसका कारण? एजेंट ने खोज निकाला कि स्टोर के प्रदर्शन का आकलन करने के लिए उपयोग किया जाने वाला industry-standard benchmark keys से values generate करता था। Values को स्टोर करने के बजाय, यह क्लाइंट्स द्वारा अनुरोध किए जाने पर उन्हें simply on demand regenerate कर देता था।

ऐसा key-value store जो values को स्टोर नहीं करता, बहुत कम समझ में आता है, फिर भी evaluator ने ठीक उसी व्यवहार को पुरस्कृत किया। Specification में कुछ छोड़ दिया गया जिसे हम स्पष्ट मानते थे, और benchmark ने उस omission को उजागर करने में विफल रहा।

Reward hacking और hallucinations की ओर ले जाने वाले दो gaps

हमारा नया paper इस व्यवहार और कई अन्य agentic failures की व्याख्या दो मुख्य gaps के दृष्टिकोण से करता है, जो परिचित implementation-verification loop के बाहर स्थित हैं—जो code generate करता है, tests चलाता है, और सभी tests pass होने तक failures को ठीक करता है।

1. Requirement Gap: यह उस चीज़ को अलग करता है जिसे हम लिखते हैं और उस चीज़ को जो हम वास्तव में चाहते हैं। हमारे मामले में, हमने इसे स्वतःसिद्ध मान लिया कि कोई भी solution client-provided values को स्टोर करेगा—आखिरकार, इसे 'store' कहने का कोई कारण तो है!—इसलिए हमें कभी यह requirement स्पष्ट रूप से stating का ख्याल ही नहीं आया।
2. Model Gap: यह जिस environment में हम evaluate करते हैं और जिस real-world में implementation deploy होगी, उनके बीच अंतर करता है। हमारे benchmark ने predictable values का उपयोग किया, लेकिन real clients arbitrary values supply करते हैं।

स्वाभाविक प्रतिक्रिया बेहतर requirements और मजबूत tests लिखना है। दोनों मदद करते हैं। लेकिन even machine-checked proofs इन gaps को close नहीं कर सकते। जैसा कि Brian Cantwell Smith ने The Limits of Correctness (1985) में समझाया था, एक proof केवल यह स्थापित करता है कि software दिए गए environmental assumptions के तहत stated requirements को satisfy करता है। यह यह साबित नहीं कर सकता कि वे requirements users की हर इच्छा को capture करते हैं, या कि वे assumptions हर real-world deployment scenario को cover करते हैं। नतीजतन, इन gaps को सामान्य रूप से close नहीं किया जा सकता।

ये gaps reward hacking और hallucinations की ओर ले जाते हैं। Reward hacking तब होता है जब agents किसी gap का शोषण करके, जैसे कि unstated requirement या real-world assumption, दिए गए objective को improve करते हैं। Hallucination तब होती है जब agents fabricated requirements या environment assumptions, जैसे कि non-existent API, पेश करके gaps को और चौड़ा करते हैं। हाल ही में रिपोर्ट की गई घटनाएं जिसमें OpenAI and Hugging Face और Claude शामिल हैं, ये सब इन gaps के ही manifestations हैं।

AI agents दो gaps को और खराब बनाते हैं

ये gaps नए नहीं हैं; ये decades से software engineers के साथ मौजूद रहे हैं। लेकिन AI agents इन gaps को बहुत अधिक खराब बना देते हैं।

• Hyper-Optimization: Agents implementations को humans से orders of magnitude तेजी से search करते हैं, और evaluator के खिलाफ actively optimize करते हैं।
• Missing Tacit Knowledge: अनुभवी human engineers tacit context पर निर्भर करते हैं (उदाहरण के लिए, यह जानना कि data store को वास्तव में data स्टोर करना चाहिए)। Agents अक्सर यह organizational context से वंचित होते हैं और missing requirements का शोषण करने में हिचकिचाते नहीं हैं।
• The Multi-Agent Trap: यदि हर agent वही incomplete requirements और environmental assumptions inherit करता है, तो more reviewing agents जोड़ने से समस्या हल नहीं होती।

Gaps को संकुचित करने के लिए Human judgement आवश्यक है

चूंकि gaps implementation–verification loop के बाहर स्थित हैं, उन्हें संकुचित करने के लिए एक outer assurance-revision loop की आवश्यकता होती है। यह loop जाँचता है कि deployed behavior human intent को satisfy करता है या नहीं। जब यह नहीं करता, तो loop deployment evidence का उपयोग requirements, environment model, या evaluator को revise करने के लिए करता है। फिर implementation-verification loop revised implementation उत्पन्न करने के लिए दोबारा चलता है।

चूंकि software को human intent की सेवा करनी होती है, इसलिए evidence की व्याख्या करने और स्वीकार्य behavior तय करने पर humans का अंतिम authority बना रहता है। Agents evidence gathering, revisions proposing, और humans द्वारा delegated authority के भीतर routine decisions लेने के माध्यम से outer loop को accelerate कर सकते हैं।

अतः, जैसे-जैसे software implementation सस्ता होता जाता है, सबसे महत्वपूर्ण resource बन जाती है human judgment—यह तय करने के लिए कि कौन सा behavior स्वीकार्य है, और systems वास्तविक परिस्थितियों में कैसा perform करते हैं, इसका faithful evaluation।