कोड की पंक्तियों को एक बेहतर प्रचारक मिल गया
AI-जनित कोड ने प्रबंधन मेट्रिक के रूप में लाइन-ऑफ-कोड को फिर से जीवित कर दिया है, जबकि दशकों के अनुभव से यह दिखता रहा है कि LoC मुख्यतः भविष्य के मेंटेनेंस बोझ को मापता है, वास्तविक उत्पादकता को नहीं। टिप्पणीकारों का तर्क है कि टाइप करना बाधा नहीं है—असली बाधाएँ यह तय करना हैं कि क्या बनाना है, बदलावों की समीक्षा और परीक्षण, और सरलता बनाए रखना—इसलिए “मिलियन LoC” या AI-लिखे कोड के उच्च प्रतिशत का उत्सव अक्सर सिर्फ स्लॉप और तकनीकी ऋण पैदा करता है। कई लोग AI लेऑफ और उत्पादकता के मौजूदा दावों को बढ़ी हुई hiring और निवेशक दबाव के लिए PR मानते हैं, न कि वास्तविक दक्षता लाभ का प्रमाण, और चेतावनी देते हैं कि LoC मेट्रिक्स के पीछे भागने वाले संगठन बेहतर उत्पादों के बजाय अधिक नाज़ुक, अनचाही विशेषताएँ शिप करेंगे।
लाइन-ऑफ-कोड मेट्रिक्स की वापसी
- टिप्पणीकार AI युग में सफलता के मापदंड के रूप में LoC के पुनरुत्थान को नोट करते हैं, लंबे समय से चली आ रही आलोचना के बावजूद।
- OpenAI की “एजेंट्स द्वारा मिलियन लाइंस ऑफ कोड” ब्लॉग पोस्ट को इसका प्रतीकात्मक उदाहरण माना गया है: उत्पाद के मूल्य पर कम स्पष्टता के साथ LoC पर भारी जोर।
- Linux, Chrome, और बड़े monorepos से की गई तुलना यह उजागर करती है कि बहुत बड़े LoC आंकड़े अपने आप में प्रभावशाली या वांछनीय नहीं होते।
AI स्लॉप, तकनीकी ऋण, और मेंटेनबिलिटी
- “AI स्लॉप” की तुलना पारंपरिक “तकनीकी ऋण” से की जाती है और इसे अधिक ठोस माना जाता है: कोड की बड़ी मात्रा जिसे बहुत कम लोग समझते हैं, और जो अक्सर उद्देश्य के लिए ज़रूरत से कहीं अधिक बड़ी होती है।
- कुछ का तर्क है कि कोड की हर पंक्ति एक दायित्व है; LoC को एक “संपत्ति” के बजाय एक “लागत” के रूप में बोलना चाहिए।
- यह चिंता कि LLM-लिखित कोडबेस में पहचानने योग्य पैटर्न होते हैं: विश्वसनीय लगने वाला कोड, पतले या नकली टेस्ट, अस्पष्ट एब्स्ट्रैक्शन।
उत्पादकता और बाधाएँ
- कई लोग कहते हैं कि “कोड लिखना अब बाधा नहीं है”; वास्तविक सीमाएँ तय करना हैं कि क्या बनाना है, कोड समीक्षा, परीक्षण, और संगठनात्मक प्रक्रिया।
- व्यक्तिगत डेवलपर अक्सर खुद को तेज़ महसूस करते हैं, खासकर टेस्ट, boilerplate, और legacy code को समझने में, लेकिन टीम- या कंपनी-स्तर के लाभ मामूली रहते हैं क्योंकि downstream bottlenecks अपरिवर्तित रहते हैं।
- “प्रति इंजीनियर प्रति माह 1M LOC” जैसे दावों पर बहस है; कुछ इसे automated porting के बारे में मानते हैं, जबकि अन्य इसे अवास्तविक और आसानी से गेम किया जा सकने वाला मानते हैं।
मेट्रिक्स, गेमिंग, और Goodhart’s Law
- उदाहरण: lines-of-code-आधारित performance reviews, PR-count-driven evaluations, code-coverage quotas जिन्हें generated junk से गेम किया जाता है।
- टिप्पणीकार बार-बार Goodhart’s Law का हवाला देते हैं: जब LoC, PRs, या “% code written by AI” लक्ष्य बन जाते हैं, तो वे वास्तविक उत्पादकता को मापना बंद कर देते हैं।
अपनाने का दबाव और सांस्कृतिक विभाजन
- कुछ लोग जोर देते हैं कि हर engineer को प्रतिस्पर्धी और रोजगार योग्य बने रहने के लिए रोज़ AI का उपयोग करना चाहिए; अन्य इसे hype या “gun-to-the-head” अपनाने के रूप में खारिज करते हैं।
- मिश्रित field reports: गैर-तकनीकी या junior उपयोगकर्ता शुरू में प्रभावित होते हैं, लेकिन अक्सर तब निराश होते हैं जब वे AI का उपयोग उन कार्यों के लिए करते हैं जिन्हें वे अच्छी तरह जानते हैं।
- HN को भी अलग-अलग प्रतिभागी दोनों “AI fanboy” और “AI hate” क्षेत्र के रूप में देखते हैं, जो एक ध्रुवीकृत समुदाय को दर्शाता है।
सुरक्षा-महत्वपूर्ण और “वास्तविक” उत्पाद
- सुरक्षा-महत्वपूर्ण और embedded क्षेत्रों को बड़े पैमाने पर LLM codegen अपनाते नहीं बताया गया है; एक उद्धृत अध्ययन में प्रमुख दिशानिर्देशों के गैर-अनुपालन का उल्लेख है।
- एक व्यापक तुलना उन क्षेत्रों के बीच की जाती है जिन्हें काम करने वाले, लाभदायक उत्पाद शिप करने होते हैं और उन क्षेत्रों के बीच जिन्हें “faux productivity” पर केंद्रित माना जाता है।