LLM-सहायित कोड गुणवत्ता सुधारने के लिए मेरा agent.md
डेवलपर्स इस पर बहस कर रहे हैं कि बड़े language models को code बनाने के लिए steer करने में dedicated “AGENTS.md” files कितनी उपयोगी हैं, बनिस्बत linters, मौजूदा CONTRIBUTING/CODING_STANDARDS docs, और सरल, high-level guidelines के। कई लोग शिकायत करते हैं कि models कम-उपयोगी comments और verbose style fixes ज़्यादा पैदा करते हैं, और तर्क देते हैं कि mechanical checks तथा concise, positively phrased rules लंबे, विस्तृत agent instruction files से बेहतर काम करते हैं, क्योंकि वे context को dilute कर सकती हैं या models के बेहतर होने पर obsolete हो सकती हैं। फिर भी कुछ लोग minimal agent prompts में value देखते हैं जो workflow norms (जैसे TDD या unrelated edits को सीमित करना) और voice/style constraints encode करते हैं, लेकिन one-size-fits-all rule sets की तुलना में per-project, evolving configurations को अधिक प्रभावी मानते हैं।
AGENTS.md की भूमिका और डिज़ाइन
- कई लोग AGENTS.md को उपयोगी लेकिन बहुत व्यक्तिगत मानते हैं: अलग-अलग लोगों, प्रोजेक्ट्स और मॉडल्स की अलग-अलग failure modes होती हैं, इसलिए एक साझा template केवल एक शुरुआती बिंदु है।
- कुछ लोगों का तर्क है कि लेख की बहुत-सी सामग्री सामान्य CS है या आधुनिक मॉडल्स को पहले से “ज्ञात” है, इसलिए अतिरिक्त नियम बहुत कम या उल्टा नुकसान भी कर सकते हैं।
- दूसरों को लगता है कि AGENTS.md एक “ugly band-aid” है जो नए मॉडल्स के साथ पुराना पड़ जाता है, अक्सर अनदेखा कर दिया जाता है, और नियमों के गलत अर्थ निकाले जाने पर reasoning को भी दूषित कर सकता है।
- वैकल्पिक तरीका: project rules को CONTRIBUTING/CODING_STANDARDS में रखें और harness या skills को ज़रूरत के अनुसार उन्हें खोजने दें।
Linters बनाम Agent Instructions
- मजबूत थीम: mechanical/style rules को linters, pre-commit hooks, और CI से enforce करें, न कि non-deterministic agents से।
- उदाहरण: एक-line
ifपर braces, nested ternaries नहीं, comments नहीं, formatting, magic numbers। - कुछ लोग forbidden patterns/comments का पता लगाने के लिए LLM को CI/reviewer की तरह उपयोग करते हैं, जिससे “robots fight robots” होता है।
Comments और Documentation
- over-commenting को लेकर व्यापक frustration: agents verbose “what this does” comments बनाते हैं, जो अक्सर code से भी लंबे होते हैं।
- कई लोग comments को पूरी तरह ban करने की कोशिश करते हैं, या केवल “why/context” comments की अनुमति देते हैं; “what” code से स्वयं स्पष्ट होना चाहिए।
- चिंताएँ: comments stale हो जाते हैं, इंसानों और future agents को गुमराह करते हैं, और context को प्रदूषित करते हैं।
- एक छोटा हिस्सा comments का बचाव करता है, खासकर बड़ी/अटपटी functions या छिपी complexity वाली जगहों के लिए summaries के रूप में; कुछ लोग editor folding से comments छिपा देते हैं।
Instruction Following और Prompt Strategy
- उपयोगकर्ता “never add comments” जैसे rules के साथ mixed success बताते हैं; नए, बड़े models बेहतर पालन करते हैं, अन्य अनदेखा कर देते हैं।
- “do” बनाम “don’t” phrasing पर चर्चा: positive instructions शायद बेहतर टिकती हैं than prohibitions, लेकिन कुछ constraints (जैसे “no comments ever”) को “don’t” के बिना व्यक्त करना कठिन है।
- लंबे, घने AGENTS.md को “lost in the middle” context dilution की समस्या हो सकती है; कई लोग छोटे core rules, या modular rule files पसंद करते हैं जिन्हें agent task के अनुसार चुनता है।
Style, Architecture, और Workflow Preferences
- style mandates पर तीखे मतभेद: छोटे बनाम लंबे function names, हमेशा braces बनाम minimalism, enums बनाम booleans, छोटे extracted functions बनाम बड़े functions।
- कुछ लोग AGENTS.md में line-level rules की बजाय architectural और “why” context पर ज़ोर देते हैं।
- उल्लेखित workflows: multi-pass generation with self-review, convergence-style rules (success/progression/honest stop), TDD-centric prompting, और agents द्वारा unrelated code को छूने पर सख्त सीमाएँ।