LLM कोड उत्पन्न करने में लगभग पूर्ण हो गए हैं, लेकिन यह कहानी का अंत नहीं है। कोड औपचारिक रूप से सही होने का मतलब यह नहीं है कि यह अनावश्यक अमूर्तताएं पेश नहीं कर रहा है, डुप्लिकेट नहीं बना रहा है, या समग्र रूप से खराब निर्णय नहीं ले रहा है। यह कोई अभूतपूर्व अवलोकन नहीं है, जिन लोगों ने किसी प्रोजेक्ट को वाइब-कोड किया है, उन्होंने महसूस किया है कि प्रत्येक अतिरिक्त सुविधा कभी-कभी कोड की पंक्तियों (LOC) के विस्फोट का कारण बन सकती है। इसके परिणामस्वरूप मानव एजेंसी का नुकसान होता है, क्योंकि प्रति माह लाखों LOC जोड़ने वाले प्रोजेक्ट्स में, मनुष्यों के लिए बनाए रखना मुश्किल है। कुछ लोग कह सकते हैं कि यह कोई समस्या नहीं है, क्योंकि वे अपने एजेंट्स पर भरोसा करते हैं कि वे इसे संभाल लेंगे। मेरे पास आपके लिए बुरी खबर है, एजेंट्स वास्तव में स्लॉप को भी संभाल नहीं सकते।

भौतिकी की पृष्ठभूमि से आने के कारण, मेरे पास समस्याओं को हल करने के लिए हमेशा एक प्रयोगात्मक/मात्रात्मक दृष्टिकोण था। जब मैंने Earendil में शुरुआत की, कोड स्लॉपीनेस को मापने का तरीका खोजने के कार्य के साथ, मेरी स्वाभाविक प्रवृत्ति पहले साहित्य में गहराई से जाना और फिर देखना था कि अन्य कंपनियां क्या कर रही हैं। स्पष्ट रूप से कहूं तो, कुछ अंतर्दृष्टिपूर्ण शोध पत्रों को छोड़कर, मैं इस बात से निराश था कि उद्योग इस समय कितना "वाइब्स आधारित" लगता है। अपने शोध और X पर, मैं लगातार "एंड-टू-एंड कोडिंग एजेंट्स", "AI जो सिर्फ कोड का सुझाव नहीं देता—बल्कि उसे शिप करता है" या "मानव-स्तरीय मूल्यांकन बिना मानव-स्तरीय लागत" जैसे संदेशों से बमबारी कर रहा था। जो सभी अच्छी कहानियों की तरह, उनमें सच्चाई का एक अंश है। LLM लगभग पूरी तरह से सही कोड लिखने में सक्षम हैं। यह कोड की स्केलेबिलिटी और सत्यापन क्षमता के कारण है। LLM को कोड उत्पन्न करने देना और फिर उस कोड को छिपे हुए परीक्षणों द्वारा जांचा जाना काफी सीधा है, जिसके परिणामस्वरूप एक स्पष्ट इनाम संकेत मिलता है। इसके विपरीत, इस कोड की 'स्लॉपीनेस' की जांच करने के लिए अक्सर मानव अंतर्ज्ञान और स्वाद की आवश्यकता होती है, और सामान्य रूप से यह एक अत्यंत कठिन कार्य है।

मुझे लगता है कि ऐसा क्यों है, यह समझाने का सबसे अच्छा तरीका स्लॉप को मापने के संभावित तरीकों से गुजरना है। AI निर्णायक के रूप में: यह संभवतः उद्योग में कोड गुणवत्ता का मूल्यांकन करने का सबसे आम तरीका है और मेरे अवलोकनों से यह शायद ही कभी काम करता है। इसे करने का सबसे भोला तरीका, अर्थात् मॉडलों से पूछना कि कोड 1-10 के पैमाने पर कितना अच्छा है, मूल रूप से एक यादृच्छिक संख्या जनरेटर के बराबर है। अधिक परिष्कृत दृष्टिकोण, अर्थात् निर्णायक मॉडल को दो समाधान A और B देने की कोशिश करना, और फिर इसे तय करने देना कि यह किसे पसंद करता है, इसका नुकसान यह है कि जब आप समाधानों का नाम बदलते हैं तो मॉडल अपनी प्राथमिकता बदल देता है। मैं यहां थोड़ा व्यंग्यात्मक हो रहा हूं और बड़े मॉडलों के साथ यह प्रभाव उतना स्पष्ट नहीं है, लेकिन मुख्य बात अभी भी बनी हुई है। LLM से उनके द्वारा लिखे गए कोड का न्याय करने के लिए कहना उचित मूल्यांकन का विकल्प नहीं है। हालांकि रूब्रिक्स या LLM द्वारा परीक्षण लिखने के साथ कुछ दिलचस्प दृष्टिकोण हैं, वे अभी भी वास्तव में स्लॉप से छुटकारा पाने से बहुत दूर हैं।

मानव AI का न्याय करता है: अगर हम इस तथ्य को अनदेखा करते हैं कि सॉफ्टवेयर-इंजीनियरों की गुणवत्ता में बहुत विविधता है, तो यह सुनिश्चित करने का सबसे अच्छा समाधान होगा कि कोड मानव-पठनीय बना रहे। इसका नुकसान यह है कि यह AI को प्रशिक्षित करने या कई मॉडल प्रदाताओं और हार्नेस के साथ बड़े बेंचमार्क रखने के लिए स्केलेबल नहीं है। सबसे सरल विधि: मेरे शोध और परीक्षणों में, बस LOC की संख्या में परिवर्तन लेना स्लॉपीनेस के लिए आश्चर्यजनक रूप से प्रभावी मीट्रिक रहा है, इस विडंबनापूर्ण चेतावनी के साथ कि अगर हम इसके लिए अनुकूलन करना शुरू कर दें, तो यह एक सार्थक माप होना बंद कर देगा। अगले दो उपाय मुझे Slop Code Bench पेपर द्वारा पेश किए गए थे, और आशाजनक लग रहे थे क्योंकि वे लीगेसी कोड बेस को LLM-स्लॉप से काफी अच्छी तरह से अलग कर सके। वर्बोसिटी: डुप्लिकेट और अनावश्यक वर्बोज़ लाइनों की मात्रा को मापने का प्रयास करता है। इरोशन: यह मापने का प्रयास करता है कि कोडबेस का कितना द्रव्यमान कुछ बड़े और जटिल कार्यों में केंद्रित है।

मुख्य संस्थाएं: कंपनियां: Earendil