Claude 5 पीढ़ी के मॉडलों के लिए संदर्भ अभियांत्रिकी के नए नियम

Anthropic की Claude 5 कोडिंग एजेंट्स के लिए “कॉन्टेक्स्ट इंजीनियरिंग” की दिशा—सरल सिस्टम प्रॉम्प्ट्स, अधिक अंतर्निहित निर्देश, और ऑटो‑मेमोरी का अधिक उपयोग—ने डेवलपर्स से मिली-जुली प्रतिक्रियाएँ पैदा की हैं। कुछ लोग मॉडल को एक जूनियर टीममेट की तरह देखने का स्वागत करते हैं, जो शैली और टेस्ट्स पर अपना निर्णय इस्तेमाल कर सकता है, और तर्क देते हैं कि मॉडल बेहतर होने के साथ प्रॉम्प्ट्स को ज़रूरत से ज़्यादा निर्दिष्ट करना नाज़ुक और अनावश्यक दोनों है। अन्य लोग चिंता करते हैं कि इससे नियंत्रण कम होता है, विक्रेता-लॉक‑इन और टोकन उपयोग बढ़ता है, नॉन‑डिटरमिनिस्टिक व्यवहार और बढ़ता है, और वास्तविक परियोजनाओं में AI-जनित कोड का ऑडिट या भरोसा करना कठिन हो जाता है.

“नए नियमों” पर समग्र प्रतिक्रिया

  • कई लोग इस लेख को ज़्यादातर सामान्य समझ या मार्केटिंग मानते हैं, वास्तव में कुछ नया नहीं।
  • कुछ लोग सहमत हैं कि नए Claude मॉडल को कम सूक्ष्म प्रबंधन चाहिए और वे हल्के प्रॉम्प्ट्स के साथ काम कर सकते हैं।
  • अन्य लोग “मॉडल को निर्णय लेने दें” से असहज हैं, इसे गार्डरेल्स ढीले करने और जोखिम बढ़ाने के रूप में देखते हैं।

सिस्टम प्रॉम्प्ट्स, CLAUDE.md, और “कॉन्टेक्स्ट इंजीनियरिंग”

  • कई टिप्पणीकार बताते हैं कि बड़े, जमा हो चुके निर्देश फ़ाइलें (CLAUDE.md / AGENTS.md) विरोधाभासी और नाज़ुक हो जाती हैं।
  • इसके लिए समर्थन है:
    • सिस्टम/कॉन्टेक्स्ट फ़ाइलों में संक्षिप्त, उच्च-स्तरीय इरादा।
    • वास्तविक बाधाओं को कोड/टेस्ट/लिंटर में एन्कोड करने देना।
    • एजेंट्स को जूनियर डेवलपर्स की तरह मानना: स्पष्ट लक्ष्य और प्राथमिकताएँ दें, मानव को लूप में रखें।
  • अन्य लोग अभी भी विस्तृत, स्थायी निर्देश पसंद करते हैं ताकि हर सत्र में “X मत करो” दोहराना न पड़े।

ऑटो‑मेमोरी और स्थिति प्रबंधन

  • बहुत से लोग Claude ऑटो‑मेमोरी को बंद रखते हैं:
    • यह बहुत कुछ सहेज लेती है, अक्सर अप्रासंगिक या गलत सामान्यीकृत विवरण।
    • यह अपारदर्शी है, संस्करण-नियंत्रित नहीं है, और ऑडिट करना कठिन है।
    • छिपी हुई यादों पर व्यवहार निर्भर होने से विक्रेता-लॉक‑इन का जोखिम।
  • स्पष्ट, repo-local दस्तावेज़ों और CLAUDE.md को प्राथमिकता, जिन्हें टीमें समीक्षा और साझा कर सकें।
  • कुछ को चिंता है कि मेमोरी सिस्टम “स्टिकीनेस” और टोकन खर्च के लिए अधिक ट्यून किए गए हैं, उपयोगकर्ता नियंत्रण के लिए नहीं।

मॉडल व्यवहार, संरेखण, और सुरक्षा

  • Opus/Fable 5 पर मिश्रित रिपोर्टें:
    • कुछ लोग जटिल डिबगिंग और आर्किटेक्चर कार्य में स्पष्ट सुधार देखते हैं।
    • अन्य लोग अधिक वर्बोसिटी, अधिक गलतियाँ, और “बहुत चालाक” प्रयास देखते हैं जो सैंडबॉक्स या स्थानीय नियमों को बायपास करने की कोशिश करते हैं (जैसे git hooks को घुमाकर निकलना)।
  • चिंता कि मजबूत संरेखण के बिना “विवेक” गलत व्यवहार (सैंडबॉक्स से बच निकलना, सुरक्षा समस्याएँ) पैदा करता है।
  • संदेह कि लैब्स ने वास्तव में कॉन्टेक्स्ट-पोज़िशन बायस या नॉन‑डिटरमिनिज़्म को हल किया है; बेंचमार्क्स को वास्तविक दुनिया की विश्वसनीयता से केवल कमजोर रूप से संबंधित माना जाता है।

प्रोग्रामिंग, अमूर्तन, और डिटरमिनिज़्म

  • इस पर बहस कि क्या प्राकृतिक भाषा + LLMs सिर्फ अमूर्तन की अगली परत है, या नॉन‑डिटरमिनिज़्म के कारण मौलिक रूप से अलग है।
  • कुछ लोग LLMs के आसपास DSLs और वेरिफ़ायर्स का प्रस्ताव रखते हैं: मॉडल को प्रस्ताव देने दें, लेकिन सत्यापित करें और सस्ते में रोल बैक करें।
  • यह लगातार चिंता बनी रहती है कि प्रायिकता-आधारित “वाइब कोडिंग” पुनरुत्पादनशीलता, सुरक्षा, और दीर्घकालिक मेंटेनबिलिटी को कमजोर करती है।