Vibe कोडिंग हाईप नीचे खत्म हो रहा है, क्योंकि बड़े भाषा मॉडल क्या कर सकते हैं के लिए बहुत सीमित हैं. इस कोडिंग एजेंट के बावजूद काफी अच्छा हो रहा है. वे नए फ्रंटएंड पेजों को स्पिन कर सकते हैं, एपीआई को तार कर सकते हैं, और यहां तक कि सीआई / सीडी कॉन्फ़िगर बना सकते हैं. लेकिन कोई भी जानता है कि वे कितने असंगत हैं. एक ही प्रिंट एक बार काम कर सकता है और अगले को तोड़ सकता है. वे अपने कोडबेस के हिस्सों को भूल जाते हैं, खराब एसडीके को मिक्स करते हैं, या बस चीजें बनाते हैं. समस्या यह नहीं है कि मॉडल बुरा है - यह है कि यह नहीं है यहाँ सबूत है - किसी ने केवल कोडिंग एजेंट का उपयोग करके एक प्रोग्रामिंग भाषा लिखी थी. यदि यह संभव था, तो कुछ भी है. अपने संदर्भ को जानें https://cursed-lang.org/ एक विश्वसनीय आउटपुट प्राप्त करने के लिए, आप केवल बेहतर प्रोत्साहित नहीं कर सकते हैं। एजेंट काम करता है - इसके इनपुट को आकार दें, इसे संरचना दें, और सही सीमाएं निर्धारित करें। . engineer the environment context engineering 1. एलएलएम इंजीनियरों की तरह नहीं सोचते एलएलएम कोड को "हम कैसे समझते हैं" नहीं करते हैं. वे पिछले इनपुट में पैटर्न के आधार पर टोकन का पूर्वानुमान करते हैं, ऐप बिल्डिंग या संरचना पर नहीं। संरचना के बिना, वे इंटर्नशिप के रूप में हैं जो स्मृति से आपके स्टैक का अनुमान लगाते हैं। आप इसे मॉडल पर चिल्लाकर ठीक नहीं कर सकते हैं. (मैं बता सकता हूं, मैंने कोशिश की) आप इसे सही तरीके से ठीक करते हैं - प्रतिबंधों और वातावरण जो इसे हर बार वैध कोड की ओर मार्गदर्शन करते हैं। scaffolding 2. सीमाएं कोड को पूर्वानुमान बनाती हैं यदि आप चाहते हैं कि एजेंट लगातार व्यवहार करे, वे संभावित आउटपुट के स्थान को संकीर्ण करते हैं, और मॉडल को आपके सेटिंग के साथ समायोजित रहने के लिए मजबूर करते हैं। constraints are your friend कुछ उपयोगी प्रतिबंध: टाइप - यदि आप टाइपस्क्रिप्ट या जेएसओएन योजनाओं का उपयोग कर रहे हैं, तो एजेंट को सटीक रूप से देख सकता है कि उसे किस आकार का पालन करना चाहिए। Lint + प्रारूप नियम - Prettier, ESLint, या codegen नियम अतिरिक्त प्रोत्साहन के बिना आउटपुट को स्थिर बनाते हैं। छोटे कार्य — "मुझे एक बैकेंड बनाने के बजाय," पूछें "इस मार्ग को src/api/user.ts में जोड़ें। कॉन्फ़िगर और टेम्पलेट्स – Typeconf और Varlock जैसे उपकरण पर्यावरण परिवर्तकों, एसडीके, या एजेंट द्वारा पालन किए जाने वाले किसी भी कॉन्फ़िगरेशन पैटर्न को पूर्व परिभाषित कर सकते हैं। चाल यह सुनिश्चित करना है कि आप हमेशा मजबूत प्रकारों के साथ कोड लिख रहे हैं. आप लचीलापन नहीं खोते हैं - आप बस गलतियों को पहले पकड़ते हैं और व्यवहार को दोहराया जा सकता है। 3. सच्चाई के रूप में सिस्टम का निर्माण करें यहां तक कि जब कोड अच्छी तरह से दिखता है, तो यह अक्सर बिल्डिंग समय पर टूट जाता है क्योंकि एजेंट ने गलती से अनुमान लगाया कि चीजें कैसे तारित हैं. लेकिन अक्सर एजेंट भी नहीं समझता है कि आपके कोड को सही तरीके से कैसे बनाया जाए. जैसे : आप इसे परीक्षण चलाने के लिए कहते हैं, यह एनपीएम परीक्षण लिखता है - लेकिन आपका रीपो पीएनपीएम या एनएच का उपयोग करता है। यह एक Dockerfile का निर्माण करने की कोशिश करता है जो आपके वास्तविक वातावरण में भी मौजूद नहीं है। यह एक पैकेज आयात करता है जो यहां तक कि स्थापित नहीं है। फिक्स करने के लिए है - एजेंट को एक स्पष्ट छवि दें कि कोड कैसे बनाया जाता है, परीक्षण किया जाता है और तैनात किया जाता है. इसे अपने परियोजना के वातावरण के लिए एक अतिरिक्त एजेंट उपकरण के रूप में सोचें. abstract the build system एक बार जब एजेंट जानता है कि आपके दुनिया में "निर्माण" का क्या मतलब है, तो वह अनुमान लगाने के बजाय उस ज्ञान का उपयोग कर सकता है। Bazel, Buck, Nx, या यहां तक कि एक अच्छी तरह से संरचित package.json पहले से ही अच्छे नींव हैं. जितना अधिक आप इस जानकारी को सतह पर उतरते हैं, उतना ही कम हल्काइयां आप संभालेंगे. यदि आप आगे जाना चाहते हैं तो आप अपने स्वयं के टूल होक्स लिख सकते हैं ताकि एजेंट को गलत बिल्डिंग सिस्टम को कॉल करने से रोकें, क्लाउड कोड गाइड देखें: . https://docs.claude.com/en/docs/claude-code/hooks-guide 4. पुराने प्रशिक्षण की समस्या अधिकांश कोडिंग एजेंट डेटा पर प्रशिक्षित होते हैं जो एक या दो साल पुराने हैं. वे खुशी से एपीआई का उपयोग करेंगे जो अब मौजूद नहीं हैं, या कोड पैटर्न जिन्हें हर कोई सदियों पहले छोड़ चुका है। आपने शायद ऐसी चीजें देखी हैं जैसे: पुराने जीवन चक्र के तरीके मौजूदा पुस्तकालय सुविधाएं Next.js APIs के बारे में जानें नई संस्करणों में स्थानांतरित किए गए पुस्तकालयों के लिए एनपीएम कमांड आप केवल प्रशिक्षण पर भरोसा नहीं कर सकते. आपको अपने स्वयं के संदर्भ लाने की आवश्यकता है - वास्तविक दस्तावेज़, वास्तविक कोड, वास्तविक कॉन्फ़िगर। अंतर को खत्म करने के कुछ तरीके: पुस्तकालय डॉक में फ़ीड, उदाहरण के लिए, Context7 जैसे एमसीपी के माध्यम से। एजेंट को वास्तविक कोड फ़ाइलों और निर्भरताओं को पढ़ने दें - इसे node_modules को पढ़ने के लिए इंगित करें, आप आश्चर्यचकित होंगे कि यह एपीआई को ठीक करने में कितनी बार मदद करेगा। AGENTS.md में अनुकूलित निर्देश जोड़ें जो मॉडल को बताते हैं कि वह दोहराने की कोशिश कर रहा है कि समस्याग्रस्त पैटर्न से बचें। जब मॉडल जानता है कि वास्तव में वहां क्या है, तो यह भूख लगाना बंद कर देता है। 5. संदर्भ के प्रकार एक अच्छा कोडिंग एजेंट न केवल आपकी परामर्श पढ़ता है - यह पूरी स्थिति पढ़ता है। आप संदर्भ को तीन परतों में सोच सकते हैं: Static context परियोजना संरचना, फ़ाइल लेआउट, प्रकार, configs, build commands, dependencies। Dynamic context वर्तमान कार्य, खुले फ़ाइल, त्रुटि संदेश, परीक्षण परिणाम, संचालित समय लॉग। External context दस्तावेज़, एसडीके संदर्भ, बदलाव लॉग, या वेब से स्नैप्स जब आवश्यक हो। सभी तीनों को जोड़ें, और एजेंट किसी ऐसे व्यक्ति की तरह कार्य करना शुरू कर देगा जो वास्तव में आपके कोडबेस पर शामिल है - स्मृति से अनुमान लगाने वाले एक यादृच्छिक फ्रीलांसर नहीं। 6. वास्तविक दुनिया से उदाहरण जब मैंने वर्कओएस AuthKit एकीकरण को स्वचालित करना शुरू किया, तो यहां मॉडल द्वारा मेरे लिए उत्पन्न किए गए मुद्दों की एक अपर्याप्त सूची है: शुरुआत के लिए, उपयोग करने के लिए अपर्याप्त withAuth और getUser एपीआई; मिश्रित फ्रंट एंड और बैक एंड तर्क; (जैसे सर्वर-साइड घटकों पर useState का उपयोग करना) गलत पर्यावरणीय परिवर्तनीय पैदा हुए; गलत पैकेज स्थापित किया है; यह कहना स्वाभाविक है कि मॉडल ने सभी पैकेज प्रबंधकों, कभी-कभी एनपीएम, कभी-कभी पीएनपीएम, जो भी एक समय में मॉडल के लिए सबसे दिलचस्प था, के माध्यम से भी छू लिया। प्रतिबंधों को जोड़ने के बाद, सीधे निर्दिष्ट किया कि एजेंट को क्या उपयोग करना चाहिए, नवीनतम एपीआई के साथ प्रदान किया गया, मॉडल ने एकीकरण कोड उत्पन्न करना शुरू कर दिया . consistently अंतर मॉडल में नहीं है - यह क्या देखता है। 7. संदर्भ नया इंटरफ़ेस है अधिकांश लोग अभी भी चैटबॉट्स की तरह कोडिंग एजेंटों के बारे में सोचते हैं: एक सुझाव दें, एक जवाब प्राप्त करें. लेकिन वास्तविक इंजीनियरिंग काम के लिए, सुझाव केवल एक टुकड़ा है. वास्तविक जादू संदर्भ में होता है - एजेंट द्वारा एक्सेस किए जाने वाले फ़ाइलों, प्रकारों, कमांडों और प्रतिक्रिया चक्र। भविष्य में, हम केवल कोडिंग एजेंटों के साथ "बात" नहीं करेंगे - हम उन्हें हमारे बिल्डिंग सिस्टम में तार करेंगे. वे हमारे repos को समझेंगे, हमारे उपकरणों को जानेंगे, और स्टैक के हर अन्य हिस्से के समान नियमों का पालन करेंगे. निष्कर्ष कोडिंग एजेंट असफल नहीं हैं क्योंकि वे मूर्ख हैं, बल्कि क्योंकि वे अंधा काम कर रहे हैं। यदि आप चाहते हैं कि वे विश्वसनीय टीम के साथी बनें, तो उन्हें संरचना दें: सीमाएं जो निर्धारित करती हैं कि उन्हें कैसे कोड करना चाहिए; अवलोकन बनाएं जो दिखाते हैं कि आपका परियोजना वास्तव में कैसे चलती है; अद्यतन संदर्भ ताकि वे पुराने पैटर्न का उपयोग करना बंद कर दें; संदर्भ जितना बेहतर है, कोड बेहतर है। आप सिर्फ अपने रेपो में एक नए इंजीनियर को फेंकते नहीं हैं और कहते हैं "यह पता लगाएं।
