AI रॉकस्टार डेवलपर्स के बाद की सफ़ाई
AI-सहायता प्राप्त “vibe coding” managers, juniors, और non-developers को बहुत तेज़ी से बड़ी मात्रा में software ship करने में सक्षम बना रहा है, लेकिन कई engineers रिपोर्ट करते हैं कि यह code overcomplicated, inconsistent, और maintain करने में कठिन है। Commenters का कहना है कि मूल समस्या संगठनात्मक है: कमजोर code review, speed को quality से ऊपर रखने वाले incentives, और ऐसे leaders जो long-term technical debt को नहीं समझते। कुछ लोग AI- और contractor-generated slop को साफ़ करने में अवसर देखते हैं, जबकि अन्य चिंता करते हैं कि disposable software की संस्कृति craftsmanship को कमजोर करेगी और भविष्य के systems को brittle तथा evolve करने में महँगा बना देगी.
“AI रॉकस्टार” / vibe-coded गड़बड़ियों की प्रकृति
- कई लोग AI-जनित कोड की तुलना पुराने “रॉकस्टार” या आउटसोर्स किए गए स्लॉप से करते हैं: तेज़ फीचर डिलीवरी, खराब डिज़ाइन, दोहराव, अजीब abstractions, और नाज़ुक integrations।
- LLM की विशिष्ट विशेषताएँ: अनावश्यक जटिलता, requirements से आगे overbuilding, frameworks जो पहले से देते हैं उसे फिर से invent करना, और बहुत बड़े, धीमे frontends।
- दूसरों का तर्क है कि यह नया नहीं है: ऐसी ही समस्याएँ spaghetti VB/PHP, copy-paste offshore work, और overengineered “resume-driven” stacks में भी थीं।
Management और संगठनात्मक गतिशीलताएँ
- कई लोग ज़ोर देते हैं कि यह मूलतः people/management problem है: code review की कमी, top-down AI mandates, और executives को संतुष्ट करने के लिए managers का “code” करना।
- कुछ कहते हैं कि आपको खराब PRs को reject करना चाहिए और authors को दर्द उठाने देना चाहिए; दूसरे जवाब देते हैं कि बड़े, hierarchical orgs में आप push back नहीं कर सकते और आपको cleanup करना ही अपेक्षित है।
- इस पर कड़ा मतभेद है कि क्या कंपनियाँ कभी “velocity” और MVPs के बजाय refactoring/maintenance को प्राथमिकता देंगी।
व्यवहार में LLMs का उपयोग कैसे किया जाता है
- सकारात्मक अनुभव:
- डेवलपर्स scaffolding, refactors, migrations, infra, और tests के लिए multiple review/cleanup prompts के साथ LLMs का उपयोग करके productivity में बड़ा लाभ रिपोर्ट करते हैं।
- कुछ लोग web + mobile + infra सहित पूरे apps largely LLMs के ज़रिए ship कर सकते हैं, और उन्हें legacy codebases खड़ा करने या मुश्किल मुद्दों को debug करने के लिए इस्तेमाल करते हैं।
- नकारात्मक या सतर्क दृष्टिकोण:
- LLMs बुरी आदतों को बढ़ाते हैं; novices “it runs” को बिना समझे स्वीकार कर लेते हैं।
- code bloat, duplicated logic, रहस्यमय abstractions, और मानवों की तुलना में तेज़ी से tech debt पैदा करने वाली organizations को लेकर चिंता।
- “agents जो auto-clean tech debt करें” या “AI के युग में कोई technical debt नहीं” जैसी धारणाओं के प्रति संदेह।
Maintainability, refactoring, और craftsmanship
- व्यापक सहमति है कि maintainability अभी भी मानव समझ, architecture, tests, और अनुशासन पर निर्भर करती है।
- कुछ लोग AI को prototypes और disposable tools के लिए बेहतरीन मानते हैं; दूसरे चेतावनी देते हैं कि prototypes अक्सर production में जम जाते हैं।
- कई लोग refactoring skills और long-term “gardener” roles पर ज़ोर देते हैं; अन्य कहते हैं कि modern orgs शायद ही कभी इस काम को पुरस्कृत करते हैं।
करियर, भूमिकाएँ, और भावनाएँ
- थ्रेड boredom, burnout, underutilization, और replace होने के डर—या AI messes को अंतहीन साफ़ करने के डर—को सामने लाता है।
- “10x developers” और “developers” बनाम “engineers” के बीच भेद पर बहस; कुछ इसे gatekeeping कहते हैं, जबकि अन्य इसे वास्तविक productivity deltas मानते हैं।