कोड की लापरवाही को मापना

SlopCodeBench और “slop” का संचय

• बेंचमार्क सामान्य पैटर्न को उलट देता है: कई पुनरावृत्त कार्य, जिनके बीच context मिटा दिया जाता है, ताकि वास्तविक agent उपयोग की नकल हो सके।
• शुरुआती खराब डिज़ाइन निर्णय एक-दूसरे पर चढ़ते जाते हैं; सख्त मानदंडों के तहत (सभी checkpoints पास हों), शीर्ष मॉडल भी कथित तौर पर 0% solve प्राप्त करते हैं।
• उपयोग किए गए सरल metrics: LOC growth, cyclomatic complexity, और अत्यधिक लंबे या redundant code का पता लगाने के लिए heuristic “verbosity rules”।
• कई commenters को यह देखकर राहत मिली कि आखिरकार उनके व्यावहारिक अनुभव वाले एक phenomenon पर एक quantitative handle मिला।

आख़िर code quality क्या है?

• कई लोगों का तर्क है कि correctness केवल एक baseline है; quality में efficiency, security, maintainability, readability, observability, portability आदि भी शामिल हैं।
• दूसरों का कहना है कि बहुत सा मानव enterprise code ऐतिहासिक रूप से low quality रहा है; AI slop को “उसी का ज़्यादा तेज़ रूप” माना जाता है।
• कुछ लोग दावा करते हैं कि code quality को मापना मूलतः कठिन या असंभव है (halting problem जैसी तुलना), और यह स्वभावतः vibe-based है।

क्या LLMs अच्छे coders हैं? अलग-अलग अनुभव

• उत्साही पक्ष:
  • कई कार्यों के लिए, LLM output औसत या junior developer से बेहतर बताया जाता है, खासकर जब कोई सक्षम human उसे मार्गदर्शन दे।
  • लोग higher throughput की रिपोर्ट करते हैं, स्वीकार्य quality के साथ, विशेषकर उच्च-स्तरीय भाषाओं और greenfield work में।
• संदेहवादी पक्ष:
  • Agents बहुत अधिक code बनाते हैं, logic की नकल करते हैं, dead code हटाने से बचते हैं, और मौजूदा architecture को तोड़ देते हैं।
  • वे अक्सर non-local changes, complex systems, और subtle bugs में विफल रहते हैं, या भारी micromanagement की आवश्यकता होती है।
  • कुछ का कहना है कि LLM-लेखित codebases खुद को “speedrun” करके unmaintainable अवस्थाओं में पहुँचा देती हैं।

Global design, maintainability, और mental models

• commenters ज़ोर देते हैं कि सबसे कठिन समस्याएँ global होती हैं: separation of concerns, layering, interfaces, और long-term evolution।
• coding को मनुष्यों द्वारा shared mental models बनाने का एक तरीका बताया गया है; यदि agents सारा coding कर दें, तो मनुष्य समझ और नियंत्रण खो सकते हैं।
• अन्य लोगों का तर्क है कि भविष्य के tooling huge codebases पर “views” प्रदान कर सकते हैं, जिससे मानव-धारित global models की आवश्यकता कम हो जाएगी।

Metrics, Goodhart’s law, और evaluation ideas

• LOC change को व्यापक रूप से एक आश्चर्यजनक रूप से प्रभावी smell metric माना जाता है, लेकिन यह optimization/pathological “code golfing” के प्रति संवेदनशील है।
• सुझाव: LOC/tokens को cyclomatic complexity, churn, coupling, cohesion, indentation depth, AST patterns, और token cost के साथ मिलाकर code को “grok” करने की कोशिश करें।
• कुछ प्रस्ताव:
  • iterative “कितने rounds सही हल हुए” को core metric के रूप में लेना।
  • यह जाँचने के लिए एक अलग baseline model का उपयोग करना कि किसी अन्य model का code उपयोगी है या नहीं।
  • domain/architecture benchmarks (जैसे क्रमशः अधिक जटिल “counter” apps) जो केवल tests पास करने के बजाय design quality को मापें।

उद्योग पर प्रभाव और खुले प्रश्न

• कई लोग “coding” और “software engineering” में अंतर करते हैं; उनका मानना है कि पहला भाग automation की ओर दूसरे से तेज़ी से बढ़ रहा है।
• इस पर बहस है कि क्या मौजूदा models पहले ही “most” developers से आगे निकल चुके हैं या अभी भी competent professionals से बहुत पीछे हैं।
• लागत और token limits व्यावहारिक बाधाएँ हैं; कुछ लोग expense और slop के कारण aggressive agentic setups को वापस रोल-बैक करने की रिपोर्ट करते हैं।
• कुल भावना: sloppiness को मापना मूल्यवान है, लेकिन वास्तविक code quality को परिभाषित करना और उसके लिए optimize करना अभी भी अनसुलझा है।