प्रोग्रामर Claude के लिए दस्तावेज़ लिखेंगे, लेकिन एक-दूसरे के लिए नहीं

लोग “Claude के लिए दस्तावेज़” क्यों लिखते हैं

• डेवलपर्स को तुरंत, ठोस लाभ दिखता है: जब वे केंद्रित संदर्भ, स्पेसिफिकेशन्स, और CLAUDE.md फ़ाइलें देते हैं, तो AI आउटपुट बेहतर होता है।
• Claude भरोसेमंद तरीके से सब कुछ “पढ़” लेता है; सहकर्मी अक्सर नहीं पढ़ते। इससे AI के लिए लिखने का ROI बहुत अधिक महसूस होता है।
• Claude के लिए दस्तावेज़ की जाँच केवल सूचना-सामग्री पर होती है, न कि गद्य की गुणवत्ता पर, इसलिए लोग कच्चे नोट्स, डिक्टेशन, और ऐसी गंदी-गली सामग्री डालने को तैयार रहते हैं जिसे वे मनुष्यों के साथ साझा करते समय शर्मिंदा होते।
• कुछ लोगों का तर्क है कि डेवलपर्स Claude के लिए नहीं, बल्कि अपने लिए और Claude के किसी भी उपयोगकर्ता के लिए दस्तावेज़ लिख रहे हैं; AI बस आखिरकार एक ध्यान देने वाला पाठक सुनिश्चित कर देता है।

दस्तावेज़ों का मानव बनाम AI उपयोग

• कई लोग वर्षों तक सावधानी से दस्तावेज़ लिखने का अनुभव बताते हैं, जिन्हें सहकर्मियों ने अनदेखा किया, और फिर वही सवाल फिर भी पूछे गए।
• कुछ टीमें “पहले दस्तावेज़ पढ़ो” संस्कृति लागू करने की कोशिश करती हैं (यह पूछकर कि किसी ने कहाँ देखा, दस्तावेज़ की आदतों को समीक्षा से जोड़कर), लेकिन मिश्रित सफलता की रिपोर्ट करती हैं।
• कई लोग नोट करते हैं कि अधिकांश उपयोगकर्ता स्क्रीन पर दिखने वाला पाठ बिल्कुल नहीं पढ़ते; कई कंपनियाँ “मौखिक संस्कृतियाँ” हैं।
• AI की प्रशंसा इस बात के लिए की जाती है कि वह बड़े, अव्यवस्थित दस्तावेज़-समूह पढ़ सकता है, PRs, tickets, wiki pages को cross-reference कर सकता है, और किसी व्यक्ति की मौजूदा समझ के अनुसार व्याख्या कर सकता है।

गुणवत्ता, drift, और रखरखाव

• एक बार-बार आने वाली शिकायत: CLAUDE.md और AI-जनित दस्तावेज़ जल्दी पुराने पड़ जाते हैं और भविष्य के AI sessions को गुमराह कर सकते हैं, यहाँ तक कि हटाई गई classes और architectures के बारे में hallucinate भी कर सकते हैं।
• कुछ लोग ऐसे files मिटा देते हैं; अन्य कुछ agents जोड़ते हैं जो living docs का एक छोटा set बनाए रखें (overview, key flows) और अस्थायी योजनाएँ छोड़ दें।
• Inline documentation (जैसे jsdoc-style) और build-time doc extraction को code और docs को aligned रखने के तरीकों के रूप में उद्धृत किया जाता है।
• एक heuristic: अगर कोई LLM आपके दस्तावेज़ों से सही उत्तर नहीं निकाल सकता, तो संभव है कि दस्तावेज़ खुद ही अस्पष्ट या गलत हों।

नई workflows और tooling

• लोग custom “skills” और agents का वर्णन करते हैं: parallel code reviewers, infinite issue generators, documentation agents जो drift पकड़ते हैं, और Claude के माध्यम से बनाए गए repo overviews।
• specs, design docs, और decision documents टीमों को align करने और agents को drive करने, दोनों के लिए केंद्रीय होते जा रहे हैं; कुछ लोग देखते हैं कि spec formats विकसित होकर AI के लिए de facto “programming languages” बन सकते हैं।

उत्साह बनाम संदेहवाद

• उत्साही लोग 4–8× productivity gains और specs तथा architecture docs में पुनर्जागरण की रिपोर्ट करते हैं, अब जब वे सीधे implementation speed में सुधार करते हैं।
• संदेहवादी चेतावनी देते हैं कि LLM output non-deterministic, आंशिक रूप से गलत, verbose होता है, और anti-social, AI‑mediated collaboration को बढ़ावा दे सकता है।
• चिंता यह है कि विशाल, AI-जनित दस्तावेज़ों के ढेर पढ़ने योग्य नहीं होंगे, जल्दी पुराने पड़ जाएंगे, और अंततः disposable होंगे।