AI के साथ काम करना कोडिंग से ज़्यादा नेतृत्व जैसा महसूस होता है

बड़े भाषा मॉडल को कोडिंग सहायक के रूप में इस्तेमाल करने पर इंजीनियर इस काम की तुलना पारंपरिक प्रोग्रामिंग से कम और प्रबंधन से ज़्यादा करने लगे हैं: लक्ष्य तय करना, काम सौंपना, और तेज़ लेकिन अविश्वसनीय “जूनियर ठेकेदारों” के झुंड से आए आउटपुट की समीक्षा करना। कुछ लोग मानते हैं कि इससे प्रोजेक्ट या लोगों के प्रबंधन का अनुभव रखने वालों को लाभ मिलता है, जबकि दूसरे कहते हैं कि गहरी तकनीकी समझ और पारंपरिक इंजीनियरिंग अनुशासन उतना ही ज़रूरी है, और AI को एक शक्तिशाली लेकिन त्रुटिप्रवण उपकरण की तरह ही देखना चाहिए। इस बहस के पीछे तकनीकी ऋण बढ़ने, मॉडलों को अनावश्यक रूप से मानवीय समझने, और AI पर निर्भरता से सॉफ़्टवेयर गुणवत्ता तथा इंजीनियरिंग करियर पथों पर पड़ने वाले प्रभावों की चिंताएँ हैं।

AI-कोडिंग “कैसी लगती है”

  • कई लोगों को AI-सहायता से कोडिंग, हाथों-हाथ कोड लिखने की तुलना में प्रबंधन के ज़्यादा करीब लगती है: काम सौंपना, प्रगति पर नज़र रखना, और दिशा सुधारना।
  • कुछ लोग तर्क देते हैं कि यह अब भी कोडिंग जैसा ही लगता है: वही मानसिक मॉडल, वही आर्किटेक्चर, और वही निचले-स्तर की चिंताएँ, बस टाइपिंग कम होती है।
  • कुछ लोग वैकल्पिक रूपक सुझाते हैं: फ़िल्म का निर्देशन, ऑर्केस्ट्रेशन, ठेकेदारों का प्रबंधन, इंटर्नों की निगरानी, या एक नौकरशाही से निपटना।

नेतृत्व बनाम प्रबंधन बहस

  • कई टिप्पणीकार ज़ोर देते हैं कि नेतृत्व मूलतः लोगों से जुड़ा है (दृष्टि, प्रेरणा, पारस्परिक प्रभाव), इसलिए LLM के साथ काम को नेतृत्व नहीं कहा जा सकता।
  • कुछ लोग “नेतृत्व” शब्द का ढीले अर्थ में उपयोग करते हैं: उच्च-स्तरीय दिशा देना, लक्ष्य तय करना, कामों को तोड़ना, कई एजेंटों का समन्वय करना।
  • एक आम बीच का दृष्टिकोण यह है कि LLMs के साथ काम करना प्रोडक्ट/टेक लीड के काम जैसा है, लेकिन उसके सामाजिक/भावनात्मक घटक हटाकर।

कौन-सी कौशलें मायने रखती हैं

  • प्रॉम्प्टिंग की बार-बार तुलना की जाती है:
    • आवश्यकताएँ एकत्र करने और स्वीकृति मानदंडों से।
    • कार्य-अवंटन, गुणवत्ता-चौकियाँ, और अपवाद-प्रबंधन से।
    • “कटोरा” डिज़ाइन करने से, जो “पानी” (LLM आउटपुट) को सीमित करता है।
  • कुछ लोगों का दावा है कि प्रबंधन या प्रक्रिया-डिज़ाइन का अनुभव रखने वाले लोग बेहतर परिणाम पाते हैं; दूसरों का अनुभव इसके उलट है।
  • प्रभावी उपयोग के लिए एक मज़बूत मानसिक मॉडल बनाए रखना, आउटपुट की समीक्षा करना, और LLMs को सीमित-कार्य उपकरण मानना ज़रूरी है, न कि पूरी तरह स्वायत्त कोडर।

विश्वसनीयता, स्लॉप, और तकनीकी ऋण

  • “वाइबकोडिंग” को लेकर कड़ी चिंताएँ हैं: AI आउटपुट को बिना सोचे स्वीकार करना, और बहुत बड़ी मात्रा में निम्न-गुणवत्ता का कोड तथा तकनीकी दिवालियापन पैदा करना।
  • किस्सों में ऐसे नेताओं का वर्णन है जिनकी कोडिंग पृष्ठभूमि नहीं है, जो AI पर बिना सवाल किए भरोसा करते हैं, दसियों हज़ार पंक्तियों का टूटा हुआ कोड बनवाते हैं, और परियोजनाओं को पटरी से उतार देते हैं।
  • इसके विपरीत उदाहरण तब सफलता दिखाते हैं जब AI को तेज़ लेकिन गलती-प्रवण जूनियर की तरह लिया जाता है: छोटे काम, सख़्त समीक्षा, परीक्षण, और सुरक्षा-घेरे।

काम और करियर पर प्रभाव

  • कुछ लोग खुद को सशक्त महसूस करते हैं: तेज़ पुनरावृत्ति, कम उबाऊ काम, आर्किटेक्चर और समस्या-परिभाषा पर अधिक ध्यान।
  • कुछ लोग हाथों-हाथ कोडिंग के आनंद के खोने का शोक मनाते हैं, और इसे एक स्थायी प्रबंधन-जैसे काम में बदलाव के रूप में देखते हैं जिसे वे कभी नहीं चाहते थे।
  • कई लोग नोट करते हैं कि dev टीमों की भर्ती कम हुई है या विस्तार रुक गया है, क्योंकि LLMs अधिक आउटपुट कवर कर रहे हैं।
  • इस बात पर असहमति है कि क्या LLMs कमजोर devs को ऊपर उठाकर और शीर्ष प्रतिभा के प्रभाव को कम करके “समानता” लाते हैं, या फिर मौजूदा कौशल-अंतर को और बढ़ाते हैं।

मानवीकरण और सीमाएँ

  • कई लोग LLMs को इंसान मानने से सावधान करते हैं: उनमें agency नहीं है, morale नहीं है, और करियर का दांव नहीं है।
  • LLMs का प्रबंधन वास्तविक नेतृत्व के कठिन हिस्सों से मुक्त होता है: भावनाएँ, टकराव, retention, और मानव परिणामों के लिए जवाबदेही।