मैं एक software engineer नहीं हूँ

• software engineer की पहचान को अस्वीकार करने की भावना 23 साल पहले मिली इस टिप्पणी से शुरू हुई कि “तुम अच्छे hacker हो, लेकिन engineer नहीं”
• agent paradigm ऐसा लगता है मानो non-deterministic program से deterministic होना चाहिए ऐसा program बनवाने का तरीका हो
• code पर भरोसा readability, समझ में आने की क्षमता, efficiency, reasoning की संभावना, और एक ही input पर एक ही output देने वाली reproducibility में है
• कार्यस्थल के agentic user flows और AI usage KPI ऐसे तरीके के रूप में देखे जाते हैं जो अच्छे code से ज़्यादा metrics और natural language input को आगे रखते हैं
• AI उद्योग का भविष्य-दर्शन software development को बदलने से आगे बढ़कर सोच पर ही moat बनाने की कल्पना जैसा दिखता है

---

Software Engineering और agent paradigm

• खुद को software engineer की पहचान से अलग रखने का रवैया 23 साल पहले एक सहकर्मी से यह सुनने के अनुभव से शुरू हुआ कि मैं “अच्छा hacker” हूँ, लेकिन engineer नहीं
• हाल का “नया agent paradigm” ऐसा दिखता है जैसे Waylon Smithers जैसी मशीन से गलती न करने को कहा जाए, और फिर उसके नतीजे को expert software engineering के रूप में पेश किया जाए
• ऐसे program से, जो non-deterministic output देता है, deterministic होना चाहिए ऐसे program लिखने का तरीका software engineering के भविष्य के रूप में पेश किया जा रहा है
• code के बारे में बुनियादी विश्वास अब भी readability, समझ में आने की क्षमता, efficiency, पर्याप्त reasoning की संभावना, और एक ही input पर एक ही output देने वाली reproducibility में है
• वास्तविक systems में reproducibility पहले से ही कठिन है, इसलिए code लिखना खुद “खिसकती रेत” पर खड़ा नहीं होना चाहिए
• combined subquery और aggregate expression से बने view का query performance पर असर, inversion of control, और functionality को methods से अलग करके स्वतंत्र रूप से testable बनाने वाला design जैसी बारीकियाँ अब भी महत्वपूर्ण हैं

AI-केंद्रित development flow पर अविश्वास

• कार्यस्थल पर मांगे जाने वाले agentic user flows का अर्थ स्पष्ट नहीं है, और यह मानना भी मुश्किल है कि natural language input textbox छोटे विकल्प-समूह में से चुनने के तरीके से बेहतर क्यों है
• software development lifecycle के हर चरण में agents लगाने की कोशिश हो रही है, और यह भी कहा जाता है कि हाथ से code लिखना COBOL लिखने जैसा माना जाएगा
• agents संदर्भ के अनुसार output का मूल्यांकन करने वाले LLM prompt wrapper जैसे लगते हैं, और वास्तविक output अक्सर अपर्याप्त महसूस होता है
• AI usage को KPI के रूप में track किया जाता है, लेकिन पिछले 23 सालों में KPI से ज़्यादा महत्वपूर्ण अच्छा code लिखना रहा है
• पहले लिखे गए code के बारे में कहा गया था कि वह “मानो किसी mathematics major ने लिखा हो”, और इसे एक बड़ी प्रशंसा की तरह लिया गया
• उसी कार्यस्थल के एक staff software engineer के implementation में explicit interface नहीं था, DI container को public static member के रूप में expose किया गया था, और CSV configuration का उपयोग इसलिए किया गया था कि “business users के लिए इस्तेमाल करना आसान है”, न कि इसलिए कि वह tabular data के लिए उपयुक्त था
• उस implementation को बहुत खराब कहने पर समस्या खड़ी हो गई, और इस घटना ने व्यंग्यात्मक रूप से इस निष्कर्ष तक पहुंचाया कि शायद मैं software engineer ही नहीं हूँ
• जिन लोगों को मैं बुद्धिमान मानता हूँ उनसे दो बार यह सलाह सुन चुका हूँ कि AI software लिखने और उद्योग के भविष्य का हिस्सा है, इसलिए उसे स्वीकार करना चाहिए, लेकिन यह रवैया लापरवाह लगता है
• जिन AI software का मैंने उपयोग किया, वे सोचने की प्रक्रिया में मदद करने के बजाय उसे बाधित करते या सक्रिय रूप से अपने कब्ज़े में लेते हुए लगे, और ऐसी co-option चिंताजनक है
• बड़ी AI कंपनियों के नेता software development उद्योग के भविष्य के बारे में उत्साह से बात करते हैं, कहते हैं कि उनके products का रोजगार पर devastating effects होगा, और “intelligence too cheap to meter” जैसी अभिव्यक्ति इस्तेमाल करते हैं
• वह भविष्य इसलिए भयावह है कि मशीनें सबको paperclip में नहीं बदल देंगी, बल्कि इसलिए कि वे सोच पर ही moat खड़ी करने की कल्पना कर रहे हैं

[GN⁺]

Lobste.rs प्रतिक्रियाएँ

• Mary Walton की W. Edwards Deming पर लिखी किताब में ऐसा एक किस्सा आता है। एक फ़ैक्टरी कर्मचारी की मशीन खराब हो गई थी और उससे सिर्फ़ खराब माल ही बन रहा था। उसने रिपोर्ट किया, लेकिन मरम्मत में देर हुई, तो वह खुद ठीक करने की कोशिश कर रहा था, तभी सुपरवाइज़र आया और कहा कि बस मशीन चलाते रहो।
  आख़िरकार यह दरअसल “खराब माल बनाते रहो” वाला निर्देश था, और उसने कहा, “फिर एक कामगार के रूप में मेरा स्वाभिमान कहाँ गया? अगर सुपरवाइज़र मुझे कम-से-कम मशीन जितना सम्मान दे, तो बेहतर होगा।” वह खराब माल बनाकर उसके पैसे नहीं लेना चाहता था।

  • क्या यह वही किताब है? https://deming.org/the-deming-management-method-by-mary-walton/
    क्या यह पढ़ने लायक है?

• लेखक की तुलना में मेरा अनुभव काफ़ी कम है, लेकिन करियर के शुरुआती दौर में CSV की कई समस्याओं की वजह से मैंने कुछ कामकाजी workflows को CSV से बाहर ले जाने की कोशिश की थी, और तब जवाब मिला था कि “बिज़नेस workflows के लिए CSV ज़्यादा आसान है।”
  उस समय मुझे भी, लेखक की तरह, यह जवाब बहुत ख़राब लगा था, लेकिन समय बीतने के साथ मुझे लगने लगा कि वह फ़ैसला शायद काफ़ी हद तक सही था।

• अगर “23 साल पहले किसी ने कहा था कि तुम software engineer नहीं हो” जैसी बेवकूफ़ाना राय आज भी आपको परेशान कर रही है, तो मेरा मानना है कि समाधान यह है कि दूसरों की राय को इतना महत्व देना बंद किया जाए।
  अगर नियोक्ता की मूर्खतापूर्ण नीतियाँ या सहकर्मियों की ईमानदारी की कमी आपको परेशान करती है, तो दूसरी कंपनी ढूँढ लीजिए। दुनिया में 8 अरब लोग हैं, उनमें से बहुत से लोग चाहते हैं कि कंप्यूटर उनके लिए कुछ काम करे, और उनमें से बहुत से लोग programming की कीमत भी चुकाते हैं।
  यह कुछ ऐसा सुनाई देता है जैसे, “जब मैंने पहली बार बेकरी में काम किया, तो एक सहकर्मी ने कहा कि croissant दरअसल Big Dairy की साज़िश है ताकि ज़्यादा butter बिके, और मैंने उसे अपनी पूरी worldview की नींव बना लिया और तय कर लिया कि मैं फिर कभी बेकरी में काम नहीं कर सकता।” अगर लेखक की उम्र न दी गई होती, तो मैं उसे कोई हाई-स्कूल छात्र समझता, लेकिन अगर वह 23 साल पुरानी बात कर रहा है, तो वह उस उम्र से काफ़ी आगे निकल चुका होगा।

  • मैं सिर्फ़ अंदाज़ा लगा सकता हूँ कि इस पोस्ट को flag क्यों किया जा रहा है, लेकिन उस अंदाज़े को लेकर मुझे काफ़ी भरोसा है। फिर भी असली समस्या सिर्फ़ यह नहीं है कि लहजा अनमना या असहज है, बल्कि यह है कि बात ने लेख के मुख्य तर्क को ही मिस कर दिया।
    लेख का मतलब यह नहीं है कि लेखक सचमुच software engineer नहीं है; संभवतः वह लंबे समय तक इसी title के साथ काम करता रहा है। बात ज़्यादा यह है कि वह खुद को उस title से अलग कर रहा है, और यह इस उद्योग के बदल चुके रूप के प्रति उसकी एक प्रतिक्रिया है।
    वह मानो कह रहा है, “यह engineering नहीं, बकवास है। अगर software engineer होने का मतलब यही है, तो मैं वह नहीं हूँ।”
    निजी तौर पर मैं इस भावना से सहमत हूँ। कई बार मुझे लगा है कि software development में हम जो करते हैं, उसे “engineering” कहना दूसरे engineering क्षेत्रों का अपमान है। ख़ासकर इसलिए कि हम ऐसा कहते तो हैं, लेकिन जो चीज़ें हम बनाते हैं, उनकी परवाह उतनी नहीं करते।
    civil engineer पुल के गिरने जैसी घटना को बेहद गंभीरता से लेते हैं, और जब कोई बड़ा ढहाव होता है, तो पूरा उद्योग प्रतिक्रिया देता है, उससे सीखता है, और कोशिश करता है कि ऐसा दोबारा न हो। इसके उलट, तथाकथित software “engineer” पूरी तरह रोकी जा सकने वाली वजहों से production environment को बार-बार ठप कर सकते हैं, और फिर भी उसे अपने résumé में सफलता की कहानी की तरह लिख सकते हैं।
    मौजूदा software engineering की दिशा—यानी वास्तव में deploy होने वाले code की परवाह न करना और उसे लिखने का काम किसी दूसरी “intelligence” को सौंप देना—उस पर मेरी राय आप शायद समझ ही सकते हैं।
    मैं यह दावा नहीं करना चाहता कि मुझे पूरी तरह समझ है कि यह सब क्यों हो रहा है, या मेरे पास इसका पूरा समाधान है। लेकिन कम-से-कम हमें इसे कोई गंभीर काम, यानी “engineering”, होने का दिखावा तो नहीं करना चाहिए।