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

स्वायत्तता का जाल (The Autonomy Trap)

रोमांचक स्वायत्तता एक जाल है। यह हमें उन बॉट्स का जश्न मनाने के लिए प्रशिक्षित करती है जो स्पेसिफिकेशन तैयार करते हैं, रिपॉजिटरी को संशोधित करते हैं, और शांति से यह दावा करते हुए कोड तैनात (deploy) करते हैं कि कार्य पूरा हो गया है। यह इंजीनियरिंग नहीं है। यह शेल एक्सेस (shell access) के साथ आँख मूँदकर भरोसा करने जैसा है। काम स्वयं इतना आसान हो जाता है कि उसे बनाना बहुत सरल लगने लगता है। कोई भी मॉडल सेकंडों में कोड, डॉक्यूमेंटेशन या आर्किटेक्चर प्लान तैयार कर सकता है। लेकिन सॉफ्टवेयर डेवलपमेंट में वास्तविक लागत कभी भी टाइपिंग की गति नहीं रही है। यह हमेशा सत्यापन (validation), समीक्षा (review), और यह सावधानीपूर्वक निर्णय लेने की प्रक्रिया रही है कि हाँ, यह सही है और शिप करने के लिए सुरक्षित है। जनरेट किया गया काम सस्ता है। अनुमोदन (Approval) महंगा है। जो कंपनियाँ यह समझ जाएँगी कि अनुमोदन को स्पष्ट और निरंतर तरीके से कैसे संभालना है, वे ही वास्तव में विश्वसनीय सिस्टम शिप कर पाएँगी।

सेल्फ-रिव्यू (Self-Review) क्यों विफल होता है

जोखिम अनुमानित पैटर्न में सामने आते हैं। एक मॉडल एक योजना का मसौदा तैयार करता है और फिर मूल्यांकन करता है कि क्या वह योजना अच्छी है। एक एजेंट आपके कोडबेस को एडिट करता है और आपको समझाता है कि उसके बदलाव सुरक्षित क्यों हैं। एक टूल एक कमांड निष्पादित करता है और अनुमति लेने के बजाय क्षमा माँगता है। इनमें से प्रत्येक एक ही मूल विफलता का प्रतिनिधित्व करता है। यदि कोई एजेंट एक स्पेसिफिकेशन तैयार करता है, तो उसके 'सत्य' बनने से पहले उस एजेंट के बाहर किसी चीज़ को उस पर हस्ताक्षर (sign off) करने चाहिए। यदि कोई एजेंट कोड को संशोधित करता है, तो एक अलग प्रक्रिया को 'डिफ़' (diff) का निरीक्षण करना चाहिए। जनरेटर को ही अपना वैलिडेटर बनने देना कोई शॉर्टकट नहीं है। यह सुविधा के रूप में सजाया गया एक संरचनात्मक बग (structural bug) है।

प्रॉम्प्ट्स (Prompts) अनुमति प्रणाली (Permission Systems) नहीं हैं

आप चतुर शब्दों के साथ किसी एजेंट को सुरक्षित नहीं कर सकते। किसी मॉडल को सावधान रहने या कुछ भी हटाने से पहले पूछने के लिए कहना कोई सीमा (boundary) नहीं बनाता है। प्रॉम्प्ट्स अनुमति प्रणालियाँ नहीं हैं। इससे पहले कि आप किसी एजेंट को प्रोडक्शन के करीब आने दें, आपको उसकी क्षमताओं की एक ईमानदार सूची की आवश्यकता है। क्या वह पूरी रिपॉजिटरी पढ़ सकता है? क्या वह शेल कमांड निष्पादित कर सकता है? क्या वह ब्राउज़र खोल सकता है? क्या वह कस्टमर डेटा को अपने कॉन्टेक्स्ट विंडो में खींच सकता है? अधिकांश टीमें पूर्ण उत्तर नहीं जानती हैं। वे मान लेते हैं कि टूल एक सैंडबॉक्स (sandbox) तक सीमित है, जबकि वास्तव में उसके पास क्रिटिकल पाथ्स तक राइट एक्सेस होता है। पहले सरफेस एरिया (surface area) को मैप करें। फिर दीवारें बनाएँ।

एक टियर-आधारित नियंत्रण प्रणाली (Tiered Control System) बनाएँ

एक बार जब आप समझ जाते हैं कि एजेंट क्या कर सकता है, तो एक ऐसी नियंत्रण प्रणाली डिज़ाइन करें जो जोखिम के अनुसार घर्षण (friction) को निर्धारित करे। कम जोखिम वाले कार्य, जैसे आंतरिक डॉक्यूमेंटेशन को अपडेट करना या सुसंगत कोड को फॉर्मेट करना, स्वचालित रूप से चल सकते हैं। मध्यम जोखिम वाले कार्य, जैसे किसी मॉड्यूल को रिफैक्टरिंग करना या एक नई डिपेंडेंसी जोड़ना, एक चेकपॉइंट पर रुकने चाहिए जहाँ एक इंसान या एक सत्यापित टेस्ट सूट उस बदलाव की पुष्टि करे। उच्च जोखिम वाले कार्य, जैसे प्रोडक्शन में डिप्लॉय करना, इंफ्रास्ट्रक्चर को संशोधित करना, या संवेदनशील डेटा तक पहुँचना, उन्हें एक अलग अप्रूवर की आवश्यकता होती है जो जनरेशन में शामिल नहीं था। प्रत्येक एकल कार्य का एक ऑडिट ट्रेल (audit trail) होना चाहिए। आप ठीक से रीप्ले करने में सक्षम होने चाहिए कि कौन सी फाइलें पढ़ी गईं, किन टूल्स का उपयोग किया गया, और क्या निर्णय लिए गए। एजेंटिक डेवलपमेंट समीक्षाओं को छोड़ने का लाइसेंस नहीं है। उबाऊ घर्षण (boring friction) वास्तव में एक फीचर है। एक उचित अप्रूवल गेट चीज़ें भटकने लगें तो सर्किट ब्रेकर की तरह काम करता है।

सीमा को जोखिम के अनुरूप रखें

अपनी सीमाओं को वास्तविक खतरे के अनुसार कैलिब्रेट करें। हर मार्कडाउन फॉर्मेटिंग बदलाव को अनुपालन समारोह (compliance ceremony) में बदलना आपकी टीम की गति को रोक देगा। लेकिन उच्च-दांव वाले कार्यों को हानिरहित मानना क्योंकि एजेंट आत्मविश्वासी लग रहा है, उतना ही मूर्खतापूर्ण है। लक्ष्य आनुपातिक नियंत्रण है, नाटकीय प्रतिबंध नहीं।

आर्टिफैक्ट्स (Artifacts) को छोटा और अवलोकन योग्य (Observable) रखें

The most useful agent systems do not try to wow you with massive autonomous runs. They produce small, reviewable artifacts. A tight plan. A focused diff. A readable log. Giant autonomous executions are nightmares to debug. When something breaks after a fifty-file agent session, you have to untangle intent, execution, and side effects all at once. Keep the blast radius small. Insist on knowing which files the agent read and which tools it called. Observable systems are maintainable systems. Black-box autonomy is just technical debt with better marketing.

Six Questions Before You Grant Access

Before you hand an agent any real responsibility, pressure-test your setup with six hard questions.

  • What capabilities does the system actually have?
  • Which actions are denied by default, blocked at the infrastructure level rather than discouraged by a polite sentence in the system prompt?
  • Which actions require explicit approval?
  • Which artifacts get frozen before the agent consumes them, so it cannot silently manipulate its own inputs?
  • Which validator, entirely separate from the generator, judges the final output?
  • Which log proves, without ambiguity, what actually happened?

This is basic engineering hygiene. Separate the generator from the validator. Keep human authority at the boundary.

The Real Test

There