मेरे एजेंट ने एक शाम में 3 PRs शिप किए। मेरे 40% संदेश सुधार (corrections) थे।
मेरे AI-संचालित कोडिंग एजेंट ने एक ही शाम में तीन पुल रिक्वेस्ट (pull requests) पुश किए, लेकिन मेरे द्वारा भेजे गए 30 संदेशों में से 40% सुधार के लिए थे।
इस सत्र में एक MCP client, एक Azure AI Agent, और एक M365 Copilot Agent तैयार हुआ। ऑटोमेटेड चेक ने तीनों PRs को पास कर दिया, और मैंने कोड की एक भी लाइन एडिट नहीं की। फिर भी, ट्रांसक्रिप्ट एक अलग कहानी बताती है: कुल 710 संदेशों में से, मैंने 30 टाइप किए, और उनमें से 12 ने एजेंट को वापस सही रास्ते पर लाने का काम किया। "स्टीयरिंग रेट" (steering rate) – यानी मेरे संदेशों का वह हिस्सा जो सुधार के लिए थे – 40% रहा।
पाइपलाइन का ढांचा कैसा था
- Claude ने एक हाई-लेवल इम्प्लीमेंटेशन प्लान तैयार किया।
- DeepSeek V4-Flash ने ऑर्केस्ट्रेटर (orchestrator) के रूप में काम किया और प्लान की समीक्षा की।
- Codex ने वास्तविक कोड जनरेट किया।
- ऑर्केस्ट्रेटर ने कोड का निरीक्षण किया और पुल रिक्वेस्ट (pull requests) ओपन कीं।
ऑर्केस्ट्रेटर की भूमिका केवल जोड़ने वाली (connective) होनी थी – उसे कंपोनेंट्स के बीच के संघर्षों (conflicts) को सुलझाना था, न कि खुद कोड लिखना था। व्यवहार में, एजेंट ने लगभग 40 मिनट में तीनों PRs में 3,500 लाइन का कोड तैयार किया, लेकिन वह दो बार-बार होने वाली त्रुटियों (error classes) में चूक गया।
दो प्रकार की त्रुटियाँ
- वर्कफ़्लो उल्लंघन (Workflow violations) – ऑर्केस्ट्रेटर कभी-कभी कोडिंग स्टेप खुद ही करने लगता था, अपनी "ग्लू" (glue) भूमिका को नज़रअंदाज़ करते हुए इम्प्लीमेंटेशन डिटेल्स खुद ही लिखने लगता था।
- कॉन्टेक्स्ट-रिट्रीवल विफलताएं (Context-retrieval failures) – स्पष्ट निर्देशों के बावजूद, एजेंट ने गलत SDK या वर्ज़न चुन लिया। सही जानकारी प्रॉम्प्ट कॉन्टेक्स्ट (prompt context) में मौजूद थी, लेकिन मॉडल उसे सही समय पर सामने लाने में विफल रहा।
ये तर्क करने की क्षमता (reasoning ability) में कमी नहीं हैं; ये वर्कफ़्लो को नियंत्रित करने के तरीके में इंजीनियरिंग बग्स (engineering bugs) हैं। एक अधिक सक्षम लैंग्वेज मॉडल को भी एक सख्त और स्पष्ट नियम की आवश्यकता होगी जो ऑर्केस्ट्रेटर को उसके नॉन-कोडिंग कर्तव्यों तक सीमित रखे और सही SDK चयन के लिए मजबूर करे।
एजेंट को नियंत्रित करने के लिए मैंने क्या बदला
मैंने यह मानना बंद कर दिया कि सिस्टम स्टेप लिस्ट से अपनी भूमिका का अनुमान लगा लेगा। मैंने एक सीधा निर्देश जोड़ा: “You are an orchestrator. You do not implement.” (आप एक ऑर्केस्ट्रेटर हैं। आप इम्प्लीमेंटेशन नहीं करते हैं।) इस निर्देश को प्रभावी होने में पाँच सुधार संदेश लगे, जिसके बाद एजेंट ने इस सीमा का सम्मान किया।
मैंने कॉन्टेक्स्ट-रिट्रीवल लॉजिक को भी सख्त किया। जब गलत टूल सामने आया, तो मैंने इसे 'हैलुसिनेशन' (hallucination) के बजाय रिट्रीवल पाइपलाइन में एक बग के रूप में देखा, और मैंने उस प्रॉम्प्ट को फिर से लिखा जो SDK विवरण प्रदान करता है, ताकि सही वर्ज़न को नज़रअंदाज़ करना असंभव हो जाए।
AI-संवर्धित विकास (AI-augmented development) के लिए व्यावहारिक सुझाव
- अपने स्वयं के संदेशों को गिनें। स्वीकृत PRs की बड़ी संख्या एक खराब प्रक्रिया को छिपा सकती है। आपके सुधारों की संख्या इस बात का मुख्य संकेतक है कि सिस्टम में कहाँ कमी रह गई है।
- भूमिका को स्पष्ट रूप से बताएं। एजेंट चेकलिस्ट से अपनी पहचान का अनुमान नहीं लगाते; उन्हें इस बारे में स्पष्ट और निश्चित निर्देश चाहिए कि वे कौन हैं और वे क्या कर सकते हैं।
- टूल-चयन त्रुटियों को इंजीनियरिंग बग्स के रूप में मानें। यदि एजेंट किसी निर्दिष्ट SDK को नज़रअंदाज़ करता है, तो दोष कॉन्टेक्स्ट-डिलीवरी मैकेनिज्म में है, मॉडल के "ज्ञान" में नहीं।
- गलतियों को पुन: प्रयोज्य कौशल (reusable skills) में बदलें। मैंने एजेंट को अपनी गलतियों से एक वैलिडेशन रूटीन जनरेट करने दिया, जिससे एक विफलता भविष्य के सुरक्षा कवच (safeguard) में बदल गई।