AI एजेंट इंजीनियरिंग के 5 जाल

पारंपरिक software engineering (deterministic, कड़े control वाली) की आदतें AI agent development (probabilistic, flexibility-केंद्रित) में उल्टा बाधा बन सकती हैं।

• Hugging Face के Philipp Schmid के अनुसार, जितने senior developer होते हैं, उतना ही वे LLM की अनिश्चितता को ‘code से हटाने’ की कोशिश करते हैं, और इस वजह से वे junior से भी धीमे हो जाते हैं।
• उपमा: air traffic controller (पारंपरिक) → dispatcher (agent) की भूमिका में बदलाव ज़रूरी।

1. टेक्स्ट ही नया state है
   • जाल: natural language input को structured data (जैसे: true/false) में जबरन बदलने पर context खो जाता है।
   • समाधान: feedback (जैसे: “अनुमोदित, अमेरिकी बाज़ार पर फोकस”) को टेक्स्ट के रूप में सुरक्षित रखें, ताकि dynamic adjustment संभव हो।

2. नियंत्रण छोड़ें
   • जाल: flow को hardcode करने पर (जैसे: subscription cancel route) non-linear interaction को संभालना विफल हो जाता है।
   • समाधान: agent (LLM) पर भरोसा करें कि वह context के आधार पर intent समझे।

3. error भी सिर्फ input है
   • जाल: error आने पर program रोक देना (पारंपरिक तरीका) high-cost execution को व्यर्थ कर देता है।
   • समाधान: error को feedback की तरह दें ताकि agent self-recovery की कोशिश कर सके।

4. unit test से Eval तक
   • जाल: binary test (TDD) को probabilistic system पर लागू करना अर्थहीन है (वैध जवाब अनंत हो सकते हैं)।
   • समाधान: reliability (Pass@k), quality (LLM Judge), tracking (Eval) से variability को manage करें।

5. agent evolve होते हैं, API नहीं
   • जाल: human-centered API (implicit context) का उपयोग करने पर agent hallucination पैदा हो सकती है।
   • समाधान: detailed semantic typing (जैसे: user_email_address) और docstring से चीज़ों को स्पष्ट करें। agent tool changes के अनुसार adapt कर सकते हैं।

निष्कर्ष

probabilistic nature को स्वीकार करें, और Eval/self-correction के ज़रिए उसे manage करें। “भरोसा करें, लेकिन verify भी करें” — कड़ाई से ज़्यादा resilient system बनाना ही मुख्य बात है। (मूल लेख का स्रोत: Philipp Schmid का “Why (Senior) Engineers Struggle to Build AI Agents”)