संपादकीय टिप्पणी: जनवरी 2026 में, एंड्रेज कारपथी द्वारा क्लॉड के कोडिंग पर टिप्पणी से एक ऐसा फ़ाइल उभरा जो दिखने में छोटी लगती है, लेकिन AI प्रोग्रामिंग वर्कफ़्लो में अत्यंत महत्वपूर्ण है: CLAUDE.md। फॉरेस्ट चांग ने बाद में इन समस्याओं को 4 व्यवहार नियमों में संकलित किया, जिनका उद्देश्य क्लॉड के कोडिंग के दौरान सामान्य त्रुटियों—चुपचाप अनुमान, अतिरिक्त इंजीनियरिंग, असंबंधित कोड को नुकसान पहुंचाना, और सफलता के स्पष्ट मानदंडों की कमी—को सीमित करना है।

लेकिन कुछ महीनों बाद, Claude Code के उपयोग के मामले केवल "मॉडल को कोड का एक अंश लिखने के लिए बुलाना" तक सीमित नहीं रह गए हैं। बहु-चरण Agent, hook श्रृंखला ट्रिगर, स्किल लोडिंग और बहु-कोड रिपॉजिटरी सहयोग सामान्य हो जाने के साथ, नए विफलता पैटर्न भी उभरने लगे हैं: मॉडल लंबे कार्यों में नियंत्रण खो देता है, परीक्षण सफल होते हैं लेकिन वास्तविक तर्क की पुष्टि नहीं होती, स्थानांतरण पूरा हो जाता है लेकिन त्रुटियाँ चुपचाप छूट जाती हैं, और विभिन्न कोड स्टाइल्स गलती से मिला दिए जाते हैं।

लेखक ने 6 सप्ताह में 30 कोड रिपॉजिटरी का परीक्षण किया और कारपाथी के मूल 4 नियमों के आधार पर 8 नए नियम जोड़े, ताकि AI प्रोग्रामिंग के एकल पूर्ति से एजेंट-आधारित सहयोग की ओर जाने के बाद उत्पन्न नए समस्याओं को कवर किया जा सके।

नीचे मूल पाठ है:

2026 के जनवरी के अंत में, एंड्रेज कारपथी ने एक ट्वीट श्रृंखला पोस्ट की, जिसमें क्लॉड के कोड लिखने के तरीके की आलोचना की। उन्होंने तीन प्रकार की आम समस्याओं को उजागर किया: बिना स्पष्टीकरण के गलत धारणाएँ बनाना, अत्यधिक जटिलता लाना, और मूल रूप से बदलने की आवश्यकता न होने वाले कोड में असंबंधित क्षति पहुँचाना।

फॉरेस्ट चांग ने इस ट्वीट श्रृंखला को देखा, और उसमें व्यक्त किए गए शिकायतों को 4 व्यवहार नियमों में संगठित करके एक अलग CLAUDE.md फ़ाइल में लिखा और इसे GitHub पर प्रकाशित कर दिया। इस प्रोजेक्ट के लॉन्च के पहले दिन ही 5,828 स्टार मिले, दो हफ्तों में 60,000 बार सेव किया गया, और अब इसके 120,000 स्टार हैं, जिससे यह 2026 का सबसे तेजी से बढ़ता एकल-फ़ाइल कोड रिपॉजिटरी बन गया।

फिर, मैंने इसे 6 सप्ताह के भीतर 30 कोड रिपॉजिटरी के साथ टेस्ट किया।

ये चार नियम वास्तव में कारगर हैं। पिछले लगभग 40% संभावना से होने वाली त्रुटियाँ, जब इन नियमों का उपयोग किया जाता है, तो 3% से कम हो गईं। लेकिन समस्या यह है कि यह टेम्पलेट मूल रूप से जनवरी में क्लॉड द्वारा कोड लिखते समय होने वाली त्रुटियों को हल करने के लिए बनाया गया था।

2026 मई तक, Claude Code इकोसिस्टम के सामने अलग समस्याएँ आ चुकी थीं: एजेंट्स के बीच टकराव, हुक श्रृंखला ट्रिगरिंग, स्किल लोडिंग टकराव, और सत्रों के बीच मल्टी-स्टेप वर्कफ्लो का ब्रेक होना।

तो, मैंने आठ और नियम जोड़ दिए हैं। यहाँ पूर्ण 12 नियमों वाला CLAUDE.md है: प्रत्येक क्यों जोड़ा गया, और मूल कारपथी टेम्पलेट कहाँ चुपचाप असफल होगा।

अगर आप व्याख्या को छोड़कर सीधे कॉपी करके उपयोग करना चाहते हैं, तो पूर्ण फ़ाइल अंत में दी गई है।

यह क्यों महत्वपूर्ण है

क्लॉड कोड का CLAUDE.md, पूरे AI प्रोग्रामिंग टेक स्टैक में सबसे कम मूल्यांकित फ़ाइल है। अधिकांश डेवलपर्स आमतौर पर तीन प्रकार की गलतियाँ करते हैं:

पहले, इसे एक पसंद का कचरा डिब्बा मान लें और अपनी सभी आदतों को इसमें भर दें, जिससे अंततः यह 4000 से अधिक टोकन तक फैल जाए और नियम पालन की दर 30% तक गिर जाए।

दूसरा, इसे पूरी तरह से न उपयोग करें और हर बार नया प्रॉम्प्ट दें। इससे 5 गुना टोकन बर्बाद होगा और सत्रों के बीच असंगति होगी।

तीसरा, एक टेम्पलेट कॉपी करने के बाद आप उसे कभी नहीं छूते। यह दो हफ्ते तक काम कर सकता है, लेकिन कोडबेस में परिवर्तन के साथ, आपको अनजाने में यह अक्षम हो जाएगा।

Anthropic की आधिकारिक दस्तावेज़ में स्पष्ट रूप से कहा गया है: CLAUDE.md वास्तव में केवल सुझावात्मक है। Claude लगभग 80% समय इसका पालन करेगा। 200 पंक्तियों के बाद, अनुपालन दर स्पष्ट रूप से घट जाती है, क्योंकि महत्वपूर्ण नियम शोर में खो जाते हैं।

करपाथी का टेम्पलेट इस समस्या को हल करता है: एक फ़ाइल, 65 पंक्तियाँ, 4 नियम। यह न्यूनतम आधार है।

लेकिन सीमा अधिक ऊँची हो सकती है। नीचे दी गई 8 नियमों को जोड़ने के बाद, यह केवल करपाथी द्वारा जनवरी 2026 में उठाए गए कोड लेखन के मुद्दों को ही नहीं, बल्कि मई 2026 में उभरे एजेंट ऑर्केस्ट्रेशन के मुद्दों को भी कवर करता है—जो मूल टेम्पलेट बनाए जाने के समय अभी तक अस्तित्व में नहीं थे।

मूल चार नियम

अगर आपने अभी तक फॉरेस्ट चांग के रिपॉजिटरी को नहीं देखा है, तो पहले इस बेसिक वर्जन को देखें:

नियम 1: कोडिंग से पहले सोचें।

अनुमानों पर चुपचाप काम न करें। अपने अनुमानों को स्पष्ट करें, विकल्पों को उजागर करें। अनुमान लगाने से पहले प्रश्न पूछें। जब अधिक सरल समाधान उपलब्ध हो, तो सक्रिय रूप से विरोध प्रकट करें।

नियम 2: सरलता को प्राथमिकता दें।
जितनी कम संख्या में कोड के साथ समस्या का समाधान हो सके, उतना ही उपयोग करें। कल्पना के अनुसार फ़ंक्शन न जोड़ें। एक बार के कोड के लिए अमूर्त स्तर न बनाएं। यदि एक अनुभवी इंजीनियर इसे अत्यधिक जटिल मानेगा, तो इसे सरल बनाएं।

नियम 3: सर्जिकल संशोधन।
केवल आवश्यक भागों को ही बदलें। पास के कोड, टिप्पणियों या फॉर्मेट को स्वयं 'सुधार' न करें। जो कुछ खराब नहीं है, उसे फिर से न बनाएं। मौजूदा शैली के साथ संगत रहें।

नियम 4: लक्ष्य-केंद्रित रूप से कार्य करें।
सफलता के मानदंडों को परिभाषित करें, फिर पुनरावृत्ति करें जब तक सत्यापन पूरा न हो जाए। Claude को प्रत्येक चरण में क्या करना है यह न बताएं, बल्कि उसे बताएं कि सफल परिणाम कैसा होना चाहिए, और उसे स्वयं पुनरावृत्ति करने दें।

ये चार नियम मैंने अनुपस्थिति में क्लॉड कोड सत्र में देखे गए लगभग 40% विफलता पैटर्न को हल करने में सक्षम हैं। शेष लगभग 60% समस्याएँ नीचे दिए गए खाली स्थानों में छिपी हुई हैं।

मैंने 8 नियम जोड़े हैं, और क्यों

प्रत्येक नियम एक वास्तविक क्षण से आया है: करपाथी के मूल 4 नियम पर्याप्त नहीं रहे। नीचे मैं पहले उस स्थिति को समझाऊंगा, फिर संबंधित नियम दूंगा।

करपाथी के नियम इस बात को कवर नहीं करते। इसलिए मॉडल ने निर्धारणात्मक कोड द्वारा संभाले जाने वाले मुद्दों को निर्णय लेना शुरू कर दिया: एक API कॉल को फिर से प्रयास करना है या नहीं, एक संदेश को कैसे रूट करना है, और कब उपचार को अपग्रेड करना है। परिणामस्वरूप, हर सप्ताह का निर्णय अलग-अलग होता है। आपको एक अस्थिर if-else मिलता है, जिसकी कीमत 0.003 डॉलर प्रति token है।

उस क्षण पर, एक कोड था जो Claude को इस बात का निर्णय करने के लिए कॉल करता था कि क्या 503 की स्थिति में पुनः प्रयास करना चाहिए। यह शुरू में अच्छी तरह काम कर रहा था और दो हफ्ते तक स्थिर रहा, लेकिन बाद में अचानक अस्थिर हो गया क्योंकि मॉडल ने अब अनुरोध शरीर को भी निर्णय के संदर्भ के रूप में शामिल करना शुरू कर दिया। पुनः प्रयास रणनीति यादृच्छिक हो गई क्योंकि प्रॉम्प्ट स्वयं यादृच्छिक था।

बिना बजट सीमा के CLAUDE.md एक खाली चेक के बराबर है। प्रत्येक चक्र अनियंत्रित हो सकता है और 50,000 टोकन के संदर्भ का बहाव बन सकता है। मॉडल खुद रुकता नहीं है।

उस क्षण पर, एक डीबग सत्र 90 मिनट तक चला। मॉडल लगातार एक ही 8KB की त्रुटि संदेश पर दोहराव कर रहा था और धीरे-धीरे यह भूल गया कि उसने पहले कौन से ठीक करने के तरीके आजमाए थे। अंत में, यह 40 संदेशों के पहले मैंने जिन्हें खारिज कर दिया था, उन्हीं समाधानों को फिर से प्रस्तावित करने लगा। यदि token बजट होता, तो यह प्रक्रिया 12 मिनट में ही बंद हो जानी चाहिए थी।

जब कोडबेस के दो हिस्से एक दूसरे के विरोधी होते हैं, तो क्लॉड दोनों को संतुष्ट करने की कोशिश करता है और परिणामस्वरूप असंगठित कोड लिखता है।

उस क्षण ऐसा था कि एक कोड रिपॉजिटरी में दो तरह के त्रुटि प्रबंधन पैटर्न मौजूद थे: एक था async/await के साथ स्पष्ट try/catch, और दूसरा था ग्लोबल एरर बाउंड्री। क्लॉड द्वारा लिखा गया नया कोड दोनों का उपयोग करता था। परिणामस्वरूप, त्रुटि प्रबंधन दो बार किया गया। मुझे 30 मिनट लगे कि समझने के लिए कि त्रुटियाँ क्यों दो बार निगल ली गईं।

करपाथी का "सर्जिकल मॉडिफिकेशन" Claude को अनुच्छेद कोड को नहीं बदलने के लिए कहता है। लेकिन यह Claude को यह नहीं बताता कि पहले अनुच्छेद कोड को समझें। इस बात के बिना, Claude 30 पंक्तियों दूर के मौजूदा कोड के साथ टकराता हुआ नया कोड लिख देता है।

उस क्षण पर, क्लॉड ने एक पहले से मौजूद फ़ंक्शन के बगल में एक ऐसा ही फ़ंक्शन जोड़ दिया, क्योंकि उसने मूल फ़ंक्शन को पहले नहीं पढ़ा था। दोनों फ़ंक्शन एक ही काम करते हैं। लेकिन import क्रम के कारण, नया फ़ंक्शन पुराने फ़ंक्शन को ओवरराइट कर दिया, जबकि पुराना फ़ंक्शन 6 महीने से वास्तविक एकमात्र मानक के रूप में माना जा रहा था।

करपाथी का "लक्ष्य-आधारित निष्पादन" यह सुझाव देता है कि परीक्षण सफलता का मापदंड हो सकते हैं। लेकिन व्यावहारिक रूप से, क्लॉड "परीक्षण सफल" को एकमात्र लक्ष्य मान लेता है, और ऐसा कोड लिखता है जो सतही परीक्षणों को पार कर जाता है, लेकिन अन्य चीजों को नुकसान पहुंचाता है।

उस क्षण पर, क्लॉड ने एक प्रमाणीकरण फ़ंक्शन के लिए 12 टेस्ट लिखे, जो सभी पास हो गए। लेकिन प्रोडक्शन में प्रमाणीकरण लॉजिक खराब थी। वे टेस्ट केवल यह सत्यापित कर रहे थे कि फ़ंक्शन "कुछ वापस कर रहा है", न कि यह कि वह सही चीज़ वापस कर रहा है। फ़ंक्शन टेस्ट पास हो रहा था क्योंकि यह एक कंस्टेंट वापस कर रहा था।

करपाथी के टेम्पलेट में डिफ़ॉल्ट इंटरैक्शन एकल-बार का होता है। लेकिन वास्तविक Claude Code कार्य अक्सर बहु-चरणीय होते हैं: 20 फ़ाइलों में रीफैक्टरिंग, एक सत्र में फ़ंक्शन बनाना, और कई कमिट्स के दौरान डीबग करना। बिना चेकपॉइंट के, एक गलत कदम से पिछली सभी प्रगति खो सकती है।

उस क्षण पर, एक 6-चरण रीकंस्ट्रक्शन टास्क चौथे चरण में फंस गया। जब मैंने इसे देखा, तो Claude ने गलती की स्थिति पर आधारित चरण 5 और 6 पूरा कर लिए थे। इसे तोड़कर ठीक करने में लगा समय, पूरी टास्क को फिर से करने से अधिक था। अगर चेकपॉइंट होते, तो चौथे चरण में ही समस्या पहचानी जा सकती थी।

एक पहले से विकसित मॉडल वाले कोडबेस में, क्लॉड अपनी लिखावट शामिल करना पसंद करता है। भले ही उसकी लिखावट 'बेहतर' हो, दूसरी लिखावट शामिल करना स्वयं किसी भी एकल मॉडल से अधिक खराब है।

उस क्षण ऐसा था: क्लॉड ने एक क्लास कंपोनेंट आधारित React कोडबेस में हुक्स शामिल किए। यह काम करता था। लेकिन यह मूल रूप से कोडबेस के टेस्टिंग पैटर्न को भी बगाता था, क्योंकि वे टेस्ट componentDidMount पर निर्भर करते थे। अंततः इसे हटाने और पुनः लिखने में आधा दिन लग गया।

क्लॉड की सबसे महंगी विफलताएँ अक्सर ऐसी होती हैं जो सफलता के जैसी दिखती हैं। एक फंक्शन "चल रहा है", लेकिन गलत डेटा लौटा रहा है; एक माइग्रेशन "पूरा हो गया", लेकिन 30 रिकॉर्ड को छोड़ दिया गया; एक परीक्षण "पास हो गया", लेकिन केवल इसलिए क्योंकि असर्शन स्वयं गलत था।

उस क्षण पर, क्लॉड ने कहा कि डेटाबेस माइग्रेशन "सफलतापूर्वक पूरा" हो गया। लेकिन वास्तव में, यह 14% ट्रिगर कंस्ट्रेंट टकराव वाली रिकॉर्ड्स को चुपचाप छोड़ दिया। छोड़ने की क्रिया लॉग में लिखी गई, लेकिन स्पष्ट रूप से प्रकट नहीं की गई। 11 दिनों बाद, जब रिपोर्टिंग डेटा असामान्य होने लगा, तब हमें समस्या का पता चला।

मैंने 6 सप्ताह के समय के दौरान, 30 कोड रिपॉजिटरी को कवर करते हुए, एक ही सेट के 50 प्रतिनिधित्वपूर्ण कार्यों का अनुसरण किया और तीन कॉन्फ़िगरेशन का परीक्षण किया।

त्रुटि दर का अर्थ है: कार्य को मूल इच्छा के अनुसार मिलाने के लिए सुधार या पुनः लिखने की आवश्यकता होती है। शामिल त्रुटियाँ हैं: चुपचाप किए गए अनुमान, अतिरिक्त इंजीनियरिंग, असंबंधित विनाश, चुपचाप विफलता, अनुबंध का उल्लंघन, संघर्षपूर्ण समझौते, और चेकपॉइंट की लापरवाही।

Compliance rate refers to: when a rule applies, the probability that Claude will explicitly apply that rule.

वास्तविक रूप से दिलचस्प परिणाम केवल त्रुटि दर में 41% से 3% तक कमी नहीं है। अधिक महत्वपूर्ण बात यह है कि 4 नियमों से बढ़ाकर 12 नियमों पर, अनुपालन का बोझ लगभग नहीं बढ़ा, अनुपालन दर केवल 78% से 76% हो गई, लेकिन त्रुटि दर फिर से 8 प्रतिशत अंकों तक कम हो गई। नए नियमों द्वारा कवर किए गए मामले मूल 4 नियमों द्वारा संबोधित नहीं किए गए विफलता मॉडल हैं, और वे एक ही ध्यान बजट के लिए प्रतिस्पर्धा नहीं करते हैं।

Karpathy टेम्पलेट कहाँ-कहाँ चुपचाप असफल हो जाएगा

नए नियम जोड़े बिना, मूल 4 नियम टेम्पलेट कम से कम 4 स्थानों पर पर्याप्त नहीं हैं।

पहला, लंबे समय तक चलने वाले एजेंट कार्य।
करपाथी के नियम मुख्य रूप से उस क्षण के लिए हैं जब क्लॉड कोड लिख रहा होता है। लेकिन जब क्लॉड एक बहु-चरण पाइपलाइन चला रहा होता है, तो क्या होता है? मूल टेम्पलेट में बजट नियम, चेकपॉइंट नियम या 'आवाज़ के साथ विफल होने' का नियम नहीं होता। इसलिए पाइपलाइन धीरे-धीरे विचलित हो जाती है।

दूसरा, बहु-कोडबेस समरूपता।
"मैच एक्सिस्टिंग स्टाइल" डिफ़ॉल्ट रूप से केवल एक ही स्टाइल होता है। लेकिन 12 सेवाओं वाले मोनोरेपो में, क्लॉड को यह चुनना होता है कि किस स्टाइल के साथ मैच करना है। मूल नियम इसके लिए कोई मार्गदर्शन नहीं देते। इसलिए या तो यह यादृच्छिक रूप से चुनता है, या कई स्टाइल्स को बराबर मिलाता है।

तीसरा, परीक्षण गुणवत्ता।
"लक्ष्य-आधारित निष्पादन" "परीक्षण सफल" को सफलता मानता है, लेकिन यह नहीं बताता कि परीक्षण स्वयं अर्थपूर्ण होना चाहिए। परिणामस्वरूप, क्लॉड कुछ ऐसे परीक्षण लिखता है जो लगभग कुछ भी सत्यापित नहीं करते, लेकिन ये परीक्षण उसे यह भ्रम देते हैं कि वह बहुत आत्मविश्वासी है।

चौथा, उत्पादन वातावरण और प्रोटोटाइप चरण के बीच अंतर।
वही 4 नियम उत्पादन कोड को अतिरंजित इंजीनियरिंग से बचा सकते हैं, लेकिन प्रोटोटाइप विकास को धीमा कर सकते हैं। क्योंकि प्रोटोटाइप चरण में कभी-कभी 100 पंक्तियों की खोजी संरचना की आवश्यकता होती है, ताकि दिशा को समझा जा सके। कारपथी का 'सरलता प्राथमिकता' प्रारंभिक कोड में अत्यधिक सक्रिय हो सकता है।

ये आठ नए नियम करपार्थी के मूल चार नियमों को बदलने के लिए नहीं हैं, बल्कि उनकी कमियों को भरने के लिए हैं: मूल टेम्पलेट 2026 जनवरी के स्वचालित पूर्ति-आधारित कोडिंग स्थिति के लिए था; जबकि 2026 मई तक, क्लॉड कोड एजेंट-संचालित, बहु-चरणीय, बहु-कोडबेस सहयोग परिवेश में प्रवेश कर चुका है, और दोनों के सामने अलग-अलग समस्याएँ हैं।

कौन सी विधियाँ काम नहीं कीं

इन 12 नियमों को अंतिम रूप देने से पहले, मैंने कुछ अन्य विकल्प भी आजमाए थे।

मैं Reddit / X पर देखे गए नियमों में शामिल होता हूँ।
उनमें से अधिकांश या तो कारपथी के मूल 4 नियमों को अलग तरह से दोहराते थे, या फिर विशिष्ट क्षेत्र के नियम थे जैसे 'हमेशा टेलविंड क्लास का उपयोग करें', जिन्हें अंततः हटा दिया गया।

12 से अधिक नियम।
मैंने अधिकतम 18 तक परीक्षण किया। 14 से अधिक के बाद, अनुपालन दर 76% से घटकर 52% हो गई। 200 पंक्तियों की सीमा वास्तविक है। इस लंबाई से अधिक होने पर, Claude "यहाँ नियम हैं" के रूप में मॉडल मैचिंग शुरू कर देता है, न कि वास्तव में नियमों को पंक्ति दर पंक्ति पढ़ता है।

Rules that depend on the existence of certain tools.
जैसे कि「हमेशा eslint का उपयोग करें」, यदि प्रोजेक्ट में eslint इंस्टॉल नहीं है, तो यह नियम अक्षम हो जाता है और यह चुपचाप अक्षम हो जाता है। बाद में मैंने इसे किसी विशिष्ट टूल पर निर्भर न करने वाले अभिव्यक्ति में बदल दिया, जैसे कि「eslint का उपयोग करें」को「कोडबेस में पहले से लागू किए गए स्टाइल का पालन करें」में बदल दिया।

CLAUDE.md में उदाहरण दें, न कि नियम।
उदाहरण नियमों की तुलना में संदर्भ में अधिक स्थान लेते हैं। तीन उदाहरण लगभग 10 नियमों के बराबर संदर्भ खपत करते हैं, और क्लॉड उदाहरणों के लिए अत्यधिक अनुकूलित हो जाता है। नियम अमूर्त होते हैं, उदाहरण विशिष्ट होते हैं। इसलिए, नियमों का उपयोग करना चाहिए।

थोड़ा सावधान रहें। गहराई से सोचें। ध्यान केंद्रित करें।
ये सभी शोर हैं। इस तरह के निर्देशों का पालन लगभग 30% तक गिर गया, क्योंकि इनकी जांच नहीं की जा सकती। बाद में मैंने इन्हें अधिक विशिष्ट आदेशात्मक नियमों से बदल दिया, जैसे कि 'अनुमानों को स्पष्ट रूप से बताएं'।

क्लॉड को एक「अनुभवी इंजीनियर」की तरह व्यवहार करना चाहिए।
यह काम नहीं करता। क्लॉड पहले से ही खुद को एक अनुभवी इंजीनियर समझता है। वास्तविक समस्या यह नहीं है कि वह ऐसा मानता है या नहीं, बल्कि यह है कि क्या वह ऐसा करता है। निर्देशात्मक नियम इस अंतर को कम कर सकते हैं, लेकिन पहचान संकेत नहीं।

पूर्ण 12 नियमों वाला CLAUDE.md

निम्नलिखित पूर्ण संस्करण है जिसे सीधे कॉपी और पेस्ट किया जा सकता है।

इस सामग्री को फ़ेiशु दस्तावेज़ के बाहर प्रदर्शित नहीं किया जा सकता है

इसे रिपॉजिटरी के मूल निर्देशिका में CLAUDE.md के रूप में सहेजें। इन 12 नियमों के नीचे, प्रोजेक्ट-विशिष्ट नियम जैसे तकनीकी स्टैक, टेस्ट कमांड्स, एरर मोड्स आदि जोड़ें। समग्र रूप से 200 पंक्तियों से अधिक न हो, क्योंकि इससे अधिक होने पर नियमों का पालन कम हो जाता है।

कैसे इंस्टॉल करें

केवल दो चरणों में:

1. करपाथी के 4 बेसिक नियमों को अपनी CLAUDE.md में जोड़ें
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. नीचे अपने द्वारा दिए गए नियम 5–12 को पेस्ट करें

फ़ाइल को रिपॉजिटरी के मूल निर्देशिका में सहेजें। यहाँ >> बहुत महत्वपूर्ण है, इसका कार्य आपके पहले से लिखे गए प्रोजेक्ट-विशिष्ट नियमों को ओवरराइट करना नहीं, बल्कि CLAUDE.md में जोड़ना है।

CLAUDE.md एक विश्राम सूची नहीं है, बल्कि एक व्यवहार समझौता है जो आपने जो विशिष्ट विफलता के पैटर्न देखे हैं, उन्हें बंद करने के लिए बनाया गया है।

प्रत्येक नियम एक प्रश्न का उत्तर देना चाहिए: यह किस त्रुटि को रोकता है?

करपाथी के 4 नियम, जो 2026 जनवरी में उन्होंने देखे गए विफलता पैटर्न के खिलाफ सुरक्षा प्रदान करते हैं: चुपचाप अनुमान, अतिरिक्त इंजीनियरिंग, असंबंधित विनाश, और कमजोर सफलता मानदंड। ये आधार हैं, इन्हें छोड़ें नहीं।

मैंने 2026 के मई के बाद आने वाले नए विफलता पैटर्न्स के लिए 8 नियम जोड़े हैं: बजट की सीमा के बिना एजेंट चक्र, चेकपॉइंट के बिना बहु-चरण कार्य, ऐसे परीक्षण जो लगते हैं कि परीक्षण किए गए हैं लेकिन महत्वपूर्ण लॉजिक को वास्तव में नहीं टेस्ट किया गया है, और शांत विफलता को शांत सफलता के रूप में प्रस्तुत करने की समस्या। ये वृद्धिमय पैच हैं।

बेशक, प्रभाव व्यक्ति के अनुसार भिन्न होता है। यदि आप मल्टी-स्टेप पाइपलाइन नहीं चलाते, तो नियम 10 आपके लिए कम महत्वपूर्ण है। यदि आपका कोडबेस केवल एक समान शैली का है और इसे लिंट द्वारा पहले से ही लागू किया जाता है, तो नियम 11 अतिरिक्त है। इन 12 नियमों को पढ़ने के बाद, केवल उन नियमों को बनाए रखें जो आपके वास्तविक त्रुटियों से सीधे संबंधित हैं, और बाकी सभी को हटा दें।

एक वास्तविक विफलता मॉडल के लिए अनुकूलित 6 नियमों वाला CLAUDE.md, उससे बेहतर है जिसमें 12 नियम हों और उनमें से 6 आप कभी उपयोग नहीं करेंगे।

अंतिम शब्द

करपाथी का जनवरी 2026 का वह ट्वीट मूल रूप से एक शिकायत थी। फॉरेस्ट चांग ने इसे 4 नियमों में बदल दिया। अंततः, 1.2 लाख डेवलपर्स ने इस पर स्टार दिया। और उनमें से अधिकांश, आज भी केवल उन्हीं 4 नियमों का उपयोग कर रहे हैं।

मॉडल आगे बढ़ चुके हैं, और पारिस्थिति भी बदल चुकी है। बहु-चरण एजेंट, हुक चेन ट्रिगर, स्किल लोडिंग, बहु-कोडबेस सहयोग—ये सब कुछ कारपथी द्वारा उस ट्वीट को लिखे जाने के समय मौजूद नहीं थे। मूल 4 नियम इन समस्याओं को हल नहीं करते हैं। वे गलत नहीं हैं, बल्कि अपूर्ण हैं।

8 नियम जोड़े गए। 6 सप्ताह में, 30 कोड रिपॉजिटरी का परीक्षण किया गया। त्रुटि दर 41% से घटकर 3% हो गई।

आज रात इस लेख को सेव कर लें और इन 12 नियमों को अपने CLAUDE.md में कॉपी कर लें। अगर यह आपको Claude के साथ एक हफ्ते का समय बचा दे, तो इसे शेयर करें।