आने वाला लूप
AI कोडिंग “लूप्स” और एजेंट्स, जो स्वायत्त रूप से कोड लिखते और refactor करते हैं, डेवलपर्स के बीच उत्साह और चिंता दोनों पैदा कर रहे हैं। कई लोग well-scoped, कम‑जोखिम वाले कार्यों के लिए स्पष्ट उत्पादकता लाभ देखते हैं, लेकिन रिपोर्ट करते हैं कि unsupervised loops अक्सर फैला हुआ, अत्यधिक रक्षात्मक “slopware” बनाते हैं, जिसे मनुष्यों के लिए समझना, review करना, या सुरक्षित रूप से maintain करना कठिन होता है। इसके पीछे एक गहरी चिंता है: जैसे‑जैसे management AI‑चालित output का पीछा करती है और token subsidies असली लागत को छिपाती हैं, engineers को समझ और craftsmanship से हटाकर ऐसे opaque machine‑grown systems की निगरानी करने की ओर धकेला जा सकता है जिन पर उनका पूरा नियंत्रण नहीं रहता।
समग्र भावना
- चर्चा “लूप्स” (एजेंटिक कोडिंग वर्कफ़्लोज़) को लेकर उत्साह और कोड गुणवत्ता, मेंटेनबिलिटी, तथा डेवलपर बर्नआउट के बारे में गहरी चिंता के बीच बंटी हुई है।
- कई लोग मानते हैं कि पोस्ट सबसे स्पष्ट और सूक्ष्म दृष्टिकोणों में से एक है, लेकिन इसके “यह भविष्य अपरिहार्य है” वाले लहजे को अस्वीकार करते हैं।
लूप्स, एजेंट्स, और “अपरिहार्यता”
- लूप‑समर्थक टिप्पणीकार मौजूदा मॉडल्स को शुरुआती “कारों” की तरह देखते हैं जो अभी “हाईवे स्पीड” तक नहीं पहुँची हैं; “अरब‑डॉलर एक‑व्यक्ति स्टार्टअप्स” जैसी अपेक्षाएँ समय से पहले की, लेकिन दिशा में संभव मानी जाती हैं।
- संशयवादी कहते हैं कि यह उपमा खराब है: 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 कौन या क्या लिखे।