कोड ऐसे लिखें जिसे कोई इंसान मेंटेन करेगा
टिप्पणियाँ, नामकरण, और पठनीयता
- बहुत से लोग भारी-भरकम कमेंटिंग की बजाय कम से कम कमेंट्स और साफ़ नामकरण को तरजीह देते हैं।
- कोड क्या करता है, यह बताने वाले अनावश्यक “explain what the code does” कमेंट्स को शोर माना जाता है और इनके पुराने पड़ जाने की संभावना रहती है; कमेंट्स को “what” या “how the framework works” नहीं, बल्कि “why” समझाना चाहिए।
- कुछ लोग literate programming जैसी वर्कफ़्लो की वकालत करते हैं (पहले गद्य/इरादा लिखो, फिर कोड), लेकिन मानते हैं कि यह अक्सर कोड को ही फिर से कहने तक सिमट जाता है।
- आम सहमति: अच्छे नाम, सरल संरचना, और कभी-कभार “here be dragons / rationale” वाले कमेंट्स आदर्श हैं।
LLM-जनित कमेंट्स और शैली
- LLMs के बहुत लंबे, कम-मूल्य वाले कमेंट्स, ऐतिहासिक नोट्स, और implementation-process की बातें पैदा करने पर काफ़ी निराशा है।
- मॉडल अक्सर भाषा की बुनियादी बातें, आसपास के कोड की विचित्रताएँ, या caller के व्यवहार का वर्णन करते हैं, जिससे encapsulation टूटता है और वे जल्दी पुराने पड़ जाते हैं।
- CLAUDE.md / AGENTS.md नियमों के ज़रिए इसे नियंत्रित करने की कोशिश कुछ हद तक मदद करती है, लेकिन यह असंगत रूप से पालन होती है; नकारात्मक निर्देश (“X मत करो”) विशेष रूप से अस्थिर हैं।
AI के साथ उत्पादकता बनाम मेंटेनबिलिटी
- कुछ लोग दावा करते हैं कि जो भी टेस्ट पास करे उसे शिप करके और AI को “बाद में गंदगी सँभालने” देने से फीचर/बगफिक्स थ्रूपुट 10x हो जाता है।
- दूसरे चेतावनी देते हैं कि यह slop बढ़ता जाता है: डुप्लिकेट लॉजिक, अलग होती बिज़नेस रूल्स, और layered defensive layers भविष्य के AI और human काम को धीमा और जोखिमभरा बना देती हैं।
- इस पर बहस है कि क्या अल्पकालिक गति का दीर्घकालिक जटिलता पर असर पड़ेगा, खासकर बड़े codebases में।
प्रॉम्प्ट, चेकलिस्ट, और review workflows
- बहुत से लोग project-level CLAUDE.md / AGENTS.md के साथ-साथ लंबे चेकलिस्ट वाले स्पष्ट “/review” कमांड्स का उपयोग करते हैं (DRY, style, duplication, dead code, tests, docs)।
- कुछ लोग review को कई विशेष passes में बाँटते हैं (security, accessibility, performance, simplification) और यहाँ तक कि multi-model adversarial review भी करते हैं।
- अन्य लोग बताते हैं कि instruction lists बढ़ने पर लाभ घटता जाता है; मॉडल फिर भी बुनियादी नियमों (जैसे git usage) को अनदेखा कर देते हैं, इसलिए system-level guardrails की ज़रूरत पड़ती है।
पारंपरिक टूलिंग और guardrails
- Static analyzers, linters, code-formatters, duplication detectors, और pre-commit/CI checks को non-stochastic baseline के रूप में व्यापक रूप से सुझाया जाता है।
- कुछ लोग custom linters या compiler-level checks लिखते हैं ताकि वे चीज़ें लागू कराई जा सकें जिन्हें LLMs नियमित रूप से तोड़ते हैं (magic numbers नहीं, dynamic imports नहीं, doc/test requirements)।
मानव बनाम AI की भूमिकाएँ
- कई डेवलपर अब LLMs का उपयोग मुख्यतः exploration, refactoring, और review के लिए करते हैं, लेकिन core code खुद लिखते हैं।
- दूसरे AI-heavy workflows अपनाते हैं, यह स्वीकार करते हुए कि humans के पास अब सिस्टम का पूरा mental model नहीं भी हो सकता, और इसके बजाय strong harnesses और tooling पर निर्भर रहते हैं।
- अंदरूनी तौर पर, बहुत से लोग ज़ोर देते हैं: maintainable structure, DRYness, और clear abstractions अभी भी मायने रखते हैं—उन इंसानों और agents दोनों के लिए जो बाद में इस कोड का उपयोग करेंगे।