आने वाला लूप
समग्र भावना
- चर्चा “लूप्स” (एजेंटिक कोडिंग वर्कफ़्लोज़) को लेकर उत्साह और कोड गुणवत्ता, मेंटेनबिलिटी, तथा डेवलपर बर्नआउट के बारे में गहरी चिंता के बीच बंटी हुई है।
- कई लोग मानते हैं कि पोस्ट सबसे स्पष्ट और सूक्ष्म दृष्टिकोणों में से एक है, लेकिन इसके “यह भविष्य अपरिहार्य है” वाले लहजे को अस्वीकार करते हैं।
लूप्स, एजेंट्स, और “अपरिहार्यता”
- लूप‑समर्थक टिप्पणीकार मौजूदा मॉडल्स को शुरुआती “कारों” की तरह देखते हैं जो अभी “हाईवे स्पीड” तक नहीं पहुँची हैं; “अरब‑डॉलर एक‑व्यक्ति स्टार्टअप्स” जैसी अपेक्षाएँ समय से पहले की, लेकिन दिशा में संभव मानी जाती हैं।
- संशयवादी कहते हैं कि यह उपमा खराब है: Mach‑1 कारें कभी वास्तविक उत्पाद लक्ष्य नहीं थीं, जबकि अरब‑डॉलर कंपनियाँ हैं; वे लूप्स को मार्केटिंग‑चालित और भारी सब्सिडी‑निर्भर मानते हैं।
- कुछ लोग “आप इससे बाहर नहीं रह सकते” वाली बात का विरोध करते हैं: आप खुद एजेंट्स का उपयोग न करने का विकल्प चुन सकते हैं, लेकिन आप हमलावरों, प्रबंधकों, या सहकर्मियों को उनका उपयोग करने से नहीं रोक सकते।
कोड गुणवत्ता, इनवेरिएंट्स, और “स्लॉप”
- इस बात पर मजबूत सहमति है कि मौजूदा LLM कोड आम तौर पर: जरूरत से ज्यादा रक्षात्मक होता है, तात्कालिक फॉलबैक जोड़ता है, लॉजिक की नकल करता है, और साफ़ इनवेरिएंट्स तथा टाइप्स से बचता है।
- लोग व्यवस्थित रोग‑लक्षण देखते हैं: अत्यधिक null checks, मनमाने मानों पर डिफॉल्ट करना, असंभव स्थितियों को संभालना, और iterations के साथ LOC का बढ़ना।
- कई लोग इसे घटिया कोड पर प्रशिक्षण और runtime errors को अत्यधिक दंडित करने वाले RL से जोड़ते हैं, जो “शॉटगन” error handling को पुरस्कृत करता है।
- कुछ लोगों को आंशिक सफलता इस तरह मिलती है:
- मजबूत आर्किटेक्चर लागू करके (hexagonal, सख्त module boundaries)।
- टेस्ट्स और checklist को लूप “oracles” की तरह उपयोग करके।
- दूसरे “judge” मॉडल से DRY, style, और design rules के लिए lint करवाकर।
- यहाँ तक कि समर्थक भी मानते हैं कि पूरी तरह एजेंटिक refactoring और बड़े unsupervised लूप्स फिलहाल गुणवत्ता के लिए खतरनाक हैं।
मानव की भूमिका, समझ, और वर्कफ़्लो
- कई लोग ज़ोर देते हैं कि जिन निर्णयों या कोड की आप “गहराई से परवाह” करते हैं, उन्हें delegate नहीं करना चाहिए; लूप्स केवल अच्छी तरह निर्दिष्ट, कम‑निर्णयात्मक, या छोड़ देने योग्य कार्यों के लिए स्वीकार्य हैं।
- एक बार‑बार आने वाला विषय: आप यह messy human phase नहीं छोड़ सकते कि आप असल में क्या चाहते हैं; लूप्स केवल स्पष्टता का लाभ उठा सकते हैं, उसे पैदा नहीं कर सकते।
- अन्य लोग ऐसे वर्कफ़्लोज़ बताते हैं जहाँ वे विस्तृत specs लिखते हैं, agents से implementation करवाते हैं, और फिर कठोर human PR review तथा targeted refactors करते हैं।
- इस पर बहस है कि अगर मनुष्य केवल orchestrator बन जाएँ, तो codebase की समझ क्या क्षीण हो जाएगी; कुछ लोग इसे अपरिहार्य मानते हैं, जबकि कुछ इसे वह सीमा मानते हैं जिसे वे पार नहीं करेंगे।
डेवलपर मनोविज्ञान और करियर रास्ते
- कई लंबे समय से काम कर रहे डेवलपर्स बताते हैं कि उन्हें coding में आनंद कम हो गया है; side projects AI‑accelerated output की तुलना में निरर्थक लगते हैं, जैसे “फोटोकॉपीर के बगल में फोनबुक टाइप करना।”
- अन्य लोग कहते हैं कि LLMs ने छोटे tools और experiments के लिए friction कम करके उनकी रुचि फिर से जगा दी।
- एक उपसमूह programming छोड़ने की सक्रिय योजना बना रहा है (जैसे diplomacy, IR, non-tech jobs में) क्योंकि AI‑चालित “rat race” और slopware संस्कृति से वे थक चुके हैं।
अर्थशास्त्र, संगठनात्मक दबाव, और अपनाना
- कुछ छोटी टीमों ने agents के साथ बड़ी उत्पादकता वृद्धि और बेहतर dev metrics की रिपोर्ट दी है; अन्य लोग सैकड़ों–हज़ारों डॉलर प्रति माह के token bills का उल्लेख करते हैं और hiring की तुलना में long‑term ROI पर सवाल उठाते हैं।
- चिंता है कि मौजूदा उत्साह subsidized token pricing से टिकाया गया है; यदि लागत 5–10x बढ़े, तो कई संगठन loops को कम कर सकते हैं।
- कई टिप्पणियाँ management और investors के “AI‑first” mandates को बताती हैं, जो 10k‑लाइन PRs को सामान्य बना रहे हैं और सावधानीपूर्ण review या skepticism को हतोत्साहित कर रहे हैं; downsides को document करने के प्रयासों को “anti‑AI rhetoric” कहा गया है।
सुरक्षा, दायित्व, और मेंटेनबिलिटी
- टिप्पणीकार नोट करते हैं कि हमलावर और सुरक्षा शोधकर्ता बड़े पैमाने पर fuzzing और exploit खोज के लिए loops का उपयोग करेंगे; maintainers यह “opt out” नहीं कर सकते कि वे निशाना न बनें।
- अन्य लोग तर्क देते हैं कि agents पर सच में भरोसा नहीं किया जा सकता क्योंकि उनके पास स्थायी पहचान और कानूनी personhood नहीं है; विफलताओं की सारी liability फिर भी मनुष्यों पर रहती है।
- कुछ लोग अनुमान लगाते हैं कि codebases अंततः केवल LLMs द्वारा ही प्रभावी रूप से maintainable होंगी; अन्य लोग ज़ोर देते हैं कि भविष्य के परिवर्तन और debugging अभी भी महंगे रहेंगे, चाहे code कौन या क्या लिखे।