क्या AI सॉफ़्टवेयर इंजीनियरिंग के मध्य वर्ग को खत्म कर रहा है?

AI coding tools even weak developers को बड़ी मात्रा में ऐसा कोड बनाने दे रहे हैं जो काम करता हुआ दिखता है, जिससे अस्थिर systems, छिपे bugs, और technical debt के तेज़ी से जमा होने की चिंता बढ़ रही है। कई engineers बताते हैं कि senior reviewers और अच्छी engineering culture bottleneck बन गए हैं, क्योंकि वे AI-generated changes को समझने और सुरक्षित रूप से approve करने में जूझ रहे हैं। साथ ही, commenters को चिंता है कि entry- और mid-level software roles दब रही हैं, जबकि productivity gains मुख्यतः कुछ मज़बूत engineers और management cost-cutting को मिल रहे हैं, जिससे career ladder senior positions तक खोखली हो सकती है.

कोड गुणवत्ता और आर्किटेक्चर पर AI का प्रभाव

  • कई लोगों का मानना है कि LLMs “Big Ball of Mud” कोड को और बढ़ावा दे रहे हैं: ऐसे विशाल, नाज़ुक, खराब संरचित कोडबेस जो डेमो में “काम” करते हैं, लेकिन स्केल, बदलाव या जाँच-पड़ताल पर असफल हो जाते हैं।
  • AI के लिए ऐसी दसियों हज़ार पंक्तियाँ बनाना सस्ता है जो compile हों, सतही tests पास करें, और ठीक-ठाक दिखें—जब तक maintenance, performance, security, और migrations nightmare न बन जाएँ।
  • कई लोग कहते हैं कि यह समस्या इंसानों के साथ हमेशा से थी; AI मुख्यतः इसे तेज़ करता है और इसे ज़्यादा लोगों और संगठनों तक फैलाता है, खासकर उन जगहों पर जहाँ engineering culture कमज़ोर है।

अच्छे बनाम खराब इंजीनियरों को और ताकतवर बनाना

  • व्यापक सहमति है कि AI एक force multiplier है: अच्छे इंजीनियर तेज़ हो जाते हैं; कमज़ोर लोग कहीं ज़्यादा नुकसान, कहीं ज़्यादा तेज़ी से करते हैं।
  • “खराब” से अक्सर मतलब होता है: architectural sense का अभाव, ownership का अभाव, invariants, backpressure, performance, या complexity पर ध्यान न देना।
  • AI के साथ एक कमज़ोर इंजीनियर code review को slop से भर सकता है और उन लोगों को overwhelm कर सकता है जो वास्तव में system को समझते हैं।

प्रक्रिया, समीक्षा, और प्रबंधन की गतिशीलता

  • पारंपरिक safeguards (छोटे PRs, code review, tests, QA) AI-स्तर के throughput के लिए नहीं बने थे; reviewers bottleneck बन जाते हैं।
  • कुछ कंपनियाँ AI usage को खुलकर reward कर रही हैं (token spend, work का AI %, PR count), जिससे समझ के बजाय volume को बढ़ावा मिलता है।
  • AI के साथ अच्छी practice को इस तरह बताया गया है: agents को सीमित रखें, बदलाव छोटे रखें, मानव मानसिक मॉडल बनाए रखें, और review व tooling में भारी निवेश करें। कई संगठन इसका उल्टा कर रहे हैं।

नौकरियाँ, “मध्य वर्ग” SWE, और pipeline

  • AI, offshoring, और oversupply के साथ junior/mid-level भूमिकाएँ सिकुड़ती जा रही हैं, जिससे भविष्य के senior तैयार करना कठिन हो रहा है—इस पर गहरी चिंता है।
  • कुछ लोगों का तर्क है कि यह क्षेत्र winner-take-all बनता जा रहा है: कुछ असाधारण लोग plus AI बड़ी teams की जगह ले सकते हैं; अन्य कहते हैं कि software की मांग अभी भी बहुत बड़ी है और काम गायब नहीं होगा, बस बदल जाएगा।
  • कारण-परिणाम पर असहमति है: कुछ लोग LLMs को दोष देते हैं, तो कुछ interest rates, hiring practices, immigration, और लंबे समय से mentorship की कमी को।

लोग वास्तव में AI का उपयोग कैसे कर रहे हैं

  • कई senior engineers बताते हैं कि वे AI का भारी उपयोग करते हैं, लेकिन कड़े नियंत्रण के साथ: boilerplate, refactors, tests, और design exploration के लिए, न कि एक autonomous coder की तरह।
  • अन्य लोग बताते हैं कि management हर जगह “AI first” अनिवार्य कर रहा है, जिससे vibe-coded products बन रहे हैं जिन्हें कोई पूरी तरह समझता नहीं।

लंबी अवधि की चिंताएँ

  • कौशल के क्षरण (“cognitive surrender”) और समझ खोने का डर, क्योंकि लोग सोचने का काम agents को सौंप रहे हैं।
  • कुछ लोग इसे एक बड़े रुझान का हिस्सा मानते हैं: consolidation, technofeudalism, और पेशेवर मध्य वर्ग का ढहना; जबकि अन्य इसे बस एक और tooling shift मानते हैं जो practices के साथ तालमेल बैठने पर स्थिर हो जाएगा।