अपने AI एजेंट्स को माइक्रोमैनेज करना असल में उन्हें बेवकूफ क्यों बनाता है

आज किसी भी मॉडर्न GitHub repo से कोई रैंडम system_prompt.txt खोलकर देखिए, आपको क्या मिलेगा? आमतौर पर, यह घबराहट में लिखा गया एक लंबा-चौड़ा टेक्स्ट होता है। "X बिल्कुल मत करना। तुम्हें सिर्फ तीन बुलेट पॉइंट्स ही आउटपुट देने हैं। इस लाइब्रेरी का इस्तेमाल तो कभी मत करना।"

डेवलपर्स मानव इतिहास के सबसे एडवांस्ड reasoning engines के साथ ऐसा बर्ताव कर रहे हैं जैसे वे कोई नाज़ुक regex स्क्रिप्ट्स हों।

अगर हम पीछे मुड़कर देखें तो यह पैरानोइया (डर) समझ में आता है। बस एक या दो साल पहले, शुरुआती LLMs को टॉपिक पर बनाए रखने के लिए बहुत ज्यादा उंगली पकड़कर चलाने (hand-holding) की जरूरत होती थी। लेकिन अब वक्त बदल चुका है। मॉडर्न मॉडल्स अविश्वसनीय रूप से स्मार्ट हैं, फिर भी हम प्रॉम्प्ट्स ऐसे लिख रहे हैं जैसे हम 1980 के दशक के किसी माइक्रोवेव को प्रोग्राम कर रहे हों। हम इंटेलिजेंस को हार्डकोड करने की कोशिश कर रहे हैं।

हाल ही में Vercel में कुछ बहुत ही दिलचस्प हुआ जो इस बात को साबित करता है। उनकी इंजीनियरिंग टीम ने एक ब्रेकडाउन पब्लिश किया कि कैसे उन्होंने अपने v0 प्रोडक्ट को बेहतर बनाया, जिसमें उन्होंने एक ऐसा कदम उठाया जो पहली नज़र में बिल्कुल उल्टा लगता है (counterintuitive): उन्होंने अपने एजेंट के 80% टूल्स हटा दिए।

नतीजा? सिस्टम टूटा नहीं। बल्कि यह और भी बेहतर हो गया। जरूरत से ज्यादा तय किए गए टूल्स और सख्त नियमों (rigid rails) को हटाकर, उन्होंने कंफ्यूजन को कम किया और मॉडल को वो करने दिया जिसमें वो सबसे अच्छा है—प्रॉब्लम को समझकर सॉल्व करना (reasoning)। कम फ्रिक्शन का मतलब था बेहतर कोड।

जो भी इस वक्त AI के साथ कुछ बिल्ड कर रहा है, उसके लिए यहाँ एक बहुत बड़ी सीख है: सिद्धांत (Principles) दें, सख्त नियम (rigid rules) नहीं।

जब आप किसी LLM को स्टेप-बाय-स्टेप बताते हैं कि उसे क्या करना है, तो आप उसे अपना लिमिटेड अटेंशन (कंप्यूट) क्वालिटी के बजाय नियमों के पालन (compliance) पर खर्च करने के लिए मजबूर करते हैं। आप उसकी उस क्षमता को छीन लेते हैं जिससे वह अपने विशाल ट्रेनिंग डेटा का इस्तेमाल करके आपके हार्डकोड किए गए तरीके से कहीं बेहतर और एलिगेंट सॉल्यूशन ढूंढ सकता था।

इस फर्क को समझने के लिए, देखिए कि ज्यादातर डेवलपर्स एजेंट प्रॉम्प्ट्स कैसे लिखते हैं और उन्हें ये कैसे लिखने चाहिए।

गलत तरीका (सख्त नियम):

"यूजर डेटा फेच करने के लिए एक Python फंक्शन लिखो। तुम्हें requests लाइब्रेरी का ही इस्तेमाल करना है। तुम्हें try/except ब्लॉक से एरर्स हैंडल करने हैं। तुम्हें एक डिक्शनरी रिटर्न करनी है जिसमें सिर्फ 'name', 'email', और 'status' कीज़ (keys) हों। async का इस्तेमाल मत करना। हर लाइन में कमेंट्स ऐड करो।"

सही तरीका (सिद्धांत और लक्ष्य):

"यूजर डेटा फेच करने के लिए एक रोबस्ट Python फंक्शन लिखो। मॉडर्न और स्टैंडर्ड लाइब्रेरीज को प्राथमिकता दो। कोड प्रोडक्शन-रेडी होना चाहिए, जिसका मतलब है कि यह नेटवर्क फेलियर और एज केसेस (edge cases) को अच्छे से हैंडल करे। चालाकी (cleverness) से ज्यादा रीडेबिलिटी और क्लीन आर्किटेक्चर पर फोकस करो। डाउनस्ट्रीम सिस्टम स्टैंडर्ड यूजर प्रोफाइल्स (name, email, status) की उम्मीद करता है।"

क्या आपने बदलाव नोटिस किया? पहला उदाहरण AI के साथ ऐसे बर्ताव करता है जैसे वह कोई जूनियर डेवलपर हो जिस पर भरोसा नहीं किया जा सकता। दूसरा उदाहरण उसके साथ एक सीनियर इंजीनियर की तरह पेश आता है जो लक्ष्य और कॉन्टेक्स्ट को समझता है। आप उसे बताते हैं कि एक अच्छा आउटपुट कैसा दिखता है और क्यों, फिर आप पीछे हट जाते हैं और उसे खुद यह तय करने देते हैं कि यह कैसे करना है।

बेशक, इस नियम का एक बहुत बड़ा अपवाद (exception) भी है।

जब एजेंट्स दूसरे एजेंट्स से बात कर रहे हों—या जब कोई अपस्ट्रीम एजेंट किसी सख्त डाउनस्ट्रीम डेटाबेस पार्सर को डेटा पास कर रहा हो—तो आपको पूरी सख्ती की जरूरत होती है। मशीन-टू-मशीन हैंडऑफ्स के लिए सटीक और सख्त JSON स्कीमा की जरूरत होती है। लेकिन रीजनिंग, जनरेशन और प्रॉब्लम-सॉल्विंग के लिए? अपनी पकड़ थोड़ी ढीली छोड़ दें।

अगर आप आज ही अपने कोडिंग असिस्टेंट्स को तुरंत अपग्रेड करना चाहते हैं, तो इस ब्लॉक को कॉपी करें और अपने claude.md, memory.md, या अपने एजेंट के कोर सिस्टम प्रॉम्प्ट में पेस्ट कर दें:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

मशीन को माइक्रोमैनेज करना बंद करें। मॉडर्न LLM पर भरोसा रखें। जब हम उनके साथ छोटे बच्चों (toddlers) जैसा बर्ताव करना बंद कर देते हैं, तो वे कहीं ज्यादा तेज, स्मार्ट और असीमित रूप से अधिक सक्षम साबित होते हैं।