विचारों को नियंत्रित करें, कोड को नहीं
Large language models कुछ developers को coding का अधिकांश हिस्सा AI agents को सौंपकर architecture, specifications, और testing पर ध्यान केंद्रित करने में सक्षम बना रहे हैं, जिससे यह provocative दावा सामने आता है कि code की हर line पढ़ना अब “pointless” होता जा रहा है। टिप्पणीकार इसे hallucinations, सूक्ष्म bugs, codebase bloat, और long-term maintainability की लगातार समस्याओं के मुकाबले तौलते हैं, और तर्क देते हैं कि code review, refactoring, और careful testing जैसी पारंपरिक प्रथाएँ अभी भी आवश्यक हैं। यह thread यह भी खोजता है कि यह बदलाव नए engineers के प्रशिक्षण, भविष्य के training data की गुणवत्ता, और AI-assisted open source development की economics और ethics के लिए क्या मायने रखता है।
कोड पढ़ने के मुकाबले कोडिंग एजेंट के रूप में LLMs
- कई लोग मानते हैं कि LLMs अब मजबूत कोडिंग सहायक हैं और सही तरह से इस्तेमाल करने पर बड़े refactors, नए modules, और असामान्य stacks को संभाल सकते हैं।
- दूसरों का कहना है कि जैसे-जैसे projects बड़े होते हैं (100k–1M LOC), models drift करते हैं, concepts को दोहराते हैं, और bespoke architectures या AGENTS.md-शैली के docs को नज़रअंदाज़ करते हुए लोकप्रिय frameworks और idioms की ओर झुकते हैं।
- कुछ का तर्क है कि भविष्य में ज़ोर हर line of code पढ़ने के बजाय “ideas को नियंत्रित करने” पर होना चाहिए (architecture, interfaces, tests); जबकि अन्य मानते हैं कि systems को समझने और दिशा देने के लिए कम-से-कम कुछ code की समीक्षा फिर भी ज़रूरी है।
Code Quality, Slop, and Scaling
- कई टिप्पणीकार LLM-उत्पन्न codebases को फूला हुआ, दोहरावदार, और concept drift के प्रति संवेदनशील मानते हैं, खासकर जब मजबूत conventions, linting, और human refactoring न हों।
- अन्य लोग मजबूत typing, aggressive refactoring/testing, और guardrails के साथ बड़े Rust/Lua projects पर सफलता का दावा करते हैं।
- चिंता यह है कि जैसे-जैसे AI-generated repositories training data पर हावी होंगे, भविष्य के models कम “entropy” और औसत दर्जे के code के feedback loops के कारण खराब हो सकते हैं।
Skill, “Skill Issue,” and Teaching
- एक पक्ष खराब परिणामों को मुख्यतः user skill, “agentic engineering,” और experimentation से जोड़ता है।
- अन्य लोग इसे घमंडी और अनुपयोगी कहकर आलोचना करते हैं, और ज़ोर देते हैं कि LLM workflows नए हैं, कम documented हैं, और करीबी collaboration के बिना transfer करना कठिन है।
- बहस इस बात पर केंद्रित है कि समस्याएँ “skill issues” हैं या “knowledge/experience issues,” और क्या experts पर practical workflows साझा करने की ज़िम्मेदारी है।
Testing, Safety, and Reliability
- व्यापक सहमति है कि models अभी भी hallucinate करते हैं और correctness को बढ़ा-चढ़ाकर बताते हैं; कठोर tests, TDD, property-based testing, और reproducible repro cases अभी भी महत्वपूर्ण हैं।
- कुछ लोग तर्क देते हैं कि tests और empirical QA बड़े पैमाने पर code reading की जगह ले सकते हैं; अन्य कहते हैं कि tests कभी bugs की अनुपस्थिति सिद्ध नहीं कर सकते और structure को समझना आवश्यक है।
Licensing, Redis/Valkey, and Hyperscalers
- एक side thread: इस पर तीखी असहमति कि क्या Valkey ने Redis को “replace” किया या सिर्फ adoption हासिल की, और क्या यह AI usage की बजाय licensing के कारण है।
- open source से अनुपातहीन योगदान किए बिना मुनाफ़ा कमाने के लिए hyperscalers की तीखी आलोचना, और यह बहस कि permissive licenses एक गलती थीं या नहीं।
- कुछ लोग “fair source” / open-core licenses को आवश्यक बचाव मानते हैं; अन्य चिंतित हैं कि इससे portability और self-hosting कमज़ोर होती है।
Careers, Learning, and Access
- चिंता है कि यदि coding को LLMs को सौंप दिया जाता है, तो newcomers architecture और design के लिए आवश्यक mental models बनाने में संघर्ष करेंगे।
- कुछ को डर है कि भविष्य में meaningful software work के लिए proprietary models और महंगे hardware तक paid access चाहिए होगा, जिससे यह क्षेत्र कम accessible हो जाएगा।
- अन्य सलाह देते हैं कि influencers को अनदेखा करें, code लिखना और पढ़ना जारी रखें, और AI को replacement नहीं बल्कि एक शक्तिशाली लेकिन त्रुटिपूर्ण tool मानें।