इंजीनियर इतिहास से सीखने से बचने के लिए कुछ भी कर लेंगे
सॉफ़्टवेयर की AI “agents” के प्रति बढ़ती रुचि परियोजना प्रबंधन और इंजीनियरिंग जैसी पुरानी विधाओं से तुलना को जन्म दे रही है, और कई लोग तर्क दे रहे हैं कि requirements, coordination, और risk के लिए मौजूद तरीकों को नज़रअंदाज़ करके उन्हें नए नाम के तहत फिर से गढ़ा जा रहा है। टिप्पणीकर्ता इस पर बहस करते हैं कि क्या अधिकांश सॉफ़्टवेयर डेवलपर “engineer” का शीर्षक पाने के योग्य हैं, और कड़े लाइसेंस, safety margins, तथा ऐतिहासिक case studies वाले क्षेत्रों की तुलना उस tech संस्कृति से करते हैं जो novelty, hype, और VC‑चालित प्रयोग को पुरस्कृत करती है। दूसरे लोग मानते हैं कि tools को फिर से गढ़ना सचमुच आनंददायक और कभी‑कभी उपयोगी होता है, लेकिन चेतावनी देते हैं कि सॉफ़्टवेयर को ऐतिहासिक और cross-disciplinary सबकों से अलग मानना नाज़ुक प्रणालियों और टाले जा सकने वाली विफलताओं की ओर ले जाता है.
प्रोत्साहन, हाइप, और “नवीनता”
- कई टिप्पणियाँ सहमत हैं कि बड़ा पैसा उन चीज़ों की ओर बहता है जिन्हें नया और अत्याधुनिक बताकर बाज़ार में उतारा जाता है, न कि ज्ञात अनुशासनों को सही ढंग से लागू करने की ओर।
- VC और IPO की गतिशीलता को लंबे समय तक चलने वाली “सब्सिडियों” के रूप में पेश किया गया है, जो संदिग्ध मॉडलों को तब तक सहारा देती हैं जब तक व्यापक आर्थिक दर्द सामने नहीं आता।
- कुछ लोग AI/agent हाइप को इसी गतिशीलता का एक और दौर मानते हैं, जिसमें लोग नई सनक पर अपने पुराने पसंदीदा तरीकों को चिपका देते हैं।
क्या सॉफ़्टवेयर डेवलपर वाकई इंजीनियर होते हैं?
- इस पर तेज़ असहमति है कि क्या सॉफ़्टवेयर डेवलपर “इंजीनियर” कहलाने के योग्य हैं।
- एक पक्ष: इंजीनियरिंग की परिभाषा औपचारिक शिक्षा, लाइसेंसिंग, पेशेवर और नैतिक मानकों, तथा सुरक्षा‑महत्वपूर्ण ज़िम्मेदारी से होती है; प्रोग्रामरों ने बिना उस कठोरता के यह उपाधि अपना ली।
- विरोधी मत: बहुत से “असली” इंजीनियर इस उपाधि की परवाह नहीं करते; इंजीनियरिंग अधिकतर एक मानसिकता है; कुछ अनुभवजन्य मतदान यह भी सुझाते हैं कि अन्य अनुशासन अक्सर सॉफ़्टवेयर को इंजीनियरिंग के रूप में स्वीकार करते हैं।
- कई लोग बताते हैं कि गैर‑सॉफ़्टवेयर इंजीनियरिंग में भी विफलताएँ और कमज़ोर जवाबदेही होती है; लाइसेंसिंग कोई सार्वभौमिक सुरक्षा कवच नहीं है।
इतिहास से सीखना (या न सीखना)
- कई लोगों का तर्क है कि ऐतिहासिक सबक को नज़रअंदाज़ करना एक सामान्य मानवीय प्रवृत्ति है, जो केवल इंजीनियरों तक सीमित नहीं है।
- अन्य लोग कहते हैं कि पारंपरिक इंजीनियरिंग अनुशासन विशेष रूप से पिछली विफलताओं से सीखाते हैं, जबकि सॉफ़्टवेयर संस्कृति पहले सिद्धांतों के आधार पर पुनराविष्कार को ज़्यादा महत्व देती है।
- कुछ लोग पुनराविष्कार का बचाव करते हैं, यह कहते हुए कि यह स्वभावतः मज़ेदार और शिक्षाप्रद है, और इस विचार से नाराज़ होते हैं कि केवल पिछली पीढ़ियों को ही चीज़ें “खोजने” का अधिकार था।
AI Agents और प्रबंधन की उपमाएँ
- कुछ टिप्पणीकार लेख की उपमा से सहमत हैं: LLM agents का समन्वय करना क्लासिक प्रबंधन, परियोजना योजना, और आवश्यकताओं के इंजीनियरिंग जैसा है।
- दूसरों का तर्क है कि agent का काम सचमुच नया है: token costs, drift, evaluation, और बिना common sense वाले अति‑शाब्दिक “workers” मानव टीमों से अलग हैं।
- एक प्रतिवाद यह कहता है कि ये अंतर काफी हद तक मौजूदा चिंताओं से मेल खाते हैं: समय और श्रम लागत, अपर्याप्त check-ins से होने वाला drift, और अत्यधिक शाब्दिक इंजीनियर।
प्रक्रिया: Waterfall, Agile, और specs
- कई टिप्पणियाँ इस विचार से सहमत हैं कि AI का प्रभावी उपयोग मुख्यतः अच्छी specifications पर निर्भर करता है; काम का बड़ा हिस्सा अग्रिम scoping में चला जाता है।
- कुछ लोग literal रूप से waterfall या PMBOK की वापसी के विरुद्ध चेतावनी देते हैं; वे मज़बूत requirements के साथ agile‑शैली के iteration को पसंद करते हैं।
- अन्य लोग ध्यान दिलाते हैं कि व्यवहार में जिसे “Agile” कहा जाता है, वह अक्सर उसके मूल विचारों को ही नज़रअंदाज़ करता है, जैसे work-in-progress को सीमित करना और context switching को कम करना, खासकर meeting‑heavy संस्कृतियों में।